We begin 2014 with a new set of challenges for the project, and one of the crucial aspects of the CELAR journey is investigating the important factors regrding resource elasticity. We have been focusing our attention in particular recently on the pertinent factors concerning resource elasticity frameworks. In our latest blog, we explore aspects including vendor lock-in and functionality limitations as well as looking at some of the choices currently available.
Cloud elasticity, i.e., the ability to scale up or down available resources according to observed demand, is a crucial requirement of today’s applications. This is more important in applications running on the cloud: the “pay as you go” nature (an example of which would be Flexiant’s granular metering offering), where resources are charged only for the time they are used, along with the existence of convenient methods for resource (de)commissioning through APIs render elasticity as a primary requirement for today’s applications.
Automatic resource scaling is employed in typical PaaS offerings such as Google’s AppEngine, Microsoft’s Azure, Heroku, CloudBees, and Engine Yard : Application providers utilize computational and storage resources without worrying about performance. When the workload is increased, these engines employ more resources to satisfy increasing demand. Nevertheless, all the aforementioned systems have the same drawbacks: first of all, the provided environment is completely sandboxed where users can interact only with the provided API. In favor of simplicity and easy deployment, everything “under” the provided API is hidden, and users cannot interact neither with the underlying infrastructure, nor with the way this infrastructure scales up or down. Second, only specific two-tier web serving applications are supported: users cannot deploy their own applications that may have a more complex topology.
To overcome these shortcomings, a set of frameworks offering elasticity at a lower level has been proposed. These frameworks allow the application provider to have access to the infrastructure level and to perform his own elastic actions and policies, according to the underlying cloud support. We give a brief overview of the current state of the art.
In the Beanstalk case, users create their code and upload it to the AWS management console, and a set of different Amazon services including Elastic Load Balancer, Auto Scaling, and Cloud Watch are being auto-configured and deployed. After the initial deployment, the user can alter the vanilla settings of these services and modify both the application’s resources and the manner in which the system will respond into sudden load changes.
In the AWS OpsWorks case, users create a number of layers that define how to configure a set of resources which are managed together, including software configuration and installation scripts. Each layer may consist of a number of application instances. Every time a new instance is initialized, the predefined configuration steps are taken automatically.
In the OpenShift case, the application is deployed into a number of RHEL Linux machines which take a “multi-tenant on the OS” approach, allowing many users to run on the same virtual machine. Auto-scaling rules such as “scale up if the number of concurrent requests exceed 90% of max concurrent requests over 1 period” or “scale down if the number of concurrent requests fall below 49.9% of max concurrent requests over 3 consecutive periods” are being utilized. Users can freely alter the infrastructure and the management/scaling rules.
The Cloud Foundry PaaS platform management system runs on Vmware’s infrastructure and utilizes its vSphere virtualization platform. The platform supports a number of runtimes and applications such as Java, Ruby, Node.Js, MySql, Redis, etc and the management follows the same concept: the application is deployed utilizing an initial pool of resources, along with some basic scaling decisions, and the user later can alter both the resource size and the scaling manner.
The Jelastic framework supports both horizontal (i.e., add or remove more nodes) and vertical (i.e., increase the CPU power or available memory of a single machine) elasticity. Resources are measured in “cloudlets”, which are roughly equivalent to 128MB RAM and 200Mhz core.
We notice that there exists a plethora of available tools for elastic resource allocation. Each application provider needs to carefully study each framework’s offerings and support, before making its choice. In some cases, simple PaaS offerings can be sufficient, but in many cases a more flexible approach is required. In that cases, users need to be very careful not to make a bad choice that may lead, for instance, to a vendor lock-in, or to a limited functionality.
Ioannis Konstantinou
Senior Researcher, Computing Systems Laboratory
National Technical University of Athens
Hello Ioannis, and thank you for an interesting post! This is also my first exposure to the CELAR project, and I find it very interesting, also!
In general, I find that your listing focuses very much on PaaS and PaaS-like systems (in the State of the Art listing, I would argue that only Amazon’s offerings are IaaS). When it comes to IaaS, I am frankly almost suspicious when someone makes a listing of players in this game and fails to mention the RightScale-T-shirt-wearing elephant in the room. Is the own product offering similar but inferior, or was there another reason it was omitted? Scalr, boasting that they are trusted by 7000 companies, including GM, Nokia, Oracle, and Disney, also belongs on any list of interesting autoscaling and automation frameworks. Also missing from the list are the Azure players, like the integrated scaling they now offer, the auto-scaling block (WASABi), and Paraleap offer AzureWatch. OpenStack’s next release will have auto-scaling built in, in addition to its Heat templates. And so forth — the name dropping can go on forever.
In general, it is very hard to find a solution that merely offers control over your application’s elasticity/auto-scaling: all companies on your list and the ones I mentioned offer additional functionality and integration with certain technologies, ostensibly to make management easier. Whether this claim of easier management is true or not (if you are an Ansible expert, all the Chef integration in the world won’t make your life easier), I find that any additional choices made by your vendor locks you in to that vendor.
Elastisys develops a product called elastisys:scale, which aims to fill this particular niche: it is a very unopinionated auto-scaling solution that works with whatever you throw at it. Hook it into your monitoring, tell it how to adjust your application, and it does just that. And, it does so predictively, so you don’t have to let your application suffer under unexpected load before action is taken to get it back on track. Rather, elastisys:scale ensures your application has the right amount at the right time.
I am sure that there are many offerings that could be on this list of state of the art solutions in the auto-scaling space, but the main question for someone reading this blog is, what makes CELAR stand out?
Full disclosure: I work for Elastisys AB, a company that creates auto-scaling solutions based on research performed in the Umeå University cloud research group.
Hi Lars,
Thank you for the detailed comments. This gives us the opportunity to clarify some things and present a clear picture towards what we think regarding cloud elasticity. It is true that many systems offer elasticity, but on a different level. As you correctly put it, there are many elasticity frameworks and their number constantly increases. A simple article cannot cover all the available frameworks. We did not include or exclude a specific framework on purpose. Our intent is to include frameworks that are different with each other: in other words, we tried to cover the cloud elasticity area with representative players on each category, from a pure IaaS level (i.e., BeanStalk and OpWorks) to a pure PaaS level (heroku, etc).
Openshift, Cloud Foundry and Jelastic are somehow different, and cannot be classified either as pure IaaS or PaaS offerings: for instance, Jelastic calls itself “Platform as Infrastructure”, so it is neither a true IaaS nor a true PaaS. A similar thing holds with Cloud foundry and Openshift: they both offer a PaaS-like interface, with the difference that users can alter the scaling rules, and they can deploy these services on top of an IaaS. Therefore, these systems seem like a PaaS over an IaaS with user-defined scaling policies (in contrast to Heroku, etc, where the scaling policy cannot be defined).
Regarding the IaaS level, all the tools you mention (RightScale, Scalr and AzureWatch) offer a similar functionality with BeanStalk and OpWorks when it comes to plain elasticity: they allow the user to define simple scaling policies (based, for instance, on threshold violations, etc) over a set of monitored values. Therefore, all these tools offer a “decision making” module that decides scaling actions, a “monitoring” module that collects performance metrics and an “Orchestrator” module that enforces scaling actions making sure that newly acquired resources join the application. Therefore, “elasticity-wise”, all those systems that you mention are similar to BeanStalk.
Regarding elastisys:scale, we would be happy if you could provide us with information on its internals and how it performs elastic actions.The CELAR framework is closer to the BeanStalk, etc IaaS elasticity frameworks. Now, regarding your question about what makes CELAR stand out, there are many cool features that are currently under development and will be released soon. These features enhance application description (by allowing modules to define fine-grained elasticity actions), decision making policies (by allowing users to define complex policies taking into consideration multiple criteria, or allow the decision making system to learn from its previous decisions), etc. All the aforementioned will be offered through an open-source easily installable package.
Thanks again for your comments.
Best wishes,
Ioannis.