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:

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

ScaleDB: A NewSQL Alternative to Amazon RDS and Oracle RAC with 10x Performance Gain

In the world of relational databases, MySQL and Oracle RAC (Real Application Cluster) own a significant segment of the market. Oracle RAC owns the majority of the enterprise market, while MySQL gained significant popularity amongst many of the Web 2.0 sites.

Today, both of those databases are owned by Oracle (MySQL was acquired by Sun which was later acquired by Oracle).

The following diagrams show the enterprise database marketshare covered by Gartner and Cloud Database market share covered by Jalistic - a Java PaaS provider.

The acquisition of MySQL by Oracle raised concern over the future of the project due to the inherent conflict of interest between its two database products. Oracle RAC is the company’s main “cash cow” product, while MySQL competes for the same audience.

Shortly after Oracle’s acquisition of MySQL, the open source database was forked by one of its original founders into a new project named MariaDB. MariaDB was established to provide an alternative development and support option to MySQL and is now becoming the default database of choice of RedHat.

MySQL vs Oracle RAC Clustering Models

The two databases take a fairly different approach to scalability.

Oracle RAC is based on a shared storage model. With Oracle, the data is broken into strips that are spread across multiple devices, and multiple database servers operate concurrently and in sync over the (shared) data.  

MySQL, on the other hand, does not use a shared data model. With MySQL, a given data set is managed by a single server (a model called shared nothing). With MySQL, scaling and High Availability (HA) is achieved by managing copies of the data. As only a single machine can update the data, this mode can only scale-up by adding more capacity to the machine that owns the database. As machines have limits to capacity yet must keep up with large amounts of data or many users, the database needs to be broken into several independent databases (a process called sharding). However, sharding is a complex process, is not dynamic and requires assumptions on data distribution, data growth and the queries. For these reasons, sharding is not possible with many applications. In particular, a cloud deployment is expected to be elastic to dynamically support changing needs and user behaviors.

For High Availability, the MySQL shared nothing approach uses Primary/Backup model with a single master and a backup node (called slave) that manage a copy of the data. Each update to the master requires that the same update will be executed on the slave. The primary and slave nodes require some handshake protocol to determine who is the master and sync the changes of the data. The master node performs updates/writes to the persistent file-system and the level of High Availability is set by the DBA, who decides if the slave can lag behind or needs to confirm the duplicate updates within each transaction.

For scaling, this model can use the slave as a read replica (or make additional copies of the data), a method called horizontal scaling in which read requests are spread across the different copies of the data. (However, all the writes need to go to the master and then be reflected on the replicas/slaves.)

Relational Databases on the Cloud

The high-end position of Oracle RAC, the low-cost and open source nature of MySQL, along with the adoption of the cloud as the infrastructure platform led to a vastly different method of deployment of databases in the cloud.

Oracle RAC took an approach similar to the old mainframe: to produce a pre-engineered appliance (called Exadata) that comes with the software and hardware integrated. That approach was specifically aimed at existing customers of Oracle RAC who needed a quick resolution to their scalability needs without redesigning their applications. Plugging a more optimized stack helped to push the scalability bar without changing the existing applications that rely on the database.

Amazon launched RDS, which is basically an on-demand version of the MySQL database. This approach fits nicely with the existing users of MySQL who are looking for a more affordable way to run their database in the cloud.

The main limitation of the Amazon RDS approach is that it inherits the limitations of MySQL and thus provides a limited and relatively complex read-scalability and doesn't provide a good solution for write-scalability other than the scale-up approach.

ScaleDB - a NewSQL Alternative to Amazon RDS and Oracle RAC

ScaleDB is a NewSQL database that takes an approach similar to the read/write scalability model of Oracle RAC and implements it as a platform that transparently supports the MySQL (or MariaDB) database. As a result, existing MySQL/MariaDB applications can leverage the platform without any changes - they use MySQL or MariaDB as the front end engine which connects to the ScaleDB platform that provides a new and more concurrent database and storage services. This approach makes it possible to run multiple MySQL or MariaDB server instances against a distributed storage in a shared data model (similar to Oracle RAC).

The diagram below shows in high level how ScaleDB works.

Each Database Node runs a standard MariaDB database instance with ScaleDB plugged as the database engine and as an alternative storage and index device.

Scaling of the data and the index is done by processing requests concurrently from multiple database instances and leveraging the ScaleDB distributed storage tier (at the storage/file-system level) where data and index elements are spread evenly across multiple storage nodes of the cluster. Read more on how ScaleDB works.

