Nati Shalom's Blog

Making Hadoop Run Faster

One of the challenges in processing data is that the speed at which we can input data is quite often much faster than the speed at which we can process it. This problem becomes even more pronounced in the context of Big Data, where the volume of data keeps on growing, along with a corresponding need for more insights, and thus the need for more complex processing also increases.

Batch Processing to the Rescue

Hadoop was designed to deal with this challenge in the following ways:

1. Use a distributed file system: This enables us to spread the load and grow our system as needed.

2. Optimize for write speed: To enable fast writes the Hadoop architecture was designed so that writes are first logged, and then processed. This enables fairly fast write speeds.

3. Use batch processing (Map/Reduce) to balance the speed for the data feeds with the processing speed.

Batch Processing Challenges

The challenge with batch-processing is that it assumes that the feeds come in bursts. If our data feeds come in on a continuous basis, the entire assumption and architecture behind batch processing starts to break down.

If we increase the batch window, the result is higher latency between the time the data comes in until the time we actually get it into our reports and insights. Moreover, the number of hours is finite -- in many systems the batch window is done on a daily basis. Often, the assumption is that most of the processing can be done during off-peak hours. But as the volume gets bigger, the time it takes to process the data gets longer, until it reaches the limit of the hours in a day and then we face dealing with a continuously growing backlog. In addition, if we experience a failure during the processing we might not have enough time to re-process.

Speed Things Up Through Stream-Based Processing

The concept of stream-based processing is fairly simple. Instead of logging the data first and then processing it, we can process it as it comes in. 

A good analogy to explain the difference is a manufacturing pipeline. Think about a car manufacturing pipeline: Compare the process of first putting all the parts together and then assembling them piece by piece, versus a process in which you package each unit at the manufacturer and only send the pre-packaged parts to the assembly line. Which method is faster?

Data processing is just like any pipeline. Putting stream-based processing at the front is analogous to pre-packaging our parts before  they get to the assembly line, which is in our case is the Hadoop batch processing system.

As in manufacturing, even if we pre-package the parts at the manufacturer we still need an assembly line to put all the parts together. In the same way, stream-based processing is not meant to replace our Hadoop system, but rather to reduce the amount of work that the system needs to deal with, and to make the work that does go into the Hadoop process easier, and thus faster, to process.

In-memory stream processing can make a good stream processing system, as Curt Monash’s points out on his research traditional databases will eventually end up in RAM. An example of how this can work in the context of real-time analytics for Big Data is provided in this case study, where we demonstrate the processing of Twitter feeds using stream-based processing that then feeds a Big Data database for the serving providing the historical agregated view as described in the diagram below.

Faster Processing the Google Way: Using Stream-Based Processing Instead of Map/Reduce

Due to a lack of alternatives at the time, in many Big Data systems today Map/Reduce is used in areas where it wasn't a very good fit in the first place.  A good example is using Map/Reduce for maintaining a global search index. With Map/Reduce, we basically rebuild the index, where it would actually make more sense to update it with changes as they come in.

Google moved large part of its index processing from Map/Reduce into a more real-time processing model, as noted in this recent post:

So, how does Google manage to make its search results increasingly real-time? By displacing GMR in favor of an incremental processing engine called Percolator. By dealing only with new, modified, or deleted documents and using secondary indices to efficiently catalog and query the resulting output, Google was able to dramatically decrease the time to value. As the authors of the Percolator paper write, ”[C]onverting the indexing system to an incremental system … reduced the average document processing latency by a factor of 100.” This means that new content on the Web could be indexed 100 times faster than possible using the MapReduce system!

..Some datasets simply never stop growing ..it is why trigger-based processing is now available in HBase, and it is a primary reason that Twitter Storm is gaining momentum for real-time processing of stream data.

Final Notes

We can make our Hadoop system run faster by pre-processing some of the work before it gets into our Hadoop system. We can also move the types of workload for which batch processing isn't a good fit out of the Hadoop Map/Reduce system and use Stream Processing, as Google did.

Interestingly enough, I recently found out that Twitter Storm came up with an option to integrate an in-memory data store into Storm through the Trident-State project. The combination of the two makes lots of sense and something were currently looking at right now so stay tuned.

 

