Nati Shalom's Blog

What is NFV?

I first heard the term NFV a year ago as part of the writeup that I was doing with Alcatel Lucent on CloudBand titled Carrier Grade PaaS covering our collaboration. Ever since that time it looks like the term has risen in popularity with every network provider or infrastructure provider now launching a new NFV initiative.

 

As with any new hype, the term NFV quickly became overloaded and confusing, so I thought it would be beneficial to try and clarify it a bit.

 

What is NFV (technical definition)?

NFV stands for Network Function Virtualization - it basically means that your routers, load balancers and firewalls that are currently shipped in boxes will become a virtual entity rather than a physical box. As in the case of compute or storage virtualization, the process of virtualizing network functions is quite the same; we take each function (box) and turn it into a software function that can run on any given box. The decision of which box is going to serve each function can change at runtime based on the desired SLA and would not involve changing the software piece.

What does that really mean?

For most people, network functions do not mean a lot. In addition, the definition that I found over the internet for NFV for the most part comes from people who often tend to speak in a language that only a small community can really understand.

 

To understand what NFV really means we need to take a step back and look at the overall change that the IT industry as a whole is undergoing.

The IT industry is going through a big industrialization change that is very similar to the change that the car industry underwent when Ford came out with Model-T. The change with the Model-T car wasn’t in the making a faster engine, quite the contrary, the Model-T was inferior to other cars that were produced in those days. The industrial revolution with the Model-T was in the ability to produce cars in mass production. This revolution changed the entire automotive industry that propagated to other industries, as well, from consumer electronics through the food industry, which followed the same principles and adopted the same mass production manufacturing principles.

 

The IT industry is going through a fairly similar change - until now we used to build our IT manually, and we’re now shifting into mass production of IT, as well.  In this analogy cloud is the manufacturing floor, and DevOps is the process for optimizing and automating the production pipeline.

 

How IT industrialization is related to NFV?

The carrier industry today relies on a highly customized infrastructure, no one carrier infrastructure runs in the same way as another carrier infrastructure.  Once upon a time carriers saw this as an advantage and ended up with layers and layers of fairly proprietary and costly setups for running their business.

 

As the competition in this industry became tighter this operational model becomes not just less economical, but a huge threat, as it limits the speed in which carriers can adapt to new economic and market changes.  This already has resulted in their loss of ground quite rapidly to competition from internet shops such as Google, Amazon, Microsoft, and others.

 

Carriers realized that in order to survive in this new world they needed to reduce their operational costs and increase the speed in which they can introduce new services, as well as scale their business.

 

This is where NFV comes into play.  NFV is basically a better operational model for running the carrier backbone.  Instead of a highly customized and costly backbone, we’ll use a commodity based infrastructure, and use opensource frameworks and with that we can innovate faster, scale and all this at a much lower cost.

 

What NFV is comprised of?

NFV isn’t a standard (yet) or a product. Even though there are various bodies such as ETSI that try to define standards for NFV, it is very unlikely that we’ll see any real standard emerging from this sort of initiative.  This is simply due to the fact that standards often emerge when an industry reaches a certain level of maturity and we’re just not there yet.

 

At this point it is a set of “de-facto” standards bred from best practices mostly from the cloud providers that proved to be able to deliver a more efficient and agile operational model for running their infrastructure.

 

Quite often that includes the following core components:

 

1. Cloud-based infrastructure - OpenStack is currently the most popular choice for this purpose.

2. Software-defined network functions - This is a mix of the existing network functions provided as software packages, as well as new purely open source players that are making a new entrance into this world.

3. Orchestration engine - Responsible for provisioning of the network functions on a cloud-based infrastructure. TOSCA is a standard orchestration language defined by the OASIS organisation that provides a standard modeling language. Projects such as OpenStack Heat, as infrastructure orchestration in combination with Cloudify as an application orchestration tool are a good reference for this.

4. Analytics engine -  Analytics engines are basically the feedback loop. They are an essential piece to measure which part to measure whether our services meet their desired SLAs and also as a means to analyze and optimize workloads. In the context of NFV, where many of the insights and decisions need to happen in real-time, the analytics engine will be heavily real-time based. A real time analytics engine that is more specific to the operational monitoring domain is Reimann.

What makes NFV different than any other cloud-based infrastructure?

For the most part network functions are not different than a database or any other software function that isn’t a defined as a network function. Having said that there are number of characteristics that are more specific to network functions such as:

• Highly distributed deployment - Carrier data centers tend to span across multi-site deployments

• Deterministic latency and performance - Network functions are more sensitive to latency and non-deterministic behavior that can be quite common in virtual data centers.

• Support for third-party virtual appliances - Many of the network functions are packed as VMs. Those third-party VMs are mostly treated as a blackbox and can be accessed only through custom interfaces that are specific to the network function. Managing those functions can be fairly different than that of the other software services, as a result. The main difference, though, is that most management systems install an agent to control each managed service. In the context of network functions, these assumptions are no longer valid, and therefore managing virtual appliances can be done only remotely and not through a local agent.

• Support for legacy network services - Many of the existing network functions were written in a pre-cloud world, as such they were built with specific assumptions that the high availability and scalability model, as well as the configuration model that are usually very much human-driven. Changing all that in one day isn’t going to be realistic, and therefore, there needs to be a more gradual path to transition those services into the new world or even replacing them with a more modern infrastructure.

• High Degree of Security - Carrier networks assume a high degree of isolation on the network level. This often maps to a daily sophisticated network setup of VLANs and a separate network hierarchy that is not yet supported by most of the existing cloud infrastructures. 

The Role of Orchestration in NFV

In a pre-NFV world setting, provisioning the carrier infrastructure was fairly human driven.  In an NFV world those human operations need to be automated through software. In that context the orchestrator is a software defined operator and it’s the piece that manages the deployment of the network function in the right location and hardware. It is also responsible for orchestrating the network firewalls, routers and such, to fit a specific service deployment and security constraints. Like the human operator it is also responsible for continuously monitoring the deployed services and ensuring that they meet their desired SLA.

Final words

NFV is part of a broader shift toward industrialization of IT. In this particular case NFV is simply a way to make the operational model of carriers more efficient by adopting similar best practices and tools that have already proven themselves at scale by the major cloud providers such a Amazon, Google, Microsoft and others.

On the business side it has disrupted the entire networking industry that used to sell proprietary boxes. In the new virtualized world, boxes have become commoditized and the software on top becomes the main play. This opens up the door to new players that will have a pure software solution that will be specifically designed for a virtualized setup.

