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.

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.