References

• Build Your Own Twitter Like Real Time Analytics - A Step By Step Guide (Blog Post)
• Build Your Own Twitter Like Real Time Analytics - A Step By Step Guide (Online Tutorial)
• Real Time analytics for Big Data: Facebook's New Realtime Analytics System
• Beyond hadoop: fast queries from big data
• Traditional databases will eventually wind up in RAM
• Why the days are numbered for Hadoop as we know it

Related articles

Elephants and Eyeballs: Real-Time Big Data in the Real World

Cassandra on ACID

GigaOm: 'Hadoop's days are numbered...' Are they?

Hadoop Officially a Big Deal for Big Data

Woz is Worried About “Everything Going to the Cloud” — the Real Issue is Giving Up Control

 

In a recent article, Steve Wozniak, who co-founded Apple with the late Steve Jobs, predicted "horrible problems" in the coming years as cloud-based computing takes hold. 

 

"I really worry about everything going to the cloud,".. "I think it's going to be horrendous. I think there are going to be a lot of horrible problems in the  next five years. ...."...with the cloud, you don’t own anything. You already signed it away.”

 

When I first read the title I thought, Wozniak sounds like Larry Ellison two years ago, when he pitched the Cloud is hype, before he made a 180-degree turn to acknowledge Oracle wished to be a cloud vendor too. 

 

Reading it more carefully, I realized the title is instead just misleading. Wozniak actually touches on something that I hear more often, as the cloud hype cycle is moves from a Peak of Inflated Expectations into through the Trough of Disillusionment.

 

Wozniak echos an important lesson, that IMO, is major part of the reason many of the companies that moved to cloud have experienced lots of outages during the past months. I addressed several of these aspects in in a recent blog post: Lessons from the Heroku/Amazon Outage.

 

When we move our operations to the cloud, we often assume that we're out-sourcing our data center operation completely, including our disaster recovery procedures. The truth is that when we move to the cloud we're only outsourcing the infrastructure, not our operations, and the responsibility of how to use this infrastructure remain ours. 

 

Choosing better tradeoffs between producivity and control

 

For companies today, the main reason we chose to move to the cloud in the first place was to gain better agility and productivity. But in starting this cloud journey, we found that we had to give up some measure of control to achieve the agility and productivity.

 

The good news is that as the industry mature there are more choices that provides better tradeoffs between producivity and control:

• Open source cloud such as OpenStack and CloudStack 
• Private cloud offering 
• DevOps and automation tools such as Chef and Puppet
• OpenSource PaaS such as Cloudify, OpenShift and CloudFoundry
• DevOps and PaaS combined such Cloudify

As businesses look at cloud strategy today, there isn't a need to give up control over productivity. With technologies like Cloudify, businesses can get the best out of both worlds.

 

References

• Apple Co-Founder Steve Wozniak Distrusts the Cloud: Is He Right?
• Mapping the Cloud/PaaS Stack
• Why Larry Don't Get It
• Lessons from Zynga & Sony on moving from Amazon AWS
• Public vs Private clouds (Again!)- it's not about the cost

Putting DevOps and PaaS together with Cloudify

 

Putting DevOps and PaaS together with Cloudify

DevOps and PaaS represent two different paradigms for delivering applications to the cloud.

• DevOps - DevOps takes an automation approach - with DevOps we basically script the process of installation, configuration and deployment of the application stack. 
• PaaS - PaaS takes an abstraction approach by abstracting the details of the cloud infrastructure from the developers. 

DevOps tends to cater to operations guys that want to maintain the flexibility and control over the infrastructure and PaaS caters more to developers who just want to write code and deliver it without worrying too much about the details of the underlying infrastructure.

 

For a while DevOps and PaaS had been considered two competing paradigms as noted in Tom Mornini’s (Engine Yard) post DevOps is DOA:

"DevOps essentially requires everyone involved in the development, deployment, and management of software to change the way they work, to cross-train for multiple functions, and to collaborate with people they’ve all too often viewed as adversaries. It creates new processes and methodologies and, in many cases, uses new tools to get the job done. In addition, it often requires a small army of consultants to implement and manage the transition. That is why the “promise” and “potential” of DevOps has yet to be realized by more than a handful of real-world companies.

