Nati Shalom's Blog

The Amazon Effect on Open Source

This post first appeared in The New Stack on November 27th, 2018.

 

 

Cloud computing and open source are two big movements that are reshaping and continually disrupting the way we think about the relationship between vendors and consumers. It opened up the entire thinking behind even the most basic questions such as: What is the right business model? What is considered a product with value that is worth paying for? How much are we willing to accept vendor lock-in?

Cloud computing brought a completely new and agile way of thinking about the vendor/consumer business model with the pay-as-you-grow model and SaaS. This model forced vendors to become more efficient and accurate with respect to how they deliver their software and think about the value behind their product.

The world where the consumer was willing to pay for “shelfware” is long gone, as cloud has also empowered the consumer to be more sophisticated with the way they measure the value behind a product and make data-driven decisions.

With open source, the picture is a bit more complex. Linux and many of the first open source projects started as a commoditization strategy i.e. providing a free or “cheap” alternative to what used to be expensive software. Today, many of the open source projects are the drivers of new innovation and often rely on substantial funding to keep them going. While many of these products come with a free edition, they use an open core strategy in which the cost for the software is in many cases as costly as any other non-open source products.

So, what is the value of being an open source product if the cost is no longer the key driving force?

That’s actually a great question. I was surprised myself to see that many of the investors that I have met over the course of the past year have been challenging me with that question and have raised lots of skepticism about whether there is even a viable business model behind open source (Red Hat is considered a unicorn on this respect).

They had good reasons for that as they have been “burned” by investing in promising open source projects (OpenStack is one of the recent examples that came up frequently as a reference on this regard).

Obviously, this got me thinking about this question quite deeply, and I came to a pretty simple realization.

Open source changes the relationship between the vendor and the consumer from a relationship of mistrust and that of a passive consumer of a veritable “black box,” to a relationship of trust and partnership. Open source makes it possible for consumers to know exactly what they are getting before they buy the product, along with more ways to control the way they will consume a given product or shape it through code contribution, feature requests, etc. With non-open source technology, a consumer is dependent entirely on the vendor every step of the way.

The “free” part in open source also allows consumers to choose when to pay for a given product based on their adoption stage, and value that they are getting from the product. Many open source companies will allow you to use their products completely free with the assumption that as you grow and get more substantial value from the product, you’ll need support and specific hardening, and this is where they will see monetization. So, in a nutshell, open source allows consumers to pay for products only when they feel that they are getting enough value from them or want to grow with the value.

This post, however, is neither about open source principles nor cloud business models — but rather that nexus where they both meet and have changed and disrupted the entire way technology is now adopted as well as consumed.

The Amazon Effect on Proprietary/Closed Source Companies

2018 has been the year in which the key closed source companies have recognized that open source is not just a technology choice but plays a key role from a business value perspective:  scale.

Successful open source companies tend to scale much faster than closed source alternatives.

The trust relationship that open source companies often have with their consumer also creates a higher degree of loyalty, and thus stickiness, which is one of the key factors that leads to that difference in scale when compared with non-open source alternatives.

Non-open source companies have to battle for every deal and customer even within their existing customer base. With open source that process is quite different as, in many cases, the monetization process starts after the customer is already convinced and has been using the product for a while. Therefore, they would be much more receptive to moving forward quickly.

How is that related to the topic of this post?

Well, cloud is all about scale. Companies like Microsoft, and now IBM, have realized that we’re now in a land-grabbing war. If they can’t build a fast-growing, scalable engine they will lose the battle to AWS. When you think about it in those terms it now makes perfect sense why Microsoft and IBM were willing to pay such substantial amounts for the Github and Red Hat deals.

The cost of losing the war to AWS is far higher than the cost of those deals.

What’s interesting in the Salesforce acquisition of Mulesoft is that it shows that this realization applies also to companies that were “born in the cloud” and not just legacy vendors.

The Amazon Effect on Open Source Companies

The Amazon effect on open source companies is actually quite interesting as it is indicative of the mutual effect that cloud, and open source have on each other.

In the opening of this post, I described the key assumption behind the business model of open source. The key assumption is that the monetization often takes place when you make serious use of the product.

When Amazon started to provide managed offering of specific open source products, they were breaking right into the middle of this assumption. In other words, by offering a managed service for a product they didn’t develop, Amazon “steals” the fruit of monetization without having to carry the cost and investment of the actual development of the product.

That broke the entire “trust system” that stood behind many of the open source models. Open source companies such as MongoDB and Redis had to respond by taking a defensive move that eventually make their product less open. That defensive move damaged the most sensitive aspect, trust, between consumers and open source providers creating a negative effect on the industry as a whole.

Cloud Native Open Source to the Rescue

So, the question comes back to, what should the right relationship between open source and cloud providers look like?

