Brave new container world – an overview

The container ecosystem changes virtualization and the way we work as software developers by providing us with new possibilities to build, distribute and run software. Docker and Kubernetes are surely the best-known technologies in this field. But a lot of other (new) tools and methods offer promising approaches to the subject as well. By now, it has become hard to keep an overview on what is out there and what serves which purpose.

ContainerConf 2019: Getting an overview on container technologies

Therefore, in mid-November, I attended the ContainerConf in Mannheim, Germany – a 4-day conference about containers, Docker, Kubernetes, and everything related to that. I learned about a lot of new and interesting concepts, tools and methodologies. In this blog post, I want to share some of my impressions with you and hopefully give you a helpful overview on the recent state of the art when it comes to container technologies.

The first thing I noticed is that the ContainerConf has a heavily interlinked sister conference: Continuous Lifecycle . It takes place at the same time and at the same location. As the name suggests, this conference is all about Build Management, DevOps, Continuous Integration, Continuous Delivery, and so forth. So the topics of both conferences definitely share a common ground. A ticket is valid for both conferences, so one more reason to attend!

Workshops: Kubernetes and Microservices

The first and the last day of the conference are workshop days. I attended one on each day and both were very helpful. “Introduction to Kubernetes” from Erkan Yanar was a pleasent hands-on workshop. Together with Erkan, we explored the basics of Kubernetes (Pods, Deployments, ConfigMaps, Ingress, etc.). We also touched some more advanced topics like Helm and Prometheus at the end. The only downside of the workshop was, that it ended when it got really interesting.

“Microservices – Architecture and Implementation with Kubernetes and Istio” was quite different because it was not a hands-on workshop. I was a bit skeptical about the format at first. I feared it would be a whole day of basically only listening to a talk. But Eberhard Wolff is a skillful teacher and the workshop was also interactive. Instead of fiddling with technical details on each participant’s laptop, we spent more time with discussions about the design of our example project. The workshop was absolutely worthwhile, and you could feel that Eberhard has a vast amount of experience.

Besides the workshops, a conference also consists of numerous exciting presentations. I attended 12 talks with a wide variety of topics. I will only give you a more detailed summary about some of them and a condensed recap about the other ones.

Keynote “Trajectory of Chaos Engineering”

