Nati Shalom's Blog

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.

Real-Time Big Data with Storm, Cassandra, and XAP

Real-time Big Data is becoming more and more common in Big Data systems.

One of the most common frameworks used for running real-time Big Data system is Twitter Storm backed by a NoSQL database, as shown in the diagram below:

 

In this architecture, Storm is used for processing data as it comes in and the NoSQL data store is used as the output for that processing as well as for reference data storage.

Challenges

This architecture presents a couple of challenges:

• Performance - Storm runs in-memory, and is therefore set to process large volumes of data at in-memory speed. However, a typical storm architecture needs to interface with a data source for its input and a data source for its output. In this context, the overall performance is now determined not by Storm itself but by the data input and output sources. Quite often these interfaces rely on file-based message queues for streaming, and NoSQL for data storage. These interfaces are at least an order of magnitude slower than Storm itself, and therefore become the limiting factor.
• Complexity - Storm itself consists of several moving parts, such as a coordinator  (ZooKeeper), state manager (Nimbus), and processing nodes (Supervisor). The NoSQL data store also comes with its own cluster management. In addition, a typical Big Data system comes with more components such as the application front end, a reporting database, and more. This makes the process of managing the deployment, configuration, fail-over and scaling of such a system quite complex.

Meeting the Performance Challenge

Given that Storm itself runs in memory, it only makes sense that in order for Storm to run at maximum capacity the streaming and data store interfaces should be implemented in-memory as well, as shown below:

As you can see in the above architecture, we added two interfaces that rely on a built-in Storm plug-in - one for the data inputs and the second for data output. In both cases, the underlying implementation is memory-based, and thus removing the impedance that the previous architecture included.

You can read the full details on how this integration works, including a code example, in DeWayne Filppi's post on integration of in-memory computing with Cassandra.

The second optimization that can be added is to the NoSQL data store.

As most analytics applications tend to be read-mostly, we can speed up access to the NoSQL data store using an in-memory local cache. This architecture speeds up read performance between 10 to 1000 times as outlined by Shay Hassidim in his post on real-time Big Data performance.

Meeting the Complexity Challenge

To meet the complexity challenge, we will use a DevOps automation approach using Cloudify in conjunction with Chef or Puppet.

With this approach, we wrap every service with a deployment recipe that abstracts the underlying details on how to manage Storm, Cassandra, and our in-memory data store. Cloudify uses these recipes to automate the deployment of the entire stack. In this way, you only need to interact with Cloudify for the deployment, configuration, and also scaling and fail-over of your stack rather than separately manage each individual component. In addition, we use Cloudify to abstract the underlying infrastructure. This enables us to use the same deployment recipe across different environments. One for testing, another for production, etc. We can also use the same approach to deploy our apps based on the type of workload. We can use a public cloud for running sporadic workload, and thus leverage the elasticity of the cloud and also enable us to create and scale the environment as well as rip it off completely when done. At the same time, we can choose bare-metal machines for I/O intensive workloads, and so on.

You can read more on how you can set Storm using Cloudify on DeWayne's post on Storm and the cloud.

Cloudify comes with a rich set of built-in recipes for other Big Data services as well, making the integration process an out of the box experience. The main ones are listed below:

Final Notes - Optimizing without Code Change

Many real-time Big Data systems are now based on Twitter Storm and a NoSQL data store such as Cassandra.

In this post I tried to outline how we can optimize this architecture by addressing two areas: performance, and management.

The good news is that all this is possible to achieve seamlessly, without any code change. Let me explain:

In the case of Storm we used built-in plug-ins - Spout for streaming and Trident as the data store interface. In this way we can simply plug our memory-based plug-ins under these two integration points. All our existing Storm business logic would work pretty much the same.

We use the same plug-in approach to integrate our in-memory data store with our NoSQL data. This integration makes the data flow between our real time streaming to our NoSQL storage fairly transparently. In addition, it allows us to plug in different NoSQL data stores such as MongoDB, CouchBase, etc., giving us another degree of flexibility.

The same applies to our management layer. Existing Storm and NoSQL deployments are wrapped into plugged in recipes, and don't require any specific code changes.

Not Mutually Exclusive

We don't have to implement all of the optimizations to gain the benefit of this architecture. Each of the optimization points can be plugged in  independently of the others. For  example, if your main pain point is complexity, you can start by only by adding the DevOps automation first. At the same time if your main pain point is performance, you can use the memory-based plug-ins to speed up processing.

The other advantage of the combined architecture that I haven't discussed in this post is that it provides more flexibility in the degrees of consistency and availability in which you set your system, as I outlined in one of my recent posts on the subject In Memory Computing (Data Grid) for Big Data.