...The appeal of the DevOps model fades even further when you consider the fact that there is a better option! You can achieve the intended benefits of DevOps without any of the turmoil by taking advantage of Platform-as-a-Service offerings, or PaaS."

Putting DevOps and PaaS together

The truth is that it's hard to choose between the two paradigms. DevOps provides a high degree of control and flexibility but this flexibility comes at the cost of complexity and reduced productivity and often requires a culture change as Tom Mornini pointed out. PaaS on the other hand, provides an extremely simple deployment environment but it also forces you to fit into the PaaS environment, including the language of choice, middleware stack and cloud environment etc.

The best of both worlds- The control of DevOps and Productivity of PaaS

Do we really need to choose between the two? We can use DevOps as the foundation of the PaaS infrastructure. In this way, the operations guys can choose their stack of choice, package their specific blueprint, pick their cloud of choice and package all that as a pre-baked environment to the developers who in turn can be relieved of all of the details as they would be with any other PaaS. In this way we get the control of DevOps and productivity of PaaS.

At this point I'll refer to Cloudify as an implementation reference of that concept to illustrate my point in this regard.

Putting DevOps and PaaS together with Cloudify

Cloudify is an Open PaaS Stack that brings DevOps and PaaS together. Here is how:

The control of DevOps 

1. Application Blueprint - Cloudify allows you to add your own application blueprint into the platform through recipes. Recipes are at the heart of Cloudify architecture. A recipe in Cloudify is a Groovy-based DSL. The recipe is where you define your application stack, including the installation, configuration, monitoring, scaling and fail-over and tell Cloudify what, how and where to deploy your app.
2. Integration with DevOps tools such as Chef - Cloudify allows you to call Chef cookbooks from within a Cloudify recipe. This gives Cloudify users a way to leverage the wide variety of existing Chef cookbooks and community and decorate it with a Cloudify recipe if needed, to add scaling, fail-over automation etc.
3. Operational Task Automation - Custom Commands  allow you to attach common operation tasks such as update-app, such as in the case of a web app, run-snapshot in the case of a database and more, as part of a service recipe, as well as automate the post-deployment operational procedures of an application alongside its lifecycle.

The productivity of PaaS

Developers can run one of the existing recipes as they would with any other PaaS without going through any of the steps above. Unlike other Platforms-as-a-Service, they can also customize the existing recipes or pick custom recipes that cover their specific environment and application blueprint. All this without losing that same productivity. Developers can also get better visibility into the underlying infrastructure, and have a better experience when troubleshooting. They can also use Cloudify as an automation tool as part of their continuous deployment environment.

Final words

Adrian Cockcroft a highly regarded Cloud Architect at Netflix provides an excellent insight on how DevOps and PaaS work at Netflix in his post Ops, DevOps and PaaS (NoOps) at Netflix:

“We have a small number of DevOps engineers embedded in the development organization who are building and extending automation for our PaaS, and we have hundreds of developers using NoOps to get their code and datastores deployed in our PaaS.”

An interesting lesson from the Netflix experience is that an important part of running an online service is the ability to resolve any friction for developing and managing such a service. Moving a large part of the operational responsibility to the developers makes it even more important that the development platform (PaaS) come with operations tools that are pre-baked into the developer environment.  At the same time, that same environment needs to also cater to a dedicated (but a significantly smaller) operational team.  This makes the idea of putting DevOps and PaaS together even more critical to reach the business agility and operational efficiency. Netflix built their own PaaS environment to address such a need. Cloudify provides a similar solution for those who want to build their own Netflix environment but without the hassle involved with doing it themselves.

References

• PaaS, Does It Really Mean No-Ops?
• Ops, DevOps and PaaS (NoOps) at Netflix
• Mapping the Cloud/PaaS Stack
• GigaSpaces Cloudify & VMware Cloud Foundry the new PaaS Jailbreaker
• DevOps is DOA
• Productivity vs. Control tradeoffs in PaaS
• DevOps and PaaS - Friend or Foe?
• PaaS shouldn’t be built in Silos

 

What should Marissa Mayer do with Yahoo!

Last week the internet exploded as the news of the new appointment of Marissa Mayer as the new CEO of Yahoo sparked.

 