As I was working on my keynote session for our first Cloud Native Days Tel Avivconference, the picture became clearer.

While cloud providers like Amazon are abusing open source products to their benefit, even at the cost of harming the open source community, other cloud vendors are seeing that as a weakness and therefore look at open source as an opportunity to break the current AWS monopoly and win more cloud business by demonstrating a “non lock-in” strategy with open source.

Google was the first to realize this with the launch of Kubernetes as an open source project. Kubernetes shows how a cloud provider (Google in this case) can take an active role in driving and contributing to open source projects, even at the risk of cannibalizing itself, by allowing other providers to offer the same offering and compete on the same stack.

That raises the question — what’s in it for Google?

The answer is actually pretty straightforward and is as true in a pre-cloud world as in a post-cloud world. It’s the same strategy that helped Google beat Apple in the smartphone business — launching Android as an open alternative to iOS.

Taking the open source route is an effective strategy to win the hearts and minds of developers. Kubernetes is a great success, and part of the reason for its success is because it’s not bound to a particular cloud provider. With that move, Google is winning the hearts and minds of developers, by not locking them into its platform. Google is creating a trust system with the developer community by making Kubernetes a great place to be, and part of the reason it’s such a great place is that they are invested heavily in contributing back to the platform.

What’s interesting to note about the cloud native ecosystem is that it helps balance the relationship between cloud providers and the consumer. Rather than competing on delivering a proprietary stack for each cloud provider, cloud providers compete for whoever has a better “home” to host this cloud native stack.

Coming back to the Android analogy, the Android community was also quite effective in driving the iOS roadmap and features, which were indirectly influenced by the competition with Android, and probably had a much stronger impact than any alternative. Similarly, I believe that the Kubernetes ecosystem will shape, directly and indirectly, how AWS will deliver its own services.

The Microsoft acquisition of Github and recent IBM acquisition of Redhat, as well as the smaller VMware acquisition of Heptio, follow a similar line of thought. Unlike Google, they took a shortcut of buying their way to the developers through a set of acquisitions. It remains to be seen whether this will lead to similar success. A large part of that depends on how much the big players understand the delicate trust system behind open source and how much they will maintain this trust system in their entire operation.

The size of the investments, specifically from Microsoft and IBM, is an indication that open source is a strategic move, so I tend to believe that they will work hard to make it a success.

Final Notes

Over the years there has been an ongoing debate whether or not open source has an important role in the cloud era, where software is often delivered as a service.

The business model behind open source was also challenged due to the high failure rate of many companies as well as the monetization threat on strategy by Amazon.

To me, 2018 will be remembered as open source’s breakthrough year. It is the year in which open source companies were able to prove their business valuebeyond a shadow of a doubt. It is the year in which open source companies went public and were valued substantially higher than other non-open source equivalents.

It is the year where major non-open source companies like Microsoft, IBM, and VMware, who have always had an ambiguous relationship with open source, joined the open source camp in full force. It is the year where the biggest software acquisition deal was made for a company whose entire business model is built around open source.

It is also the year in which open source is forcing all major cloud providers to finally agree on a common platform for delivering and managing applications, which is clearly backed by real numbers as can be seen in the recent Linux Foundation survey.

Which of the following data center types does your company/organization use? (CNCF Survey)

It is the year in which we’ve seen that production usage of Cloud Native Computing Foundation projects has grown more than 200 percent, meaning cloud native technologies, according to the survey.

So, is there a viable business model behind open source (in the post-cloud era)? Hell yeah!

Watch the talk in the video below:

Making Hybrid Cloud Simple and Real with vCloud Air, TOSCA and Cloudify

 

 

While hybrid cloud has been a mainstay discussion in the cloud world for quite some time now (note this post of mine on hybrid cloud from 2011, when CloudStack was still Cloud.com), the reality is that setting up hybrid cloud has proven a fairly complex process. Therefore we've seen only a few real implementations of true hybrid cloud in the wild.

In this post, I  wanted to describe the joint work that we've invested together with the VMware cloud team to change this reality and finally make the hybrid cloud story simple and possible.

vCloud Air makes hybrid cloud truly simple and real

While most public clouds started as independent public cloud services, and only later started to add private cloud connectivity; the exact opposite is true for vCloud Air, which was designed primarily as an native extension of VMware private cloud. In this context, users are able to use the same tools currently in use to manage their local VMware environment in order to manage their public cloud resources, as well. This makes the hybrid cloud story significantly simpler, as there is no longer the need to worry about the connectivity between the two sides of the data center, and at the same time we get the cost benefit of using resources on-demand on a pay per use basis.

The ability to make hybrid cloud so simple fit well with the Cloudify pure-play orchestration vision, and made the integration with the two platforms a perfect fit.