ScaleDB vs Other NewSQL Databases

Most of the NewSQL databases are based on MySQL as the engine behind their implementation. The main difference between many NewSQLs and ScaleDB is that NewSQL databases brings the NoSQL approach into the SQL world, where ScaleDB takes the Oracle RAC shared storage approach to scale the database.

ScaleDB can deliver write/read scale while offering close to 100% compatibility, whereas in many of the alternative NewSQL approaches, scaling would often involve significant changes in the data model and queries semantics.

Benchmark - ScaleDB vs Amazon RDS

To demonstrate the difference between a standard cloud deployment of MySQL and a ScaleDB deployment and in order to find whether the ScaleDB approach can live up to its promise we conducted a benchmark comparing Amazon RDS scalability for write/read workloads with that of ScaleDB. We tested a dataset that does not fit to the memory (RAM) of a single machine and used  the largest machines offered by Amazon. We required that scaling would be dynamic and that all types of queries would be supported. These requirements made sharding a no-go option.

The benchmark is based on the popular YCSB - Yahoo Benchmark as the benchmarking framework.

The results of that benchmark are shown in the graphs below.

Both illustrate a relatively flat scalability with Amazon RDS and a close to linear scalability on the ScaleDB front.

Benchmark environment:

• Benchmark Framework - YCSB - Yahoo Benchmark

• Cloud environment: Amazon

• Machine Type: Extra Large

• Data Element Size (per row) - 1k

• Data Capacity: 50GB

• Zones - Single zone.

• RDS was set with 1000 provisional ios

• ScaleDB cluster setup - 2 database nodes, 2 data volumes (4 machines -data is striped over 2 machines and each machine had a mirror).

• ScaleDB MySQL engine - MariaDB

Running ScaleDB on OpenStack and Other Clouds with Cloudify

The thing that got me excited about the project is that it serves as a perfect fit for many of our enterprise customers who are using Cloudify for moving their existing applications to their private cloud without code change. Those customers are looking for a simple way to scale their applications and many of them run today on Oracle RAC for that purpose.

The move of enterprises to a cloud-based environment also drives the demand for a more affordable approach to handle their database scaling, which is provided by ScaleDB.

On the other hand, setting up a database cluster can be a fairly complex task.

By creating a Cloudify recipe for ScaleDB, we could remove a large part of that complexity and set up an entire ScaleDB database and storage environment through a single click.

In this way we can run ScaleDB on demand as we would with RDS and scale on both read and write as with Oracle Exadata, only in a more affordable fashion.

To try it now please follow the steps described in the ScaleDB Git project

References

1. Cloudify Recipe for running Scale DB

2. Yahoo Benchmark

3. ScaleDB Architecture white paper

4. ScaleDB user manual

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

 

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

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

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

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

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

The Need for a Native Open PaaS

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

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

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

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

The Missing Piece in the Puzzle - Open DevOps Automation

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

AWS Stack

 

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

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

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

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

Consolidating the Efforts

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

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

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

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

Looking Into the Future

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

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

References

• Project Solum announcement

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

• Mirantis To PaaS Vendors: Stop Fighting OpenStack Gravity

• Rackspace jumps on bandwagon with open source PaaS project

• The blurring Line between the IaaS and PaaS layers

• DevOps, PaaS and Everything in Between

 

Using the Cloudify Player as an Open Source Framework for Building Your Own Cloud Application Marketplace on OpenStack

In the previous post, I outlined the main lessons learned from the Amazon Cloud Marketplace and suggested an alternative approach for building an open marketplace.

In this post I'll refer to a specific implementation of that alternative approach through a new Cloudify Service called the Cloudify Player.

Introduction to the Cloudify Player

Cloudify Player is a new patent-based service that makes the experience of trying and deploying even the most complex, multi-tier big data applications as simple as playing a video on YouTube. The new service currently supports OpenStack-based clouds and is available as a free online service from HP Cloud Services and GigaSpaces’ Cloudify. The source code for the service is also available as an open source project on Github. The Player was developed in collaboration with HP Cloud Services, GigaSpaces’ cloud partner and leading provider of OpenStack-based public cloud services.

Cloudify Player an End User Perspective

The Cloudify Player provides a user-friendly and hassle-free user experience in which applications are "played" in similar fashion to the way you play a video online. Users can choose and browse applications from public catalogs that are based on Github. Similarly to YouTube, users can share the applications or embed them easily on their blog or website.

