Memory in a microservices architecture is tricky. Gayathri Thiyagarajan is speaking at Devoxx UK about this. We asked her if you need to think about memory differently for a microservices architecture, and why.


Do you need to think about memory differently for microservices?

Microservices have many aspects such as operational complexity. So identifying boundaries to distributed computing presents challenges that need attention. Traditionally, when working on monoliths we all must have spent hours debugging memory leaks and going through heap dumps and leak suspect reports. This has not changed with a microservices architecture. It is important to realise that microservices are neither a Silver Bullet nor a Golden Hammer (to borrow from Sam Newman). In my talk, we will see how some of the perceived benefits of the microservices architecture can be quickly lost if we overlook this important factor.

How is memory management different with microservices?

Microservices are famously self-contained, independently deployable units of code. It is one of the appealing factors about microservices. Their size enables a developer to work on a single service without needing to understand the entire application. However, this is not always a blessing. We need information in terms of resource utilization and optimisation at the application level. To get this big picture in a microservices environment is challenging at best. At worst, it is impossible. Special attention is needed in individually tailoring the memory we allocate for these services.

What are the most important factors to take into consideration?

There are many factors which can impact the amount memory taken up by a microservice. Sometimes there might be genuine reasons for a microservice needing a large amount of memory. Whatever they are, it is key to grok the underlying memory model for the OS, JVM and other aspects of application. For example, when we use Spring Boot to package and run our microservice, it is possible to overlook the impact on resource utilisation that dependencies bring with it.

What are the potential pitfalls?

To quote the first of Daniel Bryant’s Seven Deadly Sins of Microservices, rushing into new technologies just because you can design microservices can quickly turn into an anti-pattern. In my talk, I am hoping to illustrate this with a project experience we went through recently.
In addition to the performance implication, there is also a cost implication to all of this. With increasing need to deploy to the cloud, now more than ever resource utilization is a key aspect which we cannot afford to overlook.


For more, see Gayathri’s talk:  They Do It With Mirrors – Java Process Memory in Microservices environment.