Infrastructure 2.0

Automate the Network!

2010-03-07T10:03:23Z

When VMware entered the production data center it was the beginning of a massive IT disruption with profound implications for careers, vendors and the next tech innovation cycle, driven by deep reductions in network operating expenses and equally uplifting increases in network flexibility and intelligence.

VMware set the stage for the multibillion dollar system virtualization category by allowing operating systems and applications to be easily set up and moved on top of commodity server hardware. They automated systems that had been requiring ever increasing amounts of manual labor as data centers grew ever more complex by creating an abstracting layer between software and hardware.

Check out the IDC slide referenced in the October, 2008 infrastructure 2.0 blog on “Virtualization, Cloud Computing and IT Diseconomies”. The market cap of VMware was to a great extent driven by the increasing proportions of management expense required for supporting ever more complex system infrastructures.

There is a similar (internal HP only, based on IDC data) slide showing the creeping opex menace growing every year to consume more than 50% of server costs. Also read "Server Management Costs Soar, Says IDC":

For every server that is purchased and installed, management costs increase exponentially. Matt Eastwood, vice president, enterprise server research for Framingham, Mass.,-based IDC says that a penny saved in initial cost is a dollar spent on management. "IT pros are always interested in getting the best deal that they can when they purchase new equipment. But what they are beginning to realize is that the cost of maintaining a server is five to seven times the purchase price."

- Brian Kraemer, SearchDataCenter.com Feb 2006

Now that VMware, Citrix and Microsoft have now declared war on manual labor and rising system management expense, it’s the network’s turn to get automated. At stake are scattered, multibillion dollar empires driven by complexity, expertise and black holes of arcane scripts, configurations and multi-step network management processes.

It all starts at the core, in the core network services addressed by the emerging DDI appliance category kicked off by Gartner last fall, then emanates into a host of initiatives (like virtualization and IPv6) that are slowed down (and incur heightened cost and risk) due to the persistence of complexity and manual processes required to simply keep networks available and secure as more IP addresses are added.

The IPAM diseconomies of scale discovered by Computerworld during the fall of 2008 was eerily reminiscent of the data discovered by IDC on rising server management costs. As networks grew, the costs of managing each IP address grew, creating the IPAM opex hockey stick.

Now that CIOs have discovered the power of system automation to break the bonds between software and hardware and automate once manual system processes, they will be looking for solutions that can break the bonds between the meaty address space (DNS, DHCP, IPAM, etc) and physical location enabling unprecedented breakthroughs in operating expense and risk, power savings and scalability. They will leverage the network like never before to take IT automation to new levels.

Network automation will start with the automation and integration of IPAM, DNS and DHCP and will spread from this waste-ridden meat space core into areas strategically bound by those manual processes. Look to announced partnerships between companies like Infoblox(my employer) in the DDI space and the likes of Riverbed, Cisco, Neustar (and the recent F5 and Infoblox announcement related to DNSSEC) to tackle a host of costs and challenges emanating from the network’s tired core.

IT is about to be radically transformed, not by cloud computing but by a wave of innovation that will make networks as powerful and nimble and economical as recently virtualized systems. And those virtualized systems will become more secure, more efficient and even more economical than ever before.

As system virtualization decoupled software and operating systems from the bonds of specialized dedicated hardware, network virtualization will decouple those systems from the limitations of specialized, dedicated locations.

Those who embrace network automation first will attain strategic advantage over their peers. Hence the recent announcements and breakthroughs by Cisco, Citrix, F5, Juniper, Riverbed, VMware and others, setting the stage for the inevitable transformation foreshadowed by the rise of system virtualization and the resultant shift in market caps between tired incumbents and the virtualization ecosystem.

You can follow my rants in real-time at Archimedius.

Microsoft Hops Into Infrastructure 2.0

2010-03-03T04:03:01Z

Microsoft Dynamic Infrastructure Toolkit for Systems Center (DIT-SC) is hopping forward, literally, into the network. With or without established standards, this dog is going to hunt.

It takes time to develop standards, something we often overlook. When the foundational standards upon which the Internet were being developed there were (almost) no users, no broadband, and no real urgency to get something available. The adoption of disruptive, highly volatile technologies such as virtualization and cloud computing result in an environment in which today’s standards groups are not afforded the luxury of time. Organizations want, nay they need, standards now and if they aren’t forthcoming vendors and customers alike will move steadily forward with their own implementation.

The myriad “cloud APIs” submitted to various standards organization indicate this pattern of behavior has already begun and will continue until the dust settles and one (and hopefully only one) API comes out on top. Microsoft may have come “late” to the cloud computing table, but it’s certainly making up time by moving forward with its Dynamic Infrastructure Toolkit for System Center.

The Dynamic Infrastructure Toolkit for System Center is a free, partner-extensible toolkit that will enable datacenters to dynamically pool, allocate, and manage resources to enable IT as a service. Whether you’re an enterprise customer, a systems integrator, or an independent software vendor, the toolkit will help you create agile, virtualized IT infrastructures.

-- Microsoft Cloud Computing Infrastructure solutions

What’s a bit different about Microsoft’s Dynamic Infrastructure Toolkit for System Center (DIT-SC) is that it’s not focusing on standardizing the interface to the cloud, a la Yet Another Cloud API, but rather it’s focused inward, on operations, much in the same way the cloud API of Yahoo! is highly focused on internal rather than external operations.

HOPPING into the NETWORK

The DIT-SC provides a framework – not an API but a framework – that allows partners and customers to manage resources, including infrastructure such as load balancers, firewalls, and other network-hosted services. By providing a framework Microsoft can leave the implementation up to vendors and customers which is of course cost-effective on their part but also provides the means by which those infrastructure solutions that are not yet Infrastructure 2.0 enabled can still be supported.

Assume for a moment a device, X, does not have a standards-based control plane accessible for automation and remote control. This does not mean it cannot be automated, it simply means alternative methods of communication and control must be used. Holistic identity management systems used this technique extensively to manage accounts on operating systems and applications for which there was no programmatic interface, and administrators have used remote scripting playback to automate tasks for what seems like eons. Using PowerShell the integration of both Infrastructure 2.0 and non-enabled systems can be accomplished, resulting in unified data center management of resources via System Center. load balancing is one of the planes of control, and will be primarily enabled through the existing Infrastructure 2.0 capabilities of various vendor implementations such as F5, Citrix, and Cisco.

Microsoft is approaching Infrastructure 2.0 and the integration of network-hosted resources in a very implementation agnostic way. Rather than simply lay the entire responsibility at the feet of individual vendors, it has taken a more “standardsy” approach in that the definition of the PowerShell interfaces to network and application delivery network infrastructure will be normalized across similar component functionality. Standardized, essentially, into a common task and model-oriented set of interfaces that can be used to basically plug-in any vendor solution in a particular data center niche. This “normalization” is very close to “standardization” and thus it is not inconceivable that in the future we may see the model and interfaces developed to support the DIT-SC framework proposed as a standard in much the same way other vendors have put forth their models and interfaces as potential “cloud” standards.

Not the framework, mind you, but rather the collection of infrastructure and resource control that result from ongoing efforts to integrate infrastructure and network and systems’ resources into a unified dynamic management system.

That’s the target of Infrastructure 2.0 standards efforts; the definition of a model and interfaces unified across the network and application delivery network as well as “interclouds.”

DE FACTO STANDARDS are INEVITABLE

The problem is that there’s no one really to “blame’ for what’s almost certainly going to happen: the rise of de facto standards. Certainly some vendors and organizations are counting on that happening, and for others it’s just going to happen because, well, that’s the way things work in a rapidly evolving environment. Standards are not forthcoming fast enough at this point to address the rapid evolution of data center operational needs. Given the scope of the task at hand – developing a set of standards that will ensure interoperability of infrastructure and cloud computing environments – it’s no surprise that it’s taking some time. At least it’s no surprise if you expect that such standards will be long-lived, well-thought out, and as future-proof as standards can be.

It may be that efforts such as DIT-SC will, in fact, be helpful to creating “accepted” standards in the future. Anyone who was involved in IT before TCP/IP rose to the top of the standards heap and became the accepted industry standard, beating out Novell’s IPX/SPX and IBM’S SNA will recall that there was a time when it was not clear which “standard” would ultimately “win”. A similar situation will almost certainly arise in the arena of cloud computing, if not at the cloud API layer, then internally, at the operational layer. By tossing the infrastructure models developed to support vendor and provider frameworks into a hat it may be that a unified set of standards can be developed that make the internal integration (collaboration) required to orchestrate IT operations and allow organizations to fully realize the benefits of virtualization and cloud computing.

