In a nutshell, ONF has been concerned with defining a set of interfaces that would be implemented inside of network switches to allow an external controller, typically running on a standard server, to get information from the switch and to send commands to the switch to control how the switch steers traffic.

Independently, within IETF, there is an effort to formalize a working group to address how single and multiple networks can be managed and configured to meet emerging requirements of service providers and enterprises to coordinate the network management and configuration with applications, services and the compute region.

With an organization, a PR budget, and sixty-plus members, a lot has been written about ONF.  ONF and OpenFlow grew out of efforts to develop and promote as an approach to allow universities and network researchers to experiment with new networking algorithms in ways they couldn’t with the embedded flash firmware which is locked down by the vendors. Nick McKeown, a professor at Stanford, observed that network technology transfer from academia to products had largely dried up.

Although the ONF vision is quite broad, the standardization effort has been confined to the specific OpenFlow protocol and APIs that are the basis for communication between an OpenFlow-enabled switch and an OpenFlow controller. This has been accompanied by discussions about the underlying hardware support needed (including the chips inside the switches) and potential use cases for OpenFlow controllers.  Although mostly focused on Ethernet switching, there is interest in a much wider range of applications, from optical wavelength management to security applications.

In contrast, the IETF SDN discussions, which have not received much publicity, are mostly about management frameworks, data models, and coordinating management across networks.  This includes, but is not limited to networks using OpenFlow protocols.

To oversimplify, in a diagram of network management, the “Northbound” interface to an OpenFlow controller would be the “Southbound” interface to an IETF SDN-style framework as the figure below illustrates.

To date, the IETF SDN activity, which isn’t yet formally recognized, has not seen much publicity. This will change.

Why is LAYERZngn concerned with this?  We have several reasons.  First, it’s in our DNA.  Second, several people who are waist deep in the initiatives have been telling us that the framework underneath CPlane Surveyor, our multi-layer infrastructure-to-applications discovery, mapping, and correlation solution is very well suited to address the requirements of both groups.

We will cover the role of LAYERZngn in a future post.  Before that, let’s review the focus of each set of activities.

ONF (Open Networking Foundation) and Software Defined Networks

In March, 2001, ONF was launched.  According to the ONF website, (www.opennetworking.org), ONF has both a vision to “make Software-Defined Networking the new norm for networks” and a mission to “create the most relevant SDN standards” and a goal to “rethink networking and quickly and collaboratively bring to market standards and solutions”.  The term Software-Defined Networking has been around a few years and appeared in an article in the March/April 2009 issue of Technology Review.  While SDN is sometimes characterized as synonymous with OpenFlow, those close to it point out that SDN also refers to networks that don’t use OpenFlow.

While ONF is a young organization, it is based on several years of work.  Its board of directors include representatives from major communications and cloud service providers, and a list of members which includes many vendors from small to large, and active participants with deep experience spanning chips, software, and people involved with production networks.

ONF’s charter indicates it is pursuing a broader direction than just OpenFlow.  From their website their first goal is to “create a switching ecosystem to support the OpenFlow interface.”  To this end, they have released two versions of an OpenFlow protocol specification, and are expected to release version 1.2 in early 2012.

This part of what ONF is doing is based on a pretty simple concept.  With existing production networks whether Layer 2 Ethernet or Layer 3 IP protocols, the decisions of how to send traffic happen in the device that is receiving and sending the data traffic. With OpenFlow, the traffic steering decisions are made by an external device, and communicated to the device that handles the data.  Whether this is called “routing” or “switching” or something else has been the subject of discussions and blogs, but, ONF, for its part, uses the term “OpenFlow Switch”.

Why ONF is Important

The motivation for separating the decisions (i.e. the control plane) from the data steering (i.e. the data plane) is very strong, going well beyond the original motivation.

As the number of network nodes and interconnecting links increases, ONF’s approach to SDN addresses several complexity problems.  For a long time it has been common for telecom networks to have separate control and data planes.  In the computing world, InfiniBand fabrics that connect supercomputing clusters operate this way, where an InfiniBand controller is used to configure the network devices.