What a talk! I really enjoyed it. Casey Rosenthal presented the basic idea (and need!) of Chaos Engineering and spiced it up with some insightful and funny anecdotes. “Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.” (http://principlesofchaos.org/ ). Especially in distributed microservice architectures, it is hard to test (or even understand) the system behavior as a whole. Chaos Engineering is one approach to tackle the complexity of such systems. One of the key points is that it is proactive.

Casey proposed that Chaos Engineering is no longer the new kid on the block. It is already accepted and used in many companies. In his opinion, we will see a new trend soon: After CI (Continuous Integration) and CD (Continuous Deployment) we will have CV (Continuous Verification). In my understanding, you can think of Continuous Verification as the automated repetition of chaos experiments – neat idea!

“Service Mesh – What the new infrastructure can do for Microservices” (Orig: “Service Mesh – Was die neue Infrastruktur für Microservices taugt”)

Hanna Prinz gave a very informative talk about service meshes. She started by presenting one big problem with distributed microservice architectures: Cross-cutting concerns like timeouts, routing, authorization, encryption, etc. You will need to implement/handle these in each of your microservices. This can be painful, especially if you use different technologies and programming languages in your microservices. The idea of a service mesh is to provide these features out-of-the-box for all your microservices. She then went on to explain in more detail how a service mesh can help you with observability, routing, resilience, and security.

For the demonstration part Hanna Prinz chose Istio , currently the most well-known service mesh. But in her opinion Linkerd is often good enough and much more easy to install and handle than Istio. She would only recommend Istio if its flexibility and complexity is truly needed. Hanna and her colleagues built a website that gives a quick overview about service meshes. This website also includes a comparison of the different implementations. Definitely have a look: servicemesh.es

“Infrastructure-as-Code with Pulumi: Better than all the others (like Ansible)?”

In this talk my codecentric colleague Jonas Hecht presented Pulumi , a new tool for Infrastructure-as-Code (cloud provisioning, configuration management, application deployment, …). After a general introduction of Pulumi and some live demos, he also did a thorough comparison with Ansible. One of the main differences is that Pulumi is not declarative, but procedural. This, of course, allows a great deal of flexibility! With the disadvantage that this might lead to a very diverse set of infrastructure files.

Nice Talk from my @codecentric colleague @jonashackt about infrastructure-as-code with Pulumi.

Seems like Pulumi has some nice ideas, but is not really the holy grail of IaC it claims to be.#ConLi19 #HypeDrivenDevelopment pic.twitter.com/3SjOowc12Q

— Bertram Vogel (@bertoverflow) November 13, 2019

My impression was that Jonas is not yet convinced by Pulumi in its current state. It claims to be language-agnostic, but almost all examples are JavaScript at the moment. It claims to be multi-cloud, but this seems to be mainly AWS currently. Pulumi resources in its current form are basically just “Terraform Wrappers”. And the comparison against Ansible did also not yield a clear winner. But Jonas also admitted that a lot of these points stem from the fact that Pulumi is still very young. Thus, it also does not have a big community. Jonas definitely was impressed by how quickly he could get an AWS Fargate up-and-running by Pulumi Crosswalk for AWS !

“Creating a fast Kubernetes Development Workflow”

This talk from Bastian Hofman was not so much about a fancy new methodology or concept, but more about software craftsmanship: How to use Kubernetes not only for production but also for your development workflow (and in an efficient way). My main takeaways are:

• use Helm : Helm is the package manager for Kubernetes and makes it super easy to install applications in your Kubernetes cluster
• Helm charts provides a templating mechanism and thus can also be used to configure your Kubernetes application for production, deployment, different branches without copy-pasting all your yaml-files
• helpful Kubernetes-tooling:
  • kubeval : validate Kubernetes configuration files
  • kubectx + kubens : easily switch between clusters and namespaces
  • kubectl-debug : would have loved to already know about this during the workshop. kubectl-debug will run a new container in a running pod so you can debug the other containers in that pod. This works because all containers in a pod share the same pid- and network-namespace.
  • helm lint : use this to validate your helm charts while editing them
  • K9s : this was actually not part of the talk, instead my colleague Dennis Effing showed me this wonderful piece of software. K9s is a CLI that greatly improves the interaction with Kubernetes clusters. Just install it and see for yourself!

Quick recap about the other talks

The following list summarizes what I personally found the most interesting in the remainder of the talks. It is not meant to be an exhaustive explanation, but just to give you some buzzwords or phrases to google if it sounds promising to you 😉

• “Infrastructure as Microservices – Alternatives to the monolith Kubernetes” (Orig: “Infrastructure as Microservices – Alternativen zum Monolithen Kubernetes”) (Nils Bokermann, Sandra Parsick ): Do you really need all of Kubernetes? It basically is a whole datacenter and it is complex. Why not slowly only introduce the parts that you currently require? Central configuration management? Consul . Reverse Proxy and Load Balancing? Traefik . You get the idea 🙂
  
• “Integration Tests with Containers” (Philipp Krenn ): You do not test the “real” datastore with Mocks and In-Memory-Databases. Embedded Databases (if available) and especially Testcontainers provide a much better alterative for integration tests.
• “More flow: essential Techniques for Continuous Delivery” (Orig: “Mehr Flow: Essenzielle Techniken für Continuous Delivery”) (Johannes Seitz ): Trunk-based development (when done right) is more in the spirit of Continuous Integration than feature branches. Have a second build-pipeline, that builds and tests with all your dependencies from LATEST. This might help to prevent big-bang-migrations to a newer framework-version or similar.
• “Helm – The Better Way to Deploy on Kubernetes” (Reinhard Nägele ): Helm is released in version 3 . The Tiller is gone. There is a migration guide and a migration plugin .
• “The Importance of Fun in the Workplace” (Holly Cummins ): If you look in a room and everyone is having fun, the team is productive and on time! Germans are easily impressed by jokes. Ducks make everything funnier.
• “100x Jenkins and not a bit tired” (Orig: “100 x Jenkins und kein bisschen müde”) (Frederic Gurr): Jiro is a cluster-based Jenkins infrastructure for projects hosted by the Eclipse Foundation. Jsonnet is a simple JSON-extension, that allows (among others) real comments in JSON-files!
• “Cloud Native Transformation Patterns” (Pini Reznik ): Cloud Native is not only about the infrastructure and architecture, it is also about the teams and the culture. They identified and described some common patterns of a Cloud Native transformation.
• “Tools to Build Container Images” (Martin Höfling , Patrick Harböck): There are more tools to build images than just “docker build”. Docker build has security and scalability problems. For small teams they recommend docker (still a valid choice), Buildah or BuildKit (which is already available as an experimental feature in docker via docker buildx ). For multiple teams with a provided Kubernetes-Infrastructure: Kaniko , Makisu . And for something completely different (no Dockerfile!): Bazel , Jib , Cloud Native Buildpacks .

Conclusion

I really enjoyed ContainerConf! Besides all the new input I got, the conference itself was very well organized. The venue was spacious and the catering was delicious (self-service sweets bar!). And it was also easy to get into some interesting conversations with other participants during the breaks. Thanks especially to Bastian , Jonas and Sandra for the amazing evening on Wednesday! Most importantly, the conference allowed me to take a deep dive into the container ecosystem. I now have a much better understanding how certain bits and pieces work together and what are promising technologies to look out for. I hope you could also learn something new and if you have any questions, please write a comment – I’m happy to answer them!