Most of the discussion was centered around the speculation of why Marissa left Google - clearly  the market leader in the search and advertising business compared with Yahoo! a company in deep trouble for a while, who seems to have lost its way and changed three previous CEOs in the past few years.

 

I was surprised though to see how little was said on what Marissa's plans are to save Yahoo! 

In this post, I wanted to try and explore this, as well as add my my own personal thoughts about what Marissa could do to regain a leading position in the market.

 

 

What Yahoo! shouldn't be doing

Until now, the strategy at Yahoo! has centered around advertising, which was based on its core search engine, homepage and email. 

Obviously, this strategy ought to come to its end, as both of these products are growing increasingly stale.

 

In addition to this, it would be almost impossible for Yahoo! to regain any kind of leadership position in that space as  Jason Del Rey and Michael Learmonth  argue in their article Predicting The Strange Future Relationship of Yahoo!, Google, and Facebook:

The economics of content aren't good enough, and Yahoo doesn't have the firepower to pony up, say, the $100 million YouTube is spending on original channels or the hundreds of millions more Netflix is spending to acquire rights to TV and movies.

Perhaps, a hint of Marissa future plans - build products instead of chasing search

Clearly Marissa didn't join Yahoo! to continue her predecesor's strategy i.e. focus on content. So the question is, what could be the next viable option that Marissa should pursue. A hint in that regard is given in the Jason Del and Michael Learmoth article:

Ms. Mayer represented what Yahoo could become, a company that builds products instead of chasing search -- as it did for nearly a decade -- and social, which is now sapping the company of its once-formidable engagement with users.

The real question is what could that mean?

The elephant in the room

Most people are not aware of the fact that the main company behind the Hadoop project is Yahoo!.

In fact, Yahoo! is probably the largest deployment of Hadoop, and still the major contributor to the project.

Yahoo runs Hadoop on 42,000 servers--that's 1,200 racks--in four data centers. Its largest Hadoop cluster is 4,000 nodes, but that will increase to 10,000 with the release of Apache Hadoop 2.0, expected...

Yahoo uses Hadoop for its own internal analysis of information captured from user interactions. It stores 140 petabytes in Hadoop. Since Hadoop keeps all data sets in triplicate, over 400 petabytes of storage are needed to sustain its systems.

Having said that, Yahoo! has done a fairly bad job on monetizing the project, and has let other companies such as Cloudera, Amazon, IBM, EMC to build services and solution around the project.

Now here's the real elephant in the room: During a recent interview with InformationWeek  Scott Burke, senior VP of advertising and data platforms provided a very interesting insight on some of the assets that Yahoo developed around Hadoop:

• Yahoo! can advise advertisers on the demographic that responds best to their campaigns so that they can adjust their ads as necessary to appeal to the widest audience. According to Burke, this can lead to improved results, sometimes even doubling expected response rates.
• Yahoo's data indicates not only who is viewing advertising, but also how much time they're spending on it, what their click-through rate is, and what they do on the Yahoo site after viewing an ad. This is all valuable feedback to advertisers, as it lets advertisers make decisions early in an ad campaign, and helps them plan their future advertising strategies.
• Yahoo has also developed a set of open source code called Cocktails, which gives advertisers the tools to extract information in Yahoo's Hadoop systems. Cocktails are written in JavaScript so they can run in browser windows; Manhattan is a server-side cocktail and Mojito is client-side. 

What Yahoo should become? - The Web Analytics Company

 Marissa already indicated its intent to move from the search business and into products but the real question is what that means.

This is where I wanted to add my own personal thoughts.

 

Yahoo! - The new Web Analytics company

IMO Yahoo should build on its strong Hadoop assets and become the leading Web Analytics Company.

 

What do I mean by that?

I mean that instead of providing content directly, it will give other companies services to manage and analyse their content using the tools and an experience gained within Yahoo. 

Yahoo should also use this position as its ticket into the new cloud world, leveraging its existing data center operation and assets that it developed over the years in managing large scale data services.

Here are few  concrete examples:

