Nati Shalom's Blog

OpenStack by the Numbers

One thing that I like about working with an open source community like OpenStack is that you get direct access not just to the source code itself, but to its users and ecosystem as well.  This allows you to be less exposed to marketing spins, and actually analyze our actions based on real numbers.

The OpenStack Foundation conducts a very insightful survey twice a year which helps to measure how users are using the technology. This is an important and useful feedback loop that goes to the PTL of the various projects, and can help product companies to analyze their go to market plans and such. You can find the source

I found the original version a bit too verbose, so I took the liberty to put together an executive summary of the main points from the survey, mostly targeted at decision makers. I hope that you’ll find it useful, any feedback would be highly appreciated.

Main Reasons for Choosing OpenStack

The main reason cited for choosing OpenStack is Open Technology and Avoiding Lock-in.

Interestingly enough Cost Saving comes only 4th!

 

Size of Deployments

The large majority of the current deployments are under 100 nodes.

Around 30% of the deployments run relatively large scale deployments between 500-1000.

QA/DEV	Production

Production seems to follow a similar trend but lower in numbers to QA, which is reasonable as I believe that some of the QA deployments represent a transition stage to production.

 

User Type

The majority of the users seem to be service providers and cloud operators.

There is also a good number of ISVs and ecosystem partners, which is a strong indication that OpenStack is indeed an ecosystem.

There's a very strong presence of OpenStack in the Telco industry. Finance seem to be lagging behind the adoption curve with only three financial organizations declaring their use of OpenStack.

The majority of the deployments run on private or hosted private clouds. About 20% run on public or hybrid clouds. OpenStack also seems to attract mostly small to mid-size companies.

 

Private/Public Clouds	Size of Organizations

 

Deployment Tools

The survey includes two categories for deployment tools, one for those that are used for deploying the OpenStack infrastructure, and the other that are used for application configuration (covered in the application survey).

According to the two surveys users tend to use different sets of tools for the infrastructure deployment and for application configuration management. Puppet seems to be the most popular choice for OpenStack users in both categories. 

One of the interesting results is to see that Bare Metal and Docker are starting to appear in more deployments. This is fairly impressive given that the two are not yet officially supported by OpenStack.  VMware is around 10%-13% of KVM of Virtualization similar to XEN.

 

OpenStack Deployment Tools

 

Applications on top of OpenStack

As noted above, Puppet is popular for application configuration, as well as infrastructure deployment. Heat and Docker take the 2nd and 3rd place respectively,  putting Chef behind in the 4th place.

Given the popularity of Heat during the last summit I wouldn’t be surprised if Heat and Docker will surpass the use of Puppet in this category.

 

 

Popular Frameworks

Interestingly enough, JClouds seems to be gaining popularity amongst OpenStack users. This may be an indication that ~ ¼ of the users are interested in frameworks that are not tied only OpenStack. Not surprisingly, Python is far more popular than any other language, however Java seems to have a good and dominant presence more than other frameworks. One possible explanation is that the type of users that are attracted to OpenStack are more of the traditional enterprise organizations, and less of the new web-facing companies.

Operating Systems

Ubuntu and CentOS are the most popular choice. Windows adoption amongst OpenStack users is between 10-20%.

<

Application Survey	Production Survey

 

Compatibility / Portability

EC2 is a relatively popular choice which indicates that there is an increasing desire among the OpenStack community to maintain portability with EC2. This also correlates with the popularity of portability frameworks such as JClouds.

 

QA/DevTest	Production Survey

 

References

• OpenStack user survey presentation
• OpenStack user survey online session from OSS Atlanta 2014

The Heat is on with OpenStack Icehouse

OpenStack Orchestration Moves up the Stack

OpenStack Icehouse, the Ninth OpenStack Release, was announced at at the last summit and was named for a street in Hong Kong. The Icehouse release is primarily focused on stability and maturity. The release marks another milestone in the growth of the project.  Just a few stats.

Icehouse had:

• 1,202 contributors, a 32 percent increase from the Havana release six months ago
• Approximately 350 new features added.
• 2,902 bug fixes were added in the Icehouse release cycle.

In this post  I’m going to focus on the updates in the OpenStack Heat project, which is a.k.a OpenStack Orchestration.  For a general overview on the Icehouse release I would recommend checking out the OpenStack Icehouse release notes or this article by InfoQ.