References:

• Big Data Real-Time Performance
• GigaSpaces and Storm Part 2: XAP Integration
• GigaSpaces And Storm Part 1: Storm Clouds
• In Memory Computing (Data Grid) for Big Data
• Check out how GigaSpaces XAP and Cassandra integration works

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
  

 

 

 

 

 

 

 

Carrier Grade Cloud/PaaS

Cloud is becoming the next-generation backbone for running the web.

As the technology for building and running cloud infrastructure matures, it is starting to spread out into more industries and revolutionizing how even the most conservative organizations are running their entire operations.

One of the areas undergoing a transformation is the carrier backbone services. For those who are not familiar, carrier backbone services includes services like cell and network services (DHCP, DNS, …), content serving (SMS, MMS, …), activation services, CRM, call centers, etc. Moving these critical carrier services from the existing environment tends to be labor intensive and proprietary. Selecting to move applications into a more open and virtualized environment such as cloud could yield a significant cost saving. An open cloud environment also enables Carrier organizations to reduce their time to market for delivering new services.

At time where the Telco/Carrier market is increasingly competitive, moving to a cloud-based carrier backbone can be more than a cost saving initiative. It can be a differentiator from the competition and is critical for survivability and success of the business.

That said, running carrier grade services requires special care to meet the required SLAs in terms of  latency, deterministic behavior, performance, location awareness, etc. These challenges are unique enough not to fit into your mom-and-pop cloud.

The purpose of the Carrier Grade Cloud and Carrier Grade PaaS is to address these gaps and challenges.

In this post I'll try to provide a more detailed overview on what Carrier Grade Cloud and PaaS actually means. I will use examples based on GigaSpaces’ joint work with Alcatel. Alcatel-Lucent recently launched a new product in this space named CloudBand which is using Cloudify for its Carrier PaaS layer.

What does Carrier Grade mean?
Learning from the Weather Chanel experience during the Sandy super-storm

The Weather Channel’s experience during Sandy is an excellent example of the need for carrier grade services. Below is a list of some of the key statistics during Hurricane Sandy:

• 1000% - The Weather Company’s traffic increase during Hurricane Sandy
• 110 GB- The amount of data, served every second during Sandy
• 170,000 - Peak number of simultaneous streams of video served during Sandy
• 1 - The amount of data centers that went bust during the storm

To address this demand during the storm, the Weather Chanel was running from 13 Data Centers managed by Verizon across North America, all with load balancing between them. During the storm Verizon increased their bandwidth capacity to meet the peak demand.

This sort of increased traffic behavior wasn't unique to the weather channel, as noted below:

So what can be learned from this process? What makes a service Carrier Grade?

Learning from the Weather Channel experience we can define a Carrier Grade service as a service with the following attributes:

• Critical to the business function
• Designed for massive scale
• Designed to deal with major usage spikes
• Location sensitive
• Designed to provide deterministic response during extreme condition

This is obviously a fairly simplistic definition, but for the sake of this discussion I think it will suffice.

What Makes a Cloud/PaaS Carrier Grade?

There are various attributes that makes a Cloud/PaaS carrier grade, as I noted earlier. The two most important attributes IMO are the network and multi-site deployments. Let me explain why:

The Network

One of the main elements that is extremely important in in a Carrier Grade environment is the ability to assert control over the network.

That include the control over:

• Isolation
• Bandwidth
• Latency

Cross-Cloud/Data Center Deployments:

Another critical element of a successful Carrier environment is the multi-site deployment. As seen with the Weather Channel’s use of 13 sites, multi-site deployment is important to address continues availability and scaling. Optimizing the latency by surveying the content closer to the location of the end user also helps to deal with challenges of data delivery.

So how are things done today?

The current Carrier backbone runs on physical appliances which basically maps to lots of irons. In this environment scaling capacity means buying more appliances. While this model works, it has two main drawbacks:

1. cost (infrastructure/operation)
2. lack of agility (i.e. it takes months and sometimes years to launch new service in this environment).

Alcatel CloudBand -- Carrier Grade IaaS/PaaS

Alcatel CloudBand is a new platform  that let Telco apps easily leverage the carrier cloud services.

It is comprised of a few main elements.

Multi node/site IaaS -- a multi-site/Cloud infrastructure. The CloudBand infrastructure is essentially a policy based management on large numbers of cloud nodes. Each cloud node can run either an OpenStack or CloudStack-based infrastructure. These nodes can live in many disparate data centers. Alcatel CloudBand glues all of the disparate nodes together into a single big cloud that is accessible through an OpenStack API.

