OpenStack is a project & technology that is close to my heart. While at Red Hat, I spent a lot of time working with early adopter customers across financial services, telco & media & entertainment who were building heavy duty OpenStack clouds. While I missed the Vancouver Summit (May 2015) due to personal reasons but have been following all the different projects as they go along their merry way adding features & continually improving stability.
A major analyst firm (one of the big two) Forrester just released a report that seems to sums up what acolytes like myself have been saying all along – “OpenStack is ready – are you?”
Report at the link below
This report clearly validates that pathbreaking early adopters (use-cases in a bit) are beginning to move proof of concepts and pilots to production & reaping the benefits of transformational technology.
For the uninitiated, OpenStack promises a complete ecosystem for building out private clouds. The OpenStack Foundation is backed by some major technology players, including Red Hat, HP, IBM, AT&T, Comcast, Canonical/Ubuntu, HO, VMWare, Nebula, Rackspace and Suse. Built from multiple sub-projects as a modular system — OpenStack allows an IT organization to build out a scalable private (or hybrid) cloud architecture that is based on an open standard, unlike Amazon Web Services (AWS). This is particularly relevant in financial services given the cost and regulatory pressures banking organizations are under, as well as a need to derive competitive advantage from agile implementations without incurring the security and business risks of a public cloud.
One of the key differentiator’s of the OpenStack project is that it is composed up of various sub-projects and one does not need to do an end to end implementation of the entire ecosystem to realize it’s benefits. It is designed to provide a very high degree of flexibility as modules can generally be used in combination, or be used as one off projects.
The report validates that OpenStack has been production grade for a while and early adopters who were brave enough to run initial production grade applications are reaping the benefits of being prescient & courageous about being able to follow their convictions. In today’s fast moving business landscape where forces like Big Data, Social,Mobile and Cloud increasingly dominate, you will either be disruptive or be disrupted. The race to build platforms and expose those business capabilities as APIs while providing seamless provisioning and service to your development community is key. OpenStack is all about being an elastic, agile and cost effective Cloud OS that enables you to layer in higher order capabilities like PaaS and SaaS.
Let’s trace a brief history of OpenStack from a release maturity standpoint as reproduced below from the OpenStack community website.
| Series | Status | Releases | Date |
| Liberty | Under development | Due | Oct 15, 2015 |
| Kilo | Current stable release, security-supported | 2015.1.0 | Apr 30, 2015 |
| Juno | Security-supported | 2014.2.3 | Apr 13, 2015 |
| 2014.2.2 | Feb 5, 2015 | ||
| 2014.2.1 | Dec 5, 2014 | ||
| 2014.2 | Oct 16, 2014 | ||
| Icehouse | Security-supported | 2014.1.4 | Mar 12, 2015 |
| 2014.1.3 | Oct 2, 2014 | ||
| 2014.1.2 | Aug 8, 2014 | ||
| 2014.1.1 | Jun 9, 2014 | ||
| 2014.1 | Apr 17, 2014 | ||
| Havana | EOL | 2013.2.4 | Sep 22, 2014 |
| 2013.2.3 | Apr 03, 2014 | ||
| 2013.2.2 | Feb 13, 2014 | ||
| 2013.2.1 | Dec 16, 2013 | ||
| 2013.2 | Oct 17, 2013 | ||
| Grizzly | EOL | 2013.1.5 | Mar 20, 2014 |
| 2013.1.4 | Oct 17, 2013 | ||
| 2013.1.3 | Aug 8, 2013 | ||
| 2013.1.2 | Jun 6, 2013 | ||
| 2013.1.1 | May 9, 2013 | ||
| 2013.1 | Apr 4, 2013 | ||
| Folsom | EOL | 2012.2.4 | Apr 11, 2013 |
| 2012.2.3 | Jan 31, 2013 | ||
| 2012.2.2 | Dec 13, 2012 | ||
| 2012.2.1 | Nov 29, 2012 | ||
| 2012.2 | Sep 27, 2012 | ||
| Essex | EOL | 2012.1.3 | Oct 12, 2012 |
| 2012.1.2 | Aug 10, 2012 | ||
| 2012.1.1 | Jun 22, 2012 | ||
| 2012.1 | Apr 5, 2012 | ||
| Diablo | EOL | 2011.3.1 | Jan 19, 2012 |
| 2011.3 | Sep 22, 2011 | ||
| Cactus | Deprecated | 2011.2 | Apr 15, 2011 |
| Bexar | Deprecated | 2011.1 | Feb 3, 2011 |
| Austin | Deprecated | 2010.1 | Oct 21, 2010 |
As far as version and component maturity goes, most forward looking customers started heavy duty evaluation with the Havana release in 2013. It is as if they said “Alright – everything is here from the perspective of an enterprise cloud operating system – compute, storage, network, a path to upgrades, certifications from established vendors and an enterprise roadmap etc etc.”
(Src – Cloud Enabled)
And when the next version, Icehouse came along, people said “that’s production and we are going to run this for real”.
And so, from an enterprise standpoint, what made Icehouse palatable, was that it was made upgradeable (take an OpenStack Havana cloud and upgrade it in place to Icehouse without bringing your workloads down)
Before that from Grizzly to Havana, you had to take your workloads down as upgrades happened since OpenStack trunk releases a major version every six months.
Add to that the 3 year enterprise lifecycle from best in class vendors like Red Hat, that avoided a lot of the churn with having to keep up with releases made it a very attractive proposition.
Block storage and Software Defined Networking – SDN (more around SDN in a series of followup posts) were also mature beginning the Havana release. Plugins had been worked out & certified for the major vendors like EMC, Hitachi etc. Project Ceilometer was also created and was crucial with an ability to get visibility into metrics. Project Sahara was created as an incubator to run Hadoop workloads on an OpenStack cloud. Cloud plays a role in the life cycle of development, deployment and optimization of Big Data applications. Innovation at the largest enterprises is often shackled by the absence of a responsive and agile infrastructure. It can take days to procure servers to host bursts of workloads that may not be feasible for existing IT departments to rapidly turn around. This problem is by no means unique to Big Data but what makes it even more relevant here is that processing needs in this specialized area are typically larger than your average IT application.
The other major gain from a deployment standpoint was Project Heat.
So, there is some value in being able to provision VMs into OpenStack but people have been doing that forever using a VMWare or a Red Hat Virtualization but where Heat gives you a distinct advantage is in being able to provision entire application stacks.
Using Heat, the granular unit in the service catalog or the contract between the service catalog and the infrastructure becomes an application. Heat provides an amazing this level of orchestration.
You can think of people using EC2 Cloudformations API..use 7 API calls to provision 7 VMs. More to provision storage, so you are looking at 10-15 calls. You need to check the status of these calls, check the result, put it into some workflow, check for errors etc.
With Heat, it is a single API call and then you define the stack declaratively along with the network dependencies. When you invoke this from a service catalog, you can imagine that the service catalog can have its own workflow and that is going to be something like .. “User requests resources”.”Check to make sure that the resources are available”.”Check users permissions and authority”.
Currently most large customers use some kind of proprietary provisioning tool to provisioning complex stacks with compute,network and storage dependencies with a bunch of 3rd party callouts, which as a model is a huge pain in that if something goes wrong, you don’t know what failed and how to even rollback. When Heat is leveraged, all of these desirables become native capability. A single API call, with a well defined audit, stack-trace and rollback.
The other thing that is important from large customers is that a couple of years ago, most started to standardize on a declarative model and these patterns. They already have dozens of patterns they have to provision their public cloud workloads back to private clouds built on OpenStack.Given that Heat is Amazon CloudFormations (CF) compliant, all those APIs are easily translatable.
Anything you can do using OpenStack is automatable and describable via Heat.
From the Forrester report –
Regardless, OpenStack’s own continuous release cycle of new OpenStack modules reflects the agile, continuous delivery that many evolving BT organizations look to mirror (see Figure 2). Whether enterprises establish and build a center of OpenStack excellence internally or leverage it through a series of vendor partners, they are turning to OpenStack as the platform layer of their solutions across core projects tying into the larger BT agenda.
So what are some of the enterprise use cases for OpenStack –
A) Create a DIY IaaS and basic PaaS in support of DevOps–
The two step process to do this looks like the below –
i) Replace homegrown cloud platforms –
Typically for a PaaS..i.e running systems of engagement like web properties and three tier application. A lot of technical debt built on BMC to orchestrate VMs, PaaS’s and Containers.
Typically for a PaaS..i.e running systems of engagement like web properties and three tier application. A lot of technical debt built on BMC to orchestrate VMs, PaaS’s and Containers.
ii) Install the PaaS on OpenStack and give developers self service access and potentially even run workloads on Docker managed containers on their Linux operating system or even on a container optimized OS like RHEL Atomic.
B) Telco & NFV –
NFV (Network Functions Virtualization) to virtualize network functions like routers,switches and do so to automate network functions that are expensive and hardware based.
C) Big Data / HPC workloads –
D) Move to a Software driven datacenter by replacing expensive and proprietary virtualization solutions
In summary, OpenStack has a ton of promise and is slowly emerging as the de-facto standard for building out private clouds, and as a way of reducing CapEx and OpeEx while converting massive amounts of compute, network and storage resources into a Software Defined Infrastructure. While there are still kinks to be worked out in terms of making the SDN more robust, better native provisioning, deployment & config management support – I expect that all these will duly be worked out in the months to come.