As with any disruptive force we will see big players that find it difficult to adapt to this change phased out to make room for new players who will take over, in a similar fashion to the way the internet wave brought Google, Amazon, PayPal and other players who were completely new commoners at the time and became the new market leaders.

On the technical side of things virtualizing the network function is only the first step. In order to experience the full potential of a virtualized carriers, we need to have the entire deployment and management completely automated. What we are missing in this picture is the software equivalent of the human operator, which is also known as the orchestrator. The orchestrator will become the major piece in putting all of this together.   

In the next post I’ll describe in more depth the role of an orchestrator in the context of NFV.

Eight Cloud and Big Data Predictions for 2014

 

Prediction has always been a fun exercise. It forces you to take a step back from your day to day activities, look at the market "crystal ball" and figure out what the future looks like. This year I found this exercise to be particularly difficult as the amount of new innovation and conflicting trends that are taking place at the same time can be very confusing.

After spending quite some time reading market analyses from different sources (see references at the end) and compiling them with all the things I've seen and heard throughout the year, I came to the following observation on how 2014 will look for Cloud and Big Data.  I'm happy to exchange thoughts on that regard and learn how you envision 2014 will look.

 

Public and Private Cloud in 2014

1. Amazon continues to distance itself while Google and Microsoft are catching up

Amazon continues to lead in public cloud and distance itself from the rest of the market. This year it reached 5 times the size of other cloud vendors combined, as noted in a recent Gartner report. Google and Microsoft are slowly closing the gap as the closest alternatives, but at a much slower pace than one would expect given the significant investment of both companies in this area.

2. 2014 will be the year of Enterprise Clouds

Traditional enterprise players, such as IBM, HP, Cisco and Red Hat, continue to fight for the remaining share of the market, mostly around enterprise adoption. Yet, enterprises have been slower to embrace and execute on private cloud strategy. Part of the reason for slow adoption is the gap between the solution provided by most of the regular contenders - who are still competing on selling an end to end story - and the reality that most enterprises are looking for Open and Hybrid cloud strategy, especially given that there is no clear winner.

3. OpenStack will be the most popular choice for Enterprise Clouds in 2014

OpenStack is now high on the radar for Enterprise Cloud, mostly threatening VMware's strong leadership in that domain. Most of the main contenders have embraced a strong OpenStack strategy, including Red Hat, Ubuntu, Suse, HP, IBM and Cisco, with Cisco taking a surprising leading position over IBM and HP, according to a recent Forrester survey.

VMware's response of embracing OpenStack is still questionable, as the transition to OpenStack is not only about technical integration, but also involves a big shift in the value chain. More enterprises are less keen on paying high cost for hypervisor licenses, which is to date the main revenue channel in the VMware pie.

4. Native OpenStack alternatives will disrupt many of the existing cloud solutions

The rapid adoption of OpenStack will also disrupt many of the existing cloud solutions that were built in a pre-OpenStack world. New solutions that take a more native-to-OpenStack approach will pop up and replace many of the current solutions. A good example of this is Project Solum, which aims to provide a native alternative to existing PaaS solutions, such as CloudFoundry and OpenShift as I outlined in this recent post. I expect that will see more of these disruptions expanding to other frameworks in 2014.

5. Orchestration & Automation will be the next big thing in 2014

Having said all that, the remaining challenge of enterprises is to break the IT bottleneck. This bottleneck is created by IT-centric decision-making processes, a.k.a "IaaS First Approach," in which IT is focused on building a private cloud infrastructure - a process that takes much longer than anticipated when compared with a more business/application-centric approach. One of the ways to overcome that challenge is to abstract the infrastructure and allow other departments within the organization to take a parallel path towards the cloud, while ensuring future compatibility with new development in the IT-led infrastructure.

DevOps has definitely been a key example for a business-led initiative that determines the speed of innovation and, thus, competitiveness of many organizations. The move to DevOps forces many organizations to go through both cultural and technology changes in making the biz and application more closely aligned, not just in goals, but in processes and tools as well.

Enterprises with legacy environments and customers take a two-step approach. They first tackle continuous delivery - automating the packages of their software deliverable and keeping tighter control over new production rollout. Once enterprises feel comfortable with their process and environment, they will automate the entire deployment process into production.

Configuration management, orchestration and workflow automation become key enablers in enterprise transition to cloud, and will gain much attention in 2014 and 2015. Again, Amazon has already recognized that need, introducing into the space a new offering called OpsWorks. It is only a matter of time until will see similar offerings embedded with other cloud providers in both public and private clouds.

As the focus moves to orchestration with greater focus on standardization of deployments and packages, DSL and API become equally important. Existing standards, such as TOSCA and CAMP, will undergo massive modifications to make them simpler to use and fit the cloud environment.

Big Data Predictions

There are many advancements happening within the Big Data/NoSQL domain that I'm not going to touch on. I will focus on two main areas that are close to my work.

6. 2014 will see a major increase of Big Data in the Cloud

Cloud infrastructure is closing the gap with the existing data center, as we see the emergence of support for Bare Metal, High CPU, High Memory and Flash-Disk. Many cloud providers are already offering Big Data as Service, such as Elastic Map Reduce and Redshift, and are continuously expanding their offering on that regard.

This advancement in cloud infrastructure removes almost all of the technical barriers for running I/O intensive workloads, such as Big Data analytics, on the cloud. I expect that in 2014, running Big Data analytics on the cloud will become the first choice for any new project, while the use of Big Data in non-cloud environments will be minimized to only niche use cases with extreme regulations and security constraints.

7. In-Memory Data backed by flash-disk will become a popular choice for Real-Time Big Data analytics
Flash disk pricing changes the economics behind the cost/performance ratio of disk-based solutions, making it possible to achieve the performance of an In-Memory-based solution at a price closer to a disk-based solution. So far, attempts have been made to use flash disks as a fast disk alternative to magnetic drives. This path inherits many of the limitations of a disk-based drive and, therefore, doesn't capture the full potential of flash disk which, like RAM, can provide highly parallel access to data.

At the same time, memory-based solutions like In-Memory Database or In-Memory Data Grid cover a small niche in the Big Data ecosystem, mostly due to the high cost/performance ratio.

I believe that the combination of flash drive, In-Memory data-grids and databases at the front-end change that dynamic and will make memory-based solutions backed by flash disk much more attractive to a bigger niche, specifically as it relates to real-time analytics of Big Data.

In some cases, the combination of memory-based solutions is also integrated with existing Big Data frameworks and, thus, provides seamless performance acceleration. A good example is GigaSpaces' integration with Storm and GridGain's integration with Hadoop.

8. Real-time analytics turns mainstream