CPaaS -- Stands for Carrier Grade PaaS, which is essentially the framework enabling the on-boarding of the carrier services into the CloudBand infrastructure via a simple click and run user interface. Cloudify is integrated into this as an integral part of the CloudBand offering.

CloudBand's Unique Approach: Putting Network and Application Together

One of the unique aspects of the CloudBand architecture is its holistic approach to Network and Application. Standard cloud infrastructures tend to look at the two pieces as separate black boxes that run one on top of the other.

What does this new approach to Network and Applications really means?

Two example scenarios that I often use to describe the value of putting network and application together is in the areas of Disaster Recovery and Cloud Bursting. In today’s cloud, DR involves lots of wiring in which i need to explicitly point a segment of the application into a particular cloud zone and the other to another zone. Beyond the complexity of setting these zones up, it also means that there is a good degree of manual intervention required to handle a recovery or a scaling process in this environment.

Taking an automated SLA-driven approach to IaaS

Instead of identifying explicitly the zones in our cloud, with automated SLA we can simply ask the cloud to figure out the right zone for the job based on our application SLA. For example, a user could simply say something like "deploy RingTone service" where continuous availability=true redundancy=3 and distance between sites=100km". Most of that information is known to the CloudBand management at the time of deployment and it can therefore allocate machine instances not solely on image ID and zone ID, but also based on those SLA requirements.

Integrating the PaaS with the network

Many of the current PaaS solutions were designed to work with a simple cloud infrastructure.

If we design our PaaS solutions to work on top of a more intelligent infrastructure, like CloudBand, that can accept SLA-driven calls to coordinate infrastructure management, a revolution will happen. We can start looking at  offloading some of the responsibility for allocating the right machine instance to a particular application tier to the infrastructure. The infrastructure could be made aware that we're deploying a data service and would therefore ensure that the nodes of that database don't reside on the same physical machine or even the same data center. Another area where the responsibility could be delegated to the infrastructure is the network isolation. Instead of dealing with security groups, the system can attach a particular network for a given application or a tier within that application and the infrastructure will make sure that any machine that is allocated for this service would be attached to this network.

Final Words

For years there has been discussion on the missing piece in the cloud puzzle - the network. Today we're at a point where this gap is starting to be filled up by projects like Quantum in OpenStack. In addition to OpenStack the Telco industry is also launching a new initiative titled NFV which stand for Network Function Virtualization. NFV was born in October of 2012 when AT&T, BT, China Mobile, Deutsche Telekom and many other Telcos introduced the NFV Call to Action document. It basically aims to combine new network API with virtualization and thus provide a standard model for a virtulized Carrier Cloud.

While it seems that the industry is moving in the right direction toward the Virtualization of the backbone systems, most of the effort seem to be focused on standardisation at the lower level of stack. Very little has been done to draw the real end game i.e. how would an end to end Carrier backbone would look like given that new virtualized infrastructure in place. More importantly we haven't yet began to think of what would be the implication of that infrastructure change on the application and services ontop of it.

This is what excites me in the CloudBand project. CloudBand doesn't just end up with yet another fancy infrastructure piece that we don't necessarily know how and what do with it. It actually takes the holistic approach and maps those fancy features into a real end to end solution which at the most basic level maps to the fact that setting up data and network clusters, disaster recovery or cloud bursting scenarios can now be fully automated in a much simpler fashion than in most of the current cloud infrastructure environment.

At a more strategic level that means that Carrier can now rely on the the cloud as an infrastructure that could manage their backbone services and thus leverage the cloud economics to meet their cost and business challenges.

References

• Carrier Grade PaaS presentation by Uri Cohen
• Network Function Virtualization or NFV Explained
• Alcatel & Gigaspaces Joint partnership
• GigaSpaces Cloudify
• Alcatel Carrier Cloud

A Groovy Kind of Java

Today's application stack is a much more complex environment than the traditional JEE one. Moving from a Spring/JEE background to the cloud can be a complicated transition.

In talk given at the San Francisco Java Meetup Group i tried to outline how Groovy can help you map and translate an old JEE evironment to a new cloud-based one using  Cloudify in a way that anyone can adapt to their own needs. You can find the slides from the talk here.

Living with cloud outages as a way of life...and being ok with it

Learning from the experience of others has always been a great source for many of the posts in this blog.

I happened to have had a meeting with Ron Zavner, Applications Architect at GigaSpaces when he reviewed his planned presentation for the AWS Meetup this week in London.

I thought that the information that Ron gathered for this purpose could be extremely beneficial for everyone who is either running, or plans to run their application in the cloud.