Users can choose to play any application as a free trial or for full production under their account.

Technical Overview

The Cloudify Player consists of the following components as outlined below:

Web Front End

The Web Front End is based on two main interfaces: a widget interface which allows users to browse through a list of applications and deploy them, and a widget management form is provided to allow users to easily publish new applications.

Users can use one of the two deployment options - a trial deployment provides a free non-gated experience for running the selected application on a single machine. Registered users can provide their cloud credentials and route the application into their cloud environment. In this way, they can also monitor the deployed instances through their cloud management console.

Multi-Tenant Orchestrator and Monitoring

The multi-tenant orchestration and monitoring service is responsible for parsing the selected application recipe and for executing the deployment of that application based on the description provided in the recipe. The web-based management allows users to monitor and manage the deployed application.

Application Analytics

Application activities are sent into an analytics service that produce real-time usage reports on the most-active application, as well as the user experience activities.

Service Catalogue Repository

The Service Catalogue is based on a Github clone.

Users use the repository to store their application recipes, track versions, manage history of updates, etc.

Cloud Pools

Cloudify can be integrated with various public and private clouds using out-of-the-box plug-ins.

There are basically two main cloud pools that are used in this architecture:

1. Free Trial Pool - The free trial pool is used to speed up the deployment experience during the trial stage. This pool is limited for time and is initially set for a single VM per deployment to avoid quick exhaustion of resources from the free pool.

2. Production User Cloud - Users that pass their credentials could use the same interface for deploying application under their account. In this case they are not limited in time nor the number of nodes per application.

Product Overview for IT Managers and DevOps

The Cloudify Player was designed to fit into a DevOps environment in which applications are expected to be modified on a continuous basis after they have been deployed. Users can add new applications easily by wrapping them with a simple script, called a recipe. Recipes can be based on either Chef or Puppet.  Recipes can be modified after they have been published by each end user before the deployment takes place.

Users can monitor and manage their applications using a single management dashboard. The management dashboard allows users to monitor the application topology and behavior as well as view real time logging and even open SSH console if needed.

Summary of the Main Features

• Out-of-the-box support for 100s of products (Leveraging the existing Chef/Puppet support)
• Supports full life cycle of user experience from simple free trial to full production
• Specific support for Big Data clusters, including Database as a Service, Hadoop as a Service, MongoDB as a Service, etc.
• Can run clusters rather than just individual VMs
• Application can run outside of the marketplace using the same tools
• Users can easily customize the services from the catalog for their own purposes, including the possibility to run their own version of each item in the catalog. Advanced users can leverage the built-in Chef & Puppet support for advanced configuration management.
• Built in multi-tenant application management so that each user can monitor and manage all of the products under his/her account using a single application-centric dashboard
• Built-in integration with analytics tools to support tracking of user activity

Using Cloudify to Build Your Own Marketplace

The Cloudify Player was designed to simplify the deployment of applications in the cloud. The open nature of the Cloudify Player provides many of the features required for building a marketplace in your own environment under your brand and with the application of your choice. In addition, we’ve put a lot of emphasise on making the user experience simple while ensuring a smooth transition from a hassle-free trial to full production usage.

You can try out the OpenStack version that we launched in collaboration with HP at www.cloudifysoure.org.

For more information about the Cloudify Player and how it works, please see Uri Cohen’s blog post Introducing the Cloudify Player.

Amazon Marketplace - Not a Fair Play, Thoughts on an Open Marketplace Alternative with OpenStack

The Promise of a Cloud Application Marketplace

The cloud has clearly emerged as the new world. Today, we find ourselves in an era of land-grabbing in which everyone wants the bigger piece of this new world.

Amazon has the advantage of being the first to grab. Others would like to follow in Amazon’s footsteps, but are met with the challenge of not being able to out-pace Amazon.

For those of us who aren’t Amazon, forming a coalition of some sort could be a good strategy.

One way of forming a coalition is through a marketplace, a system that enables faster growth through ecosystem partners.

A good example of how such a dynamic will work can be seen in today's world of mobile applications. Both Apple and Google were able to create strong marketplaces that grow much faster than they would have organically and add significant stickiness to their platforms.

Challenges of Building a Marketplace - Lessons from the Mobile Application Marketplace

A marketplace can be an excellent strategy for forming a coalition of partners and growing your offering significantly faster than you would if you were to try to grow organically.

Having said that, there is a significant advantage to being the first. As we have seen in the mobile application world, others who have tried to build a similar marketplace to that of Google and Apple are facing significant difficulties in attracting partners to their marketplaces (See Microsoft Surface as an example).

