Nati Shalom's Blog

OpenStack is Coming to Israel

I'm very excited to announce our first OpenStack Israel event on Wednesday the 30th of May in Petach Tikva in collaboration with the IGT Cloud and Rackspace. Since Avner Algom and myself started to work on the event a few months ago I was positively surprised to see the amount of local innovation and work that is already taking place here at Israel in this space. As I write this post, it looks like we’re getting close to 200 registrations, and all of this has been achieved for the most part by word of mouth, a clear indication of the growing interest here.

We’ve got a nice lineup of presenters covering different parts of the stack:

• Chmouel Boudjnah (Rackspace):  Compute, Storage 
• Arturo Suárez  (StackOps): How to Create an OpenStack Powered Service Provider in 30 Days
• Roy Amir, (Alcatel Lucent): OpenStack Quantum - Network as a Service
• Zohar Alon (Dom9): Overview the Security Controls Built into OpenStack
• Samuel Bercovici (Radware): Cloud Load Balancing and Application Delivery Control (ADC) Services in OpenStack
• Uri Cohen (GigaSpaces), Camuel Gilyadov (ZeroVM): PaaS and Big Data on Openstack
• Alex Glikson (IBM),  OpenStack-Based Cloud Hosting Infrastructure

Shlomo Swidler will be leading two panel discussions, during the first discussion we’ll review the shift toward Open Source in the cloud and the effect of that move on the cloud industry. In the second panel we’ll try to predict some future directions and trends we expect for OpenStack.

I would also like to take this opportunity and welcome our distinguished guests from Rackspace, IBM and StackOps:

• Mac Devine, Director and CTO, Portfolio and SO Offering Management, Global Technology Services, IBM Distinguished Engineer
• Chmouel Boudjnah Principal Engineer at Rackspace Hosting
• Arturo Suárez Co-founder of StackOps Technologies

During the event we reserved a slot for lightning talks -  If you have an interesting story you'll have the chance to share it during the event.

Anyway this event is going to be a kickoff for a series of meetups around OpenStack that is planned throughout the year. We'd appreciate any help in this regard, so if you have suggestion for a meetup this is your chance.

I would like to finish up with special thanks to Marc Coollier and Luaren Sell from Rackspace who's been very instrumental and supportive throughout this process. We wouldn't have been able to pull this off without their close help.

 

Making Cloud Bursting a Practical Reality

What is Cloud Bursting?

A good definition for cloud bursting can be found here:

Cloud bursting is an application deployment model in which an application runs on a private cloud or data center and bursts to a public cloud when the demand for computing capacity spikes. The advantage of such a hybrid cloud deployment is that an organization only pays for extra compute resources only when they are needed.

The Business Impact of Cloud Bursting

Neal Sample the former CTO - X.commerce at eBay gave an interesting talk last year on the economic benefit of Cloud Bursting. Neal pointed out eBay traffic statistics and showed some real numbers of the business impact of bursting peak load activities using on-demand cloud resources as presented in the diagram below.

The diagram shows real traffic statistics on eBay site (the brown lines).

The line at the top shows the associated costs for provisioning all the resources for peak loads. The blue lines show what the cost could be if they’d provision for the average load and use on-demand resources for the peak loads.

Based on this case study, cloud bursting can yield a 40% reduction in overall costs.

The challenges with cloud bursting

While the economic model of cloud bursting can be very compelling as Neal articulated in his eBay study, practically speaking, it remains an interesting theoretical model for the most part due to the technical challenges involved in implementing this model.

Let me explain...

To make cloud bursting a practical reality you need to address the following:

1. Network connectivity between the private and public site
2. Consistent environment setup
3. Data/Security model

What's changed?

The availability of new OpenStack public clouds from both HP Cloud Services and Rackspace makes it possible to create private and public clouds using the same underlying cloud infrastructure which supports the same API.

With this it makes a lot of sense to connect both ends of OpenStack clouds into one virtual cloud.

We can also see Amazon starting to partner with private Cloud solutions that are based on the Amazon API through their partnerships with Eucalyptus, as well as Citrix’s recent announcement with Cloud Stack.