Masses of merchant silicon-based servers that need to be interconnected, plus exploding numbers of virtual machines have increased the to the point where a single data center has more end points than the entire Internet skeleton of a just few years ago.

A second major motivation comes from the improvements in of-the-shelf merchant switching chips, which are now available with 64+ 10Gigabit Ethernet ports on a single chip.  At this scale, it makes sense to build distributed switching fabrics of single-chip switches, rather than build bigger centralized switches.

This is not unlike what occurred with computers.  When single-chip processors were produced with enough processing power to run multi-tasking operating systems, this enabled software for distributed applications.  In the 1990s a lot of innovation went into heavy-duty transaction processing which was previously the exclusive domain of high-end tightly-coupled multiprocessor systems.

IETF and Software Defined Networks

The motivation for the IETF SDN activities was from a different perspective. The proponents saw a need to develop standards around applications and services to address emerging needs to coordinate network configurations with the configuration of physical and virtual machines and applications, spanning multiple networks and data centers.

This was kick-started with a BoF (Birds of Feather) session at IETF 81 in July, 2001 on the subject of Software Driven Networks.  Another BoF was held at IETF 82 in Taipei in mid-November which had 500+ attendees. The presentations made at that meeting are available on the website for IETF 82. This effort is still in an unofficial state, and consequently has not received the press that ONF has, but there is real interest. While the name the IETF activity proponents picked shared the same acronym for a different name, some of the presentations and discussions are within the bounds of the concepts of what ONF is concerned with.

Why IETF SDN Is Important

The evolution of cloud and mobile services are leading service providers and vendors to wrangle with applications scenarios which are not brand new ideas, but which are now much closer to wide adoption.  Along with this, the vendors and service providers are trying to cope with an increasing number of subsystems that collectively encompass formal standards, proprietary solutions (some home grown by the service providers, some from vendors), open source projects, such as OpenStack, and new protocols such as OpenFlow. The protagonists of the IETF initiative are also concerned with how new technologies are incorporated into existing networks and services.

Although the IETF activities are still working on their mission, a central theme is that a standardized framework model, with some standards around the various APIs would be beneficial to both vendors and customers.

Along with these two trends has been the rise of business applications comprised of multiple software components and services, which depend on a myriad patchwork of other hardware, software and web services that have outstripped traditional management technology.

These trends bring promise, but also architecture and systems management complexity.  Here are some examples:

IT organizations are managing upwards of five times the number of virtual servers per headcount that they had to manage with just physical servers, and in some organizations it is already an order of magnitude.  For enterprises that have implemented a CMDB, it is going to get harder to keep it up to date.

Speed to service creation is one major reason to put applications in virtualized, and virtual Cloud environments. Although it adds more layers, and more things to manage, it can also eliminate sources of complexity. For example, ordering a petabyte of storage at a major cloud service provider in many situations is much simpler than deploying a petabyte of storage in house.

Along with this, IT organizations are also seeing accelerated entropy,  where clustered applications more quickly expand beyond the confines of a single rack. This brings with it increased likelihood of network bottlenecks, because the inter-rack network bandwidth capacity is often oversubscribed.  This makes it increasingly important to be able to look at the compute and network silos as inter-related components of a system.  As this happens, it will become more common occurrence for the hot spot that the applications performance management system found to actually be caused by a network bottleneck.

In looking at where Cloud is headed, IT organizations are going to be increasingly concerned about hybrid environments where the data is on one side of their WAN connection and the applications are on the other.  Maybe they want to keep the corporate data inside their control sphere, but want to access it from some third party Cloud application.  Or maybe a Cloud pilot becomes a hit, resulting in a new data repository that will be access by incumbent enterprise applications.

IT organizations will need new capabilities to meet these new challenges:

• Management tools that allow them to understand the relationships among the compute, applications, data center network and wide area network regions.
• The ability to replace manual data entry about IT assets with automation.
• Self-service systems management to go along with self-service provisioning, allowing each business applications owner to not only provision their own applications but to manage them without having to ask IT operations about inter-dependencies and status.

