Myths around containers. Part 2: Portability

Is it true that after so many years we finally have real, portable format for all applications? It seems that we’ve come very close to that goal and it’s time to find out more about portability that comes with container revolution.

In the first part , I was focusing on containers security. Now let’s take a look at portability.

Previous attempts

This is another attempt to create an abstraction layer for delivering applications on different platforms - besides unsuccessful format for virtual machines (anyone using OVF format?) there is Java which was supposed to be multi-platform also when it comes to delivering packages. But you can’t run java app without: properly configured OS (dozens Linux distributions, even multiple windows, different architectures), application servers (some apps were written in a way that they just can’t run without), JVM itself and whole bunch of tools around them (logging, cron schedules, connections to external services). In other words - we haven’t got real portability that could satisfy most of applications created nowadays. Until now.

Myth: There is one common format for apps running in containers

It’s one of the biggest success of container revolution - this common format created, respected and implemented by all vendors and projects. It is pretty well documented as standardized (OCI Image format) and accompanied by runtime standard (OCI standard). Thanks to Docker Inc. and all the guys involved we don’t have a different format for images itself, but still have many implementations of runtime like rkt and dominant docker engine. The layered concept is the best thing that comes with container revolution - it enables fast deployments, shared responsibility with continuous improvement and it’s just utterly brilliant in its simplicity!

Truth:

It’s true - we have one single format for containers.

Myth: With one format it’s easy to migrate apps to containers

Now that we have this “holy grail”, a common format we should start creating all new applications and migrate existing to containers. I’m a proponent of the former approach, but a skeptic in the latter. Containers are very different from standard/legacy applications in many ways i.e.:

• containers are ephemeral - they might appear and be destroyed without any notice
• configuration is done differently - you cannot do quick fixes on working environment since it’s ephemeral
• proper building and delivery process is different (harder) - it’s not that easy in distributed, often multi-tenant environments

To put it simply - it’s just very different and requires all teams (dev, qa, ops) to learn new, cloud-native way and mindset. On the other hand, modern apps can be migrated with a little effort and leverage all these fancy benefits. I wouldn’t go “all-in” however with all apps in your organization.

Truth:

Migrations are easier for new apps, but still require change many of the processes around development and deployment.

Myth: Applications for Linux and Windows can share a common platform

If you believe that containers were born to join two worlds of Linux and Windows I might have bad news for you - they are not (yet). It is quite hard to have a common format for Windows and Linux containers - even official OCI spec distinguish them. So we have two formats and two worlds, for Linux and Windows. And let me remind you that modern containers were born on Linux and based on its kernel features and Microsoft tries only to catch up after many years believing they could convince community to their Windows-only world. They’re doing an excellent job with that by providing the following:

• bash in Windows 10
• SQL server running on Linux
• .NET core platform for Linux
• SSH (sic!) server on Windows

and many more. It’s not that easy however and we see it by lack of good support in Kubernetes (it’s being developed) and of course, it still requires Windows machines which are from different world when it comes to management, speed and coolness factor :-)

Truth:

Currently, containers run mostly linux-based apps and we still need to wait for better windows support

Myth: With an app embedded in container you can easily run it anywhere

So you’ve put your application in a container image and want to run it to bring value to users. Currently, the following options are the most popular:

• run it as plain container on your systems without any orchestrators
• run it on AWS ECS, Docker Swarm, Mesos/Marathon
• run it on Kubernetes

Of course, the last one is probably the best choice, as Kubernetes is the leader (you can find out more why in my article) among container orchestrators. If you chose the other one you probably think of migrating. In theory, that should be easy, but as Kubernetes grows so does a number of features requiring sometimes complex configurations (mostly done with lengthy yaml files). It’s however justified by a long list of abstraction layers for things like networking (SDN plugins, ingress controllers), storage layers (plugins, pv with pvc), own set of standards (CNI for networking, CRI for runtime) which proves that Kubernetes is strongly independent from hardware platforms. What’s more, you will also need to adjust container images definition to meet some specific requirements. For example, on OpenShift you cannot launch container running as user root and there are some few differences when handling deployments (use of own implementation with DeploymentConfig object). Fortunately by using image layers, it’s easier, but still it’s a forced requirement of particular platform. I suspect that there will be more differences on many Kubernetes distributions, especially the ones available on biggest cloud platforms. Otherwise, it would be very easy to migrate your whole system between them in a matter of minutes and that just looks too good to be true.

Truth:

Different container orchestrators need configurations in proper, often quite complex format and even specifically prepared images.

Conclusion

In my opinion, common format for a container is a huge win for whole IT world striving to survive the battle between big companies trying to prepare more vendor lock-in traps. Windows containers are still a niche, but if Microsoft will continue to push features and follow conventions born in Linux world then we’ll have a single format for almost all applications. There’s a fly in the ointment - it’s container orchestrators features. Let’s keep our finger crossed to see how future distributions of Kubernetes will differ from each other requiring rebuilding of images.

Third part is going to be about speed - are containers really that fast? How quick can you deploy, scale and speed up whole development process? Soon I’ll bust some myths around those questions.