That basically solves one of the more complex challenges of the lack of consistent data-center models between private and public clouds.

While this is a great start it still doesn't address all three challenges that I outlined above.

Making cloud bursting a practical reality

1. Network connectivity

To address the network connectivity issue, we can use one of these two approaches:

• Virtual Private Cloud - With this approach we create a VPN tunnel between the private and public network making the network look like one big IP network. A good reference on the various solutions in this category can be found here.
• Load balancing web traffic (with a federated deployment) - in this approach the private and public site remain isolated from each other from a network perspective. What we’d need to do is use a global load balancer to route traffic between the private and public sites so the only connectivity is at the global router.

 

        

2. Consistent environment

In order to burst our private cloud activities into an on-demand public site, we need to be able to fork the exact set of services and application setup that we have on our private cloud, and push it to the cloud. To this end, we need to use automation and configuration tools that work in pretty much the same way in both environments. Tools like Chef do a great job with automating the installation and configuration parts, this partnered with Cloudify recipes enables us to leverage Chef recipes for setting up the installation of the individual services and Cloudify for setting up a complete deployment of any application stack on demand on both private and public cloud.

3. Data/Security

So obviously, bursting processes is one thing, but bursting data is a completely different ball game. Bursting data is one of the hardest challenges with cloud bursting today. There are basically two options when dealing with data in a cloud bursting scenario:

1. The primary site approach - Use the private cloud as the primary data site, and then point all the burst activity to that site.
2. Federated site approach - This approach is similar to the way Content Distribution Networks (CDN) work today. With this approach we maintain a replica of the data available at each site and keep their replicas in sync.

The primary site approach is usually the simpler of the two, as it doesn't involve data movement.  That said, it may open latency and security challenges, as it works on the assumption that every public site needs to have complete network access to the data at the private site, and at a latency that is reasonable. There are still many cases where these assumptions don’t apply. For these cases, a federated deployment approach is the only option.

With the federated deployment approach, we need to keep the data replicated between the private and public site…but how do we do that?

1. First we need to create a separate private data cloud and public compute cloud.  When we’re dealing with vast amounts of information, we simply can't burst data with the load, since depending on the amount of data involved, this process alone can take hours. A more practical approach would be to create a separate private data cloud in which each data cloud is physically located close to the location of the public compute cloud data center. In this way, we can have better control over the network latency when we start to burst loads, just like a CDN, only in this case we apply it to transactional information and not just static files.

2. Then, we launch the data cloud on demand. Even though, in most cases it’s not practical to burst data with the load, it is still a requirement to be able to launch new data clouds without any downtime or impact on the existing data clouds. The challenge of doing that over transactional data is huge, as we not only need to replicate the data to the new site but do so while the data keeps on changing as the new site is launched.

Example: Bursting Workload & Data between AWS and Rackspace/OpenStack

The following example demonstrate a simple web application with Global load-balancer (Rackspace load balancer), and Web Application (Petclinic) based on Tomcat as the Web front end and MySQL as the database.

On both ends we used GigaSpaces XAP Transactional WAN replication as a replication channel between the two instances of MySQL and Cloudify to handle the workload migration between the sites.

You can read the full detailes including code references of this examaple on Dotan Hortvitz post Bursting into the Clouds – Experimenting with Cloud Bursting 

Final notes

Cloud bursting comes with compelling economic benefits that will enable us to get the best out of both the private and public cloud worlds. In reality, the challenges involved with creating a true cloud bursting environment has kept it in the realm of a theoretical model for the most part until now.

The availability of OpenStack (and to a lesser degree EC2) in both private and public environments can simplify the process of building cloud bursting environments, as now we can have the same underlying data center infrastructure for both environments. 

To run real transactional workloads over a cloud bursting environment, we need to address other challenges such as consistent configuration and setup of our application stack, and the hardest part is managing consistent data across sites.

Bare-Metal PaaS

The Rise of Bare-Metal Clouds

