Blogpost

Cloud native the way to go?

The 2019 edition of Devoxx was a fun one, with some great talks. For me personally the talk by Martijn Verburg ‘Cloud Native Diabolical Developer’ really stood out. He was the CEO of JClarity and is now the Principal Engineering Group Manager (Java) at Microsoft. He is very charismatic and during his session he challenges everything about cloud native.

It was a bit of a controversial talk: is cloud native really the way to go?

Before we continue, I want to point out that the rest of the Blog is the speaker’s opinion, not necessarily my own. However, I found it very interesting to look at the cloud native movement from a different perspective.

Cloud native 1

Cloud native break down

DevOps 

These days software programmers are asked to be full stack developers. In recent years programmers were not only asked to be able to write backend and frontend code, but also to be a DevOps engineer. Everybody wants full stack developers! You have to be an expert in Java, an expert in the JVM garbage collection, an expert in Docker, Kubernetes, know some shell scripting, some command line for your particular cloud vendor, package managers, some React or Angular for the frontend, some basic networking/firewalls/ports, server meshes, circuit breakers,… and the list goes on.

There are a lot of tools that DevOps engineers can utilize these days (Puppet, Terraform, Chef, …) all with their specific commands and flows. The guidelines stipulate that a DevOps engineer should be in the same team as the developers. However, in practice there are mostly DevOps teams. According to our speaker – Martijn Verburg – this is not necessarily a bad thing.
You can’t be an expert in every area, so it is good to have specialists around.

Continuous Delivery 

The reason why we have DevOps is to do continuous delivery. Instead of doing deploys manually, you now have pipelines that build your code somewhere on a server. It runs performance tests, integration tests, E2E tests, …
If all goes well, your pull request is accepted. If some tests fail, you have to fix it. If someone has pushed his code by then, you can fix merge conflicts before trying to go through the pipeline again in the hope to succeed this time.

Many teams have big monitors to follow the statuses of all the different build pipelines. However, it is very rare to see all the pipelines turn green on that big screen monitor. Sometimes teams even take a sprint to fix these broken builds, just to see them red again after a few weeks.

Cloud native 2

 

Microservices

Microservices have been the go to architecture for many new projects. But as the image illustrates, microservices very easily become tangled to one another if you are not careful. They become hard to debug, and versioning becomes very important. When performance issues arise, many fall back to sharing the same data store over multiple microservices to solve the issue. But then the isolation part of the microservice architecture doesn’t hold up anymore.

Cloud native 3

 

Containers

 

Containers are yet another layer of abstraction. We, as developers, are writing Java code, which compiles to Java byte code, which gets (if you are lucky) hot spotted to machine code. It then runs on a container, that runs in a Kubernetes pod, that pod runs on a VM somewhere. The VM runs on an operating system that actually runs on a piece of hardware. Needless to say everything gets more complicated and performance-wise it doesn’t necessarily get any better.

 

Docker and Kubernetes have each a lot of commands that you need to learn and master. For Kubernetes it is even best that you learn Helm as well. Kubernetes can do wonderful things, if you get it right. But there is a steep learning curve and there are many pitfalls (readinessprobe vs livenessprobe, rolling upgrades, …).

Cloud native 4

Conclusion

 

We used to write code that got us to the moon without all the latest tools, microservices and the Agile movement. You have to ask yourself do you really need all these tools, architecture, …? These tools and architecture make things more complex. Not all projects are Netflix or Twitter. Sometimes you just need a monolith. Build for what you need, not what you want or as he calls it Résumé Driven Development.

Michel blogpost

Michel Schevernels

Software Crafter

Michel Schevernels behaalde een Master in de Toegepaste Informatica aan de KU Leuven. Momenteel is Michel aan de slag bij Ravago in Arendonk, waar hij meewerkt aan het ontwikkelen van verschillende Java applicaties.