In the meantime, Microsoft has (somewhat quietly) joined the Infrastructure 2.0 movement by ensuring the means by which network and application delivery network infrastructure can be automated and orchestrated through a centralized “cloud management” system with DIT-SC. That’s certainly a leap forward in the right direction.

Pay No Attention to the Infrastructure Behind the Cloudy Curtain

2010-02-26T07:02:53Z

What is needed to customize the cloud is a pair of data center ruby slippers called Infrastructure 2.0.

Frank Gens of IDC discussed the “New IDC IT Cloud Services Survey: Top Benefits and Challenges” in his blog and what is not surprising is that security continues to top the challenges associated with cloud services. What may be surprising to some is the increasing focus on customization. It shouldn’t be. As customers continue to push at the boundaries of the cloud computing model they will inevitably find it unable to meet some need they have, such as customization.

See, when IT professionals said they didn’t want to worry about infrastructure that didn’t necessarily mean they didn’t care about the infrastructure. What they meant was they didn’t want to bear the operational and capital expenses associated with infrastructure if they didn’t have to. That’s a very different story than not caring about the infrastructure or about their ability to provision it, manage it, and ultimately control it. Applications are never deployed in a vacuum, after all, and part of the way in which they are secured, optimized, and made highly available is through its supporting infrastructure. Many of those options are simply no longer available in “the cloud”, and this is likely to be a bullet point in the “against cloud” column for many organizations who employ a more infrastructure inclusive strategy to delivering applications.

We could easily argue that “lack of interoperability standards” (cited higher on the challenge scale at 80.2% of respondents concerned to very concerned about standards in the survey) is directly related to this lack of customization capability (76% cited this as a concern). After all, interoperability standards across infrastructure of similar ilk would, ostensibly, make it easier for cloud computing providers to offer the infrastructure services required to customize the environment.

Infrastructure 2.0 is the means by which many of these concerns will eventually be addressed.

SERVICES –» COMPOSITE DATA CENTER ARCHITECTURE

I will now shamelessly adopt terminology generally associated with SOA because cloud computing and “self-service” customization is, at its core, about leveraging a service-oriented architecture. That’s why we call them “services”, after all. That in the case of cloud computing the architecture is focused on infrastructure is irrelevant; the same principles embraced by composite applications built from software (business) services can be equally applied to a data center architecture built from infrastructure services.

Infrastructure 2.0 capable devices, whether virtual network appliances or physical hardware implementations, are solutions enabled with some sort of control-plane, usually REST or SOAP and accessible via an HTTP-based communication channel. These control planes provide the means by which cloud computing providers – or ISVs or regular old folks in the enterprise – can integrate infrastructure services into the application deployment and delivery chain.

This is nothing new. These capabilities have actually existed for nearly a decade now. What is new is cloud computing and virtualization and the need for automation and orchestration of the application deployment and delivery chain to enable efficiency and drive down the costs associated with delivering large-scale applications through rapid elasticity and scalability.

By exposing infrastructure services to customers it allows customization in a consistent way. The interesting thing about virtualization and cloud computing is that like SOA, the service implementation can vary without changing the interface through which the service is provisioned and managed. Some services may actually reside on physical infrastructure hardware while others might require the provisioning and deployment of a virtual network appliance (VNA). The customer may care about the implementation as it could effect cost or require specific management skills to include in their “virtual infrastructure” in the cloud environment.

For example, a cloud provider is going to provide load balancing as a means of scaling applications and, likely, virtualized infrastructure services. Using infrastructure 2.0 capabilities, the APIs and SDKs that manage and control infrastructure, the provider can offer a variety of options and billing structures based on the form factor and capabilities. One service might be a basic load balancing service, via a shared hardware Load balancer, with its only options being a choice of a few load balancing algorithms. Customers requiring more intelligent load balancing algorithms might be able to choose the same service on a shared hardware load balancer, but with more options and at higher costs. Customer desiring advanced application delivery capabilities such as network-side scripting or protocol optimization or security may be offered the choice of such services via a dedicated virtual application delivery controller, at yet a different cost rate. The reason this works is because the service interface is the same regardless of whether the form factor is hardware or virtual; it’s SOA in the network; an abstraction that allows for differences in implementation internal to an environment and, eventually, across environments.

As a customer chooses services to include in the application delivery chain it becomes essentially a composite infrastructure based on a chain of individual services. This is very similar to the way in which composite SOA applications would be composed: as individual services that combine to form a complete application.

INFRASTRUCTURE 2.0 is the RED RUBY SLIPPERS of CLOUD COMPUTING

What an infrastructure 2.0, service-based model offers both sides of the cloud equation – customer and provider – is choice. Choices in deployment form factor, choices in services offered and available; the customization cited as concerning by customers exploring cloud computing environments. This is the way in which cloud providers will be able to differentiate their offerings – by providing choices to customers in the infrastructure services available.

Remember Dorothy thought she needed the Wizard of Oz to get her home. Only after she saw that the wizard actually wasn’t, that he was just a man moving levers and pushing buttons behind the covers, was it revealed that she’d always had the power to go home on her own: those red, ruby slippers. Infrastructure 2.0 are the customers red, ruby slippers; providing the means by which they can customize their cloud-based application delivery infrastructure in the way that best suits their needs, without the help of the Wizard of Cloud.

An Infrastructure 2.0 services-based model is vital to addressing several of the challenges still raised in surveys: lack of interoperability standards, ease of integration with internal applications/infrastructure, migration back to the enterprise data center. If data center architectures are based on services, and not specific hardware or virtual implementations, it will be a lot easier to migrate that architecture between cloud computing providers and the local data center (“in house”) because the over-arching orchestration, the model, is a composite of infrastructure services. It essentially becomes an architecture built on solutions, not products.

That’s not to say there aren’t challenges associated with an infrastructure 2.0 services-based data center model. Differences in service implementation right now make it difficult to migrate services between vendor implementations, something that must be addressed before complete portability is possible. But this is the next evolutionary step in cloud computing: the abstraction and normalization of infrastructure services. Without this step customers will continue to raise the same integration, portability, and customization issues as they do today, and the growth of cloud computing will eventually slow to a crawl.

Cloud - Problems Foreseen are Opportunities Created

2010-02-21T08:02:30Z

I wouldn't even be a member of the Infrastructure 2.0 blogging group if it wasn't for the fact that I love the opportunity that cloud presents to enterprises. I know, where's the "but"? Keep reading....

But, as much as the benefit of cloud is relatively well understood, like any complex activity you can't just plug it in, turn it on and assume everything will work out just fine. I've talked to a number of people over the last few years who've complained that projects to implement virtualization were complex or difficult and I couldn't agree more. Here's the rub, every change we ever make, in life, IT or otherwise is difficult and often complex if it's worth pursuing. There are few people if any who can say that the well executed implementation of virtualization hasn't been a boon to enterprises all over the world, even though they were complex & often difficult.

So how does foreseeing this problem created by dumping cloud into our environments early help you develop a strong team and an excellent service?

Introducing cloud to your environment without a strategy of ownership could set back your efforts for years. At many levels cloud will change the very nature of how we deliver services, even how we own or don't own hardware and data centers. My belief is that at a minimum you should consider having the following high level cloud use or ownership strategy goals fleshed out;

What is the required end result of your move to cloud? This might sound like it's easy, but it's not. This is more than money and it's more than improving your DR or eliminating the need to buy hardware. The move to cloud should have well defined links to your enterprise strategy. Unlike many IT infrastructure solutions (Yes, Cloud is IT Infrastructure) cloud has the distinction of being a technology that could actually change the way your enterprise does business.
- Does it accelerate your ability to reach new customers
- Can it improve your ability to expand into new areas
- Does it allow you to do business with a new class of customer (I.e., you can play with the big kids now)
- Can it reduce your cost of doing business
- Does it enable a completely new level of enterprise agility and customer satisfaction
How will the implementation of your cloud strategy affect your IT group? At a minimum you're going to need to do some retraining, and if you don't plan you might find yourself in a position to have to replace staff. I'm a firm believer that making your team a part of the future will only strengthen your hand and lower the risk you're carrying. There's nothing wrong with investing a little energy in the "Leadership" portion of your management job so you can build team and staff loyalty. Some basic thoughts on the potential change to the organization:
- Dramatically reduced requirement for
  - sys admins
  - hardware support skills
  - data center ops staff
- New or Elevated skills will be needed
  - Architecture in the application stack
  - Performance & Reliability tuning and reporting
  - Security
  - Policy development and management
  - Business liaison/engagement managers
  - Contract management
  - Vendor Management and hardware selection strategies
The good news is that with proper planning your groups natural growth and attrition will mean that if you begin your team transformation now, in three years you'll have the team you need and won't likely need to reduce head count.

