Cloud Networking Hyper or Reality?

A colleague of mine pointed out a new post by Jayshree Ullal from Arista Networks on Cloud Networking Reflections. I can’t help to comment on a few things for my own sanity.

Prediction #1: The rise in dense virtualization is pushing the scale of cloud networking.

Evaluation #1: True

IT is very “trend” oriented, meaning sometimes the complexity of operating a distributed system are people are too busy look deep into the problem for themselves and instead lean on the communities of marketing wizards to make a decision for them. Despite VMWare’s success, hardware virtualization makes up a very small part of the worldwide server base, which is estimated at around 32M servers [1]. I predict within a few short years a reversal in this trend, which peaked around 2008 for several reasons.

  • One is the realization that the “hardware virtualization” tax grows increasingly with I/O, a very significant problem as we move into the era of “Big Data”. The reality is as we move to more interactive and social driven applications the OS container is not as crucial as it is in a generalized client/server model. Application developers need to continuously deal with higher degrees of scalability, application flexibility, improved reliability, and faster development cycles. Using techniques like Lean software development and Continuous Delivery, application developers can get a Minimal Viable Product out the door in weeks sometimes days.
  • Two, the age of  “Many Task Computing” is upon us and will eventually sweep away the brain-dead apps and the entire overhead that comes with supporting multiple thick-containers. I say lets get down with LXC or better yet Illumos Zones, which gives us the namespace isolation without the SYSCALL overhead.
  • Three, heterogeneous computing is crucial for interactive and engaging applications. Virtualization hides this at the wrong level; we need the programming abstractions such as OpenCL/WebCL for dealing with specialization in vector programming and floating-point support via GPU’s. Even micro-servers will have a role to play here allowing a much finer grain of control while still improving power efficiency.

Its not “dense virtualization” pushing the scale of cloud networking, it is the changing patterns of the way applications are built and used. This will unfortunately continue to change the landscape of both systems design as well as network.

My Advice: Designers will finally wake up and stop being forced into this “hyper-virtualized” compute arbitrage soup and engineer application services to exploit heterogeneous computing instead of being constrained by a primitive and unnecessary abstraction layer. In the mean time, ask your developers to spend the time to build scalable platform services with proper interfaces to durable and volatile storage, memory and compute. In this way you isolate yourself from specific implementations removing the burden of supporting these runaway applications.

Prediction #2: “Fabric” has become the marketing buzzword in switching architectures from vendors trying to distinguish themselves.

Evaluation #2: Half-True.

I think the point of having “specialized” fabrics is a side effect of the scalability limits of 1990’s based network design, protocols and interconnect strategies. Specialized and proprietary fabrics have been around for years, Think Machines, Cray, SGI and Alpha all needed to deal with scalability limits connecting memory and compute together. Today’s data centers are an extension to this and have become modern super-computers connected together (i.e. a fabric)

Generally the current constraints and capabilities of technology today have forced a “rethink” on how to optimize network design for a different set of problems. There is nothing terribly shocking here unless you believe that current approaches are satisfactory. If the current architectures are satisfactory, why do we have so much confusion on whether to use L2 multi-pathing or L3 ECMP? Why is there not ONE methodology for scaling networks? Well I’ll tell you if you haven’t figured it out. Its because the current set of technologies ARE constrained and lack the capabilities necessary for truly building properly designed networks for future workloads.

The beauty of Arista’s approach is we can scale and manage two to three times better with standards. I fail to understand the need for vendor-specific proprietary tags for active multipathing when standards-based MLAG at Layer 2 or ECMP at Layer 3 (and future TRILL) resolves the challenges of scale in cloud networks. 

Scale 2x to 3x better with standards? How about 10x or better yet 50x? Really 2-3x improvement in anything is statistically insignificant and you are still left with corner cases, which absolutely grind your business to a halt. Pointing out MLAG is better than TRILL or SPB or ECMP is better than whatever is not the point. I mean really, how many tags do we need in a frame anyway and what the hell with VXLAN and NVGRE? Additional data-plane bits are not the answer, we need to rethink the layering model, address architecture and error and flow control mechanisms.

There is no solution unless you break down the problem, layer by layer until you remove all of the elements down to just the invariants. Its possible that is the direction of OpenFlow/SDN, the only problem maybe that completely destroys the layers entirely but maybe that’s the only way to build them back up the right way.