In this post I tried to capture in words, the content of Ron’s presentation on the lessons from recent cloud outages.

Recap - History of Cloud Outages

• 21 April 2011 - Some parts of Amazon Web Services suffered a major outage. A portion of volumes utilizing the Elastic Block Store (EBS) service became "stuck" and were unable to fulfill read/write requests. It took at least two days for service to be fully restored. Reddit, one of the better-known sites to go down due to the error, said it has 700 EBS volumes with Amazon. Sites like Quora and Reddit were able to come back online in "read-only" mode, but users couldn't post new content for many hours.
• 29 June 2012 - Several websites that rely on Amazon Web Services were taken offline due to a severe storm of historic proportions in the Northern Virginia area where Amazon's largest data center is located.
• 22 October 2012 - A major outage occurred, affecting many sites, again  such as Reddit, Foursquare, Pinterest, and others. The cause was a latent bug in an operational data collection agent.
• Christmas Eve 2012 - Amazon AWS again suffered an outage, causing websites such as Netflix instant video to be unavailable for some customers, particularly in the Northeastern US. Amazon later issued a statement detailing the issues with the Elastic Load Balancing service that led up to the outage.

Cloud outages are not the sole property of Amazon – they’re everywhere

While most of the more notable failure events happened to be related to Amazon AWS, failures tend be in direct proportion to the usage of the infrastructure, and right now Amazon is probably running the biggest workloads on their cloud, and is growing pretty fast. With these statistics, it’s very likely that their failure would be more notable than others simply because they simply have a wider impact.

As we have experienced, failure has dropped a visit to other cloud infrastructure providers as well.

Microsoft Azure outage

• 28 December 2012 -  some owners of Microsoft's XBox 360 gaming console were unable to access some of their cloud-based storage files.
• 26 July 2012 - Service for Microsoft’s Windows Azure Europe region went down for more than two hours
• 29 February 2012 - The ultimate result was service impacts of 8-10 hours for users of Azure data centers in Dublin, Ireland, Chicago, and San Antonio.

Main take way

Looking at all of these failures, it becomes apparent that they don't quite follow a common pattern.

Failure tends to happens when and where you least expect it.

Rather than relying on the infrastructure to prevent such failure from happening, we need to learn how to cope with them as a way of living.

What does 99% availability mean anyway?

Quite often when we talk about availability, we’re referring to % of uptime.

In this context, for most people 99% uptime sounds good enough. Is it?

Let's examine what that means in days:

• 99% - 3.65 days downtime
• 99.9% - 8.76 hours downtime
• 99.99% - 53 minutes downtime
• 99.999% - 5.26 minutes downtime

99% downtime means that we need to be ready to tolerate almost 4 days of downtime, and no one can ensure how those 4 days will be spread across the year.

The impact of cloud outages

Although AWS went offline for a few hours only, the downtime experience did have an impact on customers’ businesses. There is no known data for the number of people affected by a cloud computing service outage. It is estimated that the travel service provider Amadeus loses $89,000 per hour during any cloud computing outage, while Paypal loses around $225,000 per hour.

How to survive cloud outages - (Lessons from RightScale & Netflix)

A good source for learning how to survive cloud outages is Netflix and RightScale who have had a good track record for surviving many of the previously mentioned cloud outages.

Below is a summary of the main takeaways.

• Make sure to have a dedicated expert to manage your disaster recovery (DR) architecture, processes and testing.
• Define what your target recovery time and recovery point is.
• Be pessimistic and design for failures – (assume everything will fail and design a solution that is capable of handling it).
• Avoid single points of failures – all parts of your app should be highly available (different AZ / regions / cloud) – load balancers, app servers, web servers, message bus, database.
• Use monitoring and alerts for failover processes and for every change in state.
• Document your DR operational processes and automations.
• Try to “break” different parts in your application. From unplugging the network, to turning off machines…then try it again.

Netflix didn't just provided its share of advice but has started to open source many of the tools it uses internally. The first one of them is  ”Chaos Monkey.”  This tool was designed to purposely cause failure in order to increase the resiliency of an application in Amazon Web Services (AWS.)

Designing your application to survive failure – It’s all about redundancy

Netflix provides an excellent toolset for surviving outages on Amazon on the operational level.

In this section, I wanted to zoom-in more on the design implications on our application.

The core principle for surviving failure is actually fairly simple, and in fact, applies to any system - not just cloud -  whether they happen to be airplanes, missiles, cars. At the end of the day, it’s all about redundancy. The degree of tolerance is often determined by how many alternate systems or parts of the system we have in our design, and how separate they are from one another. The degree of tolerance is also determined by how fast we can detect the broken part in our system and make the switch.