In this post I wanted to spend some time on what that means for VMware and OpenStack users.

Putting vCloud Air, TOSCA and Cloudify  together

 

vCloud Air users needed a simple way to deploy and manage their applications on vCloud Air using DevOps tools similar to Amazon Cloud Formation.

As the landscape is still being shaped, and there’s no clear winner yet, it is very important for these users to have tools that will allow them to keep their options open.

TOSCA seemed to be a great fit in such a context, as it provides a standard templating language that doesn’t tie users into a particular platform.

On top of this, TOSCA orchestration also aims to go beyond the installation part of the application and covers all the aspects of the application lifecycle through the addition of workflows and policies that can be used to handle continuous deployment, self-healing, and auto-scaling processes.

On a similar note, many Cloudify users comes from Enterprise and Telco markets. Such users are already heavily invested in VMware. These customers are actively looking for a more agile and cost effective way to run their data center.  The ability to bring capacity on demand seamlessly into private cloud makes the entire private/hybrid cloud story truly attainable.

By putting vCloud Air, TOSCA and Cloudify together we’re getting the cost benefit of using on demand resources for our private data center in a way that doesn’t tie us to a specific platform and at the same time provide a more complete application lifecycle and management solution that enables full automation of our deployment and DevOps processes.

Extending the solution to the rest of the VMware stack

VMware provides three kinds of platforms today, the vCenter/vSphere environment that serves many of the enterprises data centers today, and VMWare Integrated OpenStack, which provides API compatibility with OpenStack for vSphere/vCenter environments.

Cloudify comes with native TOSCA support through plugins that allows you to use TOSCA blueprints as a templating language across both vCloud Air, vSphere and OpenStack that provides a consistent way to manage applications across all three environments.  On top of this, it also makes it simple to build mixed resources of all three environments all with the same blueprint.

Having pure-play orchestration and management that is backed by an industry standard, TOSCA, enables the decoupling of the way to manage applications from the underlying infrastructure. While there is still the need to rely on specific APIs and features of the specific infrastructure, they are now at a point where the cost of the switch isn’t as significant compared with the alternative of binding themselves directly into the specific underlying infrastructure.

The benefit for OpenStack users

Many OpenStack users are Enterprises and Telco customers who are known to be heavy users of VMware platforms. This integration makes the ability to mix and match existing VMware environments together with OpenStack and vCloud Air, providing greater flexibility to decide which applications and workloads fit best in which environment while using common and consistent management for their applications across environments.

What should we expect next?

Through our partnership with VMware we’re planning to make this integration simpler for vCloud Air users by allowing them to use TOSCA directly through the vCloud Air public cloud service. In addition, the plan is to make the hybrid cloud story between vCloud Air, vSphere and OpenStack as seamless and simple as possible so we will be adding more examples and tighter integration for all three platforms.

How should I get started?

• TOSCA Orchestration for VMware - Hybrid Cloud Made Simple
• vSphere Plugin Docs
• VMware Hybrid Cloud with Cloudify

The VMware OpenStack Cloud Conundrum

OpenStack is an open source cloud infrastructure that is considered by many as a cost-effective alternative to VMware.

In reality, the transition from VMware to OpenStack isn’t that trivial, which leads most enterprises to take a hybrid cloud approach. This means they run their OpenStack infrastructure alongside their existing VMware infrastructure with an aim to gradually transition workloads into their new OpenStack environment.

Recently, VMware announced their own VMware Integrated OpenStack, which is a VMware-supported OpenStack distribution providing tighter integration between existing VMware environments and OpenStack.

In this post I will discuss three of the options for putting OpenStack and VMware together and weigh what I believe are the pros and cons of each approach.

1. Using OpenStack with VMware Hypervisor plug-in

OpenStack Nova comes with a pluggable architecture for integrating various hypervisors. It supports both KVM, VMware as well as Hyper-V.

The first option for integrating VMware into OpenStack is through the ESXDriver for Nova.

In this option the Nova scheduler can spawn VMware ESX VM’s through an ESX enabled node (as opposed to KVM which runs directly from the Nova compute node).

Pros:

In this approach, we can potentially re-use our VMware images assets and easily import them into our OpenStack environment.

Cons:

1. Limited use of VMware features:  ESXDriver cannot use many of the vSphere platform advanced capabilities, namely vMotion, high availability, and Dynamic Resource Scheduler (DRS).

2. Limited Portability: There are some features of VMware, such as vMotion, that many enterprises rely on today and would need to be turned off as we move to OpenStack. As some of the images were built with the assumption that this unique VMware features exists, it wouldn’t be possible to transition them into an OpenStack environment and expect them to work.

In summary, while this option makes sense, the cost and technical limitations make it less popular. In fact, a recent OpenStack survey report indicates a fairly small percentage of users who actually use this feature.