Now let’s explore how the software industry is responding.

Ever since computers were applied to business automation, the software and hardware vendors, industry consultants and pundits have talked about the resources consumed supporting the existing applications.  We have all seen the pie charts where 1/3 of the pie is new applications and 2/3 of the pie is supporting the existing stuff.  The numbers vary, but it is always more than half the total going towards maintenance and support.

Predictably, vendors are attacking this with approaches consistent with their position in the marketplace and where they want to go.  The major vendors of enterprise software are for the most part, saying “buy all of your enterprise software from us.”  That way you only have one throat to choke.

One leading software vendor has gone so far as to paint the future as the reinvention of the mainframe, and the best approach is to buy all your software from one vendor  But that is now how it was.  The mainframe industry in its heyday included a number of third party software companies with names like SyncSort , Computer Associates, BMC Software, McCormack & Dodge, Cullinet,  Software AG and Another leading company at the time, Applied Data Research, arguably invented third-party software packaging.

The idea that IT organizations bought all the software from their mainframe hardware vendor is a myth. One of our team remembers hearing first-hand from the head of IT at Volkswagen of America in the late 1970s that they had sixty five different software packages.

In fact, there is a lot of evidence that heterogeneity is increasing, despite continued industry consolidation.  Faster than smaller companies get gobbled up by the big guys, new products from small companies appear.

There is another phenomenon you can see. While every one of the leading software vendors has a major cloud initiative, there is a gap between their vision and what the major cloud providers are actually doing.  One of Amazon Web Services’ largest customers, Netflix, has publically said they are moving away from a leading database vendor.

This doesn’t mean that the incumbent software vendors are not going to continue to grow.   And, many of the incumbents will be successful selling the approach of “buy everything from one source.”  But those very same customers are going to continue buying other software products from other independent vendors.

For most enterprises, as many have already noted, Cloud is going to be a part of an overall portfolio, with a lot of loosely-coupled connections among the cloud and incumbent systems.  Those organizations which went from “the corporate data base schema” in the 1980s, to a “service oriented architecture” in the last decade now find themselves looking at an overall information architecture which more resembles an ant farm, with various chambers of activity, tunnels between them, and loosely-coupled divisions of labor.

Bottom line: Business applications are being built out of loosely-coupled components and services. In many cases the components are evolving in their own ways and on their own schedules.

What is needed in this environment, is a new approach to systems management, where the management of the systems spans the components, and just like provisioning tools, need to be designed for self-service.  Ideally, these new products, in order to lower the barrier to adoption, are going to design their products to be easy to choose, easy to purchase, easy to install, and easy to use. There are already a couple of good models for this: Apple iTunes and Android Market.

The 70/30 or thereabouts ratio of support to new projects is not likely to change.  Given that it hasn’t changed much in the past 40 years in the face of tremendous change in hardware and software technology, it might in fact be a kind of “Law if IT Thermodynamics”.   In other words, it may be more of a reflection on how fast organizations can absorb change rather than indicative that IT organizations are sub-optimal or that their vendors have failed them.

But what makes up the resources expended will, just like it has since the dawn of business automation.

This situation is challenging enough with internal IT teams, but what happens when you are calling a Cloud provider? You have less control over their response and you have to compete with larger companies for the same resources. Adding a service level agreement with tiered service does not really help. Sure the public Cloud provider’s IT team will pick up the phone sooner when I call on the premium hotline, but do I really get better service if I am unable to specifically describe the location of my problem? To be fair, can the Cloud provider’s IT team really know where to take action, without spending hours combing through the system stack?

What is needed is a way to translate the customer’s complaint into something that IT can use. The traditional IT management tools are not the answer. They are primarily focused on the IT team’s overall view of a system and are not specific enough. In order to capture the customer’s view we need to focus on applications and their interrelationship and dependencies in order to define the scope of what can cause the issue. Once this information is captured, it needs to be tied to all the different layers of a system. This will link applications, application components, hardware and networks together, creating the ability to traverse the complete application stack and drill down to any system layer to find our issue.