In software terms, the common parts that comprise our system are built out of two main groups - the business logic and the data.

Making a redundant software application that can survive failure is often based on setting up clones for two of those  parts of our system.

Cloning your data

There are two models for creating redundant data systems.

     1. Use database replication

     2. Use generic replication as in the case of CDN

For database replication - each database tends to have a different replication scheme.  Amazon RDS is based on a read replica that can take over when the master node fails. More modern databases, such as Cassandra and MongoDB, tend to have more flexibility and control for setting up the database replication. So the first choice that you need to make for setting up your data redundancy, is choosing the right database.

Quite often, using database replication tends to be good enough within a certain geography but can be too fragile for geo-redundancy. A model that has proven itself for replicating data across WAN is CDN.

What’s more, CDN is not tied to a specific data source, and therefore can use a generic service for replicating data from multiple sources that doesn't necessarily reside within a certain database.

Having said that, CDN is fit mostly to read data and doesn't ensure the consistency of the data. For that purpose, we need to use a generic replication service that could plug into any data source and replicate it to other locations in a way that will allow us to control the replication route, the latency, and consistency.

Cloning your application

To clone our application business logic, we need to be able to ensure that all parts of our system run the exact same version of all of our software components. That includes not just the binaries, but also the configuration, the scripts that run our application, and more importantly that all our post-deployment procedures such as failover, scaling and monitoring are also kept consistent.

Quite often the things that makes the cloning of our business logic complex, are due to the fact that the information on how to run our application is often scattered across many different sources such as scripts, as well as the mind of the people that runs these apps.

To make the job of cloning our application much simpler, and thus more consistent we need to be able to capture all parts of the information for running our apps in the same place.

Configuration management tools such as Chef, Puppet and in the case of Amazon CloudFormation can help in this regard.

Making it simpler through Cloudify

To make the work of setting all this up simpler, we tried to bake all those patterns into ready-made tools scripted into out of the box recipes.

Cloudify recipes include:

• Database cluster recipes with support for MySQL, MongoDB, Cassandra, Postgress...
• Integration with Chef and Puppet
• Automation of failover, scaling and continuous maintenance of our application.
• Application recipes that allow you to capture all the aspect of running your application, including the post-deployment aspects such as failover, scaling and monitoring.

This is a good example for setting a redundant web application between sites using Cloudify.

Final words

Cloud brings lots of promise for making our business more agile.

Cloud has also become a huge shared infrastructure in which every failure has a much more significant impact on our business worldwide.

The experience in the past year has taught us that even a robust cloud infrastructure such as Amazon can fail.

Through this experience we've learned that rather than relying on the infrastructure for preventing failure we need to design our system to cope with failure and get used to failure as away of life.

Having said that, the investment required to build a robust application can be fairly large and not something that everyone can afford.

Using tools like Cloudify, Chef, Puppet and if you’re a pure Amazon shop Netflix  could help to greatly reduce this effort by pre-baking a lot of these patterns into recipes.

 

References

• Cloudifying High Availability
• AWS Outage - Moving from Multi-Availability-Zone to Multi-Cloud
• Lessons From The Heroku Amazon Outage

 

 

Follow Nati on Twitter!

DevOps Con Israel - Behind the Scenes

I'm happy to announce the first DevOps conference in Israel that will take place on the 28th of January.

In this post I wanted to share with you a bit of the stories behind the scene on how it all started.

How it all started - The story behind the scenes

For those who are not familiar with the topic of DevOps, it can basically be categorized as a movement more than a technology per se.

As with any movement, it comes with a disruptive message that aims to change many of the existing dogmas for how to run Development and IT, in order to improve agility and shorten time to market for launching new features and products. Cloud is not directly related to DevOps, but was a major accelerator, since with Cloud we’re no longer dependent on our IT to do the basic stuff such as setting up machines and networks. Which presented the opportunity to think about doing things differently, and finally break the wall between Development and Operations.

Netflix has been one of the main advocates behind this philosophy, and has served as a great inspiration for many of us who felt that the current setup between devs and ops just isn’t working, but didn't necessarily know how to deal with this. (A good reference on Netflix can be found in Adrian Cockcroft's post - NoOps)

We got involved in DevOps through our work with the Cloudify project which was highly inspired by that same Netflix experience. Through this work we took part in many DevOps related meetups and came to learn and appreciate the people behind the movement both here in Israel and abroad. There was something common that we could all identify with at all of those DevOps meetups - everyone that got involved felt very passionate about it. While this was the case, we still felt that most of the industry events just don’t cover the topic well enough, and we throughout that the community, would be better served if we’d set up a conference that would be dedicated solely to DevOps.