Using VMware vSphere with OpenStack

In this approach we utilize the compute resources using vSphere. This will allow us to take advantage of all the VMware features that come with vSphere and overcome the limitations mentioned above.

In this case, the entire vCenter ESX cluster appears as a one big hypervisor. The actual allocation of the ESX hosts is done through VMware vCenter and is not exposed to the Nova Controller, as outlined in the diagram below:

Similarly, we will plug-in the VMware Storage and Network services to allow for even more complete integration across the compute, network and storage stack as outlined in the diagram below:

You can learn more about how this integration works in the OpenStack reference guide.

Pros:

The main advantage of this approach is that it enables users of VMware to benefit from both worlds; on one hand, they can use OpenStack as an open API and on the other hand they can utilize their existing VMware infrastructure.

Cons:

The main disadvantage of this approach is that it creates a completely different OpenStack implementation, which has some serious differences in its implementation and behavior from the original open source version of OpenStack - specifically in the way the compute nodes are managed.

The Elephant in the Room:

One of the main motivations to transition to OpenStack in the first place is to cut costs.

In both options we rely on the VMware stack, and therefore the actual savings are still unknown.

3. Using a Common Management and Orchestration as an abstraction to both VMware and OpenStack

In the third option we will not use any of the OpenStack VMware plug-ins, but instead we will use an orchestration layer as higher level abstraction between OpenStack and our VMware environment.

The orchestration layer provides a common management and deployment infrastructure. In this approach we will not be trying to force the VMware infrastructure to fit into the OpenStack API, but instead we will just map the different calls to either OpenStack or VMware into the appropriate type. In this way, the application is kept aware of whether it is running on OpenStack or VMware. However, since the calls to each of the infrastructure components are now centralized into one driver per environment, it is managed once for all the applications. Additionally, there is a default implementation for the built-in types, so in most cases the user will need to deal with the details of implementations of each element type only for specific customization.

Pros:

1. We are able to utilize all of the features and capabilities of each infrastructure with no limits.
2. We reduce dependency risk - With this abstraction we’re less vulnerable to a specific infrastructure and we keep our options open to move or add new environments as needed.
3. Support for vSphere and vCloud -Since we are not limited to the use of a specific API, we can integrate with both vSphere and vCloud API.

Cons

1. We are shifting the dependency on the management and orchestration layer.
2. We may lose some of the management and orchestration capabilities that are specific to each of the environments.
3. Additional customization effort: Since we’re not relying on a common API, we may need to customize the built-in types per environment to fit our specific needs. Having said that, it is important to note that this customization is only done once for all of our applications. Additionally, it is expected that over time the default types will cover most of the use cases. Therefore, the need for customization will be minimized.

My Take

Given that the cloud infrastructure world keeps on changing and evolving very rapidly (not just between OpenStack and VMware), any tight integration approach will have a higher chance of breaking compatibility or being limited to the least common denominator at some point. We also need to be aware that even though in the first two options we remain compatible with the OpenStack API, we still end up with different OpenStack implementations from a behavior perspective.

On top of that, we need to be prepared for new disruptions. This is actually taking place right now, for example, with Docker orchestration that continues to disrupt and challenge the way we handle our compute and network infrastructure.

With this in mind it would be too risky not to keep our options open.

Having an abstraction layer at a higher level of the stack gives us the benefit of being less vulnerable to changes at the lower level infrastructure. It also provides us the flexibility to adopt new infrastructure changes in the future.

Having said all this, the question “Are we minimizing or just shifting the risk?” still lingers.

This is where TOSCA comes in handy. TOSCA provides a standard way to describe our application blueprint. This significantly reduces our dependency on a specific implementation of the orchestration and management layer and this was one of the main reasons that led us to choose TOSCA when we designed the third generation of our orchestration with Cloudify.

References

• OpenStack VMware integration

• http://www.slideshare.net/danwent/hk-2013-v-mware-session?related=1

• OpenStack Hypervisor support Matrix

• OPENSTACK COMPUTE FOR VSPHERE ADMINS (highly recommended and the source for many of the diagrams in this article)

• Cloudify - Tosca Based Orchestration

Do I need OpenStack if I use Docker?

 

Docker has broken a record in the speed in which it moved from being a disruptive technology to a commodity. The speed of adoption and popularity of Docker brings with it lots of confusion.

In this post I wanted to focus on a trend of commentary that has been gaining popularity, that I’ve started to hear more often recently from users who just started using Docker.  Whether it makes sense to use OpenStack if they’ve already chosen to use Docker.

Before I give my take on this, I wanted to start with a short background for the rationale behind this question.

Background