Cloud and Virtualization are not mandatory, and the number of cloud providers that supports bare-metal clouds is growing, as David Linthicum pointed out in his article Going native: The move to bare-metal cloud services

It's a fact that virtualization is not a requirement when creating cloud computing services, but it is helpful to those who manage the service. Indeed, Google is able to provide a multitenant cloud computing platform without virtualization; there are other examples as well.

Internap, SoftLayer, Rackspace, Liquid Web, and New Servers (also known as BareMetalCloud.com) also provide access to the bare metal. You can count on more providers to join the fray as cloud computing users continue to demand that their managed hosting environments work like their native environments.

Performance Matters

The main reason for the rise of bare-metal clouds is that virtualization often comes with a cost. There is a  large class of applications where the virtulization overhead is unacceptable, as Carl Brooks, a cloud analyst at Tier 1, a division of 451 Research, points out here:

By having dedicated servers that are not virtualized, and therefore do not have a hypervisor layer, users can experience an uptick in speed, Brooks says, in some cases as much as 10% depending on the application. This can be an attractive option for high-performance compute needs, advanced Web 2.0 developers, or applications that require a large amount of database resources. Basically any situation "where the performance matters the most" 

Come to think of it, the main thing that brought us to virtualization in the first place was the ability to create new servers on demand, as opposed to it taking days or weeks with dedicated servers. Now, with the avliability of bare-metal clouds, it is possible to get the same level of flexibility without the virtualization overhead, and with more control and flexibiltiy on the specific HW configuration and setup. This makes the choice of bare-metal clouds much more attractive than in the past. 

Bare-Metal PaaS

Now that bare-metal clouds have become more popular, it only makes sense to have bare-metal PaaS to support them. Bare-metal PaaS provides the abilty to manage an elastic application workload without relaying on virtualization, providing the option to support high-performance workloads with the simplicity of PaaS.

This is particularly interesting for Big Data and any data intensive application that is heavy on I/O. Quite often, running these types of applications on top of virtualization isn't even considered a viable option. With bare-metal PaaS we can easily serve I/O intensive workload without compromising on performance or latency.

A Bare-Metal PaaS Example with Cloudify

Cloudify is an open PaaS stack. With Cloudify, we look at cloud infrastructure as just a bunch of compute resources with an operating system, IP address, SSH port. We use a generic Cloud-Driver that enables us to abstract the way those machines can be allocated and created on each different clouds infrastructure. In that context we treat a virtual machine as just generic container of an operating system. Cloudify manages applications at the process level. This means it manages the application workload by provisioning the application processes across machines.

With that, it only made sense to look at bare-metal clouds as any other virtualized cloud. So we ended up writing a bare-metal cloud driver, which is referred to as the Bring Your Own Node (BYON) cloud driver.

A BYON cloud is set simply by specifying a list or range of IP addresses as our cloud pool. Cloudify then uses this pool to provision the application and its services. Below is a simple example that shows what this configuration looks like.

templates ([
	SMALL_LINUX : template{
	custom ([
		"nodesList" : ([
				([
				"id" : "vm1",
				"ip" : "10.10.10.1"
				]),
				([
				"id" : "vm2",
				"ip" : "10.10.10.2"
				]),
				([
				"id" : "vm3",
				"ip" : "10.10.10.3"
				])
			])
		])
	}
])

A list of more advanced configuration options is avliable here.

Keeping Available the Choice Between Bare-Metal and Virtualized Cloud 

In reality, there are cases where the use of virtualized cloud instances makes sense, and as already discussed here, there are also cases where using a bare-metal cloud would be the right option. Ideally it would be best to abstract the application from those choices in order to easily move between the two environments, or even combine them. For example, imagine the case of a typical web application. It is very likely that we would want to run our web traffic workload on virtualized instances and our database on bare-metal instances.

In the case of Cloudify -- keeping the details of the specific cloud target at the CloudDriver enables us to achieve just that. We can define our application as a recipe, which is kept unchanged between the cloud choices. The details of whether to use a bare-metal or virtualized cloud is left to the deployment stage where all that is needed is to point Cloudify to the target cloud driver, and that's it.

