Software Development

Considering a microservice architecture? Read this first.


Microservices are everywhere at the moment. Everyone is or wants to do them. It almost seems like they are the only way of building modern applications (they aren’t). For some reason most of the complexities and challenges that microservice architectures bring, tend to get overlooked or ignored quite often. In this post I would like to share what you need to be aware of if you’re using microservices or considering using them for you next system architecture.

Start with a monolith

Although it might be tempting, don’t start developing your new application as a bunch of separate microservices. The main benefits of starting with a simple, monolithic design are that your application will be easier to develop, test, deploy and maintain. All these translate into shorter time to production and bringing value to your customer sooner. Later on, if you see that it’s absolutely necessary, you can start refactoring the code and moving some functionality to external services. Microservice architectures are an optimization technique, and like any other optimization technique in system development, you’ll want to avoid doing it prematurely.

They don’t have to be micro

One of the most disturbing things I’ve seen is teams splitting otherwise simple and small applications into multiple tiny services. Requests to the service that could have been straightforward and efficient, now involve calling a bunch of services, combining their responses, using queues for communication between services, and so on…

One of the biggest misconceptions regarding microservices is that they are supposed to be extremely small and that they should do one thing and one thing only. Besides the fact that it’s hard to objectively quantify what small and one thing only are, any non-trivial application or service will do more than one thing, and that’s fine. That doesn’t mean that it needs to be split into several services or otherwise it will be a monolith. Instead of focusing on the size of your service or application, think about whether splitting it into multiple services will give you concrete benefits.

Don’t get too attached

Sometimes you’ll realize that some of your microservices are not actually necessary. Maybe you made the wrong assumptions when you decided to create them or maybe the requirements have changed. This is especially true if you have started with a microservice architecture instead of a monolith. In this case, my advice is not to get too attached to the services and the code that you wrote. If it’s not necessary or there are other, more efficient, ways to do it, get rid of it. Remember that when it comes to code, less is more. Less code means less to maintain, less to test and less to go wrong.

Take into account performance and resiliency

Splitting your applications into several microservices has a big impact on both performance and resiliency, which shouldn’t be overlooked. External, over-the-network requests are orders of magnitude slower than local calls. With every call you make to an external microservice, you’re adding extra latency to the request. Similarly, the more external services your application depends on, the more likely it is that something will go wrong with your application. What happens if any of the services your application depends on is unavailable? Does that mean that your application will be unavailable too? Or maybe you can just degrade some of the functionality?

Partial failure, consistency and network latency must be taken into account when dealing with distributed systems. Consider using a library like Hystrix for preventing cascading failures and making your application more resilient.

Beware of the false sense of progress

If you start with a microservice architecture from the beginning, there will be a lot of overhead work you’ll need to do. You’ll need to work on service discovery, communication protocols between services and work on the integration between services. You’ll need to set-up different projects, databases and dependencies for each service. You’ll need integration tests between services. You might even decide to learn a new microservice framework… Bottom line is that using microservices demands extra work in terms of development, testing and devops.

Remember that none of the above brings real value to your customers. Customers don’t care about how your application works internally, whether it has one or dozens of internal services or if it’s using the latest microservice framework or not. Instead of doing a lot of upfront work on internal infrastructure, try to get started with working on what you application is really about, in what brings value to your customers, as early as you can.

Conclusion

Are microservices bad? No. Whether they are the right choice or not depends on the circumstances. While they may help in some situations, they also bring a whole lot of challenges and difficulties that you need to be aware of. In many cases, especially for new projects, the benefits of a microservice architecture won’t outweigh the pains and difficulties they bring. Just like with anything, focus on your project’s particular needs, use common sense and remember that there are no silver bullets.

Tutorials
Better Testing of Microservices Using Consumer-Driven Contracts in Node.js
System Architecture
Integration Patterns for Microservices Architectures: The good, the bad and the ugly
Software Engineering
Building a Serverless Mesh Processing Microservice in Node.js
There are currently no comments.