What do I mean when I say "Ownership"? I use the term regularly when I talk about data centers. My definition doesn't involve actually physically owning a data center structure, but rather a strategy for understanding and being responsible for all things related to your data center. In other words, having an ownership strategy that's aligned with thinking of the data center as a system ala the Data Center Pulse "Stack". In the case of Cloud "Ownership" I mean the same thing. In order to ensure you have the necessary skills, budget, and vision in place for your cloud, you need to see it as a system and understand what it means to own that system.

Are Multiple Clouds In Your Foreseen Future?

Going forward I strongly believe that most organizations will have multiple clouds, probably greater than three. These clouds will be a combination SaaS, public (EC2, Terramark, etc) and private (vmware, Citrix, etc). As you consider what the cloud enables (agility, flexibility, commoditized hardware, no vendor lock in, etc., etc.) you will start to see that if you want to leverage these benefits you can't fully capitalize on them if you're only using one. Also, the best of breed approach becomes a reality, without the issues of lock in.

So, if you're going to have multiple clouds how are you going to manage them? Great question, I'm glad you asked.

The last thing you'll want to do is buy/build or contract your way into multiple clouds and not have a strategy for how you'll manage their use and support. This is where cloud Orchestration comes in. The ability to spin up a stack of vm's that fit an infrastructure profile (websphere, .Net, Java) at a moments notice, regardless of the cloud you're requesting it from is key. It's key not just because it's easier, but because it will help you ensure that your governance and enterprise policies are always applied in a consistent fashion. This orchestration and governance also dramatically improves your ability to provide self service to your customers, regardless of whether those customers are IT staff or end-users.

Seeing as how cloud is still a relatively new concept, you can bet there are few solutions in the cloud management & orchestration arena. I believe that ServiceMesh is the only company on the market today that is capable of enabling the opportunities and capabilities discussed in this blog. I will make the disclosure that I've recently taken a position with ServiceMesh, so I'm naturally biased. However, that doesn't change the fact that the statement is true.

How are you going to capitalize on this oportunity?

The future of the enterprise is about to change forever. While many large tech vendors are looking to find ways to lock in their customers, the pursuit of the right to choose is a "given" when it comes to cloud, or at least it should be. The vendors that are most successful in supplying cloud solutions or IT infrastructure for the enterprise will be those companies that adjust their approach and find ways to offer technologies that are measured against new factors like, energy consumed to produced compute, and ease of acquisition with fail in place options.

It's a bold new future and we're on the cusp of being able to realize some incredible new benefits through this revolution in the use of technology. Strap in and hold on, because change is coming. You can be a part of it, or you can be buried by it, the choice will be yours. If you choose to be a part of it, proper planning and execution of strategy can mean your risks can be dramatically reduced and your opportunities improved. Problems Forseen are Opportunities Created.

Cisco HP Divorce Signals New Era

2010-02-21T01:02:24Z

The much anticipated divorce between Cisco and HP that was announced in recent weeks is a harbinger for the network equipment industry. Note Alexander Wolfe’s comments from his Wolfe’s Den blog:

Cisco has made what can only be characterized as an aggressive move emphasizing its strategic surge from a networking-centric vendor into a unified computing powerhouse.

Earlier in February Wolfe interviewed HP about their entrance into the infrastructure 2.0 category:

This may be the most astute move yet that HP has taken to blunt the high profile Cisco has achieved with its Unified Computing System, a competing Infrastructure 2.0 play, which similarly combines servers and networking.

Cisco and HP have made it clear to their investors, customers and employees that IT is being swept up into a new era of converged computing, driven by a host of new pressures, including virtualization and consumerization and increasing populations of IP addresses and network-enabled appliances.

These pressures are pushing IT vendors to support solutions with new levels of IT orchestration so that networks can grow in size and complexity without increasing risk and cost. That kind of orchestration requires network automation which requires DDI automation, based on a newly anointed category of DNS, DHCP and IPAM appliances automating the manual processes that have been used for decades to keep networks working properly.

Note: Automation within IT is both ironic and inevitable. According to Lew Tucker, IT costs will increasingly track to the cost of electricity. You can read about Lew's Law and network automation at the infrastructure 2.0 blog. You can also read more about the links between network and IT automation at The Network beneath the Clouds.

Because today’s complex patchwork of applications, endpoints and networks are connected by today’s equivalent of yesteryear’s telephone operators (layers of manual connections and processes between ever changing populations) vendors are being encouraged to combine multiple solution categories into container categories, encompassing storage, network, applications and systems.

Cisco’s recent Acadia announcement, which brings Cisco, EMC and VMware into a private cloud alliance, is one of what promises to be a wave of unified efforts to drive the necessary convergence between otherwise disparate solution groups and the manual processes that have been traditionally required for IT infrastructure to function across ever greater distances and an ever increasing breadth of devices.

Underneath the manic headline grabbing cloud rush lies an all too important network, still suspended between seventies-era practices and today’s cloudy dreams and proclamations. Those networks are still run like the early days of telephony, with growing ranks of network pros manually configuring every material change.

The question is then posed to Cisco and HP and others: who will be the first to automate the outdated, manually configured network? Will it be the network vendors -who have monetized the complexity and yet possess the expertise- or the system vendors who create a new network from scratch (or acquisition) on top of commoditized hardware?

The infrastructure 2.0 battle line, however, will likely form between network and system-centric visions and be fought between ever tighter alliances of once disparate solution groups playing to their core strengths. Automation will be a new kind of team effort supported by the coming network revolution.

The victor will likely be the first to automate the network (physical and virtual) and ultimately automate IT. That automation will drive the next major wave of IT investment and innovation, and drive new categories of converged management solutions that enable the proper functioning of ever larger networks and ever larger populations of systems and endpoints, optimized in real time with minimal manual intervention.

You can follow my rants in real-time at www.twitter.com/archimedius.

HP Joins the Conversation

2010-02-10T09:02:59Z

A few weeks ago an HP blogger commented that infrastructure 2.0 is premature:

The intercloud concept has recently emerged as a topic of discussion in the industry. Conceptually, the intercloud builds on the concept of the Internet where multiple providers participate in a ubiquitous infrastructure employing heterogeneous computing and communications technologies. Greg Ness describes the intercloud as "an elastic mesh of on demand processing power deployed across multiple data centers. This seems to be the vision promoted by James Urquhart and colleagues at CISCO as described in his blog on The Intercloud and Internet Analogies.

If this elastic mesh is provided by a single cloud provider, then it is simply a different spin on cloud computing. If it is a mesh of independent cloud providers, sharing workloads, then it is a vision that is not worth concern within the next decade.

Fred Cummins, HP Community Site, Jan 6, 2010

F5’s Lori MacVittie responded to Fred’s post with a couple spot-on observations:

I’m going to have to disagree with Fred for two reasons. The first is based on the rate of change and innovation in technology in the last decade that certainly points to the next decade being just as disruptive. Consider that ten years ago, in the year 2000, most of the web as it exists today – Web 2.0, APIs, integration, collaboration, video, audio, user-generated content – didn’t exist. From a technology perspective virtualization wasn’t even a twinkle in a VC’s eye and in the infrastructure world, well, we were just beginning to explore the advantages of moving software-based solutions to hardware and hadn’t fully managed to integrate infrastructure solutions let alone anything else.

Lori MacVittie, F5’s DevCentral blog, January 8, 2010

If you view infrastructure 2.0 as a precursor to IT and network automation, then a series of recent analyst reports could indeed be prescient. Between the power of virtualization and the promise of consumerization, enterprise IT teams are likely at a crossroad; decisions made in 2010 and 2011 could have a substantial impact on the future of their teams and organizations.

A Forrester report by Glenn O’Donnell published last year discusses the magnitude of changes already underway:

A combination of forces, including skyrocketing complexity and severe economic pressure, are radically and irreversibly altering the IT landscape. New methods, new functional sourcing, and new organizational structures are needed to address this onslaught, but one theme is obvious throughout all of these approaches- a need to automate more of what you do in IT.

Glenn O’Donnell, Forrester, IT 2009: An Automation Odyssey, July 2009

As Enterprise Strategy Group has suggested, 2010 will likely be a year of network automation, perhaps starting at the very core of the network:

Many organizations manage IP addresses using spreadsheets and homegrown tools—there is no way this will scale when we need dozens of virtual IP addresses per physical device.

Jon Oltsik, ESG, Network Industry Outlook for 2010, January 2010

More IP addresses, more dynamic systems, more green initiatives, more endpoints and more promises from public cloud vendors are threatening to sweep away decades of manual scripts and configurations, spreadsheets and committees created to connect one device to another, like the enterprise network’s version of yesteryear’s telephone operators.

The operator was such a powerful symbol of the rise of the telephone network that their jobs even had broad comedic appeal, like One RingyDingy. (Photo from YouTube.)