In its simplest form, Docker provides a container for managing software workloads on shared infrastructure, all while keeping them isolated from one another. Virtual machines such as KVM do a similar job by creating a complete operating system stack of all the OS devices (through a Hypervisor). However, unlike the virtual machine approach, Docker relies on a built-in feature of the Linux operating system named LXC (Linux Containers). LXC utilizes the built-in operating system features of process isolation for memory, and to a lesser degree, CPU and networking resources. Docker images do not require a complete boot of a new operating system, and as a result, provide a much lighter alternative for packaging and running applications on shared compute resources. In addition, it allows direct access to the device drivers which makes I/O operations faster than with a hypervisor approach. The latter makes it possible to use Docker directly on bare metal which, often times causes people to ask whether the use of a cloud such as OpenStack is really necessary if they’re already using Docker.

This performance difference between Docker and a hypervisor such as KVM is backed by a recent benchmark done by Boden Russell and presented during the recent DockerCon event.

The benchmark is fairly detailed, and as expected, it shows a significant difference between the time it takes to boot a KVM hypervisor to a Docker container. It also indicates a fairly big difference in the memory and CPU utilization between the two, as can be seen in the diagram below.

This difference in performance can map to a difference in density and overall utilization difference between the two in similar proportion. This difference can easily map into a big difference in cost that is directly affected by the number of resources needed to run a given workload.

My Take:

• This question has nothing specific to do with OpenStack and can be applied similarly to any other cloud infrastructure. The reason it is often brought up in the context of OpenStack, in my opinion, is due to the fact that OpenStack is fairly popular in private cloud environments which is the only environment in which we can even consider a pure Docker alternative.

• It's about the hypervisor stupid:

Many of the performance benchmarks compare Docker versus KVM, and have little to do with OpenStack. In fact, this specific benchmark of both KVM images and Docker containers was running through OpenStack which shows that the two technologies works nicely together. In that context, most of the utilization  arguments become irrelevant when I choose to run OpenStack on top of a Docker based Nova stack as illustrated in the diagram below taken from the OpenStack documentation.

• Cloud infrastructure provides a complete data center management solution in which containers or hypervisors, for that matter, are only part of a much bigger system.  Cloud infrastructure such as OpenStack includes multi-tenant security and isolation, management and monitoring, storage and networking and more. All of those services are needed for any cloud / data center management and have little dependency on whether Docker or KVM are being used.

• Docker isn't (yet) a full-featured VM and has some serious limitations like security, Windows support (as indicated in the following email thread in the Red Hat mailing list), and therefore cannot be considered a complete alternative to KVM just yet. While there’s ongoing work to bridge those gaps, it is safe to assume that adding the missing functionality may come at an additional  performance cost.

• There’s a big difference between raw hypervisor performance/containerization and application performance, as indicated in the following graphs from the benchmark results. A possible explanation for that is that applications often use the caching technique to reduce the I/O overhead.

• If we package Docker containers within a KVM image the difference can become negligible. This architecture often uses hypervisors for managing the cloud compute resources, and an orchestration layer such as Heat, Cloudify, or Kubernetes on top to manage containers within the hypervisor resources.

Conclusion

This brings me to the conclusion that the right way to look at OpenStack, KVM and Docker, is as a complementary stack in which OpenStack plays the role of the overall data center management. KVM as the multi-tenant compute resource management, and Docker containers as the application deployment package. 

In this context a common model would be to use Docker for the following roles:

• Docker provides deterministic software packaging and fits nicely with the immutable infrastructure model.

• Docker for excellent great containerization of microservices pods

• Using Docker on top of OpenStack as well as a bare metal environment

Having said all of the above, I do see cases mostly for well defined workloads, where the use of cloud infrastructure isn't mandatory. For example, if I were to consider the automation of a small shop development and testing environment for DevOps purposes, I would consider using Docker directly on a bare metal environment.

Orchestration can be a great abstraction tool between the two environments

One of the benefits of using an orchestration framework with Docker, is that it can allow us to switch between OpenStack or bare metal environments at any given point in time. In this way, we can choose either options just by pointing our orchestration engine to the target environment of choice. OpenStack Orchestration (Heat) declared support for orchestrating Docker starting from the Icehouse release. Cloudify is an open source TOSCA based orchestration that works on OpenStack and other clouds such VMware, AWS and bare metal, and recently included Docker orchestration .  Google Kubernetes is associated mostly with GCE but could be customized to work with other cloud or environments.

References:

• Using Docker as and OpenStack compute resource (Nova)

• Orchestrating Docker containers through OpenStack Heat

• Orchestrating Docker containers on OpenStack, VMware, AWS, bare metal and Other clouds through TOSCA/Cloudify

• Docker limitations as indicated in Red Hat mailing list

• The boring truth: full virtualization and containerization both have their place

• Using Docker as immutable infrastructure

• Docker drops LXC as default execution environment