BTW. There is nothing really special about saying “standards”, after all TCP/IP itself was a rogue entry in the standards work (INWG 96) so its another accidental architecture that happened to work.. for a time!

My Advice: For those who have complete and utter autonomy, treat the DC as a giant computer which should be designed to meet the goals of your business within the capabilities and constraints of todays technology. Once you figure it out, you can use the same techniques in software to OpenSource your innovation making it generally feasible for others to enter the market (if you care about supply chain). For those who don’t, ask your vendors and standards bodies why they can’t deliver a single architecture which doesn’t continuously violate the invariances by adding tags, encaps, bits, etc..

Prediction #4: Commercially available silicon offers significant power, performance and scale benefits over traditional ASIC designs.

Evaluation #4: Very true.

Yea no surprise here, but its not as simple as just picking a chip off the shelf. When designing something as complex as an ASIC, you have to make certain tradeoffs. Feature sets build up over time, and it takes time to move back to a leaner model of primitive services with exceptional performance. There is no difference between an ASIC designer working for a fabless semiconductor company spinning out wafers from TSMC and a home grown approach, it is in the details of the design and implementation with all of the sacrifices one makes when choosing how to allocate resources.

My Advice: Don’t make decisions based on who makes the ASIC but what can be leveraged to build a balanced and flexible system. The reality is there is more to uncover than just building ASIC’s, for instance how about a simpler data plane model which would allow us to create cheaper and higher performance ASIC’s?

Prediction # 5: FCoE adoption has been slow and not lived up to its marketing hype.

Evaluation # 5: True.

“A key criterion for using 10GbE in storage applications is having switches with adequate packet buffering that can cope with speed mismatches to avoid packet loss and balance performance, “

This is also misleading as it compares FCOE with FC with 10GE sales as a way of dismissing a viable technology. But the reality is that the workload pattern changed moving the focus from interconnect to interface.

From an application development point of view, interfacing with storage at a LUN or “block” level is incredibly limited. It’s simply just not the right level of abstraction, which is why we started to move to NAS, or “file” based approaches and even converging the reemergence of content based and distributed object stores.

Believe me, developers don’t give a care if there is an FC backend or FCOE, it is irrelevant, the issue is performance. When you have a SAN based system you are dealing with a system balanced for dealing with different patterns of data access, reliability and coherency. This might be exactly what you don’t want, you may be very write intensive or read intensive and require a different set of properties than current SAN arrays provide.

The point about adding buffering to the equation not only makes things worse, but also increases the cost of the network substantially. Firstly the queues can build up very quickly especially at higher clock speeds and the impact on TCP flow-control is a serious issue. I am sure the story is not over and we will see different ways of dealing with this problem in the future. You might want to look a little closer at FC protocols and see if you can see any familiarity with TRILL.

My Advice: Forget the hype of Hadoop and concentrate on isolating the workload patterns that impact your traffic matrix. Concentrate on what the expectations of the protocols are, how to handle error and flow control, mobility, isolation, security and addressing. Develop a fundamental understanding of how to impart fair scheduling in your system to deal with demand floods, partitioning events and chaotic events. Turns out a proper “load shedding” capability can go along way in sustaining system integrity.

Yes I know, thats a lot of opaque nonsense, and while many advantages exist for businesses which choose to utilize the classical models, there are still many problems in dealing with the accidental architecture of todays networks. The future is not about what we know today, but what we can discover and learn from our mistakes once you realize we made them.

While I do work at Cisco Systems as a Technical Leader in the DC Group, these thoughts are my own and don’t necessarily represent those of my employer.

[1] http://www.mediafire.com/file/zzqna34282frr2f/koomeydatacenterelectuse2011finalversion.pdf

 

A look back at Internet History

While doing research on the evolution of protocols I came across an interesting documentary film about the history of the ARPANET and birth of the Internet[1]. Definitely a must watch if you haven’t seen it to see how our industry was first envisioned by the early ARPAnet engineers.

Some reflection on the ideas which even today have not fully lived up with the pre-Internet expectations.

Applications moves across computers transparently, while the network provides automatic load leveling to avoid congestion. Users login to the network without care of where the computation is taking place and distributed operating systems decide which computer can best perform the job.

