It was very challenging three days at Devoxx in Krakow in terms learning, so many things in three days… it was almost impossible to ingest all this knowledge. Looking back on all the talks I can tell that there were couple of topics that were touched/discussed very often:

1. Functional programming
2. Microservices
3. Containers
4. Soft skills talks about culture at work, coding, architecture of code etc.

Functional programming

Functional programming becomes more and more popular, but why? Is not something new, I remember learning Haskell at university a long time ago, it was part of the theory to learn, but nothing else. OK Haskell is so pure functional programming, that it is useless in terms of writing production code, but the techniques were available e.g in Java Script or Python for quite long time, so why functional programming and why now? I’m not sure, but I think if people are using it, then there is a value, and I captured at least the following:

1. lazy evaluations - can foster better performance and robustness
2. lambdas - can reduces boilerplate,
3. monats - chaining functions - e.g. helps to solve so called ‘callback hell’

All of this helps to solve problems easily than in pure object oriented programming world.

Microservices

Microservices also become more and more popular as an alternative to monolith architecture. It is nice concept of putting subsystems into separate processes with e.g. REST API, so they can communicate with each other and do the job. In other words, you have to decompose your system into small manageable isolated pieces encapsulated in a process, and processes have to communicate with each other using APIs. The value in this architecture is scalability. In many cases, when designing a product, it’s hard to predict in first place which part of software become a bottleneck in a future. This architecture gives kind of confidence, that when you need to increase a performance of some particular part of your application, you simply multiply the appropriate microservice. So the scalability is something relatively easy to achieve. There are also other, not so obvious at first glance benefits:

1. integration testing is pretty straight forward, because all you need to check is whether or not your REST API is working as expected,
2. refactoring of an product as a whole is much more simpler,
3. and probably more…

It looks that such architecture is more agile, but there is a drawback - of course as always, because there is no Silver Bullet architecture. There is a price you have to pay. You have to invest in automation and in infrastructure a lot. If you have 5 microservices then probably you can leave without it, but if you have more, then you must manage those, and not by hand. There are several areas to focus on, in order to make this task a little bit easier:

1. ‘who am I’ API - beyond the designed API of microservice, each and single one have to expose version, type, status etc.
2. automatic deployment
3. monitoring

Indeed there is some overhead of work you have to do in comparison to monolith architecture. It’s clear that if you have the same functionality in one piece, it is less work with deploy, less monitoring, less versioning, less things to manage, less maintenance and easier debugging.

One way or the other, there is something in this architecture I must admit, but as always there are two sides of the coin, be pragmatic and choose wisely: if this architecture make sense for your case, then let it be, but do not choose it just because it’s trendy.

Containers

The container term pops up recently with a Docker, and because the ‘lightweight VMs’ are bringing so much value, containers focuses an attention of the world. It was quite surprising for me to learn that the concept of lightweight virtual machine is quite old. Google is being doing this for long time. The tools to manipulate environment of a process eg. to assign certain amount of CPU, memory or create dedicated filesystem, were in Linux long before Docker was born. The problem was that those were separate tools, which had to be configured differently to create a container. What Docker did was they put all the pieces together, simplify things, and now you can achieve the same with one command, sweet! But since Google is being doing this for such long time, they decided to share the lessons learned and introduced Kubernetes. It’s a system to manage containerized applications across multiple hosts in a cluster. It handles deployment of containerized/microservice-based applications, and so far it supports Docker and Rocket. One thing I noticed is that Google proposes to change the mindset of seeing the container. You have to stop thinking of a container in terms of virtual machine, instead, expect that container can die (and that’s normal thing) simply run another one. Summing up, Google noticed that Docker is missing the software to manage the containers’ ecosystem and they decided to address the gap by Kubernetes - it is very easy, powerful and has a potential.