The Team Behind the Vision

Uri Cohen -  Uri was the first to come with the idea for setting up a DevOps event in Israel and was and still is, the leading force behind it.

Ran Tavory - Not sure that I have enough words to express how much has Ran contributed to the event. I'm sure that everyone that knows Ran, and how completely he dedicates himself to a cause he believes in,  would know what I mean. I simply can't imagine a DevOps event without Ran.

Sharone Revah Zitzman - Sharone took on the challenge of setting up the event, and has been extremely passionate about it. Everything that you see starting from the website,  through the t-shirts are her making.

Avner Algom and IGTCloud who helped us deal with many of the logistics such as setting the venues and getting the word out.

I also had the honor to be a part of this great team as Uri's and Sharone right arm.

Challenges

Skepticism:

As this was the first DevOps event in Israel we didn't really know how big the community actually is in Israel. During all the initial phases we had lots of doubts even amongst ourselves on whether we can justify a full day event dedicated only to this topic. That has been probably the biggest challenge we faced in setting this all up.

It's all about the content: 

We knew early on that if we really want to get the DevOps community involved we must and cannot compromise on the content, and that we needed to get the best presenters on the topics. With Ran’s help we got a quick list of the top speakers in Israel. To give the event more of a global perspective it was also important for us to bring internationally renowned speakers. This is an area where we faced lots of difficulties, and still thinks that we have lots of lessons to learn in this regard, for the next event. It was only until I met Ben Kepes during HP Discover event in Frankfurt that I felt that we found the right speaker in this category. Luckily enough, Ben has some Jewish and Israeli roots, so convincing him to come wasn't as difficult as I thought.

Free or paid?

We were also debating whether the event should be kept free or paid - a paid event would have helped us to funds lots of the costs involved in bringing speakers, setting up venues, lunch and more, and would have contributed immensely to doing so without the pressure on the content that you often comes with sponsorship. On the other hand, we knew that many of the people involved in DevOps are individuals who wouldn't be able to come if this would have been a paid event. This led us to keep the event free for everyone but we knew that we’d have to maintain a tight budget in order not to be  too dependent on sponsorships. This is where the IGT has been very helpful with getting Microsoft onboard. Microsoft, and specifically Noga Tal, were extremely generous and offered their venue, as well as covering all of the food & refreshment costs for the event. In this way, we were able to move most of the budgetary pressure out of the way and focus on the content. This helped us focus first on setting up the right content for the event, and only once the majority of this bulk was completed, we brought the other sponsors onboard. We also kept a tight editorial review led by Uri an Ran who made sure that the content was aligned with the purpose and vision.

 

Looking Good!

Luckily today we face quite the opposite challenge than when we started.

Our challenge today is not whether or not there would be enough people interested in DevOps went but whether we will actually have enough space for everyone, and the waiting list keeps growing.

 

How can you help?

We only just set up the platform, and it is now up to you to take advantage of it by participating, speaking and spreading the word.

 

Special thanks

There are few other who deserve special thanks for their help in setting up the event.

JFrog, Baruch and Shlomi - who shared their experience and lessons in setting similar events, and for being active participants in both speaking and sponsoring the event.

Ben Kepes who is making his way all the way from New Zealand to Israel to share his international perspective with our local crowd.

Microsoft – Who have been extremely supportive in offering the venue and large bulk of the sponsorship.

Speakers - A big thanks to all the speakers who agreed to present and take part in the event - without you there would be no event!

Sponsors – And of course a big thanks to all the sponsors, without you none of this would have been made possible: Battery Ventures, GigaSpaces Technologies,  IGTCloud, Lightspeed Venture Partners, Wix (check out their job openings here), Wonga.com, and last but not least, Yahoo!.

OpenStack Israel II

I'm very excited to announce our second OpenStack Israel event which will take place on Tuesday this week, November 27th.

At this event you'll be able learn about the latest developments in OpenStack from Jonathan Bryce Executive Director at the OpenStack Foundation.

 

One of the other highlights of the event is a local success story by Koby Holzer System & Storage Engineer Group Leader at LivePerson who will talk about their experience with running OpenStack in production across multiple data centers. We will also have several talks focused on one of the hottest areas in OpenStack development - Network/ Quantum and SDM delivered by Yaron Haviv from Mellanox. Vachnis Avi from Alcatel will present their choice of OpenStack APIs as the de-facto standard for Cloud APIs. 

