There has been an ever growing number of teams looking to re-architect their monolithic systems into a series of single-responsibility microservices and with good reason. Having that separation of concerns between your multiple services helps to simplify your overall system architecture. You write a series of services that take in one value and output another, ideally this would be done with no outside influence, i.e. you pass in ‘x’ and you will always get ‘y’.

I previously worked on a system that was written purely in Java, it was a monolithic application when I first joined and we slowly tried to decompose it into a series of microservices. My team and I outlined exactly how we were going to break this monolith up and identified the goals of our 5 microservices.

The Cost of Microservices

To give you some context, the monolithic application took roughly 8GB of RAM for a single instance of it to run in Production. We had somewhere between 20–30 instances per each production server and around 12 servers all running 24/7. This meant we were using roughly 1.5TB to 2.5TB of RAM for our system in production.

When designing our new system we choose to do it in a way that meant it was easy for us to spin up new instances on the fly to cope with increased demands. We looked at running our services in a container that would include the exact environment our service needed to run. This included the JVM which brought our minimum memory requirements for each individual instance of service ‘x’ to 1GB of RAM.

So the total memory profile for our 5 individual microservices would be roughly 5–6GB of RAM in total. Great, we’ve effectively saved ourselves around 2GB of RAM per instance of our application.

The Alternative

One of our microservices was a very simple RESTful API that effectively took in a file, parsed it and returned information about that file. This service was the most crucial part of our system and as such we had to try and bake in resiliency so that it would never fail. We added both an in-region load balancer and a global local balancer and spun up 4 instances in Europe, 4 instances in NA and 4 in Asia. This equated to roughly 12 GB of RAM just for basic resiliency.

Whilst this still resulted in a net loss of RAM for this particular monolith, it is not representative for every scenario. As developers we need to move away from being unilingual with Java and branch out into the likes of Go, Python, Node.JS, and so on. By being completely unilingual we are choking our resources and ultimately costing ourselves hundreds of thousands in infrastructure costs over the lifespans of our applications.

If we took our previous set of microservices and we were to consider the likes of Go for these microservices, we could cut down the memory footprint for one of these microservices from 1GB per instance of an to something like 64MB. This represents a massive saving and would allow us to achieve the same resiliency that we needed before in 756MB worth of RAM. Less than the total cost of 1 instance of our Java based microservice.

By going down the go path in this example we could be saving 11GB of RAM for just this one particular application. If we looked at the cost of Google’s Cloud Platform 1GB of RAM equates to roughly $0.01-$0.02 per hour to run. Around $87–175 per year to run, multiply this by 12 to cover the 12GB of RAM we’ll need for our 12 java instances and we are over the $1,000 mark.

The pricing model used for the napkin paper maths.

If we then start to consider the other 4 microservices we are now running at a bill of over $5,000 per year just to keep the lights on. The go equivalent would come in at roughly $500, an order of magnitude smaller.

Conclusion

This very simplistic example hopefully highlights the potential cost savings of considering other lower memory profile languages. One of the key benefits of writing a series of distinct microservices is the ability to write it in whatever language suits that particular task best. Leverage this benefit as much as possible.

It should be noted that this is just one aspect to be considered when developing your systems, others such as language familiarity and supportability will also come in to play and more often than not trump things like this. But I believe this still remains an important aspect that when scaled out to giant enterprises could help to improve resource consumption and save millions per year.