There are a variety of Platform as a Service (PaaS) offerings on the market by now. Each supports more or less every modern programming language. But one thing they have all together! Each offering uses a maximum of one Infrastructure as a Service (IaaS) provider. Whether it is a proprietary or a third party. As expected, the infrastructure of AWS is still the preferred choice.
Let’s have a look on a small variety of PaaS offerings and the underlying IaaS offering.
- CloudFoundry, VMware
- cloudControl, AWS
- Google App Engine, Google
- Azure, Windows
- CodeRun, AWS
- Engine Yard, Terremark
- Elastic Beanstalk, AWS
So what is missing is an independent hosted PaaS offering. A real PaaS innovation! A kind of PaaS Broker. SteamCannon goes in this direction. However, he is 1. not an independent hosted service (there is just one AWS AMI available) and 2. only AWS EC2 is currently supported.
Of course, the service must be run on a platform. For this reason, the desire for an independent hosted service is a little bit mistakable initially. But even here, the power of the cloud must be used. The Killer PaaS must not only run as an AMI on one infrastructure, but must be distributed across multiple providers. This has already ensured its reliability.
The Killer
Why I describe this service as a Killer PaaS is easy. It must support all IaaS provider on the market and not just one, plus all popular programming languages. The functionality is quite simple in theory. As a user of the Killer PaaS I have previously registered at different IaaS providers such as AWS, Rackspace, GoGrid, etc. for an account. Alternatively, the Killer PaaS offers me to create one. The credentials for each IaaS provider are deposited, which will be accessible to the Killer PaaS. Here I already can set my primary, secondary, etc. provider. As a user I have nothing to do more.
If I would like to run my applications in the cloud, I upload the code on the killer PaaS. It is now taking care of the rest and deployed the application on my deposited infrastructures. It can either make it arbitrary, since it knows the status of the infrastructure with respect to performance, etc., or it takes the settings I previously defined and distributed the applications to the primary provider. If this is too busy on the secondary, etc.
The killer PaaS is so smart that it distributed the entire application across multiple vendors and thus ensures the best possible performance and availability. If I decided to let the application run on a primary provider and he has now performance or other problems, the Killer PaaS makes sure that more (or all) resources automatically be used from another provider. I know cases in which AWS users couldn’t run new instances in a AWS region because not enough resources were available. However, my application may not notice anything like this. If my application suddenly exposed to an enormous burden, e.g. due to a run of visitors, and the IaaS provider also has a resource bottleneck, the Killer PaaS makes sure that available resources from another IaaS providers will be applied, or other measures are taken.
With such a Killer PaaS even many questions can be answered with respect to SLAs. The reliability and availability of the application here is ensured by the Killer PaaS. Since it is also run over several IaaS provider in the cloud, its availability is also ensured.
So what is needed is an independent Cloud Management Platform such as enstratus, just for PaaS.
