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:
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:
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.
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)?
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.
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.
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:
It also makes Cloudify more open for special customization of the existing stack, like in the case of:
Cloudify also provides a more advanced level of control geared for mission-critical apps, including:
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.
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.
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.
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.
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.
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.
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.
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.
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
Announcing a new product is a major and exciting milestone in a company's lifecycle. Our last announcment 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 interpeting 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 primarly 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:
Final notes..
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 langague, 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 thier 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 specificaly 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:
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.
The beta is available for download at gigaspaces.com/cloudify (the link also includes an online demo for those interested).
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...
Next week, I’m going to be in JavaOne. Unlike last year, where I expressed lots of skepticism about the way Oracle drives the Java Community, it seems that this year things are starting to get back on course – not that the skepticism has vanished completely, but at least there is a stronger sentiment that things are starting to settle down and take a more positive course.
It seems that now Java is taking center stage in the Cloud world, with more application platforms such as SalesForce/Heroku, VMware, Redhat/OpenShift, Cloud.com, JClouds, and obviously GigaSpaces providing a rich set of offerings that are based on Java.
One of the most interesting things in my opinion is that the combination of Cloud and Java brings new opportunities that until recently were unheard of:
What’s interesting in those two examples is that the Cloud forces us to break away from the language wall. It brings communities that were living in completely isolated silos much closer together.
This forces a very different way of thinking about Java - and about the next generation Java platform specifically.
The new platform should be:
It seems that Java EE 7 is taking the right path in that direction. From Java EE 7 and Cloud Computing:
Java is regaining some of its luster from the last few years. It was being perceived as vaguely pedestrian and ordinary, and languages like Ruby and Python were being seen as more dynamic environments for rapid and scalable deployments.
Now we're seeing Java as the lingua franca of enterprise development. With so many environments being heterogeneous, a homogenous platform becomes a very desirable resource, and the JVM is able to run many languages in an integrated environment: Java, Ruby, Python, Scala, and Groovy, to name only a few, and many of these can run as compiled code and as scripts.
Even beyond the multiple programming language support of the JVM, you have very broad support for almost any number of remote procedure call mechanism you can think of. The old J2EE approach, where you defined your requirement and there was a specific way to fulfill it (which meant that every architecture was more or less nudged to the middle), is no longer a real limit.
If you can do it, you can do it in Java, without Java forcing you to sacrifice in the process.
This is a very powerful concept.
It puts your organization back under your control. This is desirable because you know your product and architecture better than a community process does. You know whether you need to support REST here, and SOAP there; you know you need to use NoSQL in this area and MySQL in that area.
Java EE 7 may be becoming aware of the new cloud-based environment, but it's still only one aspect of application deployment and design. What it does not address is the entire application environment.
This is where applications such as Cloudify come in. Cloudify treats every artifact involved with your deployment as a managed element.
Consider: when you deploy an enterprise application, you're not just deploying some operational code. That code has external requirements, like a database (or NoSQL warehouse); it might also rely on an Apache-based load balancer, or perhaps another independently-deployed artifact.
That's quite a burden on operations, because all of these are separately deployed and managed.
Cloudify, however, centralizes the management of each element your application is composed of, over the entire application's lifecycle, and provides a bridge to whatever environment you wish to use.
For example, you could have a MySQL database, used by a Java application hosted by a single Tomcat instance, fronted by an Apache httpd server, hosted on an internal Linux server. Cloudify can deploy and monitor each of those elements: the MySQL database, the schema and initial data; Tomcat; the Java application; Apache httpd, and the server upon which it all runs.
Now let's look at a larger deployment: a set of MySQL servers, a cluster of GigaSpaces XAP nodes, an instance of GlassFish hosting some web services, six .Net-based web services, and five httpd servers being load-balanced, deployed on a platform such as Microsoft Azure. From Cloudify's perspective, the deployment and management process is the same. You have more artifacts to deploy, and you're telling Cloudify to deploy on a different platform... that's it.
Cloudify can make sure each resource is running optimally, as well. If you can measure an attribute - such as CPU load, or disk space, or free memory - you can tell Cloudify to assert that some headroom exists, and what to do if a metric is exceeded.
For example, if you have a CPU running at 100% for an extended period of time, Cloudify can automatically deploy another instance of the component consuming the CPU, and configure load balancing so your application is more scalable, without human intervention.
Likewise, if you have four servers running a given process, all at 0% CPU load, you can reduce the number of containers with that component so that you're not overallocating resources, saving energy and money.
The key thought here:
We'll be on the floor at JavaOne 2011, in booth #5002. We'll be happy to show you both XAP, our industry-leading application platform, and Cloudify, our deployment solution for the cloud-enabled world.
(This post was co-written with Joseph Ottinger, who unfortunately won't be able to make it to JavaOne this year. But he says that the best people in GigaSpaces will be there, so you're not missing out!)
In my last post (GigaSpaces OpenStack Explained) I introduced our plan to add support for OpenStack in our platform:
One of the goals for our second-generation PaaS/SaaS enablement platform was to enable smooth migration between different cloud providers. We were able to achieve this goal through the use of our own abstraction (the Scaling Handler) and through the integration with the JClouds
project that provides common abstraction to most of the existing cloud providers. With that, we can ensure that any application can be moved from the likes of Amazon to OpenStack or to an organization's own private cloud with zero changes to the application code or configuration.
The only change involves is setting the user/key of the specific cloud.
By adding support for OpenStack, we now enable users to safely move to an OpenStack-based cloud when they're ready and with little effort, yet they gain all the benefits that comes with it in terms of cost, openness etc.
Yesterday, I had a session during the OpenStack Summit where I tried to present a more general view on how we should be thinking about PaaS in the context of OpenStack.
The key takeaway :
The main goal of PaaS is to drive productivity into the process by which we can deliver new applications.
Most of the existing PaaS solutions take a fairly extreme approach with their abstraction of the underlying infrastructure and therefore fit a fairly small number of extremely simple applications and thus miss the real promise of PaaS.
Amazon's Elastic Beanstalk took a more bottom up approach giving us better set of tradeoffs between the abstraction and control which makes it more broadly applicable to a larger set of applications.
The fact that OpenStack is opensource allows us to think differently on the things we can do at the platform layer. We can create a tighter integration between the PaaS and IaaS layers and thus come up with better set of tradeoffs into the way we drive productivity without giving up control. Specifically that means that:
The slides below illustrate a very high-level overview of the problems as well as how OpenStack can help provide a solution, from the presentation at the Summit:
We’ve recorded a short demo that shows how all different pieces pieces actually work together in the context of OpenStack:
You should note that since the demo was mainly targeted at illustrating the OpenStack integration through JClouds/OpenStack provider, it doesn’t cover much of the feature set, such as Multi-tenancy, fine-grained monitoring, or fail-over, nor does it show deploying full-blown web-apps and big-data apps, etc.
The actual code for the JClouds/OpenStack provider should be available through the JClouds project shortly.
Today, there is a lot of work and interesting innovation being done in the PaaS world by different providers. Unfortunately a lot of that work is done with very little collaboration. The OpenStack community can be a great environment to put all those great ideas into something meaningful and open.
I hope that our initial joint work with OpenStack, Citrix, JClouds, and GridDynamics can be a good start in that direction.
I’m trying to figure out what’s should be the right way to establish a more formalized Open-PaaS group as part of the OpenStack community. Any ideas/help would be greatly appreciated...
One of the major concerns of many IT organizations is cloud vendor lock-in. This concern was expressed recently in "Banks fear cloud vendor lock-in," from IT Wire:
The onset of cloud computing gives vendors the chance to lock customers in to their infrastructure, using proprietary protocols to ensure they’re on the monthly billing cycle as long as possible.
The OpenStack project emerged with a mission to address this concern by creating a community-led open source project enabling any organization to create and offer cloud computing services running on standard hardware.
GigaSpaces joined the OpenStack project with the mission to enable any organization to build its own Platform-as-a-Service (PaaS), with its own choice of language and best-of-breed middleware stack.
In this post, I’ll try to provide more insight into our current and future plans around OpenStack, and more specifically our joint collaboration with the Citrix OpenCloud initiative.
One of the goals for our second-generation PaaS/SaaS enablement platform was to enable smooth migration between different cloud providers. We were able to achieve this goal through the use of our own abstraction (the Scaling Handler) and through the integration with the JClouds project that provides common abstraction to most of the existing cloud providers. With that, we can ensure that any application can be moved from the likes of Amazon to OpenStack or to an organization's own private cloud with zero changes to the application code or configuration.
The only change involves is setting the user/key of the specific cloud.
By adding support for OpenStack, we now enable users to safely move to an OpenStack-based cloud when they're ready and with little effort, yet they gain all the benefits that comes with it in terms of cost, openness etc.
Yes. The OpenStack integration was developed in close collaboration with GridDyanmics and Adrian Cole from JClouds. We intend to make the integration with OpenStack available to the entire Java community through the open source JClouds project. In this way, any Java application can easily run on OpenStack.
Today, there are a wide variety of tools and frameworks available throughout the ecosystems in Java, .Net, Ruby, and more. We feel that limiting the platform to a specific stack that we control -- as in the case of Google App Engine -- is too restrictive.
Instead, we wanted to create a foundation that enables users of the platform to easily host any service or framework they choose on the platform. We also wanted to do this in a way that provides consistent behavior in terms of deployment, monitoring, elasticity, and scaling. Therefore, we developed a Universal Service Manager and Service Orchestration framework. The framework makes it easier users to plug in their own choice of services that comprise the application stack (Tomcat, MySQL, NoSQL through Cassandra, Hadoop, Ruby...).
In addition, we will provide a set of built-in recipes. At first we will be targeting Big Data stacks, which include integration with NoSQL and Hadoop, and also reporting tools to make the deployment of Big Data applications significantly simpler.
The integration with OpenStack will make it possible to bring these benefits to any application running on OpenStack.
The new platform builds on the collaboration announced in October 2010 by Citrix and GigaSpaces, highlighting the integration between Citrix® NetScaler®, Citrix® XenServer® -- both part of the Citrix OpenCloud solution -- and GigaSpaces eXtreme Application Platform (XAP).
In this new release we are adding the following new development:
Greater Openness
Openness at the IaaS layer -– The specific integration with NetScaler (load balancer) and XenServer would be done through more open interfaces provided through the Citrix/Openstack contribution, which means that OpenStack users can use those intefaces to plug in any hypervisor or load balancer.
Openness at the application layer –- The previous version of GigaSpaces XAP offered a limited set of application stack support features, mostly geared to services that we control and mostly in Java. With the new platform we offer significantly greater flexibility on various fronts:
Better Application Monitoring, Specifically Geared for PaaS
One of the challenges with many of the existing monitoring systems is that they were not geared for PaaS-based deployment. In this new offering we provde PaaS-driven monitoring that is tightly integrated with the platform, and which can interact with the platform to deal with failure or scaling events without any human intervention. In addition, it provides a holistic view that includes the application and infrastructure, as can be seen in these screenshots:
Furthermore, the new monitoring was designed to integrate with the existing set of data-center monitoring tools.
Better Performance and Scalability
By leveraging the Citrix OpenCloud solution, GigaSpaces will provide tighter integration between the platform and the infrastructure layers to up-level services offered through OpenStack clouds. In this way, we leverage the years of experience of both platforms in delivering high performance and low latency to mission-critical applications and remove the hassle involved in tuning the entire stack. We believe that through this joint work we can bring a lot of that experience into the OpenStack community.
We can also now offer more fine-grained multi-tenancy support –- by combining process and VM-based multi-tenancy. This makes it possible to achieve significantly higher density and utilization of existing resources, and reduces the amount of resources -- and therefore the cost -- associated with serving a particular application load.
Any user of this new offering will benefit from the greater openess and reduced lock-in concern. They wouldn’t be relying on single vendor for their future. This also means that they will have better control over their own stack and cost margins, and will therefore gain the ability to offer more competitive prices with other equivalent cloud providers. More specifically
- Enterprises can use this offering to build their own Enterprise PaaS layer that is specifically geared for big-data analytics, e-commerce, and financial applications.
- SaaS ISVs can use this offering to SaaS-enable their application and provide the same solution off- and on-premises.
- Infrastructure/Cloud providers can use this offering to offer an Amazon-like services stack, including RDS, SimpleDB, SQS, Cloudwatch, and Elastic Beanstalk as a pre-packaged solution.
Final Words
I’m very excited about all of these new developments. OpenStack fills in the missing piece in the cloud –- as its name suggests, it unlocks the cloud by providing a truly open cloud stack and provides an essential substrate that drives innovation and collaboration -- which couldn’t be done before. It's interesting to compare the level of effort that we had to invest in the past when we did the first integration with Citrix to the one with OpenStack. Openstack enables us to work completely in parallel and make progress without too much coordination and still achieve substantial progress. Moreover, every delivery of our work can be relevant to wider spectrum of users. It also enabled us to join forces with other members of the community, such as Adrian Cole from JClouds and GridDynamics, simply because we share a similar goal to support the OpenStack open cloud mission.
This is only the beginning. I hope that with this new development we can continue to work toward greater openess at the application platform layer together with Citrix and the rest of the OpenStack community.
I’m going to give a talk on on the subject (PaaS on Openstack) during the upcoming OpenStack Design Summit on April 26th, 2011, in Santa Clara, California, where I hope to share some of these thoughts and hopefully get more work on this happening within the community.
I will also be announcing the first GigaSpaces code contribution to OpenStack at the Design Summit. Note that the integration with OpenStack will be made available to the entire Java community through the open source JClouds project.
You can also get an early look at our upcoming 2nd-generation CEAP release by registering for the Early Access Program.
JavaOne 2010 is coming next week. This year will be the first time Oracle is running the show, so it'll be interesting to see how well (or badly) Oracle treats the community, as there has been lots of speculation recently on how Oracle plans to monetize the technology. The recent lawsuit against Google and the public departure of James Gosling the father of Java didn’t helped to dismiss that fear.
My plan for this year is sort of a continuation of last year. Last year, I was mostly focused on the emergence of Cloud/PaaS technologies and how they will shape the next-generation application server stack (see relevant posts here and here). This year I'm going to drill down more into the components that make up this new PaaS/Cloud stack. My session at JavaOne (NoSQL Alternatives: Principles and Patterns for Building Scalable Applications) is going to deal specifically with data scalability patterns as they have emerged through the various NoSQL implementations. In this talk, I'll try to focus on the common principles and patterns behind the various approaches, such as Sharding, Eventual Consistency, Query models, Map/Reduce, and Transaction Processing. I’ll also discuss how the two models SQL/NoSQL can live together using the examples from Google JPA/BigTable, HBase/Hive and GigaSpaces/SQL and the document model.
For those who don’t plan to attend JavaOne, or for those who are just interested in open discussion around PaaS/Cloud and Dev/Ops, we'll be holding two meetups in collaboration with Adrian Cole from JClouds on Tuesday and Wednesday. Both meetups will take place at 6:30 PM at the Joyent headquarters (345 California Street Suite 2000, 15 min walk from Moscone Center) who were kind enough to host the event.
** Note that the room for these meetups is limited so if you plan to attend please RSVP ASAP so we can plan accordingly.
I marked other sessions and BOFs (33 in total), mostly around my favorite scalability, NoSQL, and Hadoop topics during the JavaOne conference. If you have other suggestions or comments, you're welcome to post them here, and I’ll update the list accordingly.
See you next week…
| ID | Title | Type | Presenter(s) | Company |
| S313726 | Performance and Debugging Advancements in OpenJDK | BOF | Eric Caspole; Tom Deneau; Vladimir Kozlov | Advanced Micro Devices; Advanced Micro Devices; Oracle |
| S314364 | Standard Dependency Injection (DI) with @Inject and JSR 330 | BOF | Costin Leau | SpringSource |
| S314377 | Performance Tuning with Cheap Drink and Poor Tools | BOF | Kirk Pepperdine | Kodewerk Ltd. |
| S313904 | Comparing Apache CXF and Axis2 Web Service Frameworks | BOF | Thomas Liou; Jim Smith | PDX; PDX |
| S314196 | A New Era for In-Memory Data Grids | BOF | Manik Surtani | Red Hat, Inc. |
| S314190 | The Better RESTful Web Services Framework: Jersey or Spring Framework | BOF | Hien Luu | Netflix |
| S314196 | A New Era for In-Memory Data Grids | BOF | Manik Surtani | Red Hat, Inc. |
| S314563 | Hadoop vs. Relational Database: Shout-out Between a Java Guy and a Database Guy | BOF | Karthik Shyamsunder; Chethan Thippeswamy | VeriSign Inc.; VeriSign |
| S313430 | Chillin' with ICEfaces | BOF | Ted Goddard | ICEsoft Technologies |
| S313988 | The Groovy and Grails BOF, with Live Grails Podcast Recording | BOF | Glen Smith | Bytecode Pty Ltd |
| S314360 | Dependency Injection (DI) Flavors in Spring 3 | BOF | Costin Leau | SpringSource |
| S314648 | Give Me a Proper Visual JavaServer Faces Editor or Else . . . | BOF | David Konecny | Oracle |
| S313773 | Going Beyond Memory Leaks: Debugging Java from Dumps, Using Memory Analyzer | Conference Session | Chris Bailey; Trent Gray-Donald | IBM; IBM |
| S313977 | Functional Programming in Java: Lessons Learned by GridGain | Conference Session | Nikita Ivanov | GridGain, Inc. |
| S314432 | Multiple Languages, One Virtual Machine | Conference Session | Brian Goetz; John Rose | Oracle; Oracle |
| S313223 | Practical Big Data Processing with MapReduce and Hadoop | Conference Session | Shevek M | Karmasphere, Inc. |
| S314192 | Measuring Performance and Looking for Bottlenecks in Java-Based Data Grids | Conference Session | Manik Surtani | Red Hat, Inc. |
| S314235 | The Cassandra Distributed Database | Conference Session | Jonathan Ellis | Rackspace Hosting |
| S314496 | Top 10 Lessons Learned from Deploying Hadoop in a Private Cloud | Conference Session | Rod Cope | OpenLogic, Inc. |
| S313637 | What's New in Grails 1.3~ | Conference Session | Graeme Rocher | SpringSource |
| S313876 | JSR 299 (CDI), Weld, and the Future of Seam | Conference Session | Dan Allen | JBoss by Red Hat |
| S314404 | A Lean, RESTful Java Architecture for Building Rich HTML5 Web Applications | Conference Session | Keith Donald; Jeremy Grelle | VMware; VMware |
| S314445 | Scale Java Persistence API Applications with OpenJPA Slice | Conference Session | Pinaki Poddar | IBM |
| S314492 | Java Persistence API (JPA) 2.0 with EclipseLink | Conference Session | Doug Clarke; Shaun Smith; Gordon Yorke | Oracle; Oracle; Oracle |
| S312989 | Comparing Groovy and JRuby | Conference Session | Neal Ford | ThoughtWorks Inc. |
| S312998 | NoSQL Alternatives: Principles and Patterns for Building Scalable Applications | Conference Session | Nati Shalom | GigaSpaces, Inc |
| S314142 | Groovy and Concurrency | Conference Session | Paul King | ASERT |
| S314154 | Writing Domain-Specific Languages (DSLs), Using Groovy | Conference Session | Paul King | ASERT |
| S314226 | SomeSQL: Combining NoSQL Technologies with Existing RDBMS Architectures | Conference Session | Joshua Tuberville | eHarmony, Inc. |
| S314782 | Choosing the Right NoSQL Database | Conference Session | Tobias Ivarsson | Neo Technology |
| S314413 | Extracting Real Value from Your Data with Apache Hadoop | Hands-on Lab | Michal Bachorik; Aaron Kimball; Daniel Templeton | Oracle; Cloudera; Oracle |
| S313963 | Script Bowl 2010: A Scripting Languages Shoot-out | Panel | Rich Hickey; Guillaume Laforge; Raghavan Srinivas; Dick Wall; Roberto Chinnici | Clojure; SpringSource; Self; Navigenics, Inc.; Oracle |
Recent Comments