Yet as those networks grew, the Bell companies were forced to automate operator functionality. Rows and rows of operators were eventually replaced by switches and software. Expenses and mistakes were reduced. This of course was the era before cell phones, which would have been at least awkward for operators to follow.

Imagine our surprise when HP joined the infrastructure 2.0 conversation with Alexander Wolfe weeks later, talking about HP’s converged infrastructure offerings:

Alexander Wolfe, InformationWeek.com, Feb 2, 2010

You can follow my rants in real-time at Archimedius.

That Whole Concept is Broken

2010-02-10T05:02:19Z

Agreed that cloud vendors need to differentiate on services. Disagreed that cloud standards will not forward that cause and that virtualization platform makes a difference.

The battle for virtualization platform dominance rages on, but it will not be virtualization that makes or breaks a cloud computing offering; it will be the diversity – or lack thereof - of the services it offers. We need to stop focusing on virtualization as the be-all and end-all of cloud computing and start bending our efforts toward what really matters: the ability of providers to efficiently offer a broad set of differentiating services and of customers to take advantage of them to architect a cloud-based solution that delivers their applications efficiently, securely, and as fast with as little manual interference as possible. Citrix CTO Simon Crosby touches on this point in a recent interview with John Furrier, “VMWare Had Nothing To Do With The Cloud Trend. Their Strategy is Flawed”, on the topic of cloud computing and virtualization.

I don’t see any viable opportunities for cloud vendors if all of them are offering a homogeneous set of services designed by one company called VMWare. That whole concept is broken.

I’m going to agree with Simon with the caveat that he could have ended his statement at “homogeneous set of services” and the concept would still be broken. Cloud computing isn’t about any one virtualization platform, it’s about the services that it can provide – from the network to storage to application network to ease of provisioning and management. Those services must eventually encompass the whole of a traditional IT infrastructure and they must be accessible and manageable by the customer. And they need to be portable across cloud implementations lest customers continue to balk at the prospect of locking themselves in to any one cloud computing provider or architecture. Crosby questioned the need for Cloud APIs and standardization a little later in his interview saying, “Should Cloud APIs be standardized? If there was a standard then all the clouds would look the same.”

I disagree. The existence of standards would allow cloud providers – and more importantly cloud customers – to differentiate. Would all clouds look the same from the outside with standards? Yes. Would they act the same way on the inside? Absolutely not – at least one hopes not. The creation of standardized Cloud APIs is about portability and management and accessibility on the outside, which is really about interoperability from a service offering point of view. A standardized Cloud API really has very little to do with the internal implementation; it’s simply an abstracted communications layer interface. It’s SOA in the purest sense – the separation of the interface (API) from the implementation (the underlying “cloud” infrastructure). Standards are certainly part of what’s needed, eventually, to allow potential customers to explore cloud computing offerings and enable organizations to take advantage of concepts like cloud balancing, but Simon’s point about offering up homogenous services being dangerous to the longevity of cloud providers is really about services on the inside not the outside, and it is on the inside that standardization is absolutely necessary to bring about the ability for providers to offer up not only a heterogeneous set of infrastructure services, but simply to provide the choice and control that is inherently lost when moving an application to a cloud provider today.

The existence of APIs and standards inside, a la Infrastructure 2.0, would increase the ability of providers to integrate into their comprehensive management and orchestration systems more choices across infrastructure offerings, thus providing a broader set of options for customers in architecting a cloud-based infrastructure that best suits the needs of their applications. Without such standards cloud providers are faced with a limited set of choices and all of them lead to the same result: a restricted set of services that may or may not allow the provider to differentiate and add value atop the value already offered by what is essentially cheap, managed compute resources. It’s what cloud providers can build using those standards to expose services that will give them a competitive advantage.

IT’S STILL ABOUT THE APPLICATIONS

Simon later says, “At the end of the day the IT job is to deliver applications, and those applications today are sophisticated things composed of multiple runtime entities or multiple virtual machines.” I couldn’t agree more and Simon’s reminder is timely as we begin to see more and more interest in long-distance migration of “applications” across physical locations. The focus of any IT infrastructure and architecture is to deliver applications to customers, users, and partners and to do it in a way that’s fast and secure. In many cases the application – whether by design or accident – simply can’t meet these goals. In some instances it’s the case that the application, in order to be secure against attack and compromise, needs the assistance of IT infrastructure because some classes of attacks are directed not at the application, but at its supporting infrastructure: the application server, the network stack, the operating system, the physical device.

We know that the choice of load balancing algorithm has a direct impact on both the efficiency and performance of applications, yet many of the load balancing offerings today are “one size fits all” and do not allow customers control over what algorithm is used, or whether optimizations are applied. It is well understood that some application delivery services require visibility on both the client and server side of the delivery equation, yet this visibility is denied to customers. The purpose of application delivery is to extend the reach of the application out into the network, to be able to leverage services residing in the network to improve performance, increase capacity, and make more efficient the practice of securing the application. It’s about an architecture that’s designed to make the most of out all resources, not just remove the burden of acquiring and managing physical servers.

The existence of standards would allow these kinds of services to be offered, and allow them to be more varied. If every application delivery solution could provide its services via a standard API – and similarly expose what services are available – then cloud providers could leverage those APIs to offer up more choice to customers, including services from competing solutions. Cloud computing is about integration and collaboration; it’s about flexibility not just in scalability but in architecture. What should be offered is the means by which customers can pick and choose from among a broad selection of infrastructure services based on capability, price, and the specific needs of each application. Such an offering is highly unlikely to come to fruition without standards simply because of the time and effort required to integrate fifteen or twenty different APIs with a single, cloud management and orchestration system.

Taking Simon’s statement slightly out of context, I agree: the whole concept of offering homogenous services is broken. But I’ll go further and say that no single virtualization vendor (or any other vendor, for that matter) is going to be able to offer to providers – and thus customers – the entire set of infrastructure services required to efficiently and securely deliver an application.

The Network beneath the Clouds

2010-02-02T02:02:22Z

Lew Tucker’s response to the Lew's Law blog further helped to clarify the point I was trying to make about the rise of IT automation and the network’s pivotal role:

While I'm sure this is more obvious than brilliant, the cost of computing will continue to fall bounded only by the cost of the power to produce the computation. We're simply turning electricity into computation and communication using electrons to move around bits.

What cloud computing does is to use automation, scaling, multi-tenancy, and a competitive marketplace to bring us closer to this lower bound for the cost of computing.

For those of us familiar with the network equipment industry, the suggestion that computing costs will fall to the cost of power should at least raise some eyebrows within cultures that for the most part have been driven by manual labor and specialization.

While the network powered the automation of business practices it has managed to insulate itself from the competitive forces it unleashed between competing supply chains and operating models.

I think that the automation of the network is at least partially in response to: 1) the threat of consumerization; 2) the growing significance of new initiatives like IPv6, virtualization, DNSSEC and private cloud; and 3) rising network complexity (more endpoints, higher rates of change, ongoing labor specialization).

Now add to that lineup of manual opex pain a recent Gartner prediction that 1 in 5 businesses will dump their IT assets by 2012 (Jon Brodkin, Network World):

The analyst firm predicts that 20 percent of businesses will own no IT assets by 2012, a shift that will have a major impact on IT careers

Anyone still clinging to their manual DDI (DNS, DHCP, and IP address management) scripts and spreadsheets, for example, after reading this sobering and yet provocative prediction will likely join the legions of “middlemen” who were eventually retrained as network-enabled supply chains replaced similar business processes. This transformation has today set the stage for the coming conflict between the real-time enterprise and the increasingly inflexible network.

The recent ESG 2010 Outlook and Gartner DDI MarketScope for DDI appliances are harbingers of a new shift in how networks are managed; and a host of vendors and professionals who embrace automation stand to benefit.

A reduction in the operating expense of networks could vastly expand the market for network solutions that are easier to manage, more powerful and connect ever larger populations of systems and endpoints. Enterprises will be forced to automate or outsource to those who do.

This new network will be all about availability, flexibility and economy and will set the stage for a new resurgence in network spending and the rise of network software.

If you’re attending Cloud Connect, we hope that you’ll attend one of the three panels dedicated to this and related discussions. James, Urquhart, Lori MacVittie and Richard Kagan are putting together some provocative panels with some of today’s infrastructure 2.0 thought leaders. I would love to hear your thoughts…

You can follow my rants in real-time at Archimedius.

Lews Law and Network Automation

2010-01-26T10:01:07Z

Last week I heard Sun Microsystems Cloud CTO Lew Tucker predict that IT expenses would increasingly track to the cost of electricity. “Lew’s Law” (as described to a room of thought leaders) is a brilliant theorem that weaves a microcosm of IT trends and recent reports into a single and powerful concept.

