A simple whiteboard explanation on how Cloudify works
March 23, 2012
March 20, 2012
Big Data In the Cloud Using Cloudify
Edd Dumbill wrote an interesting article on O’Reilly Radar covering the current solutions for running Big Data in the Cloud
Big data and cloud technology go hand-in-hand. Big data needs clusters of servers for processing, which clouds can readily provide.
Edd touched briefly on the role of PaaS for delivering Big Data applications in the cloud
Beyond IaaS, several cloud services provide application layer support for big data work. Sometimes referred to as managed solutions, or platform as a service (PaaS), these services remove the need to configure or scale things such as databases or MapReduce, reducing your workload and maintenance burden. Additionally, PaaS providers can realize great efficiencies by hosting at the application level, and pass those savings on to the customer.
Even though Edd’s article covers all the different forms of running Big Data on private and public clouds, the article focuses mainly on the public cloud offering from Amazon, Microsoft and Google.
In this post, I wanted to cover more specifically how I see the evolution of cloud application platforms (PaaS) to support Big Data. I’ll refer specifically to Cloudify which was designed primarily to support Big Data applications.
Big Data in the cloud using Cloudify
Background
Most of the PaaS solutions out there started by focusing on simple web application deployments on Ruby, Java and Node.js. Unlike other PaaS solutions, when we designed Cloudify we picked Big Data as the primary target for Cloudify, and started by supporting popular NoSQL clusters such as Cassandra and MongoDB, as well as providing the equivalent of Amazon RDS by providing recipes for MySQL. Our goal was to make Big Data deployments a first class citizen within Cloudify. To this end,when you download Cloudify you'll notice that ALL of our examples comes with pre-integrated Big Data deployments.
There are couple of reason that brought us to make that decision:
- Managing large data clusters is a core expertise at GigaSpaces
Most people know GigaSpaces for our In-Memory Data Grid solution known as XAP (eXtreme Application Platform). Over the past 10 years, as our customer deployments grew substantially, we realized that developing strong automation and cluster management is as critical as handling data consistency, performance, and latency in of our data-grid product. In a large cluster, if something breaks it’s going to literally be impossible to handle that failure through manual procedures. For that reason, we developed lots of IP around automation of data cluster deployment which resulted in a unique self-managed data cluster.
- Cloudify is a natural evolution of GigaSpaces Data Cluster
When we built Cloudify it made a lot of sense to take the IP that we developed for managing GigaSpaces cluster and simply generalize it so it would fit with any other framework. In this way, we could leverage the years of experience as well as development in this area, and gain a significant head-start.
- Big Data applications are complex
Big Data applications tend to be fairly complex, which makes them an ideal candidate for the sort of automation and management that Cloudify can offer.
- Big Data applications have a lot in common with XAP applications
Both need automation of data, failover and recovery, both fit into large cluster deployments, and both share similar partitioning and other clustering architecture.
What makes Big Data platform different than any other application
Most of the existing orchestration systems were designed to handle stateless processes. Moving data is a completely different ballgame as you need to think of:
- Primary and Backup dependency
- Availability - moving data without losing it.
- Moving processes to the data rather than the other way around.
- Data replication within and across sites
Automating any of these processes through general orchestration tooling like Chef or Rightscale can become a fairly involved and complex process, with lots of pitfalls with handling edge scenarios for example the handshake process that is often involved when automating a data node failure, including a split-brain scenario.
In Cloudify we were able to curve out lots of that logic from the user, for example Cloudify will automatically ensure that primaries and backups won’t run on the same node or data center in case of disaster recovery. You don't need to do anything but tag your cluster nodes with a zone-tag.
Managing Big Data applications != Managing Big Data storage
Managing data clusters is one thing. Being able to process the data is yet another challenge that we need to think about when we’re dealing with application platforms as I noted in one of my earlier post.
The main challenge is that quite often the management of the data processing logic is built on completely different scaling, availability and monitoring tools than the one used for managing our Big Data deployment. It turns out, that this silo thinking leads to a whole set of complexities starting from the inconsistency in having multiple managers, each determined in a different way when there is a failure or scaling event, and that quite often end up conflicting with one another. Having lots of moving parts is yet another challenge that makes the entire deployment pretty much a complete mess.
Built-in support for In Memory Stream based processing
In an earlier post, 5 Big Data predictions for 2012, Edd pointed out that streaming data processing is going to be one of the main trends for Big Data.
Over the next few years, we'll see the adoption of scalable frameworks and platforms for handling streaming, or near real-time analysis and processing. In the same way that Hadoop has been borne out of large-scale web applications, these platforms will be driven by the needs of large-scale location-aware mobile, social and sensor use.
Being also part of XAP, Cloudify already comes with built-in support for streaming Big Data processing. This means that building your own Facebook or Twitter-like real-time analytics can be as a simple as writing only small scripts that handle the analytics counters. All the rest, i.e. scalability, availability, automation, cloud portability, management and monitoring, is covered by Cloudify as noted in this and this use case.
Examples for Big Data applications running on Cloudify
In the list below, I tried to put together a couple of references and examples that will make it easier for you to get started. The first reference points to a simpler scenario that will allow you to use Cloudify to deploy your Big Data database as a service. The other three references are full-application stack deployments that include the data-processing and web-tier of applications managed together with the Big Data database.
Running a Big Data 'Database as a Service'
Cloudify comes with built-in recipes for Cassandra and MongoDB, as well as Solr (popular search engine), which makes it easy to deploy these database clusters on your local machine, data center or private/public cloud through a single command. In this way, you can use Cloudify to automate the database.
Spring Travel application with Cassandra
Demonstrating a deployment of a JAVA-based commerce application with Cassandra as the database
The example includes recipes that provision the Cassandra database, create a schema, load the data, then spawn a Tomcat container, automatically injecting the reference to Cassandra, that then shows the custom management and monitoring of the application - all through a single command. A recent videocast showing how the travel application works on HP OpenStack cloud is available here.
Pet Clinic example with MongoDB
The Pet Clinic example does pretty much the same thing only using a sharded MongoDB cluster.
Twitter Real Time analytics example for Big Data
The Twitter example shows how you can attach real time stream-based processing for handling real live Twitter feeds, and how you can manage both the stream processing cluster and the Big Data cluster using Cloudify and run it on any cloud. The entire source code for this example is provided on Github.
Give it a try
To try out any of the examples you'll need to download Cloudify (latest) or (stable) build. Cloudify comes with all first three examples as part of the distribution under the recipes or examples directory. To try out these examples simply follow the steps from the Cloudify Quick Start Guide.
References:
March 14, 2012
Lessons from Zynga & Sony on moving from Amazon AWS
Earlier this month Zynga announced its move from Amazon AWS to its own private Z-Cloud. Sony also started to move increasing parts of its workload from Amazon to Rackspace OpenStack.
There isn't so much in common between these different use cases, except for the fact that they may indicate the beginning of a trend (I’ll get back to that toward the end) where companies start to take more control over their cloud infrastructure.
So what really brought Zynga and Sony to make such a move?
Zynga moves from Amazon to their own private cloud
Zynga ran their gaming services on Amazon for a while. It was noted that the cost of running these games on Amazon cost Zynga $63M annually. This cost and the continuous increase of their workload forced Zynga’s management to look for ways to control their cloud operational costs. Zynga realized that at that scale, they are just better off building their own cloud infrastructure. By doing so, they could also optimize the cloud infrastructure for their own needs and reduce the operational cost margins substantially as a result.
According to Zynga their private cloud operation is reported to increase utilization by 3x, which means that they will need 1/3 of the servers that they would need from Amazon for the same workload, as noted by CTO Allan Leinwand on Zynga’s engineering blog:
For social games specifically, zCloud offers 3x the efficiency of standard public cloud infrastructure. For example, where our games in the public cloud would require three physical servers, zCloud only uses one. We worked on provisioning and automation tools to make zCloud even faster and easier to set up. We’ve optimized storage operations and networking throughput for social gaming. Systems that took us days to set up instead took minutes. zCloud became a sports car that’s finely tuned for games.
What's interesting in this case, is the cost analysis. Quite often when we measure the cost of running machines, we don't measure what would be the cost of running a particular workload, which is a combination of many factors, not just the cost of servers.
The other thing that is interesting with Zynga’s move is that they didn't make the move just to cut costs. The move was part of a more strategic direction to create a gaming platform for additional games. Apparently when your service becomes a platform, controlling your infrastructure becomes more strategic than just the cost factor. It’s a big differentiator that can put Zynga in a completely different ball game than its competitors; it will also enable them to have better control over the dependency on Facebook and build their own independent ecosystem.
According to Dave Wehner, CFO at Zynga, the company will lower its cost of revenue over the next 18 to 24 months as third-party hosting costs decrease. Wehner said that Zynga plans to “roll off the majority of those third-party hosting arrangements.”
Zynga’s capital expenditures in the fourth quarter were $50 million, down from $63 million in the third quarter. Most of that spending is focused on zCloud. For 2011, capital investments were $238 million.
The building of its own infrastructure will help the bottom line. Zynga can depreciate its gear and lower quarterly expenses. “We believe this investment will have a short payback period and enable us to expand gross margins in the long term,” said Wehner
The important thing to note is that Zynga’s move wasn't because of Amazon’s failure as it first reads. It’s more of a natural evolution and maturity cycle of the company.
Sony move from Amazon to Rackspace/OpenStack
Sony’s gaming arm faced a number of security breaches last year, as reported by NetworkWorld, which compromised the personal identity information of millions of players within Sony’s gaming network. This event forced Sony to look for ways to have better control of their infrastructure exposure. Their approach was to move some of their workload to Rackspaces’ OpenStack.
By splitting their operations between Amazon and Racksapce they are able to have better control of a particular cloud failure. They are also better positioned to control their cloud infrastructure costs by reducing their dependency on a particular cloud provider, thus being in a stronger position to negotiate their cloud operational costs.
My take:
We’re often taught that infrastructure is a commodity that we shouldn't care much about, and should essentially outsource everything. It turns out, that as the cost of infrastructure get bigger, and as our needs become more unique, controlling the infrastructure becomes a critical part of our business. Controlling your infrastructure could mean having your own private cloud as is the case with Zynga, or minimizing your dependency on a particular cloud provider as is the case with Sony. The good news is there are enough free OSS tools out there such as Chef, Puppet, and Cloudify that can help to reduce the complexity that is often involved with such a move.
References:
- Zynga's play platform a big test for its cloud computing prowess
- New problem for Amazon: Sony defects to OpenStack
- Public vs Private cloud - its not about the cost.
- Five miss conceptions on cloud portability
- Making cloud portability a practical reality
- Cloudify community site
February 19, 2012
Top Myths of Moving Mission-Critical Applications to the Cloud
Top Myths of Moving Mission-Critical Applications to the Cloud
Special Guest Post By Nati Shalom, at CloudNewsDaily.com
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 per cent revealed plans to move mission-critical apps at some point over the next two to five years. This is a fairly dramatic shift in how most companies and enterprises in particular plans to embrace the Cloud.
This would be a good time for a reality check, to look at some of the predominant myths about cloud adoption, and what we should change as we start to embrace mission critical applications in the cloud.
Myth 1: The cloud is a silver bullet solution
We have all borne witness to failures with Amazon and other major cloud providers over the past few years. Because of this, we need to realize that in the cloud, failure is prone to happen even more often than with traditional enterprise IT. This instability is built into cloud economics – to move mission-critical application into the cloud we need to cope with these failures, rather than simply try to prevent them from happening. Mission-critical apps are often built to survive failure, but the fail-over processes assumes manual intervention and static configuration.
Reality Check: To move mission-critical applications to the cloud we need to completely automate the fail-over and recovery processes.
Myth 2: The cloud cuts costs
Many people think that cloud economics starts to pay dividends immediately when you move to an on-demand usage model, paying only for what you use. Cloud can actually be fairly expensive when hosting environments in use are not elastic. I was surprised to see how many startups and SaaS organizations still run their applications in the cloud just as they would in any static hosting environment. While the pay-per-use model has a lot of promise for cost-savings if our applications aren’t designed for elasticity the cost of running the application in the cloud may end up costing you more. Most of the mission-critical applications have not been designed for elasticity and on-demand usage.
Reality Check: To benefit from the overall cloud economics, with mission-critical application we need to provide more flexibility in the way we employ elasticity. For example, for applications that were not designed for scale-out we could automate the move from small instances to large instances – this is basically an elastic scale-up model. We can also embrace hybrid models where most of our resources are statically provisioned and we can employ elasticity only to part of our resources that are easy to scale – such as the web tier.
Myth 3: The cloud is simple
When cloud came out it was touted as a much simpler model for running IT. The common example given was usually the time it takes to get a new machine into our data center. In traditional enterprises this could take weeks, where in cloud getting a new machine can be done in a matter of minutes. However, as IT becomes more efficient, this is no longer the case.
If we compare the process of running applications within our IT with the way we run applications in the cloud, we will see that the time it takes to bring in a new machine is only small part of the actual process of running and managing the application. Quite often this process is actually much more complex in the cloud. This is mostly due to fact that cloud is more dynamic in nature, and there is a lack of tools that can provide the level of control that is expected when dealing with mission-critical applications.
Additionally, most of the existing mission-critical applications come with the requirement for a high degree of management and control. However, a lot of the management and monitoring tools involve a high degree of manual configuration just to get the required monitoring capabilities in place, and manual processes to get a new version or feature of the application into production.
Reality Check: To move mission-critical application into the cloud all these processes needs to be completely automated from the development stage up to the production.
Myth 4: The cloud is inherently scalable
While cloud can scale to 100’s of machines via an API, the truth is that most applications were not designed to take advantage of this approach. So while cloud itself can be fairly scalable the application running on the cloud doesn’t become anymore scalable by simply running in that environment, unless they were designed for scaling from the onset.
Most of the existing mission-critical applications were not designed for cloud scaling. People believe to fully benefit from cloud scaling often involves a complete re-write of the application, and most enterprises just aren’t ready to make such as major shift.
Reality Check: To move mission critical application to the cloud we need to do this in baby steps, starting with only automation and repackaging of the apps, without any code changes. Later steps would involve changing of modules within the application, as needed.
Myth 5: Cloud Bursting
Cloud bursting is an economical model that enables you to combine statically provisioned resources for the part of your application that needs 24/7 utilization and use on-demand resources on the cloud only in cases where you’re running out of resources. In this model, you can design your cost at the optimum level between fixed and on-demand cost.
Many cloud providers offer network connectivity (a.k.a VPC) between private and public cloud resources to enable cloud-bursting and hybrid clouds. Having said that, many applications (mission-critical application in particular) tend to be data sensitive.
Reality Check: To implement cloud-bursting not enough to have network connectivity, you also need to be able to move data not just processes. Content delivery networks (CDN) now make it possible to bring static data closer to the processes. For mission critical applications the same is needed for transactional and analytics data – without it cloud-bursting may remain an interesting theoretical model.
Final Thoughts
As the industry becomes more mature and ready to move mission critical apps to the cloud, we need to manage our expectations from the cloud infrastructure. It’s important to realize that while cloud holds a lot of promise for cost savings, scaling and more, how we run our application and business in the cloud remains our sole responsibility. In this post I tried to outline more specifically the top misconceptions we need to make clear in order to start moving mission-critical applications into the cloud.
I also believe that Hybrid cloud is the way to go – not just for legacy applications but also for new applications. For this to happen we need to think of how do we make cloud-portability a practical reality, as well as how do we practically migrate mission critical applications that were not built for a dynamic environment into the cloud without forcing a complete re-write. Based on the experience with many of the DevOps automation tools over the past years I believe that we can gain a lot by starting with automation of deployment, fail-over and scaling processes as well as automation of the management and monitoring of our applications.
With Cloudify we took many of those lessons and packaged them into a product that makes the process of moving mission-critical applications into the any cloud vastly simpler. Our experience on that regard has proven to be tremendously successful as we proved to be able to take real life telco application that wasn’t written to cloud and migrate it into the cloud in matter of 4 weeks without any code change.
References
- Companies nearing mission critical apps in the cloud
- Making cloud portability a practical reality
- Cloudify community site
January 16, 2012
GigaSpaces Cloudify & VMware Cloud Foundry the new PaaS Jailbreaker
I was reading Krishnan Subramanian's post, Two Events That “Clouded” Our Thinking In 2011. The thing that caught my attention was Krishnan's comments on why PaaS is a superior alternative to DevOps:
The shift in the thinking about the enterprise cloud consumption also poured water into the “DevOps” concept advocated by vendors and pundits with their foot in the IaaS world. When organizations embrace PaaS instead of infrastructure services, we don’t need the DevOps marriage and the associated cultural change (believe me, this cultural change is giving sleepless nights to many IT managers and some consultants are even making money helping organizations realize this cultural change). With PaaS, organizations can keep the existing distinction between the Ops and Dev teams without worrying about the cultural change. In fact, with cloud computing, the role of the Ops is not going away but it stays in the background offering an interface which developers can manage themselves.
Krishnan represents one of the common attitudes and subjects of debate between two main paradigms for developing and managing applications on the cloud:
- PaaS -- PaaS takes a developer, application-driven approach. A PaaS platform provides generic application containers to run your code. The PaaS platforms deals with all the operational aspects needed to run your code such as deployment, scaling, fail-over, etc.
- DevOps -- DevOps takes a more operations-driven approach. With DevOps, you get tools to automate your operational environment through scripts and recipes, and keep full visability and control over the underlying infrastructure.
The Difference Between PaaS and DevOps
Both PaaS and DevOps aim toward the same goal -- reducing the complexity of managing and deploying applications on the cloud. But they take a fairly different approach to deliver on that promise.
Christoper Knee summarized it in his blog post DevOps and PaaS -- Friend or Foe? as the difference between Developers and SysAdmin:
- Developers may ask: "if I have a self-service portal for deploying applications (aka PaaS), do I need SysAdmins at all?"
- SysAdmins may ask: "isn't PaaS just a monstrous black box that prevents me from provisioning the specific services we need to deploy real-world apps?" ... The typical SysAdmin thinks that they can get to 75% of PaaS functionality with DevOps tools like Chef without giving up any systems architecture flexibility.
In one of my earlier post on the subject, Productivity vs. Control tradeoffs in PaaS, I tried to outline the main limitation of most of the current "blackbox PaaS" implementations:
I thought that Carlos Ble's post Goodbye Google App Engine (GAE)
is a good example that illustrates why the initial perception behind GAE as a simple platform that provides extreme productivity can be completely wrong.
...developing on GAE introduced such design complexity that working around it pushes us 5 months behind schedule.
Part of the reason that brought Carlos through that experience IMO is that in the course of trying to make GAE extremely productive the owner made the platform too opinionated, to the point where you lose all the potential productivity gains by trying to adopt their model. In addition, with a platform like GAE you have very little freedom to leverage existing frameworks such as your own database, or messaging system, or any other third-party service that can in itself be a huge contributor to productivity.
Instead, you're completely dependent on the platform provider's stack and pace of development, and that in itself can work against agility and productivity in yet another dimension. In this specific example, Carlos couldn’t use a specific version of a Python library that would have made his productivity higher, and instead had to work around issues that were already solved elsewhere. This is a good example how the lack of flexibility leads to poorer productivity even in the case of simple applications.
Putting DevOps & PaaS togatehr
It looks like more people in the the industry have come to recognize that rather than looking at DevOps and PaaS as two competing paradigms, it might be best to combine the two, as Christoper Knee pointed out in his post:
What if you could get a PaaS that wasn't a black box, enabling developers to deploy apps easily while still giving SysAdmins the ability to provision any services they needed (a la Cloud Foundry)?
I also came to that realization myself, as I pointed out in my 2012 predictions:
In 2012, we’ll see many of the DevOps tools, such as Chef and Puppet, integrated into application platforms, making it easier to deploy complex applications onto the cloud. In the same way, we’re going to see more Application Platforms adopting the automation and recipe model from the DevOps world into the application platform. The latter have the potential to transform the opinionated PaaS offerings as we know them today, with Heroku and GAE leading that trend, into a more open PaaS offering that better fits the way users develop apps today, and provide more freedom to choose your own stack, cloud, and application blueprint.
What Makes a Cloudify and CloudFoundary a PaaS Jailbreaker?
The CIO Maginze article Cloud computing disrupts the vendor landscape defines a new class of PaaS platforms that I think represent the definition for a DevOps PaaS:
A PaaS that allows developers to use whatever tool they want to build their cloud applications and the platform tackles the deployment, scaling and management of these apps in the cloud data center.
VMware CloudFoundry is one of the more notable references in that category. Quoting Christoper Knee:
CloudFoundry runs anywhere, incuding on your laptop. CloudFoundry's service container concept is particularly strong, kind of an appliance on steroids.
These ideas were the founding concept behind Cloudify, i.e. putting DevPops & PaaS togather in a single framework. As with CloudFoundry, Cloudify enables you to break away from the "blackbox PaaS". However, even though CloudFoundry is significantly more open than most other PaaS alternatives, at the core it is still based on the "my way or the highway" approach (aka opininated architecture), which forces you to fit into a specific blueprint that is mandated by the platform. Cloudify, on other hand, pushes the envelope even further by adopting the concpet of recipes that was first introduced by DevOps frameworks such as Chef and Puppet. It introduces more application-driven recipes through the introduction of Domain Specific Language that extends upon the groovy language.
The Cloudify recipes give you the full power to plug in any application stack on any cloud (including a non-virtualized environment) and manage them in similar way to the way you would manage them in your own datacenter or machines. You can also call Chef and Puppet from within the recipes. All this, without hacking the framework itself. As with other similar DSLs, the Cloudify DSL was designed to express even the most complex application management tasks, such as <recovery from a data center failure> in a single line and avoid all the verbose script and API calls that are often involved when you work at the infrastructure level.
All this makes Cloudify an even more open alternative that fits a large variety of the current enterprise application stacks, including:
- JEE applications
- Big Data applications
- Multi-tier applications
- Native applications (C++,..)
- .Net, Ruby, Python, PHP applications
- Multi-site applications
- Low-latency applications (that can't run on VMs)
It also makes Cloudify more open for special customization of the existing stack, like in the case of:
- An application that needs a certain version of MySQL (not the one that comes with the framework)
- An application that needs to run on Redhat (not Ubuntu). or even more interesting -- a case where there are mutiple applications, each needing a different OS served at the same time.
Cloudify also provides a more advanced level of control geared for mission-critical apps, including:
- Monitoring the application stack and topology
- Adding custom application metrics
- Adding custom SLAs
It can also work on wide variety of cloud environments, including Microsoft Azure and non-virtual enviroments.
One of the great powers of the recipe is that it is a great collaboration tool. Once you develop a recipe, it is very easy to share it wtih different groups -- whether internal groups like developement, QA, and operations, where the recipie provides a programmatic definition of thier environment, or it can be shared between the product team and the pro-services team, where your sales and pro-services can easily install and update product versions in a consistent way, as well as reproduce customer scenarios and share them with the support team. Recipes are also a great tool for collaboration through a wider community network, where users can collaborate by sharing common recipes and best practices over the web.
Quick Introduction to Cloudify Recipes
Below is a short snippet that shows a simple application recipe, of a typical java-based web application based on JBoss as the web container and MySQL as a database. The application recipe describes the services that comprise the application, and thier dependencies. The details on how to run MySQL and JBoss is provided in a seperate recipe for each of the individual services. A more detailed description of how a service recipe would look like can be seen here.
application {
name="simple app"
service {
name = "mysql-service"
}
service {
name = "jboss-service"
dependsOn = ["mysql-service"]
}
}
To get a taste, you can try one of the available recepes such as Cassandra, MongoDB, Tomcat, JBoss, Solar, etc., just as a simple way to try out these products on your own desktop or on any of the supported clouds, without the hassle that is often involved in doing so and without even direct relation to Cloudify per-se.
References
January 09, 2012
December 13, 2011
2012 Cloud, PaaS, NoSQL Predictions
2011 is coming to its end and now is a good time to start planning for 2012. I thought that a good start would be too look at my 2011 predictions and if my previous (and first) attempt to predict someting in that turbulent environment held any water...so, here is a quick recap of 2011.
Recap of 2011
Private vs. Public Cloud - As I noted in my recent post Public vs. Private Clouds I felt that during 2011 the debate around public vs. public cloud would become less interesting, as most of the industry has started to accept the fact that there is a need for both environments, and the important issue would become how to make them work well together. The most interesting development in that regard was Rackspace’s recent announcement about their plan to support OpenStack based private clouds, which shows that even public cloud providers have fully embraced this idea.
OpenStack is evolving from a movement into a viable reality - the momentum around OpenStack has gone through ups and downs throughout the year as happens with every new technology. However looking back, it appears that 2011 was a fairly successful year for OpenStack with its first public cloud available already in the market. Dell and HP have started to offer the OpenStack based cloud to their customers, as has Citrix. Rackspace announced their plan to provide official support including for those who want to build their own OpenStack environment…that's quite big considering the short timeframe from when the technology was first introduced…still there is a long way to go but the future looks promising - check out this survey in that regard.
PaaS adoption has been happening at a slower pace than expected, despite the fact that the trend remains consistent. For PaaS startups 2011 was a fairly significant year with the acquisition of Heroku by Salesforce. Amazon Redhat and VMware joined the PaaS arena; Amazon with Elastic Beanstalk, Redhat with their OpenShift initiative, VMware with CloudFoundry, adding to its previous acquisition of SpringSource vFabric. This was a fairly significant year for us at GigaSpaces as we launched a new product in this same domain that aims to completely change the way PaaS is being taught today (stay tuned…).
Google App Engine have no doubt been the disappointment of the year by literally killing GAE as we knew it (amongst many other things) with their new pricing model.
Big Data has gone real time. Facebook made a big announcement on how they moved their batch-oriented analytics system to real time analytics (See my previous posts on this subject here and here). Twitter announced a launch of a new Real Time Analytics dashboard; while both join Google and Yahoo who have already started to make this shift. Google has also been transforming their web analytics framework into real time. As I noted in my 2011 predictions, the entire debate around NoSQL and SQL didn't make sense, and indeed we’ve seen quite a few announcements both from Cassandra and Couchbase on their support for SQL-like query support.
In Memory Data Grids have also taken a similar approach where, with GigaSpaces, we’ve launched our JPA support, other Data Grid implementations such as Infinispan and Gemfire seems to be heading in that same direction each adding different levels of SQL support. The interesting development in this regard is that we were able to prove that you could actually mix and match Document/Schemaless APIs with SQL APIs and have the flexibility to choose the right language for the job (See online demo Same Data Any API).
All in all I think that I came fairly close - don't you think…?
Ok that gives me enough confidence to try the same thing for 2012.
2012 predictions
Cloud
iCloud everywhere - IMO the biggest shift in Cloud is the fact that it’s going to become pretty much invisible to many of the end users as new mobile devices, operating systems and applications start to be designed with cloud support in mind. Apple iCloud and DropBox mark the beginning of this trend. Using cloud for collaboration and synchronization is definitely a killer app for many of the consumer based apps. I expect that in 2012 we’re going to continue to see a big push of many SaaS-based offerings in that space toward rich client support that uses the cloud as a backend and leverages the power of the new generation of advanced mobile devices. The difference is that those clients won’t be just another frontend for the same web UI, but something that will run almost entirely on the mobile device and will use more generic cloud services for synchronization and collaboration. This will create the need for more generic cloud services such as database as a service and other middleware services that can interact directly from mobile applications.
Moving from Amazon-centric clouds to Cloud Mashups – In 2011 we started to see new kinds of clouds starting to pop up. Literally every hardware vendor (IBM, Dell, HP,..), telco (ATT, Verizon, KT), and software provider (Oracle, Microsoft) are either developing or already offer something in this space. Each one tries to maintain a unique position to compete with Amazon either through SLAs, locality, security, or being more open through the support of OpenStack. In 2012, this movement is going to become even stronger as many of the players that have been making the investment during 2011 will come out full speed ahead in 2012.
Microsoft finally gets it with Azure - Microsoft has been around for a while with Azure with somewhat marginal success mostly around its .NET user base, an approach that is too narrow a play when it comes to cloud. Their cloud strategy is coming into focus with the offering of a more ubiquitous cloud supporting technologies that were previously unheard of on a MSFT cloud platform - such as Java, PHP and it wouldn't be too far to assume that they will be supporting Linux applications in the cloud as well.
Cost-driven Application Management - One of the things that is still fairly hard to measure in the cloud is cost, and more specifically how each component of our application and architecture contribute to cost. This is specifically true during current market conditions which are going to put even more pressure on cost savings. Cost-driven application design patterns will start to emerge, and will become an integral part of any design for cloud applications just as scalability and performance are today. A new form of Cost Driven Application Management (CDA) will start to emerge to provide better insight on how our application behaves from a cost analysis perspective - Newvem is a new startup in that space that already launched their private beta.
Mission Critical Apps move into the Cloud - As the industry matures there is no reason why we should draw the line for cloud adoption at simple apps. The challenge will be mostly around performance, latency, and ensuring continuous availability. A new class of middleware and application platforms that are designed specifically for cloud environments will become more popular to help in that transition. On the other hand, Java and JEE specifically will finally become more cloud ready as I noted in an earlier post - Java and the Center Stage.
Network Gets into Cloud API Stack - While compute and storage have become virtualized to fit into the cloud, we haven't seen much advancement on the network layer. Many of the networking providers are now launching APIs to enable better control over the cloud network. Alcatel recently announced an interesting cloud proposition in this domain specifically targeting telcos. The idea is to use the network as a vehicle for making distributed data centers look like one big cloud, making it possible to better leverage existing assets and offer SLA driven compute resources based on latency, location etc. Other cloud providers are also starting to open their network APIs starting from the Load Balancer down to the core switch. This opens up a new set of opportunities for integrating these network APIs with the upper layer of the application stack.
More OpenStack Clouds - 2011 was the just the beginning of that trend, 2012 will see more public and private cloud providers offering support for OpenStack APIs with RackSpace, Dell, and HP already making public announcements in this area. The interesting question in this regard would be how Citrix will play out their CloudStack acquisition with its OpenStack strategy.
PaaS
DevOps and PaaS Converge into App DevOps PaaS - One of the topics that drew a lot of my personal interest last year was the DevOps movement. For odd reasons, most of that movement was driven by Ops and less by Devs. In 2012, we’ll see many of the DevOps tools such as Chef and Puppet integrated into application platforms making it easier to deploy complex applications onto the cloud. In the same way, we’re going to see more Application Platforms adopting the automation and recipe model from the DevOps world into the application platform. The latter have the potential to transform the opinionated PaaS offerings as we know them today, with Heroku and GAE leading that trend, into a more open PaaS offering that better fits into the way users develop apps today and giving more freedom to choose your own stack, cloud, and application blueprint.
Beyond Google App Engine, Heroku - Heroku established itself as a one of the early PaaS providers in the market and is now expanding their offering to Java. CloudFoundry, DotCloud and others are slightly different but still follow the same path. In 2012 you should expect more choices for completely different PaaS platforms starting with JEE PaaS offerings from Redhat, IBM, and Oracle, to private PaaS offerings which essentially are frameworks to build your own PaaS, DevOps PaaS offerings (see note above), as well as vertical PaaS for specific industries. Magento announced their plan to provide PaaS for eComm and it wouldn’t be crazy to assume that others will follow that same path.
BigData
Not only Hadoop Centric - During 2010 and to a lesser degree 2011 Big Data discussions were pretty much centered around Hadoop. NoSQL solutions such as Cassandra and Mongo are gaining fast adoption mainly due to the operational and development complexity that comes with Hadoop. That movement is going to continue at an even greater pace, as Hadoop gets fragmented between many vendors and frameworks such as EMC, MapR, Cloudera, Yahoo, IBM each claiming to own their own Hadoop distro. With new funding in the hands of many of the NoSQL startups I’d expect to see more complete solution stacks targeted at Big Data.
In Memory Data-Grid and NoSQL Become Integrated - During the early days of the NoSQL movement it wasn't clear how the two technologies fit together. As I noted in my previous post here, it actually makes more sense to integrate the two technologies in a context of real time analytics for Big Data or real time data processing for Big Data. Indeed during 2011 I started to see more case studies showing the use of the two technologies as with Facebook and Twitter. MemBase is also a good example for that approach with their announcment earlier this year about their integration of Memcached and CouchDB together into a single product. At GigaSpaces we added built-in integration for Cassandra and MongoDB, as noted here, and plan to invest more in that direction during 2012.
A New Class of Big Data Application Platforms will Address the Development and Operational Complexity of Big Data Applications - As Big Data application become more mainstream we start to hit the next level of complexity, development, and operational complexity. Clearly plugging NoSQL into your architecture may address your scalability requirements but at the same time it’s going to make your development and management experience more complex. Not because the products themselves are complex, but mostly it’s because it is less obvious how to build and design the application around these new technologies. As in previous years, the goal of application platforms is to ease that task by putting together an integrated stack that makes it easier to develop Big Data applications as I noted in my post on Big Data Application Platforms.
References
- The Future of Cloud Computing: Industry Predictions for 2012 | Cloud Computing Journal
- NoSQL Consolidation: CouchOne and Membase Merge to Form Couchbase
- 10 Predictions About Cloud Computing
- 2011 Cloud, PaaS, NoSQL Predictions
- Public vs Private clouds (Again!)- it's not about the cost
- Introducing Magento Go and the Magento Go Developer Platform. The Next Evolution in eCommerce
- Real Time Analytics for Big Data: An Alternative Approach
- Big Data Application Platform
- Java and the Center Stage.
- Same Data Any API
December 08, 2011
November 22, 2011
Public vs Private clouds (Again!)- it's not about the cost
I was reading Geva Perry's post, 10 Predictions about Cloud Computing ..
As always I enjoyed reading Geva's throughts and for the most part comletely agree with him. The thing that caught my attention is Geva's point on private vs. public cloud. Geva re-iterated why the economical benefit of public cloud would turn private cloud into a small niche. Quoting Geva:
"Internal clouds will be niche. In the long-run, Internal Clouds (clouds operated in a company's own data centers, aka "private clouds") don't make sense. The economies of scale, specialization (an aspect of economies of scale, really) and outsourcing benefits of public clouds are so overwhelming that it will not make sense for any one company to operate its own data centers."
Last week I had an interesting discussion with Yoav Abrahami from Wix which made me rethink this entire argument. Wix runs their own managed data center on one of the hosters. They were able to build a pretty agile environment, which enables them to update their software a few times a day and in this way continually grow their business in this model. If they want extra capacity it takes them a couple of hours to get the hardware that they need. They pay a monthly fee and they don't need to commit to three years in advance for thier resources. The example of Wix is interesting as it doesn't fall exactly into the public cloud definition, yet they don't carry large part of a cost associated with the operation of a data center which makes the economical argument somewhat less relevant.
This brings me to the first point:
What makes a cloud private or public?
For most people, public cloud is synonymous with Amazon or Rackspace and private cloud is everything else. Which basically means that if you don't pay by the hour and can spawn x1000 of machines by a call of an API your not considered public cloud - is that really the right place to draw the line?
I beg to differ - the main thing that brought us to cloud in the first palce is agility at a reasonble cost. Agility in that context is our abiilty to launch new products, new features, and meet a growing demand continuously. Previously, it was the IT who stood in the way of the business and Cloud (public & private) emerged as a significantly better way to run IT. Wix is one good example of what some would consider a private cloud, but at the same time they were able to serve the agility and cost requirements of thier business. The thought that the only way to meet our business agility and cost would be through public cloud is wrong and there are many examples like Wix that prove otherwise. This brings me to the next point...
Its not about cost but ownership, and privacy.
The point in my previous argument is that the cost of running your own managed data center today can be fairly low and even lower than running on some of the known public clouds because you can optimize for a specific use case and workload. BeaTune (a referece from my previous post) is another good example in this regard. They claim that since they switched to HQ8 they were able to cut their infrastructure costs in half. Here are the exact numbers:
Amazon: “two servers $380/month. Add roughly $220/month for backup snapshots and EBS for the (pretty large) database and your total yearly costs are $,7200”
EQ8: “two 24GB RAM, i7-920 Quad-Core, 2x1.5TB HDD (Software-RAID 1) servers for $3,530/year at a hosting company that you can actually call
Source: Goodbye Amazon EC2 See you later cloud
The explanation that I have for that, is that with public clouds you're limited in the type of compromises that you can make, and therefore carry a fairly large cost just to be able to live to the promise of meeting huge peak loads, a high degree of failures, and more. If you design for a specific work load you could come up with different structure that fits a potentially more relaxed set of assumptions that could fit your business better and can result in a lower cost and even better performance and SLA. The other part of the explanation is that there is more than one mean to gain from the economy of scale even in the case of private clouds such as leasing the resources of our infrastrcture and using hosted data centers. A good analogy to that is leasing versus renting a car. If we run a fleet we don't have to buy the cars of the entire fleet, instead, we could lease those cars from a third party provider which uses the economy of scale to manage the cost and risk through his entire customer base. By leasing the car we still maintain pretty much the same degree of control as we would if we would own the car ourselves, but we have a more economimcal model to do so.
This brings me to the main point of this post. The important difference between private and public cloud is less about the cost but more to do with ownership and flexibility. I'll use another transportation analogy to illustrate my point. The cost of using public transportation is significantly lower than owning our own private car. If I only use the cost argument I could easily argue that owning a private car doesn't make any economical sense, still most of us wouldn't give up our private car, not because it is less expensive, but because we want the flexibility, and to control when and where we want to go, and are willing to pay extra to accommodate these needs. Pubic cloud in this example is analogous to public transportation; the fact that you can share the same infrastructure with many users enables the sharing of costs with all the users, and thus the cost per user is significantly reduced, while at the same time it means that you agree to compromise on some sort of a least common denominator which is also an attribute of that cost benefit.
If we agree on this observation, then its clear that niether private nor public clouds would ever go away but instead we'll be moving away from the old way of running data centers into a more modern data center, a hybrid data ceneter that can serve the need for control and cost. In both cases, controlling the cooling, real estate, and electiricity doesn't makes any sense, and indeed all that will be outsourced completely if that's not already the case. The main thing that will make private cloud different is who controls where and how our data is maintained, where and how our services will run, what type of infrastrcture (compute, network, storage) we choose to run our business, and most importantly how much we're willing to share that environment with other users to reduce the cost. Even with that, it's hard to draw a clear line between private and public cloud, as it may very well be the case that what's right in a particular case is a mashup between the two. For example, imagine the case where we will keep our data in a private cloud but run the compute nodes on a public cloud, is that a private, public cloud...who cares?
Final note
Many use the term private cloud to point to the old (and pretty clueless) way of running a data center. I argued that private cloud, as the name suggests, represents a business need to maintain high degree of privacy and control of its data and resources by ensuring that they are not shared with others. The key is the sharing aspect. The resources may very well be hosted somwhere else but the key is that they remain private. These needs will never cease to exist in the same way that we have public and private transportation, or the option to lease and rent a car, and will continue to have. The old way of running data centers must change and is changing to meet the cost and agility demand of the business, and is adopting many of the features of public cloud. With that the cost margin differences between private and public clouds becomes less signficant and for some scenarios has proven to be even cheaper (assuming that you can design for a particular work load and use case) in a private cloud sceanrio. All this makes the cost argument even less significant a factor for choosing between the two models.
Public cloud providers would also need to adapt to meet the demand of private cloud. Rackspace recently announced a new offering in that space around OpenStack.
Rackspace's announcement is another sign that any player that wants to compete in the IaaS market needs to offer some way to have a private and public cloud. Any offering with only half that is going to be left wanting.
In addition to that, Rackspace is conneting their hosting business which some could view as another form of private cloud with their public cloud offering which will give thier customers an even greater degree of flexability. Amazon already provides for a while now the Virtual Private Cloud (VPC) service which enables them to offer resources from the public cloud as just another node in the customer's private cloud. Amazon VPC doesn't provide the full degree of privacy and isolation of their network and resources, but is definitely another form of connecting private with public cloud offerings, and an indication of how Amazon has adapted to this demand. There are still many questions to be answered and challenges ahead, namely how to combine the two models well both technically and echonomically, but the main point is that the entire debate around private and public cloud, who's going to win should become moot. It's now time to focus our energy on how we combine the two.
References
- 10 Predictions about Cloud Computing
- Goodbye Amazon EC2 See you later cloud
- Is Rackspace Ready to Support Private Clouds?
- Amazon VPC
Powered by Qumana
November 15, 2011
Five Misconceptions on Cloud Portability
Three years ago when we started working on the first generation of our PaaS offering, cloud portability seemed to be pretty much “mission impossible.” At the time, we made a conscious decision to focus only on Amazon for our first generation PaaS as practically it was the only cloud in town.
Now, there are many different public and private cloud offerings: platforms like GoGrid, VMWare, Citrix/Xen, and Cisco UCS, with recent additions being OpenStack, Cloud.com, and Microsoft Azure. Frameworks like JClouds have been developed to make cloud portability an easier goal to reach.
As a result, cloud portability is not only a possibility, but it's easily done with the right constraints in mind.
Having said that, there are still too many options from the standpoints of API standardization, portable virtual machines, abstraction frameworks, orchestration frameworks, etc. None of them fully address the challenge and therefore a solution has to combine these options into one cohesive unit. Finding the right combination of features is a pretty tricky challenge and involves lots of trial and error, as the chances that you’ll pick the wrong ones are still pretty high, as we experienced ourselves.
In this and the next few posts, I wanted to share some of our experiences when developing Cloudify , our unified cloud deployment/management tool. I will start by covering five common misconceptions people have.
Five Common Misconceptions on Cloud Portability
1. Cloud portability = Cloud API portability
This is perhaps the most important observation in this entire discussion. When people think of Cloud portability, the immediate thing that comes to mind is Cloud API portability - a standard API, or a common abstraction, that maps all the different API’s into one common façade, right? Well... wrong.
What you're really looking for is the ability to run your application on different cloud platforms without any code change. Having a common or standard API is one way to achieve that goal but not necessarily the most practical one, given the speed in which cloud APIs evolve. This brings me to the first observation: Application Portability != Cloud API portability. Let me explain:
Most applications don’t need to interact with the cloud-specific API from the application itself. Most of the cloud API deals with stuff that happens outside of the application code, like starting new virtual machines or services, or providing elasticity. In many cases, systems management tools are the primary specific aspect for a given cloud platform; most provide support for managed middleware like MySQL (RDMS), Tomcat, memcached, or even map/reduce (through Hadoop, for example.) The mechanisms for using these are standard and common, but the APIs for managing the services are not. (There are exceptions, such as SimpleDB and SQS, which do use proprietary and localized APIs. I believe that over time, you'll see less and less of this as there will be enough nonproprietary options to restrict their use.)
The problem of dealing with application portability between clouds is vastly different than the problem of dealing with API portability. API portability is easy; cloud API portability is not.
I’ll spend more time on how we can use this realization to simplify the task of achieving cloud portability in a follow-up post.
2. The main incentive for Cloud Portability is - Avoiding Vendor lock-in
Vendor lock-in is one of the major barriers to cloud adoption as indicated in a recent survey by 451, GigaOM and North Bridge Venture - Future of cloud survey shows significance of open source
Interoperability and vendor lock-in were ranked the next most significant challenges, both with 25% of response. Though we saw vendor lock-in fade a bit as a concern for customers two to three years ago, it has risen again as a major issue in cloud computing. We believe this is in part because of the early nature of cloud computing and a desire from users to avoid getting stuck with a cloud vendor, framework or technology.
Many (myself included) view cloud portability as a mean to address vendor lock-in as the main drive for Cloud portability. If we can run our application on any cloud without any code change, we can in fact avoid vendor lock-in.
This brings me to the second realization. Cloud portability is more about business agility than it is about vendor lock-in. Let me explain:
It is not very likely that you would switch entirely between one cloud provider to the other, at least not frequently. If you are going to change cloud providers, its going to be more of a one-off event than something that you would practice on a regular basis.
On the other hand, it is probably more likely that you would use cloud portability to choose the right cloud for the job. A common example would be to run your test on the cloud and production on your own private cloud. Another example would be to run your demos and trials on the “cheapest” cloud and production with a cloud provider that offers a higher service level. A more advanced scenario would be to use cloud portability for cloud bursting.
In other words, cloud portability is about business flexibility. It gives us more choices between cost, SLA, and security tradeoffs between the different cloud offerings and product lines. Portability between our local data center and the cloud would also help in making the transition to the cloud more smooth.
3. Cloud portability isn’t for startups
If you're a startup, when the discussion on cloud portability comes up the immediate reaction is often “hmm.. interesting but not for me.” Being part of a startup company myself, I think that I can relate to that reaction. As I mentioned before, when I faced the choice for dealing with cloud portability a few years back, cloud portability was one of the first items that I took off of my list of TODOs to meet our time-to-market goal, and settled for Amazon.
Recently, I came across different cases that shows that dealing with cloud portability is often forced on us even when we don’t plan for it.
The first case is with MixPanel, a web analytics company who switched from RackSpace to Amazon:
When MixPanel started up, cost mattered as they were running out of their own pockets. In this case, every dollar counted and therefore the right choice at the time was Slicehost. As their business grew, Mixpanel switched from Slicehost to Linode and later to Rackspace due to a Ycombinator deal. As their business grew, they switched to Amazon who happened to provide more features and greater flexibility .
First was Slicehost back when everything was on a single 256MB instance.. Second was Linode because it was cheaper (money mattered to me at that point). Lastly, we moved over to the Rackspace Cloud because they cut a deal with Ycombinator... Even with all the lock in we have with Rackspace (we have 50+ boxes)..it’s really not about the money but about the features and the product offering, here’s why we’re moving”
source: Amazon vs Rackspace
The second case is BeaTunes that switched from Amazon to EQ8 Hetzner
In the case of BeaTunes, the trigger for switching off of Amazon was an Elastic Block Store (EBS) crash. During that time, I had to rely on basic support that Amazon provided. Given that BeaTunes is a small startup, they had almost no leverage to escalate their issue fast enough for the business need and had to hope that their particular issue would hit enough users in the forum to attract Amazon's support staff's attention.
They ended up choosing EQ8. Being a smaller hoster than Amazon made EQ8 a better fit for BeaTunes, a small startup itself. Even a small startup can run mission critical software, and when there is a failure, it is even more important to get a timely response as your entire future may rely on this. Unlike big companies, you often don’t have the means to survive such failures easily. It also happened that by switching to EQ8 BeaTunes could choose better hardware configuration that fit their needs and at half the price of the original services!
Amazon: “two servers $380/month. Add roughly $220/month for backup snapshots and EBS for the (pretty large) database and your total yearly costs are $,7200”
EQ8: “two 24GB RAM, i7-920 Quad-Core, 2x1.5TB HDD (Software-RAID 1) servers for $3,530/year at a hosting company that you can actually call
Source: Goodbye Amazon EC2 See you later cloud
These are only two samples, representative of a much bigger trend in the industry at large.
The interesting thing in both MixPanel's and BeaTunes' histories is that their choice of cloud changed over time due to changes in their maturity as a company, as well as changes in the business requirements which involve cost, support level, flexibility and feature set, etc. At each point in time, the right cloud happened to be a different cloud.
Personally, I found that issue around supportability in the case of BeaTunes quite interesting as quite often we tend to go for the brand thinking that it’s the “safest bet” where perhaps the right choice would be to choose the one that fits our size (and stage).
The main point in both examples is that even during a relatively short period of time, the two startups found themselves switching from one cloud to another. In the case of MixPanel, this happened four times during their company lifetime.
The thought that you can avoid such a move between cloud platforms is likely to be too optimistic, even if you’re a startup. Given that there are more options to deal with cloud portability today, and the effort is not as a great as was the case few years back, I would encourage every startup that is expecting rapid growth to re-examine their deployments and plan for cloud portability rather than wait to be forced to make the switch when you are least prepared to do so.
4. Cloud portability = Compromising on the least common denominator
By definition, standards tend to lag behind implementations. Standards are therefore a compromise on the least common denominator. In a dynamic environment, such as the one we're experiencing with cloud today, compromising on the least common denominator is a choice which may come with great cost on “reinventing” things that are already available outside of the standard or common API.
If we think of application portability, we don’t need to compromise on the least common denominator as most of the interaction with the cloud API happens outside of our application code anyway, to handle things like provisioning, setup, installation, scaling, monitoring, etc.
There are orchestration tools such as Chef and Puppet that can provide higher levels of abstraction for automating those processes between clouds without relying on a common cloud API. Frameworks like JClouds provide common abstractions to the common set of APIs (such as Compute and Storage APIs) while still allowing the application to interact with the underlying cloud-specific APIs and thus minimizing the areas of differences between clouds that would require specific handling.
5. The effort for achieving cloud portability far exceed the value
Many would argue that cloud portability comes with a cost and rightly so. Indeed, there is no such thing as free lunch, and cloud portability is no exception.
However, the cost isn’t as great as many of us think, especially now that there are more tools and frameworks available.
The effort to achieve cloud portability is far less than it used to be, in most cases, making it a greater and more valuable priority (with less investment) than it used to be.
Final notes
The term "cloud portability" is often considered a synonym for "Cloud API portability," which implies a series of misconceptions.
If we break away from dogma, we can find that what we really looking for in cloud portability is Application portability between clouds which can be a vastly simpler requirement, as we can achieve application portability without settling on a common Cloud API.
As in the case of MixPanel and BeaTune, choosing the right cloud for the job may vary over time. The right cloud when we create a new startup can be different than when we grow, and if we're very successful, we may find out that managing our own cloud is the right choice.
If we focus only on what’s needed to ensure application portability between clouds, we may find that cloud portability can be easier than it seems at first glance. If done correctly, it can result in greater flexibility for our businesses:
-
Choose the right cloud for the Job
-
Reduce vendor lock-in
-
Enable advanced deployments such as a hybrid cloud, and cloudbursting
In the next post I’ll touch on what it takes to turn cloud portability into a practical reality.
References
Search
Recent Posts
- Ramping Up for the 3rd OpenStack Israel - the Biggest One Yet
- Using the Cloudify Player as an Open Source Framework for Building Your Own Cloud Application Marketplace on OpenStack
- Amazon Marketplace - Not a Fair Play, Thoughts on an Open Marketplace Alternative with OpenStack
- Real-Time Big Data with Storm, Cassandra, and XAP
- Paypal To Drop VMware From 80,000 Servers and Replace It With OpenStack - My Take
- DevOps, PaaS and Everything in Between
- Carrier Grade Cloud/PaaS
- What is Cloudify? an End User Perspective
- A Groovy Kind of Java
Recent Comments