The Long and the Short of Agile IT
#OpenStack #Cloud #devops It's not just about operations, it's also about IT as a whole
A Forrester Infrastructure and Operations analyst, Dave Bartoletti, offered up his thoughts on OpenStack in a recent blog, "OPENSTACK SUMMIT REPORT: REAL CUSTOMERS BUILDING BETTER PRODUCTS FASTER WITH OPEN-SOURCE CLOUD", in which he mentions several real organizations that have adopted OpenStack and more importantly, why they adopted OpenStack.
There was the usual success stories of reducing time to market from months to weeks (Comcast) as well as improving operational efficiency (BestBuy). But the nugget that captured my interest was with respect to Bloomberg and its reason for adopting OpenStack:
The Bloomberg team also went open source for agility (to be able to pull out a bad or immature layer in the stack if they wanted to replace it with something better) and devops efficiencies.
It's that first one - agility - that reminded me that agility and devops isn't just an operational concern, it's an IT business concern. The kind of agility Bloomberg is seeking through implementation of OpenStack is enabled by core modern programming techniques based on the idea of "abstract and extend." It's predicated on the principles of object-oriented programming (OOP) and service-oriented architecture (SOA) that decouple interface from implementation (which if you squint and look at SDN, sounds a lot decoupling control and data planes, doesn't it?)
Interfaces and Implementations
I could dive into the theory and talk about polymorphism and reification and a host of other concepts that, unless you're really into programming language theory, wouldn't really be of much use. Suffice to say that the end result is a lot like that of interoperable protocols.
When you send a ping at any node in the network, you have no idea how the node processes and ultimately generates its response; you just know that it's going to send back to you a reply (conceptually, of course). The protocol itself is a sort of a polymorphic interface, it's a high-level abstraction of sorts. Each network-enabled device or system implements how it deals with ICMP in its own way.
OpenStack is a lot like that; it's defining a framework - a set of interfaces (protocols) that can be implemented by various data center components and thus "plugged in" to the stack. It therefore becomes a straight-forward process to replace X with Y, as long as the same interfaces are implemented.
This is pure SOA. Or perhaps as we're talking the network you'd prefer SON (service-oriented network). Regardless, it's the service-oriented design that introduces the kind of agility Bloomberg is talking about. The entire point of object-oriented anything (and by extension, SOA) was that as long as the interfaces were consistent, implementation could change non-disruptively. I can change the behavior of addVLAN to be whatever is required by the system I'm in without requiring modification to the management system. The management system doesn't care how I implement addVLAN, only that I have implemented addVLAN so it can call it and trust that I'll do whatever I need to do to execute on that and, well, add a VLAN. And if the system changes how addVLAN is implemented, well... nothing. Nothing changes in the management system. Nothing changes in the overall architecture. The change is localized and impacts on the device in question.
It's also the means by which heterogeneous infrastructures can be more consistently managed. If vendor X and Y can be plugged into OpenStack and managed via the same means and methods (which derives from the polymorphic principles of OOP, if you were interested) then organizations gain a lot of flexibility (agility) in picking and choosing what elements make up the infrastructure fabric.
It also means scaling functionality along with growth of the business. You might start out with a commoditized hardware-based switching fabric managed by OpenStack but at some point require some advanced network functionality that requires a more dedicated hardware-based solution. Assuming that the solution has implemented the appropriate interfaces, OpenStack provides the means by which you can switch out (plug-in) the new solution and take advantage of that functionality without having to worry about the operational overhead of a new device or vendor or management system. This is the long view, the view of agility as a long-term growth enabler that doesn't require IT compromise on capabilities or ability to extend functionality when needed.
This was largely the goal 5 years ago when we started talking about Infrastructure 2.0:
Making Infrastructure 2.0 reality may require new standard
Managing a heterogeneous infrastructure is difficult enough, but managing a dynamic, ever changing heterogeneous infrastructure that must be stable enough to deliver dynamic applications makes the former look like a walk in the park. Part of the problem is certainly the inability to manage heterogeneous network infrastructure devices from a single management system.
...
VLANs, IP addresses, gateway, routes, pools, nodes, and other common infrastructure objects must be managed and configured across a variety of implementations. Scaling the management of these disparate devices and solutions is quickly becoming a nightmare for vendors involved in trying to build out large-scale data centers, whether those are large enterprises or cloud computing vendors or service providers.
OpenStack is the reification of the idea of an Infrastructure 2.0 standard; of a system that scales management of disparate devices heterogeneously. It's enabling agility narrowly by improving operational efficiency and broadly by enabling choice and extension of functionality without adding operational overhead.