Lew’s Law is a powerful idea whose time has come, with profound and far reaching impacts, including the automation of the network.

While Lew is focused on electricity as a cost, the power of his theorem is driven by the power of IT automation. For Lew’s Law to be prescient either electricity costs go up and/or labor costs go down. For labor costs to drop, the ancien' regime of outdated processes and manual labor must be swept aside.

It seems that one can forget the endless buzzword proclamations about cloud computing, what it is and who is delivering and instead focus on the rise of IT automation. Feel free to ask Lew directly, but I think he was suggesting if not predicting the ultimate automation of IT, the end of today’s tight link between manual configuration and needed outcome.

That automation won’t be trivial or easy but it is necessary for the evolution of IT into a more energy-efficient, powerful and strategic force in the global economy. It’s also necessary for the survival of IT, as network endpoints mushroom and new initiative pressures build, including virtualization.

If Lew was in a vacuum it might be easier to dismiss his prediction as far out, citing today’s legion’s of clerks, configurations, committees and procedural delays as ample evidence of an unchangeable status quo. Add a few fax machines to this manual labor empire and you have a business culture not unlike the legions of “middlemen” replaced by the evolution of the network over the past several decades.

Yet “the network is the computer”, “just-in-time IT” and “real time infrastructure” all align with Lew’s Law. Late last year Gartner published its first DDI MarketScope grouping appliances that automate DNS, DHCP and IP address management. Early in January Enterprise Strategy Group published a 2010 Outlook for the networking industry. I’ve pulled a few highlights that align with Lew, including the eventual alignment of networking, computing and virtualization:

According to ESG research, server virtualization is the number one IT spending priority for 2010. The networking industry will support this trend in several ways. Cisco’s whole UCS and Data Center 3.0 strategy is built on the assumption that networking, computing, and virtualization are coming together. Beyond strategy, Cisco’s Nexus 1000V and VN-Link products already align networking and virtualization intelligence. Expect other vendors to turn up the volume on similar initiatives in 2010. Juniper’s secretive “Project Stratus” will begin to bear fruit, as will comparable efforts from Extreme Networks, Force10, HP, and startups like Overlook Networks. ESG also anticipates more activity on the standards front to bridge networking and virtualization intelligence.

- Jon Oltsik, Enterprise Strategy Group

Some of the report’s suggestions might be seen as forward-looking, including the final chasm crossing of IPv6, but his perspective on F5 and the rise of network automation are very consistent with Lew’s Law and the recent Gartner MarketScope.

Check out Jon’s predictions regarding the overhaul of the network services at the core of the automation problem:

Network services infrastructure upgrade. Imagine the future: massive data centers with tens of thousands of servers dynamically allocating processing loads to meet demand and conserve energy. Cool stuff, but how will this play out in the network? Even more fundamental, how will large organizations manage their IP addresses, provision them dynamically in real-time, manage ever-changing DNS, etc.? Many organizations manage IP addresses using spreadsheets and homegrown tools—there is no way this will scale when we need dozens of virtual IP addresses per physical device.

Jon understands the issues at the core of the network and the automation that must take place in order for networks to prepare for their ultimate support of IT automation. The rest of the ESG report contains more detail about how network automation will evolve and the increasing influence of virtualization on the network itself.

You can follow my rants in real-time at Archimedius.

The Cloud Elasticity Myth

2010-01-15T07:01:25Z

I love reading cloud pundits talk about the power of elastic, cloud computing. You get as much processing power as you need, on demand. Wow. Enterprise IT types beware: the cloud is coming.

Indeed it is coming, but on the way to the dream there are plenty of anxious wake up calls. Check out Chris Hoff's blog on the difference between over capacity and over subscription.

“On the other hand, the sad truth is that we will have over capacity issues in cloud; it’s simply a sad intersection of the laws of physics and the delicate balance associated with cost control and service delivery.” Hoff, Rational Survivability, Jan 2010

After a few Tweets with the Hoff I was inspired to call it the “elasticity myth.” He was quick to point out that the problem is that systems are more elastic than networks. Yes. That is the core problem.

When I hear cloud pundits talk up their elasticity I will hear the Hoff in the background bringing the over marketing down to earth. There has been enough noise about infrastructure 2.0 thus far to put any cloud “elasticist” on notice. In the words of the Who: “Don’t get fooled again.”

You can follow my rants in real-time at Archimedius.

The Data Center Transformers

2010-01-12T03:01:42Z

Infrastructure 2.0 enabled application delivery platforms have more than a few things in common with the Transformers. Like Autobots, there’s more to it than meets the eye.

If you’re familiar with the mythology of the Transformers – and perhaps even if you aren’t – you know that they key attribute of Transformers is their ability to take on “alternate modes” such as cars, trucks, and winged vehicles simply by scanning the object and then adapting their own form to match.

One of the key premises of Infrastructure 2.0 is also the ability of network and application networking solutions to adapt to their environments. While they won’t be transforming their physical manifestations into some other device they can transform their configurations based on the environment in which they are deployed. Like the Transformers ability to take on alternate modes, the ability to react in real-time is a native capability of Infrastructure 2.0 solutions and should not be overlooked by those integrating Infrastructure 2.0 into their cloud-based architectures.

While everyone seems aware of the capability of Infrastructure 2.0 to be managed and integrated with the rest of a cloud-based ecosystem via a standards-based control-plane API, there’s more to infrastructure 2.0 than meets the eye, here. That same dynamic control plane can be used at run-time to transform configuration and policies to better match customer need for balancing of performance and cost across the application infrastructure. That’s the transformative power of infrastructure 2.0, and what will certainly be core to the next generation of network management systems when trying to enforce SLAs across applications, data centers, and cloud computing environments, a.k.a. cloud balancing.

Now I doubt that anytime in the future we’ll hear application delivery controllers describe themselves as autonomous networking organisms from <insert vendor city here> still there are enough similarities between a self-optimizing application delivery network and a Transformer to run with the analogy – and as long as I have the opportunity to legitimately include a picture of Optimus Prime in my blog, well, I’m going to take it.

TRANSFORM and DISTRIBUTE LOAD

In the case of application delivery the “transformation” that makes this analogy work may involve many different functionalities: security, acceleration and optimization, core load balancing. Today we’re focusing on the load balancing algorithm, specifically, as the use of load balancing in cloud computing environments in order to achieve “elastic scalability” is a requirement. Unfortunately there is very little time spent on the unique challenges associated with load balancing applications executing in environments with varied compute resource capabilities. One of the mantras of cloud computing is the use of otherwise idle resources to provide the additional compute power necessary to scale an application. What this ignores is that these idle resources may very well be of different capacities in terms of CPU and RAM available. By pooling together these “servers” of varied capacities, it creates a heterogeneous environment which in turn directly impacts the entire application delivery chain. Of particular note should be the load balancing algorithm used to distribute requests across the pool of “servers.”

The problem is that by dynamically adding a server with a different CPU and RAM configuration – whether virtual or physical – to the “pool” of resources across which the Load balancer is distributing requests it changes how effective that algorithm is which in turn impacts application performance and can, unfortunately, actually render smaller instances of servers unavailable in short order. Also a possibility is that it will overwhelm the smaller server before the larger servers, which could – depending on how you have your environment configured – lead to the launching of another small server which, of course, incurs more operating costs.

Consider you have three “super size” servers, all with the same RAM and CPU capacity. A spike in use is anticipated because of some EVENT but not so much that you need a super size server, a “regular sized” server will suffice. You provision it. The spike in use occurs and then the load balancer, which has been distributing traffic based on a round robin algorithm, overwhelms the regular sized server causing timeouts, delays, and other availability and performance related problems for visitors.

What happened? The load balancing algorithm, which was perfectly suited for a homogeneous environment, was not so well-suited to a heterogeneous environment. In fact, it was downright wrong for a heterogeneous environment. What happened is that no one took into consideration that the infrastructure, optimized for a given environment, might not be so optimized if that environment changed and did not appropriately modify the load balancing configuration.

SOLUTIONS

There are a number of solutions that address this particular challenge:

Provision homogeneously
If the load balancing algorithm you are using is optimized inherently for a homogeneous environment, then never deviate from that. Ever.

Human intervention
Manually change the load balancing algorithm when new servers are added, then change it back when it’s released.

Automate
Employ the collaborative nature of a dynamic control plane to automatically recognize the addition of a server that creates a heterogeneous environment and dynamically change the load balancing algorithm to one better suited to a heterogeneous environment, then reverse the change when the environment returns to a homogeneous one.

The load balancing algorithm that might be right for one application might not be right for another, depending on the style of application, its usage patterns, the servers used to serve it, and even the time of year. And changing any of those variables can have an impact on the behavior of the application because it directly impacts the load balancer.