• Hadoop as a Service - similar to Amazon Elastic Map Reduce (EMR) but significantly simpler and richer with built-in analytics and reporting tools.
• Analytics PaaS - similar to GAE but focused in the area of Analytics where it would give users the ability to build apps that specialize in data analytics, rather than serving web apps or mobile apps.

Become the Market Place for Web Analytics

There are many services that collect data over the web including social media, and try to extract their own insights out of it.

 

By collecting this data and organizing it for other companies - Yahoo could give its users an easier path to building useful insights (rather than starting with collecting data).  This would then provide a simpler way to build their own insights on-top of that data, rather than building it from scratch. It could also become the marketplace for such insights, where they would offer other analytics companies tools to provide specialized insights for companies consuming this data.

 

Win the developers mindshare

The web and social world is driven by developers - Yahoo can and needs to win the heart and mind of the developer community.

This is specifically true as Google and Facebook are starting to lose some of that mindshare. Given that it already has good assets in the open source community, such as the Hadoop project, Yahoo can leverage this to create even more traction within this community. With the right focus, this shouldn't be too difficult.

Anyway these were my own personal thoughts on this interesting excerise.

 

Good luck Marissa! 

 

References

• 3 Challenges Yahoo’s new CEO Marissa Mayer shares with IT managers
• The real reason Marissa Mayer left Google: She had to
• Google's Marissa Mayer: 3 Leadership Traits She'll Bring to Yahoo
• Predicting The Strange Future Relationship of Yahoo!, Google, and Facebook
• Yahoo Has Seen Its Future; In One Word, It's Products
• How Yahoo Spawned Hadoop, the Future of Big Data
• Yahoo And Hadoop: In It For The Long Term

Google Now and the Future Shock

I was following the Google announcment last week as i was at a Dell Future Cloud meeting just few blocks away from the Google event. We all started throwing idea's that was mainly inspired by the new Google Now and Google Glasses announcement. A world where were going to be allways connected, monitored and managed. We even went further to describe that world.  A world where all this new devices would be planted in our body and we wouldn't even need to carry external devices like Glasses to do all that.

When we finished this session, on my way back home something felt wrong. Google Now sounds cool and scary at the same time. Is this the world that i want to be part of? more importantly is this the world that i'd like to see my kids growing to?

As i was going through this philosofical thoughts i looked around and came across an interesting book from 1972 by Alvin Toffler  titled the  Future Shock.

Alvin looks at the pace of innovation and the effect of that innovation on human being's. Alvin  book looks at whether were really improving our productivity and quality of life with all this innovation. Here some of the interesting thoughts from his book that i thought we should all think about as when we decide to adopt all this "coo" technologies.

While a human being's capacity to adjust physically, psychologically, and socially to this torrent of change is finite and quite limited, the pace of change is increasing and expanding into more and more areas of individuals' lives. Moreover, no one is asking for these profound and endless changes; they stem more from the economic impulses of the marketplace than from any kind of consumer demand, and perhaps we should be asking to what extent this flood of innovations actually enhances our lives, and personal convenience associated with all these innovations and technological improvements are worth the social, economic, and political change that follows in its wake.

To put it simple - were becomming salves of our own inventions, unlike the old generation slaves were doing it out of free will and even willing to pay for it and get excited about it.

Isn't there a better way? Food for thoughts..

 

Lessons from Amazon RDS on Bringing Existing Apps to the Cloud

Its a common believe that Cloud is good for green field apps. There are many reasons for this, in particular the fact that the cloud forces a different kind of thinking on how to run apps. Native cloud apps were designed to scale elastically, they were designed with complete automation in mind, and so forth. Most of the existing apps (a.k.a brown field apps) were written in a pre-cloud world and therefore don't support these attributes. Adding support for these attributes could carry a significant investment. In some cases, this investment could be so big that it would make more sense to go through a complete re-write. 

In this post I want to challenge this common belief. Over the past few years I have found that many stateful applications running on the cloud don't support all those attributes, elasticity in particular. One of the better-known examples of this is MySQL and its Amazon cloud offering, RDS, which I'll use throughout this post to illustrate my point. 

Amazon RDS as an example for migrating a brown-field applications