Our Open Source Cloud (Re) Architecture with OpenStack + TOSCA

Cloudify OpenStack Native approach - The Story behind the Scenes

In the previous post I outlined what I mean by native-approach to the OpenStack cloud. In a nutshell, a native approach represents out of the box tighter integration with OpenStack, all without being limited only to OpenStack.

In this post I want to share some of the stories behind the design of Cloudify 3.0 and the approach that we have taken to make Cloudify *native* to OpenStack.  I would first start by outlining our motivation behind this approach.

OpenStack-only or Not-only-OpenStack?

It is our core belief that for the foreseeable future supporting hybrid cloud is going to be important for many of the OpenStack users for the following reasons:

1. Transitioning to OpenStack is a long journey - Many enterprises have VMware-based stacks as their core infrastructure. Where many of these organizations have often started their journey toward OpenStack by creating a dev environment, and then gradually moving more workloads into their OpenStack environment as they get more comfortable with it. This process usually spans over months and possibly even years. It became apparent to us, that during this time these customers would still be using VSphere and VCloud in parallel to OpenStack. For such users, having a common platform to manage their app deployment across two environments can smoothen the transition and also reduce the risk of getting stacked if one of the environments doesn’t meet their needs.
2. The public cloud market is going to be dominated by non-OpenStack clouds - while OpenStack is on a trajectory to dominate the private cloud market, the public cloud market looks quite different with AWS as a strong and long-standing leader and other major clouds emerging such as GCE and Azure - hoping to close in. Many organizations wouldn’t want to host their entire data center on a private cloud, and would therefore need to take a hybrid cloud approach. In order to support hybrid cloud, we had to include an abstraction layer that will allow us to integrate with clouds other than OpenStack.

At the same time we wanted to have a more intimate integration with OpenStack in order to leverage the fact that it is open source and allows for a deeper integration with its core services. Through that we were able to enable smooth and simple integration of Cloudify into OpenStack.

Extending or Rewriting?

Cloudify 2.x already took a step toward deeper integration with OpenStack and we were one of the first to announce our support for OpenStack. Recently, we also added support for OpenStack Neutron.

We realized that if we want to make Cloudify fit natively into the OpenStack infrastructure it is not enough to have integration with the OpenStack components.  We also need to ensure that the design behind Cloudify will be consistent with the way other projects and services of OpenStack are implemented. This led us to the conclusion that we wouldn’t be able to be a first class citizen with OpenStack unless we underwent a major redesign of Cloudify.

Going Python?

Our first step in this direction was to move from Java to Python. Moving to Python wasn’t as painful as you would think for us, because many of our developers already knew the language. This decision quickly proved itself, as it became much simpler not just to develop the new version of Cloudify faster, but it also enabled us to join other OpenStack projects as well as reuse some of the same components and frameworks that are already used by OpenStack.

Integrating with Core OpenStack Services

Many of the products that declare support for OpenStack mostly integrate with the compute API (Nova), and quite often come with their own security, messaging, configuration, and other such considerations. We felt that this is not enough, and doesn’t fit in with the way other services are built within OpenStack. Hence, we decided to deepen our integration with other services such as Keystone, Neutron, Heat and later with Ceilometer, Mistral and others.

Going TOSCA?

Cloudify 2.x was designed around a proprietary Groovy-based domain specific language (DSL) for defining application topology and configuration. It became apparent that the DSL had become a central piece of Cloudify architecture. As a result, maintaining a proprietary DSL would only serve as a barrier going forward. TOSCA (Topology Orchestration Specification for Cloud Applications led by the Oasis Foundation) defines a standard templating language. TOSCA was similar and richer in concept to our previous 2.x specification. Because of this, using TOSCA seemed like a natural evolution.

At the time when we decided to use TOSCA, the specification was provided in a fairly complex XML. Our first step for adopting TOSCA was to come with a simplified YAML based version which better fits into the spirit of OpenStack. After the OpenStack summit in Hong Kong, when we first introduced the idea, it became apparent that members from the Oasis group were already thinking along this line.We decided to join forces and join the Oasis organization. We started working with the team to incorporate TOSCA as an official part of OpenStack. During the Atlanta summit, it was decided to integrate the TOSCA project into the Heat project and now there is an official definition of the TOSCA 2.0 specification based on YAML. Our goal is to use the TOSCA 2.0 specification as the official templating language for Cloudify instead of our current TOSCA like DSL.

Integrating with OpenStack Heat

OpenStack is growing, and with this the services that are included as part of the core OpenStack project continue to grow up the stack. One of these services is OpenStack Heat, which started as the equivalent of Amazon Cloud Formation, and is becoming more of a general purpose infrastructure orchestration these days.