Heat Project Icehouse - Main Updates

The Heat project started as a clone of Amazon CloudFormation which is basically a declarative approach to automate the infrastructure set up on Amazon environments.  The Icehouse release marks an evolution of the project up the stack. If in previous releases Heat was mainly used to orchestrate the OpenStack infrastructure, with Icehouse it has added many more capabilities to handle orchestration of the software stack as part of the application boot process.

This shift is reflected in the new HOT template format  which allows you to describe a broader aspect of an application configuration including the new OS::Heat::ScalingPolicy. With the Icehouse release these HOT Templates have become the recommended approach. In addition, there is an ongoing effort to introduce TOSCA (Topology and Orchestration for Cloud Applications) into Heat, which is an OASIS-led standard. A new TOSCA translator project for Heat is now part of StackForge. A preview of the TOSCA simple profile can be found here supported by IBM, GigaSpaces, Huawei, Vnomic a preview version of a TOSCA-based Orchestration project for OpenStack is available with the new Cloudify 3.0 project.

Other updates include new the Trust-based security model that will allow the delegation of user roles and permissions without passing Keystone tokens or credentials. For more information on the new Heat Trust Model see the Steve Hardy post Heat auth model updates - part 1 Trust. In addition, the Icehouse release includes improvements to scalability by allowing the distribution of Heat deployments tasks between multiple Heat engines. 

To learn more about the Heat Project Icehouse updates I’d recommend looking at Steve Baker’sonline presentation

Try Out the Heat Icehouse Release on DevStack

Yoram Weinreb a Lead OpenStack Architect from GigaSpaces wrote a detailed example on how you can setup a Heat Icehouse environment on DevStack. What’s interesting with this example is the addition of Neutron orchestration as part of the simple WordPress example.

To try out the example with Heat Icehouse follow the steps from Yoram’s post.

I will be demonstrating this example at the upcoming OpenStack Design Summit in Atlanta next week in the talk - When Networks Meet Apps.

Network Automation and Orchestration with Openstack and Cloudify

In my previous post I discussed the evolution of networking in the cloud - from commodity hardware to the cloud, and the need for the virtualization of network functions, and the different drivers for change.  In this post I will focus on orchestrating your networking through OpenStack’s Neutron, its challenges and potential.

Bringing the Network and Applications Together

So, as I mentioned in my previous post, when OpenStack introduced its networking API, known as Neutron, this provided a new way to set up networking services and configurations such as routers, subnets, floating IPs, security groups, and more through a simple API.  Until now we used to think of network configuration and application deployments as two separate things. This also goes back to the way most of our IT is structured.  We have different groups for networking operations and for applications’ operations and in most cases they have a fairly loose interface between one another.

As with DevOps once we open our infrastructure layers through APIs we can break those traditional boundaries between networking and apps. In a networking context, this means being able to create and configure our network as part of the application deployment.  To understand what this really means, let’s examine what the typical steps that we need to follow to set up networking for our application.

Typical Network Configuration:

1. Set up admin network for our application monitoring and control services
2. Set up application network to allow internet access to the relevant machines
3. Set up the security group per application tier (open only the ports and IPs relevant for that tier)
4. Set up floating IPs where needed
5. Set up a load balancer and configure it to route traffic to our web containers

Adding Continuous Availability

There are a set of additional network configuration steps that needs to be considered when we think of high availability.

Such steps often include:

1. Partitioning our services into separate availability zones and regions
2. Setting up connectivity between the availability zones and regions (which often run on separate networks)
3. Switching back and forth between each availability zone in case of a failure

Orchestrating and Automating  Network Configurations as a Part of Application Deployment

Today most of the steps required to set up our network are often done manually and externally to our applications. Now that we have API access, and our networking is basically software-driven, we can automate this entire process.  As many of those steps tie in more directly to our application services, we need to include them with our application deployment.

Network Orchestration Through a Simple Blueprint

With an orchestrator, users can define their own gateways, routers, and security groups through simple software configuration files, or blueprints, that are written in a language that the orchestrator (software operator) can understand.