References

• Going native: The move to bare-metal cloud services
• New bare metal cloud offerings emerging
• How much overhead does x86/x64 virtualization have?
• Amazon EC2 versus Bare Metal and KVM? The inside story on what you thought you knew about EC2

 

Related articles

• Mapping the Cloud/PaaS Stack (natishalom.typepad.com)
• GigaSpaces Cloudify & VMware CloudFoundry the new PaaS Jailbreaker (natishalom.typepad.com)
• PaaS is the New Middleware (redmonk.com)
• Big Data In the Cloud Using Cloudify (natishalom.typepad.com)

Mapping the Cloud/PaaS Stack

Cloud is evolving at an incredible pace, changing almost every aspect of our industry. It’s only natural then, that with this change also comes a continuous evolution of how we classify and categorize the various components of the cloud stack.

In earlier days, it was enough to draw the lines between IaaS, PaaS, and SaaS, and while this categorization is still very handy, we are beginning to see the lines between these categories start to blur. On the one hand, we see more IaaS providers starting to move up the stack, and on the other hand, we are seeing new categories such as DevOps gaining popularity and bridging the gaps between the IaaS and the PaaS layers.

 

I was recently asked to draw a map of how I see the current cloud stack. This ended up being an interesting exercise. To make things simpler I decided to focus on the IaaS/PaaS piece, both because this is my area of expertise, and also because IMO this is where many interesting developments are taking place. I ended up with the diagram below, which I thought would be worth sharing in order to get feedback and different perspectives.

It’s important to note, that this diagram is not based on any scientific scoring of different products in the market. I'll leave that part to the analysts. The specific products I chose to use are only there to illustrate and support my analysis of the components in the stack and where they map to within each category.

What's Driving the Cloud Stack?

The two main (and often conflicting) driving forces behind the evolution of the cloud stack are Productivity and Control. As cloud started to emerge it was productivity that took center stage, often by giving up almost completely on the level of control. As the industry started to mature we started to see an evolution where we could have various degrees of tradeoffs between these two driving forces. A good indicator of this, is the rise of DevOps and Private Clouds. We could also see the new open source movement as yet another major step in that direction - the most notable one is OpenStack, and the recent Citrix announcement about the moving of Cloud Stack into the Apache Foundation.

We could also see similar movement happening on the PaaS layer, where VMware launched Cloud Foundry as both a self-service PaaS for development productivity, and as an open source project to provide users with more control. Cloudify takes similar yet more explicit moves in that direction by bringing DevOps and PaaS together, in addition to making it open source.

 

Mapping the PaaS Stack

Geva Perry wrote a good summary mapping the current Java PaaS players in his post Listing the Java PaaS Public and Private Clouds . Geva chose to classify the different players based on their private/public cloud position and language support (Java in this particular case). Obviously the correlation behind public/private cloud and productivity/control is fairly close, so I can see where he was coming from. While this makes a lot of sense, I believe that it’s not accurate enough as there are still solutions that work on both private and public clouds and are not limited to just Java - Cloudify included. So is there a better way to classify the PaaS providers?

Here is my suggestion:

I would classify the PaaS providers based on those who focus on delivering PaaS through a self-service portal I’ll refer to them as PaaS service providers, where they assume full control over the underlying infrastructure and own the entire operation of your application - this is where I would put GAE, Heroku etc. Next will be  those who gives you the tools to build your own PaaS on private or public clouds, I’ll refer to them as PaaS stack providers - this is where Cloudify and I believe, Cloud Foundry and Stackato also fit in.

The second sub-category of classification would be on the level of openness and control i.e. open source, language support, cloud environment support, DevOps support and such.

In any case, we can easily get into a complex matrix of features/mapping for even more fine-grained classification but this far beyond the scope of this post which is merely drawing a rough map rather than providing a complete competitive analysis.

How would you categorize the Cloud/PaaS Stack?

As I noted earlier, this is just my own personal view on the subject. I hope that this will spark an interesting debate in which we may either come out smarter, or possibly even more confused. :)