Cloudify for Azure

image

By now, if you’re following GigaSpaces, you should probably have heard about our new Cloudify for Azure offering. In this post I’ll try to provide a high level overview of what this offering is about, how it was conceptualized, and what are its benefits for the end user.

Cloudify – A Brief Intro

If I were to summarize Cloudify’s mission statement to a single sentence – it would be to cloud-enable enterprise and mission critical apps easily and non-intrusively. This essentially means that Cloudify enables you to take an existing application and seamlessly deploy and manage it on your private or public cloud, with no code changes. When we set out to create Cloudify, we had three primary design guidelines in mind:

imageAny app, any stack: We wanted to provide a flexible yet simple mechanism to deploy and manage applications on the cloud. That’s pretty much standard. But we also wanted it to be flexible enough to support any kind of application – i.e. No matter what your application stack of choice is: Java/Spring, JEE, PHP, .NET, Ruby on Rails or others, with a relational (e.g. MySQL) or non-relational (e.g. Apache Cassandra) data store, or with other middleware components, you will still be able to leverage Cloudify to… well, Cloudify it.

imageAny cloud: From talking to numerous customers and prospects, we quickly realized that they want the same kind of flexibility in their underlying cloud environment as they do with the application stack. For example, many customers talked about public clouds such as Amazon, Rackspace, and Azure, while others talked about private cloud, ranging from higher level cloud platforms such as OpenStack and cloud.com, all the way down to plain virtualized environments such as VMWare vCenter and Citrix XenServer. Moreover, some expressed the need to deploy the same application on multiple environments, for example for cloud bursting purposes. This meant that we had to create a framework flexible enough to, on one hand, handle any application stack, yet on the other hand, isolate the application completely from the underlying cloud runtime, whatever it may be.

imageFull control: When deploying enterprise, mission critical apps to the cloud using existing PaaS solutions, you gain a lot of benefits such as agility and productivity since it’s no longer about the underlying OS and runtime, but rather about the application itself. But in many cases, you lose at least some degree of control, since you’re not exposed to the underlying infrastructure and cannot monitor and tune it the way you’re used to with traditional data centers and applications. Since Cloudify does have access to those resources, it can provide a much greater level of control, but only if you actually want it. Otherwise, it hides the complexities using a set of predefined application blueprints and best practices that the less advanced users will typically find sufficient.

So How Did We Get Here to Begin With?

GigaSpaces has been providing XAP, our end to end, elastic application platform, for quite some time now. XAP is being used for the most demanding applications, for a variety of mission critical and high performance use cases, so you can say it’s pretty much battle proven. XAP’s core runtime is designed to allow for the management and on demand scaling of such application’s on both cloud and on premise environments. Furthermore, it can use the underlying virtualization technology, when such is available, to provision or decommission resources on the fly, as needed by the application. Realizing that the above are some of XAP’s most appealing capabilities, and taking into consideration the fact that migrating to XAP may in some cases entail non-trivial efforts, we wanted to open it to as many applications and use cases as possible. The way to do this was to enable any type of middleware service (web containers, databases, messaging servers, and basically anything you can install and start with a script..) and not just XAP’s own application containers, to be managed and scaled within the same powerful runtime platform. To open XAP’s runtime platform in this way, we’ve created a number of mechanisms that mediate between the provisioned service and the runtime environment:

RecipeWithFilesRecipe-based configuration: At the core of Cloudify stands the mechanism of application recipes. You can think of a recipe as a “manual” that tells Cloudify all the details that are needed to run an application: what middleware services it needs to run, what the dependencies are between these services (e.g. a Tomcat-based web app that accesses a MySQL instance), how to install those services and where to find the application and service binaries, when to spin more instances or terminate existing ones, and even how to monitor each of the services. Recipes are expressed in a Groovy based DSL (domain specific language), which makes them very intuitive and easy to extend and customize.

Complex DeploymentsUniversal service adapter: This component runs on every node, and basically translates the recipe into actions (install, start service, monitor it, etc.) on the local node. You can think of it as Cloudify’s local delegate on each node. The nice thing about it, is that it doesn’t really care what service it manages (Tomcat, MySQL, Cassandra, JBoss, or even Apache with mod_php), as long as the recipe configures it correctly.

Monitoring n ManagementPluggable and customizable monitoring: The monitoring framework was built as a set of plugins for common monitoring protocols (e.g. JMX, SNMP, JDBC/SQL, and others). The universal service adapter activates the plugin locally on each service node, and the plugin connects to the local service and starts collecting metrics from it (for example the value of a certain JMX MBean in Tomcat). These metrics are then communicated to the Cloudify runtime, exposed to the user via the various user interfaces, and are used for auto-scaling decisions defined within the recipe.

How Does Azure Fit into the Picture?