The most interesting indication that real-time analytics is becoming mainstream is Amazon's support for real-time analytics, with many of the existing analytics solutions providing real-time analytics capabilities as built-in parts of their reports. Another good example of that is Google Analytics Real Time View.

New disruptive forces in Cloud worth watching in 2014
Disruptive technologies change the market landscape in ways that are difficult to anticipate by their very nature. Rather than predicting their impact, I felt it would be simpler to list them.

• Networking - The networking segment of IT is experiencing a major disruption as of late with the move to Software Defined Network, OpenStack Neutron project and Network Function Virtualization. These developments will change networking from not only a technology perspective, but they are also driving a completely different business model which will be based on utilization or a subscription-based model.

• Linux Container - Linux containers are gaining interest both as light-weight software packaging as well as VMS's. The most commonly used use case for Linux containers has as an underlying container for PaaS. With the introduction of new projects, such as Docker - which makes the Linux container easy to use, we will see wider and more pervasive use of containers as high performance virtualization, as packaging tools in continuous deployment scenarios, etc.

• Bare Metal Cloud - Bare metal cloud has been a small niche in the cloud space, mostly due to the fact that it is usually offered in a static configuration setup. Bare metal clouds provide the same degree of elasticity to bare metal devices. With OpenStack, for example, you can spawn a new bare metal device just as you would provision any other VM. The development would reduce one of the last remaining barriers for bringing mission critical applications to the cloud.

• OpenStack as an Innovation Accelerator - Many items on the list of disruptive technologies that I listed above are not that new, and to a certain degree, have existed for years, like in the case of Linux Container. Often, a disruptive force needs to gain certain critical mass before it can break into massive adoption. OpenStack creates an ecosystem that provides a platform for many users to integrate new technologies in a way that could be consumed by end users immediately and that plays a major role in the acceleration of adoption of many of those disruptive technologies.

Where do we go from here?

There are many individual technologies and trends that have a disruptive force behind them. Having said that, I think that it is the intersection between those technologies that holds the most promising potential. Here are few examples:

• Big Data and the Cloud Application Orchestration - Big Data analytics for operational information could serve as the new "brain" behind a new class of orchestration engine that would combine artificial intelligence decision-making based on trends and historical analysis and handle complex failure and scaling scenarios automatically.

• Putting Network and Applications together - Putting network and applications together holds a lot of promise in the way we scale applications across regions and multiple sites, as well as how we control application SLA's in a shared environment. For example, giving priority to customer-facing services versus batch analytics or optimizing the network routing based on the locality of the data, etc.

Getting your Favorite Open Source Framework on OpenStack is Now Simpler than on Amazon, GAE or Azure

The number of open source frameworks that are available today is continuously growing at an enormous pace, with over 1 million unique open source projects today, as indicated in a recent survey by Black Duck.

The availability of these frameworks has changed the way we build products and structure our IT infrastructure products are often built through integration of different open source frameworks rather than developing the entire stack.

The speed of innovation is also an area that has changed as a result of this open source movement. Where previously innovation was mostly driven by the speed of development of new features, in the open source world innovation is greatly determined by how fast we can integrate and take advantage of new open source frameworks.

Having said that, the process of trying out new open source frameworks can still be fairly tedious, especially if there isn't a well-funded company behind the project. Let me explain why.

Open Source Framework Integration Continuum

The integration of a new open source framework often goes through an evolution cycle that I refer to as the integration continuum.

A typical integration process often involves initial exploration where we continuously explore new frameworks, sometimes without any specific need in mind. At this stage, we want to be able to get a feel of the framework, but don't necessarily have the time to take a deep dive into the technology or deal with complex configurations. Once we find a framework that we like and see a potential use for it, we start to look closer and run a full POC.

In this case, we already have a better idea of what the product does and how it can fit in our system, but we want to validate our assumptions. Once we are done with the POC and found what were looking for, we start the integration and development stage with our product.

This stage is where we are often interested in getting our hands on the API and the product features, and need a simple environment that will allow us to quickly test the integration of that API with our product. As we get closer to production, we get more interested in the operational aspects and need to deal with building the cluster for high availability, adding more monitoring capabilities and integrating it with our existing operational environment.

Each of those steps often involves downloading the framework, setting up the environment and tuning it to fit the need of the specific stage (i.e. trial, POC, dev, production). For obvious reasons, the requirements for each of those stages are fairly different, so we typically end up with a different setup process with various tools in each step, leading to a process in which we are continuously ripping and replacing the setup from the previous step as we move from one stage to the next.

The Friction Multiplier Effect

The friction that I was referring to above refers to a process for a single framework. In reality, however, during the exploration and POC stages, we evaluate more than one framework in order to choose the one that best fits our needs.

In addition, we often integrate with more than one product or framework at a time. So in reality, the overhead that I was referring to is multiplied by the number of frameworks that we are evaluating and using. The overhead in the initial stages of exploration and POC often ends in complete waste as we typically choose one framework out of several, meaning we spent a lot of time setting up frameworks that we are never going to use.

How can we make the process simpler?

In a nutshell, we combined two main principles - SaaS as a means to carve out the infrastructure complexity and open source practices and tools to allow for full customization.

We use a SaaS-based model to provide a self-service experience that will allow users to launch their framework of choice through a simple one click deployment. This is particularly useful for the initial exploration stages in which users want to get a preview of many products and don’t have time to spend on setup and installation. The difference between our service and other SaaS services that are often done per product is that in this case, Cloudify provides a single-click deployment for many different frameworks using a single service. 

By relying on open source practices and tools, such as Github, we allow different degrees of customization at each stage to the point where a user can take the entire framework that we are using online on his own environment with full customization.

Launching a New Application Catalogue on HP’s OpenStack-based Public Cloud

This week we are launching a new application catalogue service on HP’s OpenStack-based Public Cloud, with the aim to make the use of open source frameworks on OpenStack simpler than on any other cloud.

The service includes the following main features:

1. Hassle-free preview - One click experience for trying out several open source services for 60 min.

2. Trial as a Service - Aimed for simple, 1 week POC.

3. Frictionless transition to unlimited account - Allows you to use the exact same one-click experience, but in this case the service will be launched under your account and managed by you.

4. Built on Github - The catalogue service is built on Git - this means that you can use the Git experience to add new services, customize them as you would any other open source project. 

5. Fully open source - Having the catalogue (including the UI), the orchestration engine and the OpenStack-based cloud in open source means that you can also choose to clone this entire framework anywhere you like, including in your own private environment. In addition, leverage the investment that you built for the trial and POC stages for future phases, as you're going to use the exact same tools throughout the entire process.