We realized that since Heat is closely integrated with OpenStack it will follow the OpenStack release cycles and API, and therefore would provide a useful tool for setting up the OpenStack infrastructure. The approach that we have taken with Heat is an “overlay approach”. This means that users can use Heat as they do today to set up their infrastructure. Then, Cloudify integrates with Heat in a way that will allow it to discover any resource that was provisioned through Heat, and ultimately add the monitoring, logging and software stack on top of that environment. 

Integrating with Neutron - Network Orchestration

Networking becomes a core service in any cloud deployment. Networking refers to an element such as security-group, private IP, floating IP as well as routers, DNS, vLans, load balancers, and such.

Cloudify 2.7 included basic integration with Neutron that allows users to attach floating IPs and set the availability zone configuration.

With Cloduify 3.0, we included support for all the networking elements and can now create vLans, security groups and more, as part of the application deployment.

Design for Scale

Application orchestration often requires intimate and continuous integration with the application so that it can detect failure in sub-seconds and take corrective actions as needed. This often imposes a more complex scalability challenge.

Cloudify 2.x uses a hierarchy of managers, where each manager controls 100+ nodes as a scaling architecture. One of the things that we have experienced over the last year is that there is a growing class of services such as  Big Data and NFV. With these services, a single service can be comprised out of more than 100s and potentially even 1000s of instances. This is why the manager of managers approach didn’t fit well to these use cases.

To enable scaling of 1000s of nodes per manager, we decided to use a message broker approach based on AMQP as well as to separate the provisioning, logging and real-time monitoring tasks into separate services that can scale independently. This allows us to also control the level of intimacy between the Cloudify manager and the application services. As an example, we can tune Cloudify to handle the provisioning and logging only, and use the real-time information that has already been gathered by the infrastructure. This is especially important in the context of OpenStack, as we expect that a large part of the metrics can be gathered through the infrastructure itself.

Integrating your DevOps toolchain of choice

One thing that has become clear through the various OpenStack statistics based on their annual survey, is that many of the OpenStack users are using a toolchain that is comprised of tools available through OpenStack infrastructure, as well as tools that are not specific to OpenStack such as Docker, Chef, Puppet, Ansible, JClouds and others.

Integrating all these tools as part of a deployment system becomes a fairly complex task that can takes weeks and even months.

We realized that if we want to provide a full lifecycle management of the application, it wouldn’t be right to force a particular stack or toolchain on a user, but rather provide an open pluggable architecture that could enable you to easily integrate your choice of tools into the same deployment.

With Cloudify 2.x we included support for Chef, Puppet and also had a cloud driver that allows us to integrate with various cloud infrastructures, as well as with tools like JClouds.

With Cloudify 3.x we created a more generic plugin architecture that allows users to plug in almost any element of their application, starting from the cloud plugin to configuration management, orchestration, monitoring etc.

To make this simple we included a Bash plugin that provides a simple framework for integration with external tools, just by pointing the plugin to the relevant Bash script.

Final Notes

In this post I thought sharing the story behind the scenes that we went through to make Cloudify OpenStack native, and the rationale and decision process behind them, would be relevant to other users that are considering their OpenStack strategy.  Especially for those still deciding how deep they should integrate with OpenStack.

The good news is that, it is quite possible to integrate natively with OpenStack without limiting yourself only to OpenStack. Having said that, the initial investment required to get there is quite big. I hope that this lesson from our own experience will save others time.

Going Hybrid Cloud with OpenStack

OpenStack Silicon Valley is just a few short weeks away and we are looking forward to talking OpenStack with the local community.

A main focus for Team Cloudify at the event will be around the topic of portability AKA hybrid cloud, not only between environments, but also between OpenStack and non-OpenStack environments. In July we announced the release of Cloudify 3, a complete rewrite and redesign of Cloudify.  This change provides an intelligent orchestration and management platform that is even more compatible with the open source world of OpenStack. The platform is designed to integrate with any tool chain and provide interoperability across stacks and environments.

Why the focus on portability? It is our core belief that for the foreseeable future, supporting hybrid clouds is going to be important for many OpenStack users. Here are a couple of reasons why:

1. Transitioning to OpenStack is a long journey - Many enterprises are based on VMware as their core infrastructure. Often, those organizations begin their journey to OpenStack by creating a dev environment and gradually moving more of their workload onto OpenStack as they become more accustomed to the new environment. This process typically spans the course of months and sometimes years. It is clear that during this period of transition, customers will continue to use vSphere and vCloud in parallel with OpenStack. For those users, having a common platform with which to manage their app deployment across those two environments can ease the transition and reduce the risk of hitting a roadblock if one of the environments does not meet their needs.

