There’ve been various discussions in the community on OpenStack Interoperability and Portability.
The discussions tend to be centralized around the future of the OpenStack API and whether or not it would make sense to support the AWS API on top of OpenStack to allow for better compatibility with the AWS environment.
From a recent webinar titled "OpenStacking your enterprise applications," we chose four fairly different use cases from various types of organizations, each of which took a different approach to "OpenStacking" their applications using a combination of Cloudify with either Chef or Puppet.
Despite the differences in strategy and the challenges each organization faced, the way in which they all implemented their strategies shared much in common, which is the reason we feel that they are also relevant for this discussion.
This week we will be joining the OpenStack NY Meetup: AWS APIs: What's the Big Deal? to discuss this subject together with Randy Bias and Dave McCory. Even though the topic of this post is not necessarily directly related, we thought that sharing these case studies could broaden the discussion beyond APIs and provide other perspectives on OpenStack interoperability and portability.
1. App First vs IaaS First: Taking an Application-Centric Approach when Moving to OpenStack
One of the biggest banks in the US runs today over 10,000 applications across the organization.
The bank had various initiatives for building a private cloud infrastructure, but none of them was at a maturity level that would allow the bank to move a large chunk of their applications onto such an environment. In addition, the bank is still considering the move to OpenStack and concerned by the level of maturity of the OpenStack framework.
Most other organizations take an IaaS first approach, in which they first try to figure out the IaaS layer and only then move up the stack. The problem with this approach is that it of often takes a fairly long time to get this first bit to work. Many who took this approach had to redo large parts of their work as new frameworks and products started to emerge. The other challenge is that they often discover that this infrastructure isn't yet ready to run their apps in production. Moreover, they often learn this quite late in the game, when they’ve already started to move their apps to the new infrastructure.
In this specific case, the bank decided to move in parallel in both IaaS and application-centric approach, starting the process of moving their applications to the cloud in two parallel tracks. Here is how it worked:
-
They used an automation-first approach, leveraging a combination of Cloudify and Puppet to turn their applications into cloud-ready apps.
-
They abstracted the applications from the underlying infrastructure by not using anything specific to infrastructure layer.
-
By abstracting the infrastructure tier from their applications they could use both their existing infrastructure and the OpenStack environment in parallel for deploying their applications, allowing for a simple switch of between those two environments without having to re-do any of their work.
-
They leveraged their existing Puppet assets to speed up the "Cloudification" process.
Main Benefits
-
Time to value - Speed up the migration to the cloud by parallelizing the effort of setting up the IaaS layer and cloud-enabling their apps.
-
Reduced risk - By decoupling their apps from the infrastructure, the bank could decide which applications to move and when.
-
Immediate value - Plugging automation first allowed the bank to get an immediate benefit through automation of their manual processes even while they run on their existing infrastructure.
-
Gradual migration - Using the same deployment management tools across their existing data center and cloud infrastructure allowed the bank to easily move applications from one environment to the other. This allowed them to gain much more flexibility when implementing their migration approach. For example, they could run their testing/staging environment on the cloud and keep the production environment in their existing data-center. They can later to decide to move the production environment to the cloud once they feel confident with the environment.
-
Easy upgrade of their IaaS layer - The decoupling of their application from their IaaS environment allows the organization to be less sensitive to changes and new releases of their new IaaS layer and thus, adopt new IaaS releases relatively fast.
2. Moving Big Data to OpenStack
A leading System Integrator provides services around BI solutions which include Cognos, IBM BigInsights (Hadoop) etc. Their existing customers run mostly on-premise. In many cases, they even use bare-metal machines due to the I/O intensive nature of those applications.
Having said that, the cost of setting up such an environment has became a major inhibitor in the sales process, up to the point where new prospects and customers were not ready to pay the cost of setting up a large environment before they could evaluate the product for their needs.
For that purpose, it made sense to provide those BI products on-demand first using the cloud, and deliver the product in the customer’s data center once they were ready to make the switch.
The approach that they have taken was to automate the deployment and management of those products on one of the public OpenStack clouds and offer them on-demand through a self-service portal. Then, they could offer that same product in the customer’s data center.
This process looks fairly similar to the one in the previous case, except that in this case, the primary deployment environment was the public OpenStack cloud.
Here is how that worked:
-
They implemented automation first using Chef and Cloudify.
-
They abstracted the applications from the underlying infrastructure - to enable smooth migration from the trial environment on the public cloud to a production environment on a private cloud / traditional data center.
-
They enabled each user to run his/her own *private* environment on the cloud by provisioning a complete cluster for that customer on demand.
Main Benefits
-
SaaS enablement without code changes - They now deliver their existing BI product portfolio on the cloud without having to wait for each product to become cloud enabled by its vendor.
-
Consistent Management - They use the same management tools for provisioning and controlling the various BI products on their portfolio.
-
Frictionless process from trial to production - They use the same management and provisioning infrastructure between the trial environment on the public cloud and the production environment on a private cloud.
3. Carrier Cloud - Creating a Virtualized Carrier Backend on Top of OpenStack
The economic pressures on the telco market force many of the carriers to look for ways to reduce their infrastructure costs. One of the ways to reduce their operational and infrastructure costs is to use virtualization and cloud driven infrastructure.
A major trend in that category is known as NFV (Network Function Virtualization) in which carriers move all their services that currently run on many proprietary hardware appliances to software-based infrastructure that can be installed and run on any cloud infrastructure.
One of the leading providers of such a solution is Alcatel-Lucent with its new product, CloudBand.
The challenge that Alcatel-Lucent faced is that most of the existing carrier products, including some of its own, were not designed to run on top of virtualized environments, and specifically the cloud.
By taking an automation first approach, they could turn many of those existing products into cloud services that can be delivered on their OpenStack-compatible carrier cloud platform, and thus enable carriers to speed up their move to NFV without waiting for all their suppliers to support this environment.
You can read more about the Alcatel-Lucent use case here.
4. Migrating from Amazon to OpenStack
A SaaS provider in the transportation business is providing tracking services for vehicles. They run their entire service on Amazon. During the past year, they had to deal with several outages. They were looking for ways to reduce the chance for outages as well as how to reduce their costs and their dependency on the AWS infrastructure.
Out of all other options for cloud providers, OpenStack provides a range of choices for OpenStack-supported cloud providers, with the additional benefit of having the option to run it on premise under their full control. Having said that, the current reality is that many of the OpenStack providers are still lacking many of the services that AWS provides such as auto-scaling, RDS, load balancer as a service, etc..
Cloud-enabling their application allowed them to break each of the tiers in their application into individual services that can be wired together during deployment through the orchestration capabilities of Cloudify.
When running on OpenStack, they were able to complement the missing services such as load balancing and auto-scaling in the OpenStack environment, through a rich list of existing middleware technologies supported by Cloudify and Chef. At the same time, they chose to turn off these services and use the ones provided by the infrastructure provider when applicable.
Having said that, moving their entire application to OpenStack was too risky. To reduce that risk, they wanted to use a hybrid approach in which they will continue to run their AWS environment and move gradually to OpenStack only after they will feel comfortable with the environment.
Using OpenStack as the DR site allowed them to reduce their sensitivity to AWS outages and at the same time enabled them to move more gradually onto OpenStack.
As with the previous case, they were able to achieve all their goals by abstracting their application from the infrastructure, using a plug-in approach to enable simple switching between AWS and the OpenStack cloud environments, as well as using OpenStack as a DR site first.
Main Benefits
-
Improved high availability by reducing the dependency on a single infrastructure provider
-
Reduced costs through the flexibility to choose an infrastructure provider based on cost
-
Reduced dependency on proprietary AWS services by complementing them through Cloudify and Chef
-
Keeping all options open - You can still choose to follow the AWS route without wasting the investment by leveraging the automation part of the investment on the existing AWS environment
Final Words - Minimizing the Scope of Differences or Hiding them through Common APIs?
In those four use cases, we’ve seen completely different organizations and kinds of applications taking similar steps to move their application to OpenStack. These often include automation first, decoupling of the application from the infrastructure and using consistent management tools that work across those various environments. These steps are anyhow also an implementation of some of the best practices related to running and managing applications on the cloud. By following them, you’re guaranteed to benefit from the investment, even if you choose another route down the road.
It is important that we don’t try to hide the differences between the various environments or create a common facade, but rather minimize the scope and places where we need to deal with these differences by putting them outside of our application and in a central place.
This is the main differences from an API-centric approach which tries to hide these differences by providing common sets of APIs (AWS API in our specific case) across all clouds as a portability strategy.
While both options are valid, we believe that the abstraction approach is far more practical and could be applied to a wider range of scenarios even today, as opposed to the API-centric approach which is at best a potential future direction.