With this tool, users can launch any app outside of the catalogue service through a unique embed model similar to the way someone would embed a video from YouTube.
How is that different that Amazon, GAE or Azure offerings?

All other clouds limit their services to a particular set of pre-canned frameworks. In addition, the infrastructure and tools that most clouds offer are not open source. This means that you will not be able to use the same services under your own environment. It also introduces a higher degree of locking.

This flexibility is critical as the industry moves toward more advanced development and production scenarios. This could be a huge stop gap. If you get stuck with the out of the box offering, you have no way to escape, with your only way out to build the entire environment yourself, using other sets of tools to build the entire environment completely from scratch.

The hassle-free preview model as well as the fact that you can run any of the services outside of the catalogue service makes the Cloudify Application Catalogue significantly simpler. This is especially true when comparing it with any of the existing alternatives on other clouds which often require registration and credit card as a way to get started.

Final Words

In today’s world, innovation is key to allowing organizations to keep up with the competition.

The use of open source has enabled everyone to accelerate the speed of innovation, however, the process of exploring and trying open source frameworks is still fairly tedious, with much friction in the transition from the initial exploration to full production.

With this new service, we believe that we have changed the game, showing that we can now make the experience of deploying new open source services and applications on OpenStack simpler than on other clouds. By taking an open source approach, we guarantee not to hit a stop-gap as we advance through the process and avoid the risk of a complete re-write or lock-in. At the same time we allow hassle free one-click experience by providing an “as-a-service” offering for deploying any of our open source frameworks of choice. By the fact that we use the same underlying infrastructure and set of tools through all the cycles, we ensure that users can take their experience and investment from one stage to the other and thus avoid a complete re-write.

With all this we now allow many users and organizations to increase their speed of innovation dramatically by simplifying the process of exploring and integrating new open source frameworks.

The Breakup: Why OpenStack Needs a Native Alternative to CloudFoundry and OpenShift

 

Alex Freedland, Co-Founder and Chairman at Mirantis, wrote a controversial post in which he basically marks the breakup between some existing PaaS frameworks and OpenStack - CloudFoundry specifically.

Personally, I think that Freedland highlights a growing sentiment in the OpenStack community. The fact that OpenStack is open source should change the way we think of the PaaS and IaaS layers, as I noted in one of my earlier posts, The Blurring Line Between the IaaS and PaaS Layers.

In the case of CloudFoundry and OpenShift specifically, PaaS was built with the assumption that the IaaS layer provides basic compute, storage and network services and all the rest should be handled at the layers above. The reality, though, is that the IaaS layer is continuously moving up the stack in a very similar way to which Amazon has grown its stack.

This shift up the stack changes many of the built-in design assumptions of many existing PaaS products, CloudFoundry and OpenShift specifically. For example, the way we handle user-security, metering and scheduling is often in a completely parallel stack that exists in both the IaaS and PaaS layers. This leads to a lot of unnecessary redundancy and therefore complexity and inconsistency. On top of that, the middleware stack (Ruby vs Python) also leads to another layer of redundancy and complexity, especially for organizations looking to deploy the end-to-end stack. For example, why would we need two different models to handle database availability? Why do we need different agent systems to monitor our instances? If we already have a model to detect and monitor device failure, why do we need to add another failure detection mechanism on top to detect the same failure? In many of these cases, we already built solutions at the IaaS layer and we only need to make the right use of them.

Now there is nothing wrong with CloudFoundry or OpenShift; they do exactly what they were designed to do. That being said, on OpenStack we can do things differently than we can on other closed IaaSs, creating a great opportunity to not just simplify things, but do do things that are much harder otherwise. Let me explain.

The Need for a Native Open PaaS

A native open PaaS is a PaaS that comes with a much thinner stack and relies more heavily on a common set of services provided by the IaaS layer for user management, metering, etc.

Its main focus is to provide a higher level abstraction that would simplify the deployment and management of applications on OpenStack.

Another area that a native open PaaS differs from its existing predecessors is the native DevOps support. Many of the existing PaaS platforms were built with the assumption that developers only worry about their code. However, in real life, continuous delivery or deployment can expose changes at all layers, including the configuration of the application and PaaS stack, and should therefore be consistent with the way updates and configuration management takes place in the IaaS layer.

A native open PaaS should leverage the same DevOps tools used by the IaaS layers to push updates to the application layer.

The Missing Piece in the Puzzle - Open DevOps Automation

Earlier this year, Amazon launched a new piece in their stack - OpsWorks, which basically filled a gap between their existing IaaS and PaaS layers. They refer to it as DevOps automation.

AWS Stack

 

AWS OpsWorks provides an orchestration and workflow service that currently runs on top of Chef and provides users with the ability to build their own custom stacks on top of AWS, as I noted in my earlier post DevOps, PaaS and Everything in Between.

The OpenStack Heat project fills the AWS CloudFormation box in the above image, providing a basic templating model for orchestrating and automating the deployment of software stacks on OpenStack.

I believe that OpenStack also needs  to fill in the OpsWorks box as higher level abstraction for application deployment. Given the open nature of OpenStack and the private cloud focus I think that this piece should be more open and support not just Chef, but also other configuration management frameworks such as Puppet, Ansible and Salt through Heat. There should also be a much stronger emphasis on the application orchestration piece to enable automation of complex application related processes, such as continuous delivery, deployment automation, recovery and scaling and for that we need a more advanced rule engine to support those advanced flows.

If done right, tools like OpsWorks in conjunction with Heat can serve as a great foundation for PaaS. At the same time, I can see many cases in which users would simply use something like OpsWorks directly without needing another layer of abstraction on top of it, hence why it makes sense to keep those boxes also as independent services.

Consolidating the Efforts

There are currently many projects and initiatives in the OpenStack community, each trying to address different aspects of the application deployment and management complexity. Let me name a few:

Adrian Otto, Principal Architect at Rackspace, announced Project Solum support from Rackspace, eBay, Red Hat, Ubuntu / Canonical, dotCloud as well as GigaSpaces.

Some of the guys from my team at GigaSpaces are also going to give a talk during the OpenStack Hong Kong event about delivering the equivalent of Amazon OpsWorks on OpenStack - See the details here.

There are many other related projects and initiatives that I haven’t listed here and many others that are probably being worked on as we speak - it is beyond the scope of this post to list them all.

Looking Into the Future

I think that this is a great and an exciting opportunity for the OpenStack community to deliver on its promise and really push the open source cloud forward. It can do so by breaking the traditional barriers between IaaS and PaaS, and go above and beyond what we've seen normally in closed source clouds. There are many areas in which such an approach can lead to an even greater degree of innovation. For example, think about bringing the network and the application together, making multi-site deployment a breeze.