With the latest Cloudify 2.7 release we added the ability for users to set up their network configuration as part of their application deployment blueprint. This allows users to set up security groups, separate networks, isolate the management network from the application’s network, define whether a certain piece of your application will run in the same availability zone or not, control if the storage will be close to the application geographically (i.e. the affinity rule).  Read about Network Automation to see how such a blueprint should look.

Final words

Bringing the application and networking together provides an easy way for users to capture the value of newly available network capabilities without having to become a network operator themselves. This significantly simplifies the complexities involved with exposing networking elements to the user by abstracting the networking piece of our deployment into an application blueprint.

In addition, the fact that we can setup our network configuration as part of our application deployment allows us to harden our security to match our application topology exactly . For example, we can choose to open only the necessary nodes to internet access, setup security groups dynamically to match the ports and IP addresses that are allowed to access our service and other such customizations. In this way, setting up an application and its network configuration is infinitely simplified for an application developer.

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.

Industry Survey Shows: Organizations Turn to Stream Processing for their Big Data Needs

In a stream processing model, data is processed as it arrives to the Big Data system. With a batch processing model, only once the data is stored does the system run a variety of batch analytics - typically through a map/reduce style of processing.

 Facebook and Twitter are good examples of stream processing models in use today, as I outlined in a previous post entitled Facebook’s vs Twitter’s Approach to Real-Time Analytics.

 According to a recent survey of approximately 250 respondents, there is a trend moving towards stream processing in order to speed up analytics, with a significant increase in the popularity of this model when compared with last year. The number of organizations planning to use stream processing in 2014 has more than doubled (24%) from last year’s amount (10%).

This goes hand in hand with the fact that real-time analytics is also becoming more mainstream, as I pointed out in my 2014 Predictions.

Another interesting data point from the survey is that roughly 43% of the respondents defined real-time as sub-second and 42% defined it as sub-minute. This difference is quite interesting and could lead to different approaches for implementing stream processing.

For example, real-time is defined differently by Facebook and Twitter. In the case of Twitter, they chose Storm as their event processing engine, allowing them to process events at a sub-second resolution. Meanwhile, Facebook defines real-time at a 30 second batch window, choosing a logging-based approach to fit their need.

Based on the survey, it appears that both approaches are valid and can be applied in correlation to the degree of real-timeliness of your analysis.

 

Facebook Log-Centric Stream Processing	Twitter Event-Centric Stream Processing

In-Memory Data Grids become a more popular choice for real-time processing

According to the survey, 64% of the respondents indicated that they plan to combine In-Memory-based solutions for delivering their real-time analytics processing. This is also consistent with last year survey done by Ventana Research.

 I believe that will see an even bigger movement in this direction, as the cost/performance ratio of In-Memory Data Grids and In-Memory Databases would go down significantly with the combination of RAM and Flash devices, which together provide a fairly compelling solution from both performance and cost ratio to that of other disk-based alternatives.

 

Big Data in the Cloud increased to 56%

New developments in cloud infrastructure, such as the support for bare metal in the new OpenStack releases, as well as support, high memory, flash disk, etc, are removing many of the technical barriers for running I/O intensive workloads like Big Data in the cloud.

Indeed, according to the survey, there is a significant shift towards the use of Big Data in the cloud with 55% of organizations either using or planning to run their Big Data in the cloud in 2014.

 

Where do we go from here? How does this effect GigaSpaces’ future roadmap?

There are multiple areas in the GigaSpaces roadmap that aim to address this demand. 

• Real-Time Processing through Storm Integration - In this project, we integrate Storm on top of a Memory backend for both stream processing and data-store.
• Support for Flash Disk - The integration with flash disk is planned for our upcoming XAP release and will include support for SanDisk, Fusion I/O and other flash disk devices.
• Big Data in the Cloud - through Cloudify - We've been continuously extending our Big Data portfolio support and recently added support for Storm and Cognos, adding to our existing support for Hadoop, MongoDB, Cassandra, ElasticSearch, etc.

 

References

• GigaSpaces Annual Big Data & Cloud Survey 2013
• Eight Cloud and Big Data Predictions for 2014
• GigaSpaces and Storm Part 2: XAP Integration
• GigaSpaces And Storm Part 1: Storm Clouds
• Big-Data-Real-Time-Performance - Enjoying both worlds with one Architecture!
• 2012 Big Data Survey Report
• In Memory Computing (Data Grid) for Big Data

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'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