Blog

There are many opinions as to what the right size for a microservice is. Chopping an architecture into microservices of the right size is quite important. When the size is too big, a microservice becomes too complex to be built and maintained. Since the single responsibility principle is most likely violated, it invites developers to throw even more stuff into the microservice, making it even bigger and hairier. On the other hand, when the size is too small, that increases overhead in managing and deploying microservices. Also, it may result in performance issues, since the number of interprocess calls between small microservices may increase.

No strict rules exist when it comes to building microservices. And because microservices are fairly small, rules are not as important as in, say, monolithic systems. If something doesn't look quite right, you can always come back later and reimplement it within a matter of days. However, when dealing with a large enterprise system with tens or even hundreds of microservices, structure and consistency become very much appreciated.

When microservices entered mainstream development, they changed the way we built complex enterprise backends. At the same time, complex enterprise frontends suffer from similar problems as their backend counterparts. Aside from these frontends being very challenging to develop and maintain, the biggest problem lies in constantly changing technologies. Backend technological stacks change every 3 to 5 years. Frontend technologies, on the other hand, require major upgrades every 6 to 12 months.