With this new capability in place there are a number of ways to resolve our system slow down problem. The simplest is to call IT and let them know the specific application that has the issue. IT can then navigate the application system stack to find the most likely cause. The second possibility is that the Business Application Owner has access to the application stack and they can locate the problem before calling IT. In both cases the focus on the application provides a framework that shortened the time needed to resolve the issue.

The ability of a Business Application Owner to drill down into the application stack and find an issue before calling IT is a big advantage when dealing with a Cloud provider. They can now provide enough information to the Cloud provider’s team to have a good chance of getting the issue resolved. This shortens the problem resolution time and will jump your issue ahead of those other companies that are still reporting a vague application slowdown.

Eventually this type of management software that can translate and flatten the views between IT and application managers will become more important as businesses, who are nervous about moving to public Cloud solutions, demand a level of service that makes them comfortable with loosing direct control over IT resources and business applications.

Next time you need to reach for your ‘rolodex’ to contact IT, think of how much easier it is now that you have this capability in place. You now have a specific suggestion for where the issue is located and you know before you pick up the phone, which IT area can help you.

Just yesterday the LAYERZ team was engaged in a discussion on this topic and the conclusion was that the technologies that underlie the cloud service model are becoming quickly commoditized. In fact, we’ve reached the stage where the hypervisor is simply becoming another operating system, with all its benefits and complexities. Ultimately, customers simply want their applications to run efficiently, effectively and reliably on top of this cloud infrastructure. As we have shared before, the future is about building applications from collections of services that live in the various cloud models, and ensuring that the owners of those applications have clear visibility to all those services and how they connect together. But more importantly, it’s the ability to share that view with all of the owners of those services – so they have the same view of the application ecosystem. Without this coordinated and consolidated view we will continue to point fingers when something goes wrong.

So now that we’ve reached the stage of infrastructure commoditization, what’s next? We are quickly seeing the jockeying for position in the various sectors and disciplines, and over the next couple of years the key players in the services delivery and management space will emerge. At the same time we will also see the architectural boundaries between the various cloud services models start to blur, and in effect we will see the “converged cloud” emerge. What’s driving this change? First, cloud-based application performance requirements are dictating that cloud services act like “distributed systems”. That is, they live under the same requirements for “RAS” that we’ve come to expect from legacy systems. Good enough simply won’t be good enough in the future model.

Second, smart mobility and the demand for large amounts of data movement and management is going to require that the interconnection of cloud-based services provide higher levels of responsiveness and performance. We are already seeing this become a major focal point as cloud providers, hosting companies and managed services providers are teaming together to provide “direct connect” capabilities. At the same time, carriers are recognizing the revenue opportunities of this market and are jumping into the fray – offering cloud services on top of their connectivity services.

As the elements of the cloud continue to converge into a distributed services delivery capability, the notion of “end-to-end” service level management becomes more important. Tools that work inside the data center simply won’t be sufficient to mange all the elements that make up cloud-based applications. Quality of service at the end points, integration points and across the global networks that connect them will be a key aspect of defining the performance requirements of those applications – and the end user experience. Not only do we have to worry about traffic that has shifted from “north/south” to “east/west” inside the data center, but we may also need to understand the implications of quality of service over global carrier networks.

IT managers that rely on traditional silo tools are going to be faced with ever-increasing costs as they try to manually meld the disparate views those systems provide into a cohesive end-to-end picture of highly distributed, services-based applications. But worse, they will be faced with lack of visibility and the ability to manage (either directly or indirectly) the elements that are essential to the health of their applications. Net result, without an integrated approach to managing this convergence, business and IT managers are going to fall short of realizing the value that the converged cloud offers.

What cloud computing brings to the landscape is not so much about technology as it is about how services are delivered. Over the years we became accustomed to “self-contained” solutions comprised of building blocks that we would acquire from a handful of vendors. Planning cycles were longer (too long…) and control over the application “ecosystem” was easier to enforce and manage. Cloud computing has somewhat opened the flood gates and allowed the surge of readily-available services to wash over us, often leaving a lot of debris in its wake. We’re experiencing the same “giddiness” that we did when we realized that we could bypass corporate guidelines and go out and acquire PCs and laptops with our credit cards, building our own little “IT shops” inside our business units. We are potentially headed down that same path with cloud computing.

