To microservice or not - that is the question

August 21, 2015 by Johanna

blog-frans-2

It’s time for a new blog series by our talented engineers. Today our Chief Architect Frans Ekman will tell you more about Kiosked’s approach to microservices.

The word microservices is starting to become a buzzword in software architecture. It is the current trend, which more and more software companies like Twitter, Netflix, Amazon, SoundCloud and Kiosked are following. Although the ideas are not really new, there has not been much discussion about it in the past.

Microservices are an architectural pattern to break down a larger application into smaller independently deployable modules called microservices. The main benefit is that large applications are more manageable. A microservice is like a small application running on its own servers offering an API to the main application and other microservices, so that these can use it. Usually the microservice has its own databases and other similar components.

The opposite of microservices architecture is the big monolith, where the whole application is just one huge codebase that is deployed to all servers. Modules within a monolith will not communicate over APIs, but instead use normal function calls within the same codebase. This approach is not necessarily always bad and there are plenty of companies that have made it work.

Microservices should always be deployed to logically separate servers. Although in practice they may be deployed to the same physical servers to save costs. This must be supported by the underlying infrastructure. Microservices must appear to other microservices as if they were on completely separate servers. Moving them later to their own servers is usually straightforward, as long as they are built the correct way.

One core benefit with microservices is that teams can quickly and independently fix things in a microservice and deploy it immediately when ready. Short release cycles are a huge benefit compared to the old-fashioned approach, where the team would have to wait until the next deployment of the whole monolith.

There are plenty of additional benefits as well. A smaller codebase is easier to work with, especially since tests run faster and there is obviously less complexity. Easier testing also leads to easier fault detection. A good architecture ensures fault isolation and allows each microservice to be scaled separately when traffic or the amount of data grows. Additionally, a microservice can easily be rewritten if there is a need, even in a different programming language. Finally, teams can be organized around microservices; so growing the development department becomes easier as well.

Unfortunately, microservices come with the cost of some additional implementation effort, e.g. integration testing, monitoring, and so on. Plus, some initial investment is needed to get the underlying infrastructure in place.

Another drawback is the loss of some flexibility in how the application can be developed further. Planning helps, but if the whole concept needs to change too much in an unexpected direction, it will be trickier. A typical example is when there are plenty of new use cases requiring changes to all microservices. Changing APIs requires more coordination between deployments.

Going for microservices involves some tradeoffs and not for every company is it a good tradeoff. For a startup it generally does not make sense to create too many microservices too early, since the whole business concept is likely to change a lot during the early days of the company. However, it’s worth considering if there are clear components that are somewhat independent and less likely to change.

The tradeoff with microservices is quite similar to the tradeoff between scalability and flexibility, which I wrote about in an earlier post. Startups should aim for flexibility in the beginning and once product/market fit is found, they should go all-in with the scalability. This applies to microservices as well.

Each company needs to evaluate which tradeoffs make most sense for them and how to keep things as lean as possible but still be prepared for anything, like splitting into more microservices. This applies to Kiosked as well and we have a solution, which is the topic for our next post.

KIOSKED ON TWITTER

Kiosked On Facebook