The main reason for these challenges is the Chicken vs. the Egg problem. In other words, for any marketplace to work, two essential factors must be in place: suppliers and consumers. Apple and Google already had their consumer-base and, therefore, it was easier for them to attract suppliers. Microsoft, on the other hand, does not yet have the mobile consumer-base on its side and is therefore facing a hard battle to bring in the suppliers.

A Cloud Application Marketplace

A Cloud Application Marketplace is similar in concept to that of mobile applications, but aims at cloud data-center services such as Database services, Application Containers, Messaging, CMS, CRM etc which are deployed on a cloud.

Amazon Cloud Marketplace

The marketplace concept is nothing new to Amazon and is already running a successful marketplace for its eCommerce business.

It only made sense for Amazon to latch on that model and use it as a basis for building its Cloud Application Marketplace, as described here.

The Limitations of Amazon Marketplace

While the promise of the a Cloud Marketplace as an ecosystem play is a no-brainer, an over-simplified implementation of it can yield a diminishing return as noted in Janakiram MSV article AWS Marketplace – An Oversimplification of the Cloud? Janakiram points specifically to the following limitations:

· Persistent Services Limitation:

By default, the database and other persistence-dependent services are confined to the ephemeral storage or instance storage of the EC2 instance. This is a very risky proposition as the data will be lost completely in the case of an instance failure. I wouldn’t be comfortable even running a non-mission-critical application like a WordPress blog on EC2 without attaching an EBS volume.

· Not Designed for Real Production:

Launching a LAMP or Tomcat stack with 1-Click is great for a small proof-of-concept or a demo, but no one would attempt this for a production application. Moving to the Cloud is not just about forklifting an app from on-premise server or a host to a VM. It is definitely much more than that! AWS Marketplace squarely focuses just on compute by launching an EC2 instance with pre-configured stack without considering any of the essential building block services like storage, networking and databases.

· Loadbalancer Limitations:

For example, the Amazon EC2 instances launched through the Marketplace cannot be added to an Elastic Loadbalancer. I attempted to launch 2 instances of the free Tomcat 6.0/MySQL Stack provided by OpenLogic and adding them to an Elastic Loadbalancer. ELB threw an error and refused to add the instances. This is a huge limitation for any real-world web application that intends to run on a Tomcat instance launched via the Marketplace. I wouldn’t be comfortable running my web application in just one instance without any possibility of scaling out in the future.

The Limitations of the VM-Centric Approach

Cloud applications are often packaged and run on VMs. It seems only natural that if applications are packaged on VMs, a marketplace would be a repository of pre-packed VMs, as in the case of the AWS marketplace.

Having said that, there are some basic flaws in this assumption - cloud applications and services are much more complex. Many of the services and applications need to run on high-availability mode, which often means that they need to run in more than one availability zone with inter-connectivity between them. In addition, many of the services, such as database services or web-services, need to run in a cluster deployment. In order to do so, multiple instances of VMs must be deployed. As real life applications tend to be multi-tier, there needs to be a way to deploy a set of VMs with some level of interdependency between them. When running an application on the cloud, we often need to think of it as a living organism that continues to change and evolve, rather than one-off deployment.

All these factors make the VM-centric approach a good trial and demo tool, but as Jankiram pointed out, a significant over-simplification of what cloud applications tend to be.

AWS Marketplace - Not a Fair Play

In order for a marketplace to be successful, it is essential that all players will get a fair shot to win consumers.

A marketplace owner in this context needs to take the role of "honest broker."

Amazon offers a long list of its own set of services as products outside the marketplace that don't face the limitations I listed above, in contrast to the applications that do run on the marketplace and are met with these challenges. This gives Amazon an unfair advantage over its own partners.

 

 

Building an Open Marketplace on OpenStack

The creation of an open marketplace would serve as an alternative to that of Amazon. A good substrate for that alternative approach would be to use open cloud frameworks like OpenStack. OpenStack already has a growing community of users and a growing support of cloud providers which provide an excellent starting point for the marketplace.

Below are some of the principles that I believe should serve as a foundation for building an open marketplace.

A Recipe-Based Marketplace

