Announcing a new product is a major and exciting milestone in a company’s lifecycle. Our last announcement was the launch of XAP a few years ago – the Xtreme Application Platform aimed to provide a complete end to end scalability solution through the entire application stack, meaning Data, Web, Messaging, everything.
Today is one of those exciting days, as we are announcing a new product, Cloudify.
As its name suggests, Cloudify is primarily targeted at making the processes of bringing new and existing application to the Cloud extremely simple, to the point that it would require no code or architecture changes to deploy on any distributed platform.
In this post, I would like to share some of the motivations that led us to come out with Cloudify and provide a bit of an insight into how Cloudify is being used already.
The motivation behind Cloudify
The first thing that led us to Cloudify was the need to reduce the barrier of entry for applications that want to leverage the cost effectiveness and agility of the cloud, but are not yet ready to make the investment in re-writing their existing application, or switch to a new platform for that purpose.
In many situations, it was apparent that reducing the time to market in which those applications can offer through the cloud was a much bigger concern than making the application completely elastic. There are also those who are launching new applications but are not yet ready to make the switch to the cloud.
These organizations are looking for ways in which they can “future proof” their applications so that when they are ready to make the switch to cloud-based deployment, they can migrate with a simple configuration change. ISVs in particular, need this flexibility so that they can continue to serve their existing deployments while at the same time providing new cloud-enabled product offerings without the overhead of maintaining two completely separate product lines for that purpose and without disrupting thier current business.
The second motivation was around openness, and reducing the lock-in concerns. Too many cloud solutions and platforms introduce a high degree of lock-in, starting from the infrastucture, through the API and specific language and stack that is forced upon users.
Big players such as Oracle and VMware are starting to offer their own data center infrastructure and tie this even further into their platforms, leaving their customers with an even greater lock-in risk. As Oracle and VMware expand their stacks, more and more of their ecosystem partners are finding themselves in direct competition with little option of fighting back.
As many data centers become cloud-enabled through private cloud initiatives, it becomes more apparent that the right way to leverage cloud infrastrcture is through some sort of hybrid cloud. A common use case for mission-critical applications would be to run testing on the public cloud, for example, and the production application on a private cloud. Another use case could be to use the private cloud for running steady workloads and burst to the public cloud during peak loads.
Today, however, the private and public clouds look fairly different. Moving an application from one cloud environment to the other is still a fairly complex process. That brings me to third motivation: the need to provide a consistent cloud story behind both the private and public cloud.
Cloudify to the rescue
The heart of Cloudify relies on two main parts: a recipe model, which is a Groovy based DSL (Domain Specific Language) specifically designed to provide cloud semantics to any application, and an orchestration engine that is responsible for interpreting this recipe and executing it.
With these two components, we are able to reduce the barrier of entry for Cloudifying an application to the point where all you need is a simple start and stop script! You can automate the deployment of your application on any cloud, include monitoring, and even add more advanced capabilities such as elasticity and continuous availability. More advanced monitoring and SLA management can be added easily at any stage through a set of plug-ins. Below is a snippet of this recipe:
Cloudify’s orchestration works at a process level.
This means that the deployment, installation, and scaling can be supported in the same way no matter what the deployment stack is, whether it’s based on Java, .Net, C++, Ruby, PHP, or anything else.
Further, Cloudify comes with pre-integrated recipes that support the likes of Tomcat, JBoss, MySQL, Spring, Cassandra, MongoDB, HSQL, ActiveMQ, and Solr as well as a set of pre-backed application blueprints for Web Applications and Big Data Analytics applications.
This makes Cloudify open to any application stack.
Plus, it actually makes many of the popular OSS stacks run better.The Groovy-based DSL and the planned integration with other automation engines such as Chef make it fairly easy to extend the platform and plug in your application or stack of choice. We actually invested a lot of effort in Cloudify to make the process of developing and testing recipes very simple, to the point where you can test an entire application stack on a local Cloudify-managed cloud.
The third point relates to DevOps. Many of the existing automation and orchestration services have been designed primarily for operation teams. They are often not even accessible or available at the development environment.
With Cloudify, we realized that the right way to make an application ready for the cloud would be to empower the developers of those applications with tools that fit their development environment through Local-Cloud, a simple DSL, and a set of IDE integrations along with the Cloudify Application Management and Monitoring system, which was designed to fit into both the development and operational environment.
With these, we can provide a smooth transition from the development environment to the production cloud environment through a single operation. The same abstraction enables us to move between different cloud environments, whether they happen to be public or private clouds. This allows us to choose the right cloud for the job.
For example, we can run our testing in the cloud and the production application locally, or vice versa. We can choose a cloud resource based on cost and/or locality; for example, we may want to use a “low cost” cloud for demos, and for production deployment, a cloud that provides the best service levels. All this brings a consistent cloud story between local, private, and public clouds.
What does this means for XAP users?
As mentioned above, XAP provides an end to end scale-out middleware stack.
Cloudify was designed to manage XAP middleware services as a first class citizen within the Cloudify environment. That means that with XAP, users can now have get significantly better automation, orchestration, as well as management and monitoring services than with previous releases. Cloudify comes with specific support for running XAP middleware components, including DataGrid, Messaging, Processing, Map/Reduce, et al.
The combination of the Cloudify and XAP also opens the opportunity to integrate XAP with other middleware services such as Tomcat and JBoss on the web container side, and MongoDB, Cassandra on the database side, managing the entire stack through a consistent provisioning and management experience. It also completely automates the process of deploying complex applications such as Big Data applications that span multiple sites.
How can Cloudify users benefit from XAP?
One point that needs to be made is that Cloudify and XAP protect you from external services. For example, Amazon provides an excellent feature set: RDS, SQS, SimpleDB, Elastic Caching, and more, but using these features ties you to Amazon. With Cloudify and XAP, you get each of these feature sets, along with multi-site replication and Xtreme Transaction Processing, which protects you from being locked in to cloud-specific services.
Who is integrating with Cloudify
Even though Cloudify wasn’t officially released until today, the interest behind the product was enormous and brought many new prospects and existing customers to try out earlier versions of the product. I picked a few of the intreesting use cases:
- A large Telecom ISV plans to use Cloudify to move many of their existing network applications and services into a virtualized environment.
- A leading Bank that is already using XAP plans to use Cloudify to manage their entire application stack and build their own private PaaS.
- A large ISV plans to use Cloudify to build a fully managed Big Data stack that integrates with Cassandra.
- A large system integrator is using our Integration platform Cloudify for Azure to bring Java applications into Azure.
- A large provider in the financial sector plans to use Cloudify to move their entire portfolio of products that were built through aquisitions into a common platform that can provide consistent management across the stack and reduce the cost of managing their existing application, as well as reduce the time it takes them to launch new features and applications.
Today many organizations and ISVs wanting to leverage the value of the cloud are left with a fairly limited number of choices – they can either choose to use one of the public PaaS platforms and give up full control over the language, data center, and stack that they can choose, or they can choose to build their own platform and in that case face the complexity, cost, and more importantly time that is often involved in building such a platform.
Many of those organizations need a platform that they can use to Cloudify their application and build their own PaaS without the complexity involved, without giving up control at the same time.
ISVs and SaaS providers need such a platform to embed as part of their own product distribution or service.
According to recent Forrester research (Sizing The Cloud), the demand for such middleware platforms is going to grow substantially over the course of the next years.
By 2020, the middleware virtualization market will be the largest private cloud segment in terms of total revenues, at $9 billion.
“a new set of technologies that allow virtualization of large-scale, server-based enterprise applications are starting to become more important. Application-aware virtualization (AAV) will be the primary driver of future growth in this category”
Cloudify is positioned specifically to fill-in that void.
In addition to all that, Cloudify will come with a feature-rich free edition. Unlike many of the other alternative offerings in this space, we designed the free edition to serve real enterprise application workloads and not just demo or development environments. (We’ll share more in few weeks time as we complete this beta stage).
The current beta version already comes with support for Tomcat, JBoss, MySQL, Spring, Cassandra, MongoDB, HSQL, and ActiveMQ. It also comes with examples that show full application stack deployments, including:
- Web Application deployment stacks including the traditional PetClinic and SpringTravel applications, demonstrating an elastic deployment of a common web application stack.
- A Real Time Analytics for Big Data example, demonstrating how you can process large volumes of events in real time and store them in a NoSQL backend.
Trying out these examples is an extremely simple process. You don’t need to download or install a full virtual machine image or integrate with a particular cloud. All you need is to download Cloudify, start the Cloudify local-cloud and execute a single command <install-application ..> and you’re good to go.
On a more personal note – with Cloudify, I feel that we’re able to take a lot of the experience that we’ve gained over the years in dealing with large-scale mission-critical applications and come out with something that integrates all this into a simple product. I believe that the days in which you had to “outsource” your entire application to someone else’s PaaS, or SaaS just to mitigate the complexity will be gone. Cloudify brings the power back to where its belongs – to the application owner!
I look forward to hearing your feedback, receiving your input, and getting the ball rolling…