The Battle Of The Clouds

They come in many flavors, all which claim to be a “cloud” provider. But really, what is the cloud? Is it to host everything on a Linux server like yesterday, but virtual? What is a virtual server? What benefits does it give me to put the world virtual in front? That depends.

Virtual Private Server, VPS

This is what is easiest to grasp when coming from hosting and managing your own server. It has a configured harddrive, some amount of RAM and a CPU. You usually manage it the same way as you would have done with a traditional dedicated server, the difference is that the cloud provider can squeeze more customers into the same hardware. This makes it possible to get a cheap VPS, which has the same capabilities as a dedicated server.
The features after that really depends on what provider it is. Some might let you add and delete virtual hard drives or change the amount of RAM and CPU allocated within the actual hardware it is running on. Some use it as a way to hide the fact that you’re really not getting all that CPU but share it with other customers behind the scenes.

Infrastructure as a service, IaaS

Now it gets a little bit more interesting. Here we’re not only virtualizing the server but we’re also doing virtual networks and interfaces, adding metadata services to do introspection about ourselves and the environment we run in, creating groups of multiple servers (now called instances) that often collaborate and scale together in a dynamic fashion, often with a load balancer in front. This is also accompanied by APIs that can be used to control all this, making for a great opportunity to automate. But similar to using a single VPS; we’re still focusing on building a network of computers, the infrastructure. Not on what will run on them.
A great example of IaaS is Google Compute Engine

Containers as a service, CaaS

As a fairly new concept, CaaS falls somewhere in between IaaS and PaaS (see below). Here we’re starting to abstract away the details of the infrastructure. We’re now thinking more in terms of services and application configuration, neatly packaged into containers. We think less of any particular server instance that might currently be running it, instances come and go (sometimes whole groups of them) come and go in any given moment, while services stay.
See Google Container Engine for more information about automated container management.

Platform as a service, PaaS

Here we have almost stopped caring about what runs our service, we can spend all our attention on the core parts of our business logic we’re trying to develop. All details of distributed logging, HTTPS load balancing, auto scaling depending on load etc is already solved for us.
This level of abstraction is great for getting a scalable product out the window quickly and to not have to worry about the operational tasks. It usually have a steeper price tag than the lower levels explained above, but we also have to take into account all the time that is saved. It’s not uncommon to have to put At least 50% of the time into operations tasks when managing the full stack by yourself.
You can try App Engine for this type of platform.

Software as a service, SaaS

This includes fully managed products such as monitoring and debugging dashboards, authentication solutions, invoicing services and analytics. We can benefit from these services instead of having to host and develop all of it from scratch or hosting it ourselves. We can keep to our core business domain instead, it’s the ultimate time saver but it also brings the highest cost in form of usage fees and subscriptions.
See for example Stackdriver on how to outsource the monitoring of your services.

Conclusion

There are many levels of abstraction to choose from, and many more abbreviations than explained here. What a cloud provider offers can vary greatly, so can the implementation details behind them. But in general when selecting what solution to build on, take into account what stage the development is in, the complexity of the problem and experience of the developers. Try to focus on the problem at hand and benefit from existing solutions as much as possible.
As an example, I like to start with building on App Engine, moving parts to Container Engine when more flexibility is required and finally leverage the ultimate flexibilty from Compute Engine for any remaining requirements or optimization tasks.

I believe a common misconception when moving to the cloud is to try and solve the same problems of yesterday in the new environment, instead of making it cloud aware. Take the traditional Wordpress service as an example, it’s easy to start thinking about a need to share the disk volume between many instances. Or that PHP sessions requires a sticky route on the load balancer. This type of setup is not built with a dynamic cloud or distributed service in mind.

The state does not necessarily have to be shared directly by using the disk volume. We could use a separate database (possibly managed by the provider) for saving blog entries, object storage for uploaded media and memcache for sessions. Now we’re only left with the rendering of the pages or the “Wordpress API”, which is much easier to scale and does not rely on its local disk for sharing state or the complexity of synchronizing this volume between multiple instances. We could take it even further and move the sessions and rendering up to the client, only fetching the actual content from an exposed API. But that’s a different blog post.

You can try all of these different solutions for free with the USD $300 trial at Google Cloud, happy hacking!