Unfortunately we’re not quite at the point where the load balancer can automatically determine the right load balancing algorithm for you, but there are ways to adjust – dynamically – the algorithm based on the capabilities of the servers (physical and/or virtual) being load balanced so one day it is quite possible that through the magic of Infrastructure 2.0, load balancing algorithms will be modified on-demand based on the type of servers that make up the pool of resources. Today, if you know which algorithm is best given a specific set of resources you can codify the change such that it is automated; it’s only the choice of algorithm that can’t be, today, automatically determined. You probably could develop a system that does automatically determine through trial and error and monitoring of response times and capabilities, but it would not be a trivial task.

In order for application delivery infrastructure to automatically detect and optimize load balancing algorithms itself it’s necessary to first understand the impact of the load balancing algorithm on applications and determine which one is best able to meet the service level agreements in various environments. This will become more important as public and private cloud computing environments are leveraged in new ways and introduce more heterogeneous environments. Seasonal demand might, for example, be met by leveraging different “sizes” of unused capacity across multiple servers in the data center. These “servers” would likely be of different CPU and RAM capabilities and thus would certainly be impacted by the choice of load balancing algorithm. Being able to dynamically modify the load balancing algorithm based on the capacities of application instances is an invaluable tool when attempting to maximize the efficiency of resources while minimizing associated costs. Infrastructure 2.0 enabled load balancing solutions are capable of this level of automation; what they can’t do, yet, is decide which load balancing algorithm to apply. But if you know which one to apply – because you’ve tested and you know, right? – then you can automate the change based on triggers you specify, such as the addition of a server with CPU and RAM that turns a homogeneous environment into a heterogeneous environment. And vice-versa.

Virtualization and cloud computing are definitely game changers. But they not only change the basic rules of the game, they also change the strategy with which you must approach the game. It’s like moving from checkers to chess. There are a great many more moves you can make, and you’ve got to carefully consider how this move right now will impact a move you may need to make later on. One of the most important parts of that new strategy must be to recognize that while the ability to automate provisioning and integrate with the rest of the infrastructure is certainly a key benefit of infrastructure 2.0, just as beneficial is the ability to adjust and optimize the delivery of applications in real time.

Network Industry Wake Up Call (or... Jenga Anyone?)

2010-01-08T04:01:58Z

Network equipment vendors today are suspended –sometimes in disbelief, sometimes in denial- in a choice between innovation and irrelevance. The world around them has changed dramatically from the first Interop, from the powerful supply chains that have driven time and expense out of dozens of industries to the amazing rise of ecommerce in retail and banking.

Dan Lynch (one of the founding fathers of the network equipment industry) quipped to us after our Future in Review panel last May that networks have indeed fallen behind the world that they helped to create. (You can watch the FIRE infrastructure 2.0 panel and come to your own conclusions).

The core of the network hasn’t changed materially in decades. That’s a critical consideration now that virtualization has triggered the automation of systems in production environments.

Virtualization deployed within today’s networks is contained/constrained by issues related to capacity, integrity and orchestration. Whoever breaks those barriers first will have a strategic advantage over the “denialistas”.

These problems may not be visible to those who work within these networks or to those who are simply out of touch with the growing operational malaise stemming from outdated tools and practices overlaid on increasingly complex networks.

Network equipment vendors need to align their products and visions with the inevitability of virtualization (not today’s virtualization-lite pockets but rather dynamic and dispersed multi-site meshes of processing power) and the longer term likelihood of cloud computing. That will set the infrastructure 2.0 era in full motion, generating powerful new business cases for network gear by enabling network automation.

Out there is the VMware for the network, driving value by similarly automating outdated network processes. Yet IT automation will also require network automation. The network will become a strategic part of the solution.

Then How Did We Get Here?

As the pendulum has swung between various initiatives more pockets of expertise and specialization were created, more certifications, more configurations, more gear, etc; and network teams were charged with creating ever more scripts between ever more devices. As each vendor created a new release addressing customer pain points, new scripts were often needed.

Perhaps that’s why network and security pros could make great Jenga® players. They live every day adding, removing and scripting (while the world around them embraces automation). That’s also why many networking and security pros often resist innovation until a threshold of pain is crossed; that is, when “new” is less painful than “old.”

If you’ve played Jenga you know that it’s more fun to watch others (at least for me with my hands) carefully change the stack. The games get progressively more difficult as changes are made.

Jenga® images thanks to Wikipedia.

Virtualization has converted some of these “Jenga blocks” into elastic, flexible cores in some data centers -that are still static on the outside (virtual networks or VLANs)- yet the network game hasn’t changed. Ops pros have mouse clicks (automation) while the network teams are still suspended in time-consuming processes designed to counterbalance the risks of manual labor.

That’s opex spend creating the need for more opex spend. Sounds remarkably similar to the case for the virtualization of servers, doesn’t it?

When virtualization crossed into production environments it was the first shot in the coming IT automation revolution. Whether cloud computing is real or whether it comes in three or five years (or whether yet another vendor redefines its existing services as cloud), the network industry has been served notice: VMware, Citrix and even Microsoft have proven how easy and compelling system automation is compared to the hours and even days it takes to simply move a server the old fashioned way.

Automation is powerful and highly contagious as legions of “middlemen” have learned since the 80s and 90s; and those who embrace it win. Those who cling to manual processes are increasingly marginalized by decreasing economics. The larger the manually managed network the higher the per unit operating cost and the higher the outage risk. Opex begets opex.

Jenga anyone?

Pursuit of Intercloud is Practical not Premature

2010-01-08T02:01:59Z

Kicking of the new year (and a new decade) with a lively debate on a technological concept that is barely out of its infancy is always a good thing. Fred Cummins over at HP recently penned “Pursuit of the Intercloud is Premature” and caught the eye of several of us for whom Intercloud is near and dear and, I think, provided a great way to start off the year by declaring the concept of Intercloud “not yet worthy of concern”.

If this elastic mesh is provided by a single cloud provider, then it is simply a different spin on cloud computing. If it is a mesh of independent cloud providers, sharing workloads, then it is a vision that is not worth concern within the next decade. [emphasis added]

I’m going to have to disagree with Fred for two reasons. The first is based on the rate of change and innovation in technology in the last decade that certainly points to the next decade being just as disruptive. Consider that ten years ago, in the year 2000, most of the web as it exists today – Web 2.0, APIs, integration, collaboration, video, audio, user-generated content – didn’t exist. From a technology perspective virtualization wasn’t even a twinkle in a VC’s eye and in the infrastructure world, well, we were just beginning to explore the advantages of moving software-based solutions to hardware and hadn’t fully managed to integrate infrastructure solutions let alone anything else.

The rate of change in technology makes a “decade” in real time more like a century in technology-time, as far as innovation and use of new technology goes. So to say that the vision of Intercloud isn’t worth concern for the next decade isn’t realistic. It is imminently more practical to consider where we want to be in ten years and head in that direction than it is to stand pat and let our options essentially stagnate.

The second reason I’m going to disagree with Fred is on the basis that Intercloud is not an “exclusive or” concept. We are not “here” or “there”, but rather we’re going to be, for some time, “somewhere in between.” Intercloud is an evolution from where we are now to where we (think we) want to be – a customer defined mesh of independent cloud providers sharing workloads. As we move through this next decade we’re going to see the application of Intercloud concepts being applied in an evolutionary – not revolutionary – manner.

INTERCLOUD is EVOLUTIONARY not REVOLUTIONARY

Intercloud today in a simple, amoebic form exists as simply the inclusion of cloud computing hosted workloads in a global application delivery strategy. Where we once leveraged multiple data centers and global server load balancing (GSLB) to improve application performance and availability we will – and already are in many cases – leverage cloud computing environments in much the same way. This is not futurama, it’s fact. The use of GSLB and layer 7 (application layer) content-based routing to distribute workloads across individual servers (physical or virtual) is hardly much different than using those same technologies to distribute workloads across data centers – whether those data centers be physically owned by the organization or rented by the hour from a cloud computing provider. Leveraging cloud-based storage for images or other static content and the subsequent integration with on-premise applications is very similar in implementation to the use of CDN (Content Delivery Networks) and thus not a stretch to imagine that organizations will take advantage of cheaper storage options available “in the cloud” for their image-heavy applications.

The next step is to incorporate business-layer metrics into the decision making process when workloads are distributed across data center implementations, cloud-based or otherwise. When the global application delivery platform is able to base its decisions on where to route a given user and request on business-layer metrics such as costs and location as well as on performance and availability metrics, then we’ve moved beyond simple GSLB and into the realm of cloud balancing. Cloudbursting and cloud balancing are simply evolutionary steps in Intercloud, transitioning us from static application delivery architectures to more fluid, dynamic architectures that take into consideration the context in which requests are made and base service-related decisions on all the variables available.