MySQL was written in a pre-cloud world and therefore fits into the definition of a brown-field app. As with many brown-field apps, it wasn't  designed to be elastic or to scale out, and yet it is one of the more common and popular services on the cloud. To me, this means that there are probably other attributes that matter even more when we consider our choice of application in the cloud. Amazon RDS is the cloud-enabled version of MySQL. It can serve as a good example to find what those other attributes could be.

The Amazon RDS Approach for Cloud Enablement of MySQL

Amazon's approach for cloud enablement of MySQL includes the followings elements:

1. Pre-tuned MySQL -- A pre-configured version of MySQL that was tuned to run well on the AWS instances.
2. Automation -- Automate the installation, deployment of MySQL database.
3. Automate a scale-up/process.
4. Automate the high availability configuration

What Can We Learn from the RDS Experience?

There are couple of lessons that we can learn from this Amazon RDS experience:

1. There is value in migrating existing applications to the cloud. Or in other words, the cloud shouldn't be considered only for green field applications.
2. Automation of the installation and deployment processes is the "low hanging fruit" for migrating application to the cloud.  
3. Elasticity -- quite often when we think of elasticity we think of scaling out, i.e. -- adding more capacity by launching more machines. As MySQL wasn't designed for this model, the RDS approach to elasticity was to automate the move from small to a bigger machine. Apparently this model had proven to be useful even if it involves downtime and is limited to scale-up.
4. Baby steps approach: When Amazon first released RDS it only included basic automation and it was only somewhere down the road htat it kept enhancing the service with more automation. This baby steps approach was a key to speed up the migration process of MySQL.

RDS vs SimpleDB

When AWS was first introduced it started with SimpleDB as its cloud database service. SimpleDB fits into the "green field" application approach to cloud. The approach with SimpleDB was to trade features and functionality for simplicity, elasticity and scalability. The popularity of RDS over SimpleDB is another interesting lesson -- trading features for scalability is definitely a simpler approach to get things running on the cloud. However, there is a considerable number of users and applications that would prefer to trade some degree of scalability for features. This also teaches us that the "green field" approach isn't necessarily the right approach. Migrating existing services has lots of value, especially if they are already in wide use.

Applying These Lessons to Existing Applications

The main take away for migrating your existing app to the cloud can be summed up as follows:

1. Use the baby steps approach
2. Start with simple automation and monitoring of the installation and deployment process
3. Add automation of post-deployment processes such as fail-over and scaling as a secondary step
4. Use a pragmatic approach to elasticity. There are areas of your app where the simplest way to apply elasticity would be simple automation of the move from a small to a bigger machine, often the stateful part of your application. There are other areas of your application, such as the web-tier, where using full elasticity can be done by spawning new instances and automating the discovery and configuration for how these instances group together, as in the case of a web tier.

DevOps & PaaS Can Be a Great Tool to Implement These Steps

There are many ways we could implement the baby steps approach, especially if we look at it as a one-time operation. If we need to move more than one application, we can easily find ourselves repeating the same effort over and over again for each application. DevOps tools such as Chef provide a good generic tool for scripting your installation and configuration processes. New open PaaS  platforms, such as CloudFoundry, Cloudify, and OpenShift address the entire application deployment life cycle, including the automation of scaling, fail-over and monitoring. An integration between DevOps and PaaS, such as the integration between Cloudify and Chef,is even better-suited tothis challenge, as it gives you the best of both worlds. 

Final Words

According to a recent HP Survey with 940 IT responders, a majority of businesses are planning to move their mission-critical apps to the cloud over the next two to five years. A recent survey by Cisco of 1300 responders shows that today only 5 percent of the responders are able to migrate meaningful parts of their application to the cloud. According to this survey, what makes migration to the cloud even more difficult is the lack of information about the process.

Many new cloud users are lost in a sea of hype-driven desire to move to cloud computing, without many proven best practices and metrics.

I believe that the lessons from Amazon RDS could serve as a good reference on what that process could be. If you are considering moving more than one application into the cloud, you should consider the use of DevOps & PaaS as the means to deliver those steps.

References:

• Cloud On-Boarding: The True Story
• Companies nearing mission critical apps in the cloud
• Cisco Global Cloud Networking Survey
• This just in: Cloud computing is hard and takes a long time
• Cloudify and Chef integration 

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. :)