Files can be backed up on more than one site so files are always accessible and retrievable. People, data, computers, circuits, protocols and facilities are all resources which allow people to work together and collaborate.

Computing centers can be built with specialized form and function, data communication evolve allowing every terminal, computer to interconnect. Connect at messages not at circuits.

Some day you can store 100,000 books for $1MM

Many realize a big problem in the Internet (really not an Internet but a bunch of concatenated IP networks or catenet) has been around the adoption of TCP/IP by DARPA in the early days. Alex McKenzie from BBN has a great history on the discussions that progressed from ARPANet NCP to INWG-96[2]

Even after the international body selected INWG-96 for testing amongst the emerging networks such as ARPANET and Cyclades. DARPA adopted TCP/IP, the somewhat defective version of INWG 39 that lacked a proper addressing model, incorporated an ineffective congestion control system, and failed to clearly distinguish the end-to-end TCP layer from the IP layer (the infamous TCP “pseudo-header” ties TCP sessions to specific network interfaces and sub-networks.) The effort to correct the TCP/IP deficiencies, ISO’s Open System Interconnect project, became mired in politics and missed deadline after deadline, ultimately missing the window for an Internet-wide upgrade, and now we’ve landed in the IPv6 conversion.[3]

There are many ideas how to solve the problems in TCP/IP some are under the Clean-Slate programs such as GENI, FIND, etc.. Some see hacking the datalink layer, others RINA and yet others see OpenFlow as the framework to fix the structural problems with TCP/IP. A good overview of the problems and the possible solutions was just published by Time Warner Cable Research, Remaking the Internet: Taking Network Architecture to the Next Level[4]

All of the current protocol work masks the problems of the network and internetwork layer (figure 1). This creates complexity, adds to the cost of the network and ultimately diminishes the use of the network I.e. Such as the move to cloud computing.

Clearly this problem exists, its not going away and in fact is getting worse every day as the amount of smart connected devices grows. Eventually someone will need to push this industry into proper theory and engineering after 40yrs of craft. This is not to say it is easy, it won’t be. Many still have a hard time seeing beyond TCP/IP as its the only protocol they have known.

Clean-Slate opportunity is all around for those willing and able to take on this endeavor. We have learned a alot in the past 4 decades, TCP was under development for almost a decade and implemented in less than 1 year from specification to implementation . I think its time for a change.

Figure 1
  1. http://video.google.com/videoplay?docid=4989933629762859961
  2. http://alexmckenzie.weebly.com/inwg-and-the-conception-of-the-internet-an-eyewitness-account.html
  3. http://www.hightechforum.org/the-internets-first-turning-point/
  4. http://www.twcresearchprogram.com/pdf/TWC_Bennett_v3.pdf

Facebook announces HipHop for PHP

Companies like Facebook not only see their core values centered around delivering products and services which “impact” people but also technology. Besides the OSS contributions to Memcached, Hive, Cassandra and Thrift, facebook team announced HipHop for PHP.

Mark Zuckerberg adopted OSS early on utilizing Memcached, Apache HTTP, MySql and PHP in his Harvard dorm to build the first Facebook site. Facebook is now comprised of millions of lines of PHP code. PHP provides Facebook with an expressive well understood programming environment for quickly generating new web content.

But of course due to their size and scale ( 400 Billion page views per month servicing 350 million people) they were faced with the constraints of an interpreted scripting language and its impact on CPU and memory.

PHP and ZEND runtime are highly optimize but at large scales the inefficiencies are quite costly. HipHop for PHP is a code generation technology with static analysis and transformation capabilities to turn PHP source code into c++ source code able to be compiled by g++. HipHop allows Facebook to run 50% less CPU with equal traffic on their web tier and 30% less CPU with 2x traffic on their application tier. Thats a significant number in terms of 10s of thousands of servers.

By allowing developers to continue to use PHP with its common syntax, tools and debugging, they don’t have to learn another language and deal with changing millions of lines of code (although who knows if that will be inevitable). Developers can code and debug with their natural toolsets and dynamic runtime while in development and than promote their code into a compiled set pushed out to the production systems.

HipHop is a great example of the ingenuity of the developer community to think outside the box and concentrate on delivering value to the business. I am sure their efforts will benefit the community of PHP developers at large in a profound way.

