bright ideas

Containers to the left of me, PaaS to the right...

Containers

|

17 Aug 2016

Containers or PaaS

... Here I am stuck in the middle with you (with apologies to Stealers Wheel).

I started thinking recently that cloud might be forking, into 1) Containers, with their ultimate portability, and 2) PaaS with its built-in vendor value. But it turns out that it’s not quite that simple.

Most of the recent discussion of cloud has been coming from the business angle, encouraging users to embrace the more sophisticated services being offered by Public Cloud providers so as to achieve value faster, and with easier on-going management.

All kinds of lock-in

SaaS and PaaS are all about rapid business value and ease of ownership, but the downside is vendor lock-in, and it’s usually true that the more business value a service provides, the more it locks you in.

At an IaaS layer it’s relatively easy to copy your VM to and from Azure and AWS should one or other provider start to annoy you for any reason. e.g. Moving an Oracle database server on Azure to an Oracle Database server on AWS.

When it comes to PaaS there is a lot more talk of lock-in, e.g. if I have data in Azure SQL Data Warehouse and I want to move to AWS RedShift, then I have quite a lot more work on my hands. However, it’s arguably not a lot more than if I wanted to move from Oracle on IaaS to Green Plum on IaaS, or if I start using Cloud vendor tools to manage my IaaS more efficiently. There’s a lock-in lurking around every corner.

SaaS takes lock-in a lot further. Anyone who has ever tried to change ERP systems can tell you that it’s a pretty significant project, yet avoiding application lock-in is not something I have ever seen buyers focus on. The focus is always on the business value over a time horizon that is unlikely to include replacement of the app.

Portability and continuous delivery

Both VMs and Containers offer portability, but Containers are more portable and a lot easier to own. You can’t use Containers as a direct substitute for every VM however, because Containers are inherently non-persistent. They’re only suitable for stateless services like app servers, web servers etc. In some cases that might even mean that an app is best deployed as a mix of Containers and VMs.

Perhaps the greatest advantage Containers have over VMs is that you never need to update or modify a running Container. There’s no more live system patching or upgrades. If you want to change something inside a Container, you update the image, and tools like Docker and AWS Elastic Container Services (ECS) will automatically deploy new Containers and squish the old ones like expendable insects.

Container images are made up of layers and are not like the monoliths that are usually associated with VMs. The ease of changing a layer, then squishing and re-spawning a container also makes them ideal for use in continuous software delivery environments.

With automatic image deployment you also avoid the old problem of having multiple VMs that are supposed to be the same but actually end up being slightly different. So Containers also make it less likely that you’d need layered tools like Puppet to manage consistency.

With the idea in my head that Containers were portable transient insects and PaaS services were high-value locked-in pets, you can see why it seemed to me at first that the Cloud was forking. But it occurred to me that if I use tools like AWS ECS to maximise the value of Containers then I’m using PaaS anyway, and then I also started to think about data…

Data

About two years ago I had a customer describe their vision of a completely non-persistent environment, and I didn’t understand Containers at the time, but what I did understand was that data needs to be persistent and consistent.

If I’m going to be nervous about any part of my infrastructure stack it will be the database, and I’m not sure I’m comfortable treating database servers like squishable insects in the same way that I can with app servers.

While it’s true that there are synchronous clustering techniques designed to make databases container-ready, it’s not a fully mature field. I’m going to look deeper into this in the future, but meanwhile it turns out that the ideal back-end for your containers is probably a PaaS database service like Azure SQL or Amazon RDS.

Bringing it all together

So how does my Container solution look now? It looks like it uses Containers, and Vendor-PaaS for orchestration and more Vendor-PaaS for making the database end of things simple, and maybe even some IaaS for other persistent components.

So like so many things, it’s not “either/or” but rather it’s “all of the above”. A place for everything and everything in its place.

But one thing I am now very clear on is that the core value of Containers is simple, automated management of many non-persistent servers, and an easy step into continuous delivery.

What are your thoughts on Containers or PaaS, or a combination of the two? Is anyone out there having any success and interested in sharing their thoughts or tips?

Jim Kelly

Author: Jim Kelly

Jim specialises in cloud consulting, defining client requirements, developing strategies and designing infrastructure solutions with a focus on cost and risk optimisation.

17 August 2016 / 0 Comments