While the basic unit of deployment in many clouds tends to be based on VMs in many *real* deployments, the VM is used mostly as a generic container of the operating-system. The actual application services are deployed through a DevOps automation tool such as Chef, Puppet or Cloud Formation (Heat is the OpenStack alternative for CloudFormation on OpenStack) after the VM has been created. In this way, the deployment unit is the recipe rather than the VM. The recipe is used to describe the application services that will be deployed into the VM after it has been created. Unlike a VM, a recipe can be extended beyond the boundary of a VM and can describe fairly complex, multi-tier, clustered applications. It can also deal with the automation of post-deployment processes such as upgrades, monitoring, fail-over etc.

Based on that description, it only makes sense that we will use recipes as the unit of deployment instead of VMs. In this way, we can overcome many of the AWS marketplace limitations that are outlined above. As there is no standard recipe model as of yet, we'll need to be able to integrate with existing recipes such as Chef, Puppet and CloudFormation.

Other Considerations

Having a recipe-based marketplace is a good starting point. However, there is much more to building a marketplace than to choosing the recipe-based engine upon which to run an application. The main challenge is around the user experience and mastering the balancing act of keeping the marketplace attractive for both the consumers and suppliers.

Below are some of the key principles that I believe should be taken into consideration when building an open marketplace:

• Open source - An open source marketplace would enable different cloud providers to offer and share similar applications and services across different cloud providers.
• Popular frameworks – The marketplace should be based on popular open frameworks such as Chef, Puppet or CloudFormation/Heat templates.
• Reduce the barrier to entry - Make the investment of porting the application to the marketplace worth the effort beyond the marketplace. To reduce the barrier of porting applications into the marketplace we need to design it in such a way that we could use the same elements for deploying our application outside the marketplace.
• Support both multi-tier and cluster deployments
• Extensible - Users can pick a service from the marketplace and easily customize it to their needs.
• Fair play - Applications that are running through the marketplace should have the exact same capabilities as any application that is running outside of the marketplace.

If You Build It, They Will Come - Doesn't Work

These days I'm seeing many cloud providers trying to mimic Amazon’s success and launch their own marketplace. As in the case of Amazon, they also start with a VM-centric approach and thus, inherit many of its limitations. Furthermore, the main problem that I see with many of those attempts is that they seem to be taking the "if you build it, they will come" approach, not realizing that they don't have the advantage of being first and, more importantly, are not at the same point where Amazon was when it launched its marketplace ( i.e. with a huge consumer-base running on their platform).

As a result, I personally believe that many of those attempts are doomed to fail.

The real opportunity IMHO is to take a more open approach that could work outside the boundaries of a specific cloud provider. OpenStack could serve as a great starting point for forming this ecosystem.

To illustrate the points from this post on what an Open Marketplace could look like, in the next post I'll refer to how we use Cloudify as an open source framework for building your own cloud application marketplace on OpenStack.

DevOps, PaaS and Everything in Between

This month Amazon announced AWS OpsWorks, which is the result of their acquisition of Peritor and the embedding of its Scalarium platform within AWS. OpsWorks is a new framework for simplifying the deployment of applications on the cloud.

Given that Amazon already has a few frameworks automating application deployment, such as CloudFormation and Elastic Beanstalk, I find the addition of OpsWorks to the mix to be an important recognition of the void that exists between the existing PaaS and Automation frameworks.

 

In this post I'll try to zoom in to that void between PaaS and DevOps.

I'll start with a post that I wrote a few months back - PaaS Jailbreaker, in which I pointed out the two models for delivering applications in the cloud, from PaaS to DevOps. In this post I suggested that rather than thinking of the two models as separate entities, it would make sense to combine the two.

James Urquhart wrote an excellent article on GigaOM - Is your PaaS composable or contextual? In his article, Urquhart refers to the differences between the two approaches to PaaS as composable vs contextual. A good example for a contextual approach is the plugin-based approach implemented by Heroku or Force.com. Plugins provide a flexible way to extend the platform, but the extension needs to fit into a certain model. For example, in the case of Heroku you don't control the actual VM or underlying cloud infrastructure, nor the network that is provided for that infrastructure. A composable approach, on the other hand, is focused on the composition of the different application components and, as such, doesn't need to assume anything about the underlying infrastructure that runs the components of our application. Amazon OpsWorks fits into that second category.

Urquhart specifically pointed out Dietzler’s Law for Access as a way to illustrate the limitation of the contextual approach.  While the contextual approach (customization via plugins) provides some degree of flexibility, it is the 10% of the things that you can't control that matters most, as they define whether you'll be able to be deliver your application the way you want to:

Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want.

Interestingly enough, Amazon launched OpsWorks a week later.

