Key takeaways The container technology market is becoming crowded. Various technologies are competing for share of this emerging market

Orchestration of containers is key for successful deployment and operation of containers in production.

This article examines the various container technology platforms and tooling currently available

Several cloud vendor services allow quick adoption and elastic scalability of container deployments, with varying degrees of ‘lock-in’

We recommend that developers create the business logic of their microservices in a vendor -and platform- agnostic approach in order to be resilient to future developments within the container technology domain

I attended a great event organized by Microservices Meetup Berlin: “Orchestrating Microservices”. They invited experts from various companies (Google, Microsoft, Amazon, Mesosphere, CoreOS, DigitalOcean) to present container technologies respectively cloud services and how they orchestrate container-based microservices. This article extends the content of the event and gives an overview about many different alternatives, their differences and the potential future of container tooling. The container war has just begun!

Definition – Container Technologies and Orchestration Engines

If you do not live behind the moon you have probably heard of Docker and all the hype around it. However, we’ll begin with a short definition of two key container-based application concepts in order to establish a shared understanding:

Related Sponsored Content Kubernetes Up & Running - Download the eBook (By O'Reilly) Containers run as a group of namespaced processes within a Linux operating system, avoiding the overhead of starting and maintaining virtual machines. Key differentiators of containers compared to VMs are the packaging format and portability being created as fit for purpose for modern infrastructure, and therefore lowering footprint and startup times, and providing repeatability, better resource utilization of servers and better integration into the whole development ecosystem (such as Continuous Integration/Delivery lifecycle). See Microservices, Containers and Clout-Native Architectures” for more details.

Orchestration includes especially the following tasks: Scheduling (placement, replication / scaling, resurrection, rescheduling,, upgrades, downgrades), resource management (memory, CPU, volumes, ports, IPs, images) and service management (i.e. orchestrating several containers together using labels, groups, namespaces, load balancing, readiness checking). I quoted Mesophere for this definition.

If you are still unsure about container orchestration, please watch this fascinating 8 min video: “The Illustrated Children's Guide to Kubernetes”. This is one of the best technology videos I have ever seen! Worth watching even if you understand the concepts already.

Container Alternatives and Cloud Services for Orchestration

Plenty of container alternatives and corresponding cloud services are available on the market that orchestrate microservices (and therefore the underlying containers). Container technologies and orchestration engines are usually used closely together. Often, they are built into the same tooling. Cloud offerings, where “users pay only for the resources - such as compute instances, load balancing and scheduling capabilities - that they use” are called CaaS (Container as a Service).

The following list contains the differentiating container platform feature sets with different pros and cons. Also note that the following is – of course – not a complete list of container and orchestration offerings (but hopefully shows most of the currently relevant options):

Container Wars with Various Technologies

As you can see, there is so many different technologies, frameworks and cloud services available on the market for container packaging and orchestration. The above is not even a complete list, and there are still new ones emerging.

Therefore, the key lessons learned from this event (from developer’s perspective): Do not focus on developing code for the container under the hood. Care instead about the business logic. Implement your microservices in a vendor agnostic way.

Do not make the same fault as we all did with J2EE / Java EE where all vendors used the same standard specifications, but still offered many vendor-dependent features and “added value” in their specific “standard implementation”. Migration, i.e. deployment to another Java EE application server was a lot of efforts (re-development, testing, …); sometimes a complete re-write was easier and faster.

Docker has huge momentum today. However, there exist some doubts about what the future will bring. Several software vendors are not happy with the power of Docker Inc. as company behind Docker. For example, putting Docker Swarm Mode into the main Docker project made other orchestration vendors like Red Hat or Google unhappy, because they focus on Kubernetes as container orchestration tool. Therefore, these vendors created a new open source project “cri-o” to run containers in Kubernetes without Docker. Read the following InfoWorld article for more about the latest discussion of forking the current Docker project into an independent open source project: “New Red Hat project looks a lot like a Docker fork”.

Combining Differing Container Technologies and Tools

Note, that the discussed technologies and tools can also work together very well. Often, they are really complementary. There is not always a need for war!

For example, a Kubernetes cluster can manage pods with different container technologies such as Docker or rkt in parallel. Another example is Apache Mesos, which can manage different clusters – including plain Docker Swarm clusters, Kubernetes clusters, but also big data clusters using frameworks like Apache Hadoop or Apache Spark. Though, note that this is not a trivial configuration! Just as side note: Even Apache Hadoop will offer Docker support soon to deploy independent components such as Apache Kafka or Apache Spark in their own container instances (I saw the roadmap at Hortonwork’s roadshow last week where they presented their future Hadoop strategy).

The Future of Containers: To Standardise or Not?

Let’s see what the future brings regarding a potential Docker fork, and regarding all the discussions about standardization of container technologies. The following three options exist for next years:

Docker gets the de facto standard Different technologies spread out in parallel; maybe including a Docker fork Container technologies become (at least partly) standardized) and different technologies respectively vendors adopt the standard

Let’s hope that #3 will happen… Several initiatives and discussions are going on these days, including appc (App Container specification), CNI (Container Network Interface), CNCF (Cloud Native Computing Foundation) or OCI (Open Container Initiative. For instance, the OCI tries to standardize container image definitions. Docker, CoreOS, Google, Red Hat, Facebook, Amazon and others work together here.

Conclusion: Develop Container-Agnostic Microservices

This article discussed plenty of different fantastic container technologies, orchestration platforms and cloud services. All of them have their pros and cons. In addition, the market is evolving quickly.

The key conclusion for now: Develop the business logic of your microservices in a vendor-agnostic approach to be future-safe and have fun leveraging all the great advantages and features of microservices and container technologies in opposite to monoliths and heavyweight virtual machines. The article “Can we avoid cloud-vendor lock in?” elaborates this in more detail.

In summary, no matter if you develop your business logic within a microservice with source code (using technologies such as Java, .Net or Go) or visual coding (such as middleware technologies), you should be able to develop it once and be able to deploy it in different containers, test environments or cloud providers without re-developing it or even having to change the technology you chose before.

About the Author

Kai Wähner is Technology Evangelist and Community Director for TIBCO Software - a leading provider of integration and analytics middleware. His main area of expertise lies within the fields of Big Data, Advanced Analytics, Machine Learning, Integration, SOA, Microservices, BPM, Cloud, Internet of Things and Programming Languages such as Java EE, Groovy or Golang. He regularly write about new technologies, articles and conference talks on his blog.