I look forward to meeting everyone on the Solum team next week during OpenStack Hong Kong and to being a part of this next wave of the revolution.

References

• Project Solum announcement

• Deployment and Management of Your Application on OpenStack using an All Encompassing DSL based on TOSCA (OpenStack session in HK)

• Mirantis To PaaS Vendors: Stop Fighting OpenStack Gravity

• Rackspace jumps on bandwagon with open source PaaS project

• The blurring Line between the IaaS and PaaS layers

• DevOps, PaaS and Everything in Between

 

Four Case Studies for Moving Mission Critical Apps to OpenStack

 

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.

 

OpenStack Native API Debate - A Recap and an Alternative Path

Randy Bias CTO of Cloud Scaling sparked an interesting debate around the need of OpenStack to align itself with major public cloud offering, namely Amazon and Google clouds. According to an interview on GigaOM the timing behind Randy's proposal is a result of the concern that Rackspace is heading to a different and potentially opposite direction with their view of Amazon as a rival to OpenStack and also from the thought that relying on AWS API could be too restrictive from an innovation perspective.

Portability Defined

While the debate was sparked around the use of the so called Native (Nova) API according to the twitter thread between Randy Bias @randybias, Dave Neary @nearyd, and Simon Wardley @swardley, it appears that the three look at portability in its broader sense (not just about around Nova API):

@nearyd: “@randybias user confidence that they can easily move work off one OpenStack to another"

@nearyd: “@randybias Also ability to burst off private cloud to a public cloud will be important.”

According to this definition what were really looking for is application portability from non-OpenStack environments to OpenStack.

API Interoperability != Application Interoperability

I think that most of the community would  agree with the general sentiment behind Bias’ call that OpenStack should align itself with that of major public clouds. Now zero-in on the Nova API as the means for portability – this is where the debate lies and where I feel that Randy may be wrong in his assessment for the following reasons:

• The complexity is underplayed - as Adrian Cockcroft from Netflix pointed out:
  • The permutations and complexity of doing this across many vendors has sunk many previous attempts over the last decade.
• Randy’s reference to CloudStack AWS API bridge is actually a reference to why API bridges aren't that useful after all.  Based on my experience, most if not all CloudStack users do not really use the CloudStack AWS bridge as it doesn't expose many of the CloudStack features, it’s not well tested and doesn't always work well simply because it's not considered a main path. I also heard similar feedback from Adrian Cole, the founder of the JClouds project - a popular cloud abstraction framework.
• API Portability != Application Portability - API portability covers only a small part (and not necessarily the important part) of what is needed to get true application portability, as noted in Chief Engineer at eBay Subbu Allamaraju's  post OpenStack is not Cloud and also in OpenStack COO Mark Collier’s response:

"I do agree that APIs sometimes get more credit than they deserve. Sometimes people oversimplify the concept of a platform and the compatibility of a platform based on just saying, 'If you've got the API, you've got compatibility.' The reality is that an application architecture depends on the behavior of the whole system it's interacting with. The API is simply the way it talks to that system."

What We Can Learn from the Android vs IOS Experience on Cloud Portability

Apple IOS and Google Android are actually good references for achieving fairly good application portability between two  environments without necessarily agreeing on the same API.

Can you imagine Google adopting the same IOS API?

This shows us that there must be alternative approach to portability.

Alternative Path for Portability

Subbu Allamaraju suggested that portability should be done through glue code.

“AWS API compatibility is what an operator should worry about above all these? Nah. You can fix API incompatibility with glue code.”

Jeremy Jarvis, Co-founder of Brightbox, suggested a similar idea in his comment to Randy's post:

"Anyone writing code to interact directly with APIs of popular clouds is probably doing something wrong (and certainly wasting effort). There are a number of cloud abstraction libraries which are doing a great job in providing a unified interface to multiple clouds. Fog (Ruby) is a great example - sponsored by Heroku no less - of how a community/ecosystem is developing around multi-cloud interaction."

Ben Kepes pointed to orchestration framework as an alternative in his post On OpenStack and the AWS API – Internal Divisions Surface

“If the future is, as I suspect, made up of enterprises using lots of different cloud offerings (not so much in a hybrid/cloud migration model but more of a discrete multi cloud approach) then there is less of an urgent need to resolve to one common API set. So long as there are products that give visibility and management over these discrete resources (and this is where Dell, with its recent acquisition of enStratius and dropping of its own public cloud play, is thinking) the actual interoperability or commonality of the different products API sets is secondary."

My Take

Given the dynamic nature of the cloud environment, there is no doubt in my mind that portability is important - not just between AWS, GCE and OpenStack, but also between different OpenStack providers, as well as between traditional data-center environments and OpenStack as I noted in my previous post To OpenStack or Not to OpenStack? Moving Enterprise Applications onto OpenStack Today. Having a native cloud API that is compatible with AWS and GCE is wishful thinking and, unfortunately, makes it less practical at this point in time.

Application deployment is better described in recipes, which cover a wider spectrum of application deployment and behavior - such as the tiers of the application, the metrics, the scaling policies, the configuration etc. The OpenStack Heat project, which is actually driven from its AWS equivalent CloudFormation, can get us much closer to the desired portability, even if the underlying Cloud API doesn't conform to the same API. If done right, this means that we could execute our application recipes in a similar way on both AWS and OpenStack.

Having said that, in order for OpenStack Heat to become the solution for cloud portability there is more work to be done in designing the framework in a way that will be more loosely coupled with the underlying OpenStack infrastructure and also to adopt richer deployment recipes that can cover more aspects of our application deployment in a declarative way. It looks like there are already plans in this direction, but the progress seems to be fairly slow. Therefore, I think that it would be both simpler and less disruptive for the community to align its effort in maintaining portability around the Heat project rather than re-writing the Nova API.

Thoughts From Not so Long Past..

While I was writing those lines I came across one of my previous talks Making Cloud Portability a Practical Reality from 2011. I thought that many of the points from this presentation are still relevant… Enjoy.

References