The introduction of OpsWorks was quite interesting as it came two years after Amazon launched its Heroku/GAE equivalent - Elastic Beanstalk. I found the announcement by Amazon quite interesting. The fact that they had a PaaS offering already and still found it necessary to launch a new platform for delivering applications is:

1. Acknowledgement that the current PaaS offering isn't a one-size-fits-all solution, and despite the various extensions that Amazon delivered to support other languages within the platform, there are still many applications, and consequently organizations, that do not fit into the Elastic Beanstalk model.
2. Recognition of the fact that within the realm of the application delivery, there is a need for a more open framework for delivering applications, and that realm needs to take a more "composable" approach. In the case of OpsWorks, the composable approach happens to rely on Chef and the OpsWorks orchestration layer on top of it.

Werner Vogels uses the control vs convenience tradeoff as a way to position the various AWS offerings, as he pointed out in his post: Expanding the Cloud - Introducing AWS OpsWorks, a Powerful Application Management Solution:

With the launch of AWS OpsWorks customers now have a very powerful solution that allows them to manage their application easily without giving up control. 

In other words, OpsWorks is aimed at filling a void between the Beanstalk model and the DIY (do it yourself) model.

Interestingly enough, I used to describe the various solutions in the cloud stack in very similar terms to the way Vogels does, with the slight difference that I used the term Control vs Productivity and looked at a broader scope between IaaS and PaaS.

OpsWorks vs Other Kinds of PaaS

In a discussion I had on that subject last week with Ran Tavory and Ori Lahav as part of the Reversim podcast, we seemed to agree that currently, there is space for both models of PaaS - the OpsWorks model (composable) and the Beanstalk model (contextual). Having said that, when I framed the question "which of the frameworks/approaches will run 80% of the cloud workload in the future?" we all seemed to agree that the answer would more likely be OpsWorks. The last point led me to believe that while there is space for the two models right now, this may be only a transition stage, while over time we’ll see that first generation PaaS and the likes of Beanstalk will be replaced with second generation PaaS offerings, as in the case of OpsWorks.

OpsWorks and the blurring line between PaaS and IaaS

The fact that OpsWorks runs on Chef, as do many of the IaaS services in many cloud infrastructures, also raises the question whether it is right to draw a line between our IaaS services and applications, as I pointed out here: The blurring line between PaaS and IaaS.

OpsWorks and Cloudify

OpsWorks and Cloudify follow the same foundational concepts from an architecture perspective - both frameworks integrate with DevOps tools like Chef and add an orchestration layer on top of it, making it easier to compose various parts of the application stack. In many ways you can think of Cloudify as a framework for building your own OpsWorks.

PaaS, DevOps and Everything in Between

Vogels seems to avoid labeling either Beanstalk or OpsWorks as belonging to the PaaS category. Urquhart, on the other hand, looked at the two as two kinds of PaaS solutions - Contextual (Beanstalk) vs Composable (OpsWorks).

One thing that is clear to me is that the current PaaS category is too narrow to fit all the different kinds of PaaS.

Looking at the definition of PaaS in a broader context, I would frame it as a "Platform for running and managing applications on the Cloud." In that context, the way we choose to run those apps becomes an implementation detail. Having that context in mind, I tend to look at both Beanstalk and OpsWorks as two kinds of PaaS offerings. What we’re missing at this point is a simple way to label those different categories.

One approach would be to use Urquhart’s definition (“Contextual vs Composable) which categorizes the different PaaS solutions based on the approach through which they choose to deliver the apps. We can also look at CloudFoundry vs GAE as open vs closed. Another possible category is PaaS frameworks (i.e. frameworks that provide middleware to build your own PaaS), vs PaaS as a self-service solution.

RightScale, on the other hand, uses the term Cloud Application Management to define a similar category and looks at PaaS as a private use-case for using the Cloud Application Management framework. We also had internal debate on that subject at GigaSpaces and couldn't come to a final agreement on where to draw the line between the different categories.

What do you think? Is OpsWorks a new kind of (Composable) PaaS or Cloud Application Management Platform?

Does it really matter?

References:

• GigaSpaces Cloudify & VMware Cloud Foundry the new PaaS Jailbreaker
• Is your PaaS composable or contextual? (Hint: the answer matters)
• Mapping the Cloud/PaaS Stack
• The blurring line between PaaS and IaaS
• Expanding the Cloud - Introducing AWS OpsWorks, a Powerful Application Management Solution
• Amazon adds OpsWorks application life cycle management to AWS cloud