Bravo Facebook team..

Distributed Computing

We can all agree that we are in the midst of a shift in the practice of information technology delivery, fueled by economization, global interconnection and changes in both computer and social sciences.

Although this can be considered revolutionary change in some circumstances, it is rooted in problems known almost 20 years ago. For those of you interested in the history and a very clairvoyant look at this current shift read “A Note on Distributed Computing, “. This paper concentrates on integration of the current language model to address the issues of latency, concurrency and partitioning in distributed systems.

“They [Programmers[ look at the programming interfaces and decide that the problem is that the programming model is not close enough to whatever programming model is currently in vogue..A furious bout of language and protocol design takes place and a new distributed computing paradigm is announced that is compliant with the latest programming model. After several years, the percentage of distributed applications is discovered not to have increased significantly, and the cycle begins anew.”

This paper concludes with very specific advice:

“Differences in latency, memory access, partial failure, and concurrency make merging of the computational models of local and distributed computing both unwise to attempt and unable to succeed.”

Now there are a few things not known back in 1994 including where exactly Moores Law would take us, language development, ubiquitous device access and the scale at which the Internet has grown but when you examine the issues discovered by the likes of Google, Amazon, Facebook, etc… you recognize that the cycle has indeed begun anew.

The interesting part is the velocity of innovation to solve these problems along with the cooperative nature of open source software has fueled an even broader manifestation of change and companies of all sizes can help contribute to the greater good of open software, enabling communities of interest to develop and share information in an open, yet secure way.

[1] Waldo, Wyant, Wollrath, Kendall, Sun Microsystems, 1994, SMLI TR-94-29

The Machines Are In Control

I am sitting here watching the markets break down as the Bulls run out of steam. Smart ones are collecting their profits as they scrape the bottom while putting on lots of protection.

But who really is in control?

Mathematical algorithms are firing off at a blistering pace, they hunt for alpha out in the open and even in the dark (see Dark Pools).. Technical trends are crossed driving bullish execution while the bears use counter strategy similar to a game of chess..

Markets swing back and forth sometimes 3..4% a day.

Every quarter companies need to show over the top growth, shrinking operational cost is fizzling as a good excuse as we look for concrete signs of a recovery.

The machines get bigger and wider and more connected they spread out sometimes reminiscent of a “shanty town”. There actually is a software design paradigm called The Big Ball of Mud.. The lesson? “It’s ugly, but it works for what ever reason”

Well lets see if the bears lose their grip and our systems can handle the options traffic as investors try and protect their value play with a downside PUT.

Amazon on the Enterprise

Last week I attended the AWS Cloud for the Enterprise Event held in NY and was not surprised to see a massive turnout for Dr. Vogels keynote and the following customer presentations.

I have been to the last three events held in NY and each time the crowds get larger, the participants become more enthusiastic and the level of innovation continues to accelerate at a mad pace.

Some of the customer representatives included Conde’ Naste Digital including Wired.com, Nasdaq OMX, Sony Music Entertainment, and New York Life. I thought the most compelling discussion was given by Michael Gordon, First VP New York Life where he discussed how he migrated his applications onto AWS in 2 weeks while translating capital expenditures to Amazon pay as you go model.

In a time where it costs the Enterprise business upwards of 1MM to even engage the IT organization and looking at 3-6month or longer implementation time-lines Amazon is showing how web-scaling can provide an effective approach for any kind of business even a hundred year old life insurance company.

Some of the other more poignant parts of the discussion included how the application development teams had to think differently about hosting their applications on EC2. Customers have to make some changes to the application architecture when running on virtualized hosts . Some of Amazons’ technologies like EBS and SimpleDB can be used for providing persistance and an effective caching layer for key/value pairs.

As Enterprises start to incorporate similar IaaS services within their own organizations app/dev teams will surely wind up reevaluating their architecture and finding alternative ways for accomplishing performance and scalability goals.. This is definitely a key point to understand and why its important for developers and infrastructure architects to take a blank slate approach in re architecting our business applications.

Emmergence of DataGrids to solve scaling problems

There is a great post at BigDataMatters discussing the emergence of Open Source Data Grids and the introduction of Infinispan 4.0.0 Beta 1.

The Infinispan site defines data grids as:

Data grids are highly concurrent distributed data structures. They typically allow you to address a large amount of memory and store data in a way that it is quick to access. They also tend to feature low latency retrieval, and maintain adequate copies across a network to provide resilience to server failure.

In the article Chris Wilk explains some of the challenges in data grid technologies around dynamic routing.

The reason that GigaSpaces suffers from this limitation is that it has a fixed space routing table at deployment time. The above scenario was described to Manik who said that Infinispan does not suffer from this restriction as it uses dynamic routing tables. Infinispan allows you to add any number of machines without incurring any down-time.

The spreading of data across many hosts is accomplished using different techniques but the point to take here is that altering the partition routing logic in mid-stream is very destructive to supporting distributed transactions. There are also many system level aspects which create inconsistencies including garbage collection and network overhead which could jeapordize the movement of dynamic objects between partitions.

Increasing the capacity of a data-grid to provide deterministic performance , robustness and consistency should be done by running a fixed amount of partitions and “moving” partition from one JVM to another newly started JVM. With GigaSpaces you can have 10 , 50 or 200 partitions used when starting the data-grid and have these running within a small amount of JVMs, later you can increase the amount when needed (manually or dynamically). You can re-balance the system and spread the partitions across all the existing JVMs. It is up to you to determine how far you want to scale the system which means you have total control on system behavior.

The routing mechanism with GigaSpaces will function without any problems and spread data across all  partitions as long as you have more unique keys than the amount of partitions. This should not be a problem with 99.99% of the cases.

The comparison ignores many other GigaSpaces features such as Mule integration , Event handling and data processing high-level building blocks , Web container and dynamic HTTP configuration , Service management , system management tools , performance (especially for single object operations , batch operations and local cache) , text search integration , massive amount of client support , large data support (up to several Tera data ) , large object support , Map-Reduce API , Scripting languages support (Java, .NET, C, Scala , Groovy…) , Cloud API support , schema evolution , etc….

Having new players is great and verifies that there is room for new vendors in this huge market for In-Memory-Data-Grid technologies on the cloud (private/public) – But it is important also to do the right comparison.

See more here:
http://www.gigaspaces.com/wiki/display/SBP/Capacity+Planning
http://www.gigaspaces.com/wiki/display/CCF/CCF4XAP+Documentation+Home

The Reencarnation of Enterprise Architecture Cast as a “Cloud”

What have we learned from ITIL, Zachman and Togaf? Now I don’t claim to be an expert in any of these models although I have researched them in the past and while fond of their utter intent, could not really figure out how to “operationalize” them while running a major production system. I have been through Six Sigma training from my days at BOFA and found the mathematical principals along with the DMAIC work flow extremely important for IT to measure their full understanding of the business.

So today, What is Information Technology? Is the IT group organized, trained, supported in order to fully execute on the mission at hand. Can they really transform into a service driven organization where they can effectively manage cost, capacity and business flexibility?

So I am going to highlight the constructs of what I call the “Enterprise Stack”. Utilizing all of the combined intelligence and research around large scale compute designs such as grids, clusters, farms and clouds we can setup the organization to adapt correctly to different demands of the business.

Enterprise Stack

There are three axis: Organizational Alignment, Archetypical Interfaces and Service Layers.

Organizational Alignment is about shifting the organization to focus on delivering a specific set of services which allow transparent access to workloads and resources.

Archetypical Interrfaces deals with the architecture as a whole providing different technology approaches to supporting the over arching application stack.

Service Layers divide up the technology boundaries based on Organizational Alignment. It is core to the delivery model of the SBU, PBU and IBU to cleanly segregate responsibilities across the service layers.

The thing to be aware of is that their is an implied circular reference here. IBU could be a Consumer of PaaS and SaaS services fundamentally to support their business. Each IBU is both a provider and consumer of the different organizations.

Enterprise Consumer

  • Can be the business itself or an external customer
  • Service Catalog Driven
  • Service Driven Management and Pricing
  • Qualitative and Quantitative Service Level Attributes

Below is an example set of responsibilities for each BU.

SPI

Archetypical Services are based on different technology capabilities

Archetypes

It is definitely a new age and despite the nay sayers IT is in the process of transforming into a much more efficient organization which can be driven at a higher velocity of change thanks to more effective computing models.