Those who are also looking to get their hands dirty will have the chance to learn how to setup a simple OpenStack environment on your desktop from Ori Tzoran, DevOps Senior Engineer @ "Tikal Knowledge".

You can see the full agenda at the event page.

As with previous times, we’ve reserved slots for lightning talks -  so, if you have an interesting story you'll have the chance to share it during the event.

I look forward to seeing you all at the event.

Please make sure to RSVP to secure your place at the event as the seats are limited.

Moving Enterprise Workloads to the Cloud on a Massive Scale

Cloud has quickly become a disruptive technology, with the main disruption being a revolution in the way in which organizations run their IT.

The poster child for these cloud discussions was often the new Web 2.0 companies such as Google and Amazon who have been true pioneers in this new and emerging world. Quite often enterprises were used as the reference for how bad IT can get, and quickly became the representation of the antithesis for IT in these cloud discussions and conferences.

Two weeks ago I was at the OpenStack conference and other meetups that took place around the same time. The thing that was pretty apparent is that the large majority of the audiences in each room were from the enterprise world. What’s more, a quick look at the OpenStack foundation shows that those leading one some of the most trendy technologies in the cloud space are run by Enterprise HW and Software companies such as HP, IBM, Dell, Red Hat, among others.

Could this mark the beginning of a new era for enterprise and the cloud?

- A series of recent surveys on the subject seems to indicate that this is indeed the case:

Research conducted by HP found that the majority of businesses in the EMEA region are planning to move their mission-critical apps to the cloud. Of the 940 respondents, 80 percent revealed plans to move mission-critical apps at some point over the next two to five years.

A more recent survey, by research firm MeriTalk and sponsored by VMware and EMC (NYSE:EMC), showed that one-third of respondents say they plan to move some mission-critical applications to the cloud in the next year. Within two years, the IT managers said they will move 26 percent of their mission-critical apps to the cloud, and in five years, they expect 44 percent of their mission-critical apps to run in the cloud.

This shouldn't come as a surprise as  most enterprises are using the cloud today but don't necessarily know they are doing so, and getting huge benefits from it (SalesForce.com, ServiceNow)

The Cloud needs Enterprises just as Enterprises need the Cloud?

As I was sharing this observation with a few of the folks during the conference, I heard an interesting comment by one HP Executive Thomas Ryan who made an interesting statement: "Linux wouldn't be where it is today if enterprises wouldn't have adopted it". Quite often we look at the cloud (OpenStack in particular) as the new Linux. If that's true, then it looks like we’re reaching the point where for cloud to remain a viable technology it needs enterprise adoption just as enterprises needs the benefits the cloud brings.

The Renaissance of Enterprises in the Cloud

So are we seeing the renaissance of enterprises in the cloud? It's a bit too early to say, but there are clear indicators that this is where the market is heading. There are a couple of reasons for this:

1. IT is becoming a new manufacturing pipeline for enterprises in the new information era

It's clear today, that in this data driven world, the ability of any business to survive is determined by how agile they can be, how quickly they can respond to change, and react accordingly. In this context, it becomes more apparent for many enterprises that their ability to reach this level of agility is dependent on how well they are running their IT. At the same it becomes clear that cloud is just a better way of running their IT, and in this context it’s pretty much a no brainer.

2. Cloud technology is maturing

Many of the technology gaps that prevented enterprises from adopting cloud technology such as security, complexity, and more, have been addressed or are in the process of being addressed. There are many options today including private cloud, hybrid cloud, with different degrees of SLAs and cost that make it easier to run enterprise workloads in the cloud.

3. Strong business incentive

Enterprise applications tend to be one of the more costly workloads today in terms of IT infrastructure and resources, due to both the size and the complexity involved with running these systems. Any savings with running these systems would yield a significant impact to an organization’s bottom line, as indicated in MeriTalk research:

Enterprises can save $16.6B, or 21% if they moved just three mission-critical apps to the cloud.

The Challenge - How to bring Hundreds of Enterprise Apps to the Cloud

All that, of course, is great, but the reality is that cloud economics only start making sense when there are true workloads that utilize the cloud infrastructure.

If the large majority of your apps fall outside of this category, then you’re not going to benefit much from the cloud. In fact, you’re probably going to lose money, rather than save money. 

The Current Approach