• OpenStack’s Future Depends on Embracing Amazon. Now.Embrace major public cloud APIs (Randy Bias blog)
• To OpenStack or Not to OpenStack? Moving Enterprise Applications onto OpenStack Today
• On OpenStack and the AWS API – Internal Divisions Surface (by Ben Kepes)
• Is Rackspace holding OpenStack back? (GigaOM)
• OpenStack is Not a Cloud (Subbu Allamaraju's Blog)
• Making Cloud Portability a Practical Reality
• COO Mark Collier discusses OpenStack roadmap, API fit with AWS
• Portability defined-  a Twitter thread

OpenStack's Third Birthday - a Recap with a Look into the Future

OpenStack was first announced three years ago at the OSCON conference in Portland. I remember the first time I heard about the announcement and how it immediately caught my attention. Ever since that day, I have become a strong advocate of the technology. Looking back, I thought that it would be interesting to analyze why.

Is it the fact that it's an open source cloud? Well partially, but that couldn't be the main reason.  OpenStack was not the first open source cloud initiative; we had Eucalyptus, then later Cloud.com and other open source cloud initiatives before OpenStack emerged.

There were two main elements missing from these previous open source cloud initiatives: the companies behind the initiatives and the commitment to a true open movement. It was clear to me that a true open source cloud movement could not turn into an industry movement, and thus meet its true potential if it was led by startups. In addition, the fact that companies whose businesses run cloud services, such as Rackspace, brought its own experience in the field and a large scale consumer of such infrastructure such as NASA, gave OpenStack a much better starting point. Also, knowing some of the main individuals behind the initiatives and their commitment to the Open Cloud made me feel much more confident that the OpenStack project would have a much higher chance for success than its predecessors. Indeed, after three years, it is now clear that the game is essentially over and it is apparent who is going to win the open source cloud war.  I'm happy to say that I also had my own little share in spreading the word by advocating the OpenStack movement in our own local community which also grew extremely quickly over the past two years.

OpenStack as an Open Movement 

Paul Holland, an Executive Program Manager for Cloud at HP, gave an excellent talk during the last OpenStack Summit, comparing the founding of the OpenStack Foundation to the establishment of the United States.  Paul drew interesting parallelization between the factors that brought a group of thirteen individual states to unite and become the empire of today, with that of OpenStack.

Paul also drew an interesting comparison between the role of the common currency that fostered the open market and trade between the different states with its OpenStack equivalent: APIs, common language, processes, etc. Today, we take those things for granted, but the reality is that common currency isn't yet trivial in many countries even today, yet we cannot imagine what our global economy would look like without the Dollar as a common currency or English as a common language, even if they have not been explicitly chosen as such by all countries.

As individuals, we often tend to gloss over the details of the Foundation and its governing body, but it is those details that make OpenStack an industry movement that has brought many large companies, such as Red Hat, HP, IBM, Rackspace and many others (57 in total as of today), to collaborate and contribute to a common project as noted in this report. Also, the fact that the number of individual developers has been growing steadily year after year is another strong indication of the real movement that this project has created.

Thinking Beyond Amazon AWS

OpenStack essentially started as the open source alternative to Amazon AWS. Many of the sub-projects often began as Amazon equivalents. Today, we are starting to see projects with a new level of innovation that do not have any AWS equivalent. The most notable one IMHO is the Neutron (network) and BareMetal projects. Both have huge potential to disrupt how we think about cloud infrastructure.

Only on OpenStack

We often tend to compare OpenStack with other clouds on a feature-to-feature basis.

The open source and community adoption nature of OpenStack enables us to do things that are unique to OpenStack and cannot be matched by other clouds. Here are a few examples:

• Run the same infrastructure on private and public clouds.
• Work with multiple cloud providers; have more than one OpenStack-compatible cloud provider with which to work.
• Plug in different HW as cloud platforms for private clouds from different vendors, such as HP, IBM, Dell, Cisco, or use pre-packaged OpenStack distributions, such as the one from Ubuntu, Redhat, Piston etc.
• Choose your infrastructure of choice for storage, network etc, assuming that many of the devices come with OpenStack-supported plug-ins.

All this can be done only on OpenStack; not just because it is open source, but primarily because of the level of adoption of OpenStack that has made it the de-facto industry standard.

Re-think the Cloud Layers

When cloud first came into the world, it was common to look at the stack from a three-layer approach: IaaS, PaaS and SaaS.

Typically, when we designed each of the layers, we looked at the other layers as *black-boxes* and often had to create parallel stacks within each layer to manage security, metering, high availability etc.

The fact that OpenStack is an open source infrastructure allows us to break the wall between those layers and re-think where we draw the line. For example, when we design our PaaS on OpenStack, there is no reason why we wouldn't reuse the same security, metering, messaging and provisioning that is used to manage our infrastructure. The result is a much thinner and potentially more efficient foundation across all the layers that is easier to maintain. The new Heat project  and Ceilometer in OpenStack are already starting to take steps in this direction and are, therefore, becoming some of the most active projects in the upcoming Havana release of OpenStack.

Looking Into the Future

Personally, I think that the world with OpenStack is by far healthier and brighter for the entire industry, as opposed to a world in which we are dependent on one or two major cloud providers, regardless of how good of a job they may or may not do. There are still many challenges ahead in turning all this into a reality and we are still at the beginning. The good news, though, is that there is a lot of room for contribution and, as I’ve witnessed myself, everyone can help shape this new world that we are creating.

OpenStack Birthday Events

To mark OpenStack’s 3^rd Birthday, there will be a variety of birthday celebrations taking place around the world. At the upcoming OSCON event in Portland from July 22-26, OpenStack will host their official birthday party on July 24^th. There will also be a celebration in Israel on the 21^st, marking the occasion in Tel Aviv. For more information about the Foundation’s birthday celebrations, visit their website at www.openstack.org.

To OpenStack or Not to OpenStack? Moving Enterprise Applications onto OpenStack Today

Peter Chadwick Senior Product Manager - Cloud Infrastructure at SUSE wrote an interesting article arguing  Why OpenStack Will Rule the Enterprise. Chadwick refers to three main points in his arguments:

• Variety - OpenStack is the only cloud platform that supports every major hypervisor.
• Familiarity - OpenStack follows an open source model similar to Linux. Most enterprises are already comfortable with that model and in that context OpenStack would be a natural evolution.
• Governance - The OpenStack Foundation was created to ensure that OpenStack evolves to meet a wide range of requirements that are not controlled by a single vendor.

Current Challenges for Enterprise Adoption of OpenStack

While there is a growing acceptance that this is the general direction, others seem to point out some of the gaps that still exist to enable enterprise adoption of OpenStack. Nancy Gohring mentions in an article in ITWorld Immaturity holding back OpenStack deployments  that the main challenges are the  lack of maturity and the fact that OpenStack is used mostly for testing and development and is not ready for true multi-tenant production deployments. She also points out the fact that many of the OpenStack distributions today are offered by relatively small companies, creating another barrier for adoption.  Bernard Golden more specifically highlights the upgrading and deploying of OpenStack as the main challenges for enterprise adoption in his article How OpenStack Should Prepare Itself for the Enterprise.

A Possible Strategy for Adopting OpenStack in an Enterprise World Today

All the cards indicate that despite some of the maturity and growing pains of OpenStack as a framework and community, it is heading in the right direction. But as we often say in those cases, "there is no fast forward for maturity." We need to expect that over the course of the coming years the reality is going to be fairly dynamic with lots of new developments coming out with every release and with many providers and players promoting their different OpenStack offerings. To compete with one another, these providers will also try to add their own value-added features as differentiators. So our proposed strategy has the following foundations:

• Design to cope with a continuously changing and evolving environment: We need to design our OpenStack environment in such away that we could adopt new versions of OpenStack  and new ecosystem frameworks easily.
• Design for portability across different OpenStack providers and versions: During a visit to one of our investment banking customers, he used an interesting analogy to describe his strategy for implementing an OpenStack-based private cloud on his environment:

“In a traditional data-center world we used to work at a hardware device and hypervisor level. We used different resources from Dell, HP etc. We’re thinking of doing the same thing in the cloud world, only that rather than working at the device and hypervisor level, we can work at the IaaS level with the hardware, storage and network pre-integrated. OpenStack allows us to standardize those providers and have a mix of them installed in our data-center."

In order to keep this level of flexibility, you need to ensure portability between the different OpenStack providers. This is especially true in a world where each provider tries to sell you the entire world wrapped up into one with OpenStack on top. If you design your data center to work with various providers in place, you're more likely to remain portable and avoid a complete lock-in.

• Use a high availability approach to enable simple upgrades without downtime: The simplest approach to upgrade any given system is to rip and replace it with a new one. Having said that, in most enterprises, taking a system down for the purpose of upgrades or maintenance is often not acceptable, for obvious reasons. If we design our system for continuous high availability, we could take down each of the cloud zones one at a time and still keep our application running. In this way, we could have a simpler upgrade approach; rather than trying to upgrade individual units of our infrastructure, we can can rip and replace an entire unit one at a time to continuously upgrade our system.
• Take a baby steps approach: As with any complex project, it would be more practical to implement OpenStack in small bits rather than taking a *Big Bang* approach. Here are few examples of what those steps could look like:
  • Start with automation first and future-proof your application to run on OpenStack at a later stage.
  • Run OpenStack for your development and testing environment.
  • Use OpenStack as your DR environment and gradually move your primary site to OpenStack as well.

Implementing the Strategy by Abstracting the Application from the Infrastructure

The points outlined above may seem obvious, but it is not yet clear how they can be implemented.

One of the ways in which we could implement portability, future-proof our application and allow for smooth upgrades is through the use of devops automation frameworks, such as Chef, Puppet or Cloudify, which itself integrates natively with Chef and  Puppet.

Such frameworks allow us to create an abstraction layer between our OpenStack infrastructure and our application to easily migrate our application across different OpenStack providers, versions etc.

Using Cloudify to Abstract your Deployment Between Different Private and Public OpenStack Providers

One of the challenges with many of the abstraction frameworks is the fact that they often rely on a least common denominator API approach. An API abstraction approach limits the level of unique features and capabilities that can be provided by each specific vendor.

In the case of Cloudify, we use a plug-in approach that is referred to as the Cloud Driver, which provides access to the IaaS layer, while a recipe model separately defines the application plan or blue-print that needs to be deployed.

With this approach, there is a basic contract/interface that each driver must implement to allocate compute, storage or network resources. Each driver can be given a set of specific properties and arguments with which the user can choose a specific network setup or compute API of a specific driver.  This approach provides a higher degree of flexibility than an API-based abstraction and we can, therefore, apply it to address a variety of scenarios as outlined below:

• Migrating between different OpenStack providers: The application deployment plan (recipe) is kept abstracted from this information. This way we can deploy our application on different providers using the same frameworks, but at the same time our application can still run better on a specific provider and utilize its specific set of features. 
• Migrating from an existing (non-OpenStack) data center to OpenStack: This abstraction allows us to work on top of our existing data center which may not yet support OpenStack. We can use this model to manage our application in the existing data center by pointing to a BYON (Bring-Your-Own-Node) CloudDrive, which gets a list or range of IP addresses as an input and manages the workload within that predefined pool.
• Migrating between different OpenStack versions: We can also use this model to migrate workloads from one version of OpenStack to the other. In this case, each provider's availability zone will represent a a specific OpenStack version. We can upgrade our underlying OpenStack zone just by removing it from the system. Cloudify in turn will automatically provision the application that was running on this provider in another zone which will be set to run the new version of our application.

Making Cloudify Native to OpenStack

One of the benefits of OpenStack as opposed to other cloud infrastructures is the fact that it is open and provides easy access to its underlying stack. We can, therefore, build Cloudify in such a way that utilizes some of the underlying OpenStack infrastructure, such as Heat for provisioning and Keystone for authentication. 

We can also standardize the existing component of Cloudify, such as the recipe, by adopting TOSCA and Heat notions and templates.

This way we can make the migration to OpenStack even easier. Not only are we enabling our application to run on OpenStack, we also do it in a way that will better utilize the underlying OpenStack infrastructure.

Big Data on OpenStack

Big Data systems by their very nature tend to be...Big.

Big in the amount of data, in the number and size of infrastructure behind it, etc. Cloud based infrastructure can be a good fit as a cost effecive instrastrucutre for running those Big Data systems. While this may sound obvious, many of the Big Data deployments that I've encountered run outside of a cloud environment. The main reason is the performance overhead that is often associated in running on a virtualized cloud environment. Let me explain..

The Performance Overhead of Running Big Data on the Cloud

A recent benchmark done by Petersenna over various virtualization solutions, such as XEN, VMWare, HyperV etc, shows that on average the performance overhead associated with virtualization can lead to 2.4 times slower disk latency and 25% slower network I/O.

How does the performance overhead translate into cost?

Based on the various benchmarks, I think that it would be fair to assume that running I/O intrusive workloads such as Big Data on a virtualized infrastructure would require 3X more resources than its Baremetal equivalent.

As we are talking about Big Data infrastructure - 3x means a lots of wasted resources. The operational costs coupled with the complexity associated with running a significantly bigger system yields a fairly substantial overhead and cost. In addition, the Network and Disk overhead are not deterministic and can vary quite substantially when the utilization gets higher. This leads to not just performance overhead, but also non-deterministic overhead. In Big Data terms, that means that a query for particular data can take 10msec one time or 30msec another time. Quite often, running Big Data analysis requires a sequence of those operations. Therefore, if we pile this overhead in a sequence of 10 queries, the variance in the response time can vary quite substantially.

While the choice of running Big Data on the cloud holds a lot of promise, the performance and non-deterministic behavior makes that choice limited to more of a niche scenario where this overhead  becomes less significant in comparison to the elasticity benefit of the cloud. For example, for sporadic worklads in which we run our analysis for a certain period of time and then can release the resources, using on-demand infrastructure is still a better choice, as running 3x the amount of resources for an hour is significantly cheaper than having a third of that infrastructure allocated 24/7.

OpenStack Bare Metal Cloud

The analysis above shows that for I/O intensive workloads, virtualized infrastructure isn't such a good fit.

Cloud is often viewed as an infrastructure on top of virtualization. Therefore, by definition, a cloud-based infrastructure inherits the benefits and limitations of virtualization.

Is the coupling between cloud and virtualization really mandatory?

If we think of a cloud as an infrastructure for getting compute, storage and network resources on-demand, then there is nothing  to necessitate the coupling of the cloud with virtualization. It became common to pair the two mainly because of the complexity involved with provisioning non-virtualized resources and the limitations in enabling partitioning of a given bare metal machine.

As I noted in one of my previous posts Bare Metal Cloud/PaaS,  there are ways today to provision a baremetal machine from an image and partition it just like we would do with a hypervisor based VM.  There are already cloud providers that offer a choice of bare metal machines as part of their cloud infrastructure.

A new bare metal project in the OpenStack Grizzly release takes this a step further. It allows us to use the same compute API (NOVA) and allocate a bare metal machine just as we would with a virtualized machine.

All we need to do to make the switch is to change the image type of our target machine and the cloud infrastructure will know to map that request and allocate a bare metal image instead of a virtualized instance.

With this option we can now run our entire Big Data workload on the cloud and not worry about switching environments depending on the workload happen to be sporadic or I/O intesive.

HubSpot OpenStack – Bare Metal Case Study

During the last OpenStack Summit, Jim O’Neill CIO at HubSpot showed how using OpenStack with a combination of a public virtualized cloud and private bare metal cloud enabled a 4X increase in their infrastructure efficiency:

 

“We took this single image, picked it up from public cloud into a Rackspace-powered private cloud and saw a 4X increased efficiency running that workload.”

 

Moving from Existing Data Centers to the Cloud

Many existing Big Data and BI systems run on traditional data center environments. Moving those systems into an OpenStack-based environment isn't going to be a walk in the park. This is where automation frameworks, such as Cloudify with the combination of Chef and Puppet, make this transition smoother.

In this approach, we can automate the deployment of our existing Big Data/BI systems in a way that will be abstracted from the underlying infrastructure. We can later use this abstraction to run Big Data systems in our existing data center, and when ready, we can use the same deployment framework on an OpenStack-based environment without re-doing any of that investment.

 

 

Learn more through hands-on experience - a Real Life Experience on HP OpenStack

As it often happen in this sort of conceptial discussions the points and arguments from this post may often sound artificial and not easy to grasp. To make it more down to earth, we've put a NoSQL datastore such as Couchbase, MongoDB, Cassandra, ElasticSearch and Big Data applications available on-demand on HP OpenStack cloud services. You can use this reference to launch any of those applications and then use the management console to browse through the recipes and customize it to your environment as needed.

It is also worth pointing out that the recipes behind this project are available on Github and can be easily deployed on your cloud or in your data center or even desktop in pretty much the same way. If you are interested in more details, please post a comment on this post or in the Cloudify forum.

For more on Big Data on OpenStack, come check out my presentation at Cloud Expo East on Tuesday, June 11th at 8:15am in the “Cloud Computing and Big Data” Track.

References

• Bare Metal Cloud/PaaS
• OpenStack Baremetal Project
• Big Data in the Cloud
• Big Data in the Cloud using Cloudify
• Putting Hadoop On Any Cloud (A video presentation)
• In Memory Computing (Data Grid) for Big Data
• Using the Cloudify Player as an Open Source Framework for Building Your Own Cloud Application Marketplace on OpenStack
• Going native: The move to bare-metal cloud services
• New bare metal cloud offerings emerging
• How much overhead does x86/x64 virtualization have?
• Amazon EC2 versus Bare Metal and KVM? The inside story on what you thought you knew about EC2

Ramping Up for the 3rd OpenStack Israel - the Biggest One Yet

OpenStack is one of the fastest growing open source projects in the history and is quickly becoming the de-facto standard for Open Cloud Data Center. The project is gaining maturity quickly with major companies such as PayPal, eBay, BestBuy, Intel, Samsung, Bloomberg and HubSpot using it in production, with major vendors such as HP, Rackspace, IBM, Redhat, Ubuntu and GigaSpaces behind the technology.

On May 27th, we will open the doors for OpenStack Israel for what will our biggest OpenStack Israel yet with over 350 attendees. We welcome top industry leaders to Israel to discuss the latest news in OpenStack, as well as showcase real life case studies from Intel, LivePerson, Alcatel , Mirantis and eNovance. This event would not be possible without support from the OpenStack Foundation and the IGTCloud as well as from our sponsors: GigaSpaces, HP, IBM, Rackspace, Cloudsoft, eNovance and CICC. The conference will be held in the Herzilya Arts Center in Herzilya, Israel on May 27th, 2013.

As a member of the OpenStack Israel Committee, I am excited to see that Israel is one of the three locations leading the adoption of OpenStack in Europe (with Germany and Hungary), with more startups, ISVs and organizations joining this year. Unlike in previous years, this year we have had tremendous support for the event, bringing in new committee members, building an agenda with a record number of speakers from all over the world as well as an unprecedented number of attendee registrations. The event will exhibit great content with fresh case studies as well as technical sessions covering the core aspects of OpenStack. For those who want to get their hands "dirty" with OpenStack, we have also arranged a three day training session following the event through collaboration with StackOps.  For details on the schedule see the event agenda.

With a focus on OpenStack technology, innovation and implementations, attendees will hear actual case studies as speakers from Intel, LivePerson, Alcatel and others will share their user experiences with OpenStack. Guests will learn how leading OpenStack cloud providers, software vendors and system integrators  are now delivering OpenStack-based clouds and solutions to the market. The session tracks will take guests on a technological deep-dive into the inner workings and frameworks around OpenStack technology.

This is sure to be a big event, both in size and in success. I encourage everyone to come out and see how OpenStack has had an impact on countless organizations, both here in Israel and abroad. Register today for your spot at OpenStack Israel. I hope to see you all there.

References:

• Podcast

• OpenStack Grizzly

• OpenStack Portland