So now that we understood Cloudify’s main purpose and components, let’s talk about the underlying Cloud infrastructure. Cloudify contains a very powerful abstraction called the Multi-Cloud Adapter. This abstraction was designed to isolate the application from the underlying cloud environments, and to provide a common foundation for integrating with all major cloud and virtualization vendors. Azure is one of the first clouds which we have integrated with Cloudify, but we plan to integrate Cloudify with many virtualization and cloud vendors over time. We’ve already done a lot of work around Amazon EC2, OpenStack, Rackspace, GoGrid, Citrix XenServer and we intend to have each and every one of them natively supported by Cloudify. As part of these efforts, we’ve also made contributions to the excellent JClouds project around its OpenStack compute and blob store support, and we plan to continue contributing to it the future, since we believe cloud portability is key in reducing the entry barriers and making people feel more comfortable with their choices (knowing they will not be locked in to their cloud platform of choice later). It’s worth noting, that the list of platforms above is diverse and there’s quite a large variance between the supported platforms. We’ve designed Cloudify to be flexible enough to be able to use these environments for provisioning virtual hosts and add and remove them on demand per the application’s requirements. But it’s not just about VM provisioning. In many cases, you’d want to leverage a certain platform’s unique capabilities, such as Azure’s load balancer or failover capabilities. By using the Azure worker role, load balancing becomes as simple as spinning up another role instance and provisioning the application (e.g. A Tomcat web server) to run on it. In addition, the worker role guarantees automatic self-healing by the Azure cloud in the event that the application instance fails, since Azure automatically recovers role instances when they fail. This also enables the user to utilize the Azure blob store for storing application and service binaries. If you use Tomcat, this would probably be the best place to put your Tomcat installation binaries, and even the application’s deployment package (a .war file in our case). The other bit is that Cloudify does not limit your ability to leverage other Azure cloud services in any way , such as SQLAzure, the table service, or the queue service, since it is not intrusive to your application. So in short – Cloudify and Azure are a great match, allowing you to easily on-board your mission critical Java apps to Azure while still leveraging Azure’s built in capabilities.

A Few Words about Cloud Portability

Cloud portability is often underrated, since in the quest for cloud-enablement of your application, there are much more pressing issues, such as, say, getting the thing working on the cloud to begin with… But making sure your application and deployment configuration is not bound to a specific cloud environments is important for a number of reasons:

imageAvoid cloud vendor lock-in: In many cases, we’ve seen customers migrate from one cloud to another, or from public to private cloud for a variety of reasons, such as service levels, pricing, and more. What works and fits the bill today may prove the opposite in a year or two, and as a user you want to make sure you’re not tied to a specific environment or vendor. One might (rightfully) ask whether using Cloudify doesn’t actually lock you in to Cloudify itself instead of the cloud platform. Well, it does to an extent, but by its nature Cloudify is completely non-intrusive to the application code, so the lock in is much less risky for you. The key is that Cloudify helps you keep your application, which is what you care about most, cloud-neutral.

imageMulti-Cloud Deployments: Another important factor is the ability to mix and match on premise and cloud environments or availability zones of the same cloud environment as part of the same application. This can help you deal with a number of important scenarios:

  • Cloud bursting: In many cases, your application average load is very different from its peak load. Take e-commerce web sites for example. For most of the year they sustain a fairly reasonable load, but for very short periods such as black Friday or Cyber Monday, their loads increase significantly. When your applications is serviced from a public cloud, you can easily accommodate by spinning up more hosts (assuming your application is scalable enough of course). But if you’re running in your own data center (as many e-comm sites often do) you don’t want to buy 10 times more hardware than you need on average just to be able to sustain the black Friday madness. In such cases, one of the most appealing options is to “burst” to the cloud – so you use the cloud to provision more resources when needed and have the application use them to deal with the excess load. To be able to burst to the cloud, you need a framework that can manage the application in your own data center (virtualized or not) and on public clouds.
  • Improve Quality of Service: Applications that service users globally often use content delivery networks to optimize the delivery of the application their users. But CDNs are only good for static content (images, videos, etc.). What if you could bring the entire application closer to the users? in such cases, having a platform that can manage the application on multiple zones or environments is a key enabler for this. You simply choose the availability zones and cloud providers that are closest to your users and deploy the application there. The ability of the deployment platform to isolate the application from the underlying cloud environment is what makes this possible.
  • Cross-Data-Center and Cross-Cloud High Availability: Deploying your application on multiple cloud environments, or even multiple data centers of the same same cloud environment, makes it far less sensitive to failures such as the one occurred in Amazon’s US-East data center recently. Why parts of your application maybe out of service, other parts can still be fully functional and even used to compensate for the failures of other parts and receive traffic that they serviced before the failure.

Final Words

Cloudify for Azure takes all of Cloudify’s capabilities and makes them available on Azure:

  • Enable users to easily deploy even the most complex Java apps onto Azure with zero code changes
  • Provide an enterprise-grade production environment for your Java app on Azure through continuous availability, elastic scalability, production ready management and monitoring, and fully automated deployment
  • Maximize Azure’s platform capabilities with extremely tight integration
  • Leverage GigaSpaces’ decade of experience in delivering application platforms for large-scale, mission-critical Java applications


Leave a Reply