• Focus on building IaaS - Current cloud strategies of many enterprises has been centered on making the infrastructure cloud ready. This basically means ensuring that they are able to spawn machines more easily than they were before. A quick look at many initiatives of this nature shows that there is still only a small portion of enterprises whose applications run on such new systems.
• Build a new PaaS - PaaS has been taught as the answer to run apps on the cloud. The reality however, is that most of the existing PaaS solutions only cater to new apps and quite often the small, and “non” mission-critical share of our enterprise applications, which still leaves the majority of our enterprise workload outside of our cloud infrastructure.
• App Migration as a One Off Project - The other approach for migrating applications to the cloud has been to select a small group of applications, and then migrate these one by one to the cloud. Quite often the thought behind this approach has been that application migration is a one-off project. The reality is that applications are more of a living organism – things fail, are moved, or need to be added and removed over time. Therefore it’s not enough to move apps to the cloud using some sort of virtualization technique, it’s critical that the way they’re run and maintained will also fit the dynamic nature of the cloud.

Why is This not Going to Work?

Simple math shows that if you apply this model to the rest of your apps, it’s probably going to take years of effort to migrate all your apps to the cloud. The cost of doing so is going to be extremely high, not to mention the time to market issue which can be even an even greater risk in the end, as it will reflect on cost of operation, profit margins and even the ability to survive in this an extremely competitive market, if it is too long.

What's missing?

What we’re missing is a simple and systematic way to brings all these hundreds and thousands of apps to the cloud.

Moving Enterprise Workloads to the Cloud at a Massive Scale

Instead of thinking of cloud migration as a one-off thing, we need to think of cloud migration on a massive scale.

Thinking in such terms drives a fairly different approach.

I've listed the principles, that IMO, are the crux to such a strategy, below:

• No Code Change - Any change, even the slightest one, to our existing apps will slow down our migration efforts substantially. Furthermore, many of the apps are third-party apps, where we often times don't even have control over the application code, so changing the app is likely not an option. There are many things that we can benefit from by moving our apps to the cloud, such as automation, ease of change, and configuration. We can obviously benefit more if we change our apps to take better advantage of the cloud infrastructure, but the right order would be to do this after we’ve already migrated the app to the cloud in the first place. There, of course, will still be many cases where just automating the way we run our apps and make them available on-demand would be sufficient enough.
• Plug-in to the Current Way of Running Apps - The common way for running apps today is either through custom shell scripts in the simple case, or through configuration management tools such as Chef or Puppet in the more advanced case. If we want to migrate apps at a massive scale, we need to be able to plug-in to the most common environments, and make it possible to import them almost as is. In this way, we could leverage the knowledge and know-how that has already been invested into these systems and make the migration process vastly shorter.
• Use Shared Infrastructure Across the Stack Regardless of the Language - Using different frameworks for each element of our application stack based on the language and environment in not going to scale for obvious reasons, such as complexity, a large number of moving parts, inconsistency, among other reasons.
• Add Cloud Properties from the Outside - There are many cloud properties that we can apply to our existing apps without forcing any changes. For example, we can automate the scaling from small to bigger machines, we can also automate the configuration, and setup. We can significantly simplify the way we run the app by making it available on-demand. All these cloud properties can be plugged into almost any existing app without forcing a real change, as noted in the MySQL example.
• Use the Baby Steps Approach - One of the main inhibitors to migrating apps was the all or nothing approach. There are many risks involved in migrating apps that go well beyond the technology challenge. The easiest way to mitigate such risks is by taking them one at a time. For example, we can first make our apps cloud ready, in which case we will abstract the automation part from the target infrastructure. By doing so, the decision where to run our app becomes tactical and less strategic. We can choose to run our production in our private data center, and run only testing and demos on the cloud. In this way, we can also make the migration gradual and smoother.
• Incorporate Bare-Metal into our Cloud - One of the main challenges that I’ve seen for moving true enterprise workloads to the cloud wasn't necessarily related to the cloud, but to the virtualization overhead that is often used as the underlying infrastructure of many clouds. Today it is possible, to gain access to bare metal clouds  which make it possible to run almost any workload including I/O intensive ones without any performance overhead, as I noted in my post about the emergence of bare-metal clouds.

Final Notes

I often like to compare the revolution that we’re experiencing right now in the IT industry to a similar revolution that happened in the automotive industry few decades ago.

You probably know what I’m referring to. The automotive industry experienced a similar revolution when Henry Ford came up with his Model-T car. The change wasn't so much in the engine or other parts of the car, but rather in the scale and cost in which cars could now be produced. As I noted earlier, in many aspects cloud is the IT industry manufacturing assembly line.

As with cars, it doesn't make sense to run only 10% of our cars on the new manufacturing assembly line, and build the rest in the traditional way. So is the case with our IT. Now the question becomes how to make the move.

In this post I outlined what I believe should be the principles to migrate apps at a massive scale.The second post describes more specifically the Cloudify way of doing this.