Evolving from that will be the ability to actually move workloads on-demand based on those same variables. Today it is assumed that the workloads and/or resources already exist in several locations. Indeed, without existing application instances cloud bursting and cloud balancing are not really efficiently executed today. Though there are ways to migrate workloads on-demand today, it isn’t universal and requires very specific conditions. Experience and, one hopes, standards will smooth this process until it’s ubiquitous and seamless. But as we continue to refine the migration in real-time of virtual images and application packages across data centers (including cloud computing providers) we will eventually get to the point where that vision of “an elastic mesh of on demand processing power deployed across multiple data centers” is not just a vision, but a reality.

That said, Fred makes some very valid points and raises questions/challenges that certainly must not be ignored:

The economies of cloud computing come from optimization of operations supporting a homogeneous computing infrastructure that is driven by market demand and a high degree of trust in the cloud service provider. Cloud providers must make choices of technologies and develop optimal operations based on a high level of automation. They must commit to levels of service, security and reliability. They must make services easy to use and responsive to problems. This is a rapidly evolving market. Different providers will make different choices, potentially appealing to different markets. They cannot optimize if they must also maintain compatibility with other providers. In addition, they would need agreements for ensuring quality of service and establishing cross-billing mechanisms. Computing and storage resources are not free like the Internet. A client is not going to turn over data and applications to be managed somewhere in a network of independent providers. Who would be held accountable for failure to perform or breaches of security?

I don’t think anyone is suggesting that Intercloud become a free-for all, where data and applications are willy-nilly moved around without the owner’s consent or knowledge. That kind of a situation would certainly, as described by Fred, be potentially disastrous. What the standards around Intercloud will hopefully do is exactly what Fred exhorts such standards do: “avoid service-provider lock-in” and enable “integration between business applications and services using Internet protocols.” Such standards should also "make services easy to use” and provide the ability for customers to determine where and when application workloads should be moved. That is, and always should be, a customer-driven choice, not a provider-driven choice, and Intercloud standards must allow for customer control over workload execution with as much granularity as possible.

CUSTOMERS MAINTAIN CONTROL

It appears, too, that some of Fred’s arguments are based on the premise that applications residing in “the cloud” or in multiple “the clouds” are also being managed and controlled in “the cloud”. That’s not necessarily going to be the case – though it’s certainly a possibility. If we extend current global application delivery models to take advantage of cloud computing environments the control and management is still on-premise, or at least it can be. Cross-billing isn’t an issue, then, because the contracts are between provider and customer, not provider and provider. Each provider is responsible for breaches in security in only their environment, just as hosting providers today are only responsible for their environment if though a customer might be leveraging multiple hosting providers. For specialized services such as a cloud computing provider partnering with another provider for DNS management, we have well-established policies that already govern responsibility and accountability and as long as the customer is aware – up front – of that partnership it shouldn’t be any more of a problem than it is today.

The mere existence of Intercloud-focused standards (or the existence of a working group to define those standards, more accurately) does not negate these goals nor is it inconsistent with Fred’s view of on what we should be focusing our energy. Many of the concerns and needs that Fred points out are milestones along the path to Intercloud, concerns that must be addressed and needs that must be met in order to reach the penultimate apex of Intercloud. (I say penultimate because there’s always something beyond what we’re striving for; some goal or technology that evolves out of our efforts to reach our current goal and thus becomes the next penultimate goal…etcetera, etcetera, ad nauseum). In fact, one of the benefits of Infrastructure 2.0 and the leveraging of dynamic control planes via standards is to ensure that providers don’t need to worry about compatibility with other providers while ensuring that customers can move between providers with ease and without loss of infrastructure functionality.

Intercloud isn’t going to be – nor can it be – a dramatic leap from one application deployment methodology to another. It’s going to be a gradual introduction of technology-related capabilities in the area of global application delivery that allow more control and freedom over the deployment and subsequent execution of workloads across data centers. It’s going to be an evolutionary process, not a revolutionary one, that is driven by experimentation and customer-demand as they leverage the capabilities of increasingly context-aware infrastructure to distribute and leverage resources.

Virtualization, Clouds and Meta Orchestration

2009-12-18T04:12:45Z

One of the most powerful drivers of virtualization is the flexibility enabled by the decoupling of applications from hardware. In essence that decoupling enables unprecedented flexibility, management and automation, all within the confines of virtualized local area networks (vLANS). It is likely one of the most significant recent developments in the IT industry.

We’ve compared this decoupling to the rise of the steam engine more than one hundred years ago, but perhaps that vision wasn’t big enough. The ability to automate the creation and inter-vLAN/offline movement of servers is so powerful that some have suggested that servers could become obsolete in emerging cloud environments.

Virtualization makes networks strategic again.

Networking leaders like Cisco and F5 Networks see networks taking virtualization to the next level by enabling even higher levels of IT orchestration. Why stop at the VLAN border? Imagine the power of a completely dynamic, fluid infrastructure of data centers that can act as a single logical network and take advantage of even momentary changes in power expenses/requirements, users or even avoid predictable natural disasters.

These new infrastructures are run by policy instead of manual configuration. They are automated. They are the IT supply chains of the future.

If you could deliver on this promise of meta orchestration you could dramatically reduce the expense of delivering IT services. Electricity alone can be 60% of the operational expense of a data center. Imagine VMs (virtual machines) programmed to chase inexpensive off-peak power around the world, or moving to a data center(s) with more capacity to address a demand spike.

“Infrastructure 2.0 is not just about automation, but rather is about the orchestration of processes, which are actually two different things: the former is little more than advanced scripting, the latter requires participation and decision making on the part of the infrastructure involved.”

- Lori MacVittie, F5 Networks

Today’s tired status quo of legacy configurations between a myriad of software, systems and networks are one of the key barriers to the de facto adoption of virtualization because they ultimately limit the efficient utilization of IT resources, including power and people. They confine the power of flexibility and automation into increasingly dense, isolated networks.

Every manual process and configuration between them represents a cost and/or delay and other wasted resources. It also forces architects to build more capacity (overbuild) into each data center, to address potential usage spikes or seasonality. Note: Amazon seemingly got into the cloud business by leveraging that extra capacity.

Today’s Pony Express of manual configurations (infrastructure 1.0) is still required to keep data centers functional. As the physical servers are replaced the old processes still remain. Yet if these virtualized networks can be automated and orchestrated along with physical networks, the payoffs would transform the economics of IT.

How did we get here?

Decades ago TCP/IP set the stage for eventual connectivity between millions of networked devices. More recently virtualization migrated from development and test environments to production data centers, creating unparalleled system automation within pockets across thousands of data centers.

That automation is now trapped because connectivity isn’t enough to unite/orchestrate all of the applications, networks, solutions and systems connected by TCP/IP. That connectivity has been patched together piecemeal over decades with layers of custom configurations maintained with manual processes.

One prominent cloud VP told me recently that it cost him $700+ to simply move a server (that costs $1100 to purchase new) because of the complexity and limitations inherent within the physical data center infrastructure. That also costs millions in lost business, because of the excessive delays inherent in delivering new services (from complex environments) or the inability to service user spikes.

In some businesses margins are slim or “free services” introduce scattered, micro expenses to operations. Inflexibility and outdated infrastructure can sometimes hide legacy expenses or lost revenues in a wide array of cost centers.

What is needed today?

A new abstraction layer is now needed to allow TCP/IP to be orchestrated across diverse environments (physical and virtual) and great distances.

Today’s IT infrastructures are larger and more complex than anyone expected back in 1983 when the Arpanet was migrated to TCP/IP. With virtualization came unprecedented potentials for change/movement and increasing pressures on an already tired status quo. Soon after, cloud computing models started popping up architected for the latest demands, applying more pressure on the tired, complex world already falling behind.

As cloud computing spreads, these tired status quos will have to either evolve (e.g. more elastic private clouds) or be replaced by more efficient and elastic public cloud services. Bechtel's recent coverage in CIO Magazine gives us an insight into the future direction of enterprise IT:

We operate "as a service provider to a set of customers that are our own [construction] projects," Ramleth says. "Until we can find business applications and SaaS models for our industry, we will have to do it ourselves, but we would like to operate with the same thinking and operating models as [SaaS providers] do."

- Geir Ramleth, CIO, Bechtel, quoted in CIO, Oct 2008

The Era of Meta Orchestration

And that evolution will likely require a kind of meta orchestration, probably enabled by a new layer of IT metadata. Cisco’s Chris Hoff blogged about IF-MAP last year and raised some interesting meta orchestration potentials:

“While IF-MAP has potential in conventional non-virtualized infrastructure, I see a tremendous need for it in our move to infrastructure 2.0 with virtualization and cloud computing… Integrating, for example, IF-MAP with VM-Introspection capabilities (in VMsafe, XenAccess, etc.) would be fantastic as you could tie the control planes of the hypervisors, management infrastructure, and provisioning/governance engines with that of security and compliance in near-time.”