I’m actually moving away from this picture of a stack. I think this picture of a stack where you have infrastructure at the bottom, platforms on top of that and all the services on top of it is actually just a model. It is really outdated. In essence, most of the whole Amazon cloud is much more than the Amazon services. It is a whole collection of all services from all ecosystem providers as well. So there’s many different players. Many in the ISV world, many coming out of the system integrator world and management world that are adding so many different services into the Amazon ecosystem that the cloud is much more, and can no longer be define by just having strict layers. Many applications will be pulling different services from different places and connecting them together.

Werner Vogels, Amazon CTO – GigaOM Structure 2011

Building applications from cloud services is a great thing – if managed properly. It gives us flexibility, agility and responsiveness on a scale that we have never before seen. Companies can now not only react to market conditions – they can anticipate them and offer new services in advance of those trends.

With that flexibility, agility and responsiveness comes some challenges. Application performance, while always a challenge, is now even a bigger challenge – as you are now more dependent on the performance of resources that are outside of your control – with little consideration for service level agreements.  Sustainability is another key consideration – services come and go, and if not careful, many enterprises may get caught in a “spring cleaning” session, with APIs suddenly (or with little warning) disappearing. Reliability becomes harder to maintain as service providers arbitrarily deprecate interface methods and procedures with little warning.

As we have seen from some of the post mortems of recent cloud outages, application design, not only for performance but also for recoverability is not getting any easier. While the cloud makes life simpler on some fronts, it adds complexity on others. This leads us to the notion that the application “owner” now has to play a larger role in the oversight of the application life cycle. As seen in the quote from Werner Vogels, we no longer live in a world where you can draw the application as a simple “stack”. Application owners, architects and operations all have to play from the same playbook which in some cases is pretty complex. Creating the view of the application of the future requires a close connection between not only the infrastructure that supports it, but also the connections to and dependencies on many services outside the direct control of the enterprise.

Like application architectures, it’s time to re-examine the tools we use to create those playbooks.  The tools that create the view of the apps will also help with the communication between the owners/managers of all the components and infrastructure (at all levels) when something goes wrong. This will get everyone talking the same language/terminology (think of a analyst which is in charge of configuring an Accounts Payable module of an ERP talking to a network administrator).  This becomes even more challenging when they all work for different companies.  Time to resolution would drop significantly which will allow vendors to provide better/aggressive SLAs.

How’s that company-wide CMDB implementation going?

It sounds like an innocent enough question, but for many organizations, the answer is, it isn’t done yet and often it is way past the original target completion date. For other organizations, victory may be been declared, but the burden of the phone calls, the emails, and filling out the spreadsheets so that the CMDB can be kept, relatively speaking, up to date has people muttering whether the ends justify the means.

And still, for all the attention CMDBs have gotten over the past 5 years, our guess is that well under 20% of IT organizations have CMDB-based IT asset management systems up and running.

There are multiple reasons why this is happening. Getting a CMDB up and running requires cross-organization commitment to change day to day procedures, and use the new repository and dedicated resources during the implementation phase. In this era of never-ending IT budget pressures and adoption of virtualization and cloud technologies, and getting access to all of the resources that were committed when the project plan was approved can be a challenge. This is normal slippage in the planned part of the implementation.

On top of that there are all the unplanned things that happen. The VP of finance reads a magazine article about cloud computing saving money, and the CMDB implementation gets interrupted while you come up with a “cloud strategy”. Since a CMDB implementation starts with a comprehensive inventory of all of the IT assets, surprise discoveries are inevitable.

The non-production inventory application for your remote offices running on Windows NT 4 that IT pretty much forgot about years ago? If you have the right process, you will find it. And, more than likely, you will decide you should track down the owner, find out if they still need it, figure out if it can/should be upgraded, etc. All of which adds up to useful activity, but also an unforeseen hit to the schedule.

Over time, they add up.