1. The public cloud market is going to be dominated by non-OpenStack clouds - While OpenStack is on a trajectory to dominate the private cloud market, the public cloud market is led by AWS with other major clouds emerging, such as GCE and Azure. Many organizations would not want to host their entire data center on a private cloud and would, therefore, need to take a hybrid cloud approach. In order to support hybrid cloud environments, an abstraction layer is needed to enable integration with clouds other than OpenStack.

While we strongly believe in the necessity of supporting hybrid deployments, the integration with OpenStack was a major consideration when redesigning the Cloudify platform. By switching to Python code, developing compatibility with Heat and supporting the TOSCA specification, Cloudify is now more than ever more deeply integrated with OpenStack’s core services.

This deeper integration with OpenStack technology makes Cloudify even more equipped to handle the task of multi-cloud deployment and management between OpenStack and not-only-OpenStack environments.

Open Cloud Deconstructed. What does it mean to be OpenStack Native?

OpenStack is just not like any other cloud.

OpenStack is an open source cloud and that makes it quite unique in comparison to many of the closed source public clouds generally available today, the most common being AWS, Azure GCE, and others.

The fact that it is open source, allows us to integrate with the lower level of the stack and know exactly how each element of the infrastructure is designed and implemented.

As with any open source project we have the option to contribute and influence how the OpenStack cloud ultimately shapes out.

Given the above background, when we're designing an integration with OpenStack, we should approach it differently than we approach other clouds. A more native integration with OpenStack involves two main angles:

• Integration with OpenStack core and infrastructure services, which usually includes this full OpenStack component list - as well as those that are continually being developed and added with every release.

• Follow the OpenStack design principles - OpenStack is written in  Python and uses a certain stack for messaging, database and such . To be OpenStack native you should align yourself with the OpenStack design principles as closely as possible.

Current options to be a part of the OpenStack ecosystem

In addition to the general guidelines outlined above, there are couple of additional options to be part of OpenStack. These options mostly fit in with those looking to take an OpenStack *only* approach, and require heavy involvement in the OpenStack community project.

• OpenStack Core - be a part of the OpenStack distribution

• OpenStack StackForge is an incubation framework that allows you to add new projects into the OpenStack ecosystem. StackForge uses the same set of tools and frameworks that are used to develop the core OpenStack services, and as such it allows smoother transition from an incubation project into the core services. That makes this option more relevant for projects that are likely to be included as an OpenStack core service once they've successfully passed the incubation stages.

• OpenStack Marketplace - The marketplace is a web directory that lists the various ecosystem players and their OpenStack solutions. Currently the marketplace is focused on OpenStack distros, training, consulting and drivers, and doesn’t cover solutions on top of OpenStack.

What’s missing?

While there is a fairly clear process, and tool chain for handling core and incubated services on OpenStack, these options fit mostly with services that are primarily designed to only run on OpenStack. What’s missing is a clear certification process that will allow users to find solutions in the ecosystem, outside of OpenStack, and find out quickly what their level of integration and support for OpenStack is. This should include information such as version support, and platform the solution was certified on, which of the OpenStack services are integrated, how much of the stack of the solution is compatible with that of OpenStack’s, and other such important information. A good and simple starting point could be the OpenStack marketplace, however this is just the first step. What’s needed is a set of frameworks similar to StackForge but much more permissive that will provide a means for validating the compatibility with OpenStack.

Why should you care?

As with any popular framework there are many tools that claim support for OpenStack, however in many cases the integration mostly includes basic integration with the OpenStack compute API (Nova). A good example for this is Cloud Foundry, or other tools such as Chef, Puppet, Docker, just to name a few. While these tools do have support for OpenStack, the level of integration can vary quite dramatically. Quite often, each of these  solutions comes with a parallel stack for handling security, monitoring and other issues, which isn’t compatible with the OpenStack infrastructure. As an end user, it is important that to be able to find out quickly which of these products comes with basic support for OpenStack, and which one takes a more native approach to OpenStack. There are many implications to the level of complexity and also to the level vulnerability of those services based on the support level.

OpenStack should attract more ecosystem projects rather than competing with them

In my opinion, there has been too much focus developing more alternative projects for the OpenStack project in comparison to the focus that has been placed on projects that exist within the broader ecosystem. The main reason for this, is the lack of native support for OpenStack. A good example of this, is project Solum and its ecosystem equivalents Cloud Foundry and OpenShift. 

I think that it’s time that OpenStack realign its focus from growing all around the stack, to supporting and attracting more ecosystem projects, that focus on adding native support to OpenStack. In order to do this, there needs to be more emphasis on creating certification, compatibility and testing projects. Additionally, the marketplace initiative needs to receive more attention and investment in order to make it more than a web-based directory service, similar to the AWS marketplace.

I would like to propose a discussion on that subject during the next summit in Paris. Do you think this is a good or bad idea? I’d appreciate it if you could share your thoughts.

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

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.

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.