Chris Hoff, Rational Survivability, Nov 2008

As the private and public cloud alliances form, expect all camps to eventually have a metadata play, as metadata will enable new IT orchestration capabilities. These capabilities will drive IT costs substantially lower.

Thiele’s Mesh

Operations Director/CTO Mark Thiele talked about how smaller networks of data centers could be built at a fraction of the cost of an equivalent “Fort Knox” in September on an Infoblox-sponsored Nemertes Webinar on Virtualization and the Future of the network.

Today’s regional or branch office may indeed have more resemblance to the data centers of tomorrow than the massive “Fort Knox” cloudplexes being built today by the likes of Google and Amazon. These data centers are concentrated today because of the power, intelligence and orchestration limits inherent in today’s networks. Mainframes were “all that” until TCP/IP (infrastructure 1.0 or basic connectivity). Cloudplexes will be “all that” until infrastructure 2.0 (dynamic, policy-driven connectivity).

Others May See IT Evolving Differently

Certainly the system-centric and chip-centric vendors (like Intel or IBM) might have a different view, anticipating that IT orchestration will evolve, but only in ever-denser isolated pockets, driven by system or hardware breakthroughs. The network is perhaps a mere sideshow, not a strategic element.

Intel’s recent cloud on a chip announcement seems to be betting on such a direction, toward physicalization (centralized processing) of servers versus virtualization. By making concentrated data centers more energy-efficient and tactically flexible, Intel is making a case for an evolved, increasingly dense, server-centric future.

Who knows how these competing visions will play out, but one could have been surprised by the advance timing of Intel’s cloud chip announcement.

If virtualization crosses the chasm in two years, physicalization may have an uphill battle against virtualization (as the de facto standard). If the network players (Cisco, F5, Juniper, etc) unleash infrastructure 2.0 then cloud chips may target smaller data center meshes for adoption; the data center cloud becomes a collection of boxes (perhaps racks) scattered around the world.

The Density Disadvantage

In an infrastructure 2.0 world, density can mean disadvantage. It’s all about having physically distributed processing power behaving as it is in a single location, yet dynamically optimized to respond to changing conditions. That’s why I think it is interesting that Intel’s cloud chip advance is pre-announced, possibly to influence customer cloud expectations:

“All of this [Intel cloud chip advances] is still in the research phase, but it's at least far enough along to begin talking about. And given that many data center managers have been around long enough to remember the advantages of centralized processing, it probably won't come as too much of a shock.”

- Ed Sperling, Forbes, Dec 2009

Perhaps Intel needs to offer a competing vision to the likes of IBM (dynamic infrastructure) as well as Cisco’s Acadia venture with EMC, and other cloud container partnerships likely yet to be announced. So they enter the cloud conversation with a futuristic, powerful and flexible chip.

Today’s networks certainly aren’t ready to unleash the full potential of virtualization, but when they are it will promise a new age of IT orchestration. Disparate and complex IT islands enabled by layers of applications and operating systems, multiple versions of hardware, specialization tied to hardware, applications and networks all maintained and tracked manually will be replaced by a new layer of meta orchestration and new applications designed to allow processing power to be efficiently delivered as needed based on policies, compliance and real-time developments.

In the meantime, network administrators still rely on spreadsheets to keep up with network IP addresses. So those massive cloudplexes promise to be around for some time.

You can follow my rants in real-time at Archimedius.

We Need Vanity In the Cloud and In Your Data Center

2009-12-04T03:12:55Z

Watching the Scale, It's Not Just For Humans Trying To Lose Weight!

Dieting, the mere thought of it makes me shudder. I could easily diet if there was just no food around! What are the triggers that make us go on a diet, well there are the obvious things; appearance, health, energy level and maybe a desire to get out and enjoy the planet a little more. How are these things any different that managing our data centers, infrastructure or basic facilities more effectively? The simple answer is there isn't a difference. The only reason it's not as obvious is that we don't have simple visibility into the real performance or health of our facilities and infrastructure. As humans we have friends and family who can say "Mark it's great to see you, looks like life’s been treating you well", or worse "why are you married to that guy, he's getting old and fat?". Then there’s the mirror, the scale and the doctor, assuming our lack of breath from walking up the stairs or fear of trying on last years suit wasn't enough. And therein lies the problem, the data center, your cloud, and or your facility don't have that simple visibility that we do.

The sophistication in our current tools and the metrics should enable most organizations to put the equivalent of a health metering, management and reporting solution in place. So why haven't we? The reasons are myriad and range from a lack of concern for the issue to not having the right organization in place to identify and implement improvements. A while back I did a blog about why data centers are slow to improve and this story has some direct correlations. In that blog I point out the issue of visibility in the sense that if there isn't someone responsible for owning the data center then the chances of real improvement being made diminish dramatically. This same concept might eventually apply to the “Cloud”. If you build a cloud and don’t know what it’s supposed to look like when it’s done or when it’s running at peak/off peak utilization, how will you know you’re getting your monies worth? I’m guessing you’ll need to have a person responsible for ensuring success.

So, what to do, what to do, I guess we could just wring our hands and hope for a miracle. Unfortunately, I've never been very good at the whole waiting for a miracle thing. I've got this old fashioned belief that I need to take responsibility, what a concept, responsibility, there I said it again.

I just got off the phone with a friend in the EPA who believes like I do, that we need to get in front of the issue that faces us today, we can't wait for regulation or the famous miracle. We need to take responsibility for our environments and develop a level of visibility that can shame us into action. This visibility should take the form of an environment health, improvement, metering and management solution. The risks are in every facet of our infrastructure from the buildings to the data centers and yes, even the cloud. I know, I said it, you could even be wasteful using the cloud, who would've thunk it?

I guess the next question is where, what & how, OK, three questions.

Where - on the building, including power, water, & waste, especially e-waste. In the data center, measuring PUE, DCIE, or EUE and on the Cloud measuring “useful work per watt” or something like that.
What - software tools that can provide a sophisticated view of how your environment is running against goals, in comparison to benchmarks and or other assumptions of efficiency.
How - install the tools and use them to provide analysis, dashboards (the scale) and reporting (Global Reporting Initiative, Carbon Collective, Cap & Trade, or customers & partners).

Over the last few years I've been looking for or helping to develop tools that could help with some of the problems outlined above. One of my first hair brained ideas was to create the equivalent of a "Gas Gauge" for the cloud. The thinking was that you could monitor one screen to tell what the health (from an efficiency and capacity standpoint) of your Cloud or virtual infrastructure is. We have those tools for buildings and even for buildings that house compute infrastructure, tools like CSRware. These tools with minimal regular human intervention can help you ascertain whether a given building is performing as expected or whether you're using more or less energy or water than you should be. You can compare buildings against each other and define targets, metrics and reporting. This is what a health management solution really looks like. It's not a "fix the problem" solution (stop eating for two weeks and then go back to normal), it's a tool that helps to ensure you get on track and then stay there, kind of like a diet with teeth! This capability can be applied to a campus or to the data center facility or both. However, the real problem with effective use of resources (understanding whether we're a little or a lot over weight) is that you need to be able to quantify what it is that you're producing. In the cloud and in generic IT infrastructure there is the distinct risk of over provisioning. As humans we have an amazing ability to use up what ever extra (space, power, roads, food, money, bandwidth) capacity we create.

So I guess what I'm saying is fairly straight forward. We need to establish measurable objectives for ourselves, our infrastructure and our buildings, baseline where we're starting and measure our progress. I'm sure this isn't a foreign concept, but it's amazing how rarely it gets applied to IT, data centers and buildings. If you're just starting out and you've been inspired by someone (even yourself) to make a change for the better, I suggest starting small. Bite off something small that's got a strong 80/20 ratio. A tool like CSRware's solution is a great example, low cost and quick implementation, which is especially important for facilities that are already in operation. If you're looking for a more complete solution for a new facility then be sure to invest properly in the right monitoring and metering solutions (Energy Wise from Cisco, Foreseer from Eaton, Tivoli from IBM, etc.) that can help feed a CSRware type tool. On the cloud and virtualization front there aren't any good tools that I'm aware of yet. I think VMware is working on something, but I don't have the details and I know several groups are trying to create the all knowing data center infrastructure solution.

Time will tell, I just hope we can convince the majority of business owners before it becomes regulation. If you know a small to medium business owner pass this along, they are often the most at risk because they don’t have the scale that makes facility or Cloud operations an obvious target for the CFO. The fact that they don’t have the “scale” doesn’t mean they can’t benefit themselves and the planet by focusing on using what they have more effectively.