Earlier in this blog series we described how every strategy comprises a goal and the actions we take or tools we use to accomplish it. We’re now going to consider some of the tools that Cloud Native uses, including container packaging, dynamic management, and a microservices-oriented architecture.
In this post we’ll consider container packaging - what it is and the effect it has. But first, let’s take a big step back. What the heck are we running on?
Before we start talking about software and tools, a good question is where is all this stuff running? Does Cloud Native have to be in the cloud? I.e. does a Cloud Native strategy have to use infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) with the physical machines owned and managed by a supplier like Microsoft, Google or AWS? Or could we build our own servers and infrastructure?
We’d argue that Cloud Native strategies generally exploit the risk-reduction advantages of IaaS or PaaS:
These advantages can potentially be duplicated by a large organisation in their own data centers - Google, Facebook and others have done so. However, it is difficult, distracting, time consuming and costly and therefore a risky process. For many Enterprises it is more efficient to buy these IaaS/PaaS advantages off-the-shelf from a cloud provider. Fundamentally, if you have a tech team who are smart enough to build a private cloud as well as Google or AWS then is that the best way for your business to use them?
Cloud Native systems don’t have to run in the cloud but Cloud Native does have tough prerequisites that are already met by many cloud providers, increasingly commoditized, and difficult to build internally. To be honest, I’d probably use the cloud unless I was Facebook.
In the current Cloud Native vision, applications are supplied, deployed and run in something called a “container”. A container is just the word we use to describe wrapping up all the processes and libraries we need to run a particular application into a single package and putting an interface on it to help move it around. The original and most popular tool for creating these containerised applications was Docker.
Containers are so hot because containerisation accomplished three incredibly sensible things:
Together, these 3 revolutionary innovations have changed our assumptions about how data centers can be operated and about how rapidly new applications can be deployed. Hurray!
Now that these concepts of standardised application packaging, isolation and control are out there we’re already seeing alternative approaches being developed that provide some of the same functionality. For example
In addition, other container types to Docker exist and even more ways to achieve the benefits of containers will undoubtedly be developed. However, what’s important is understanding the advantages of common packaging, control interfaces, and application isolation even if in 5 years we end up using something other than containers to provide these features.
ASIDE - to avoid confusion, although the interface for managing Docker images is consistent across all operating systems, the contents of the image are not necessarily portable. The contents of a container image are a set of executables. A Linux image will only include executables compiled to run on Linux. A Windows image will only include exes and dlls compiled to run on Windows. You therefore cannot run a Linux container image on Windows or a Windows container image on Linux any more than you can run an executable compiled for one on the other. However, once the containers are running on the right host OS you can control them all with the same format of API calls. Remember - the container engine is not an environment like Java. A container runs natively on the host so the executables must be compiled for that OS.
Before we get too carried away, there are still ways a VM is better than a container. On the downside:
In the VM’s favour, however, it is a much more mature technology with years of tooling behind it. Also, containers isolate processes but they don’t do it perfectly yet - especially for antagonistic applications. The VM’s heavyweight approach is currently more secure.
The reason everyone’s going crazy about containers is not just because they are a nice packaging format that plays well with automated deployments. Containers also provide us with lightweight application isolation and an application control API. Paired with dynamic management that can give us automation, resilience and much better resource utilisation, which is both greener and cheaper.
Read more about our work in The Cloud Native Attitude.
Photo: Banksy in New Orleans https://www.flickr.com/photos/29350288@N06/2818267461/