Should you build your application on microservices?

Microservices have gained popularity in recent years with the likes of Netflix, Amazon and Google relying on this architecture pattern to run their user-intensive applications.

But what are microservices?

Prior to their rise in popularity, software was built as a monolith. This means that the application consists of a single unit that runs as one process on the same hardware in the same network.

With microservices, software is generated from different processes that run independently of each other and are connected by well-defined interfaces. Each service is responsible for a small, designated task.

If you are looking to build an application based on microservices, here are some key aspects to keep in mind.

Planning

Microservices require more planning and higher overhead for interface communication. If a wrong step is taken during the design process, a lot of effort may be required later for refactoring.

A design mistake could for example lead to one service calling too many other services, making the application slower and less robust.

Robustness

In monolithic architecture, if one part of the application fails, it will cause problems for the entire application. Think of it like one player in a team getting injured and therefore having to stop the entire game.

In microservice architecture, the game can keep going by simply replacing or “fixing” the injured player. This is possible when building the application in such a way that every call between services is seen as a predetermined breaking point. This is a strategy used to combat failures of individual services. There are a few methods called resilience patterns which can be used in case the call to another service fails and the required data cannot be fetched:

• Data replication: The application uses replicated data. The drawback is that this data may be outdated.
• Retries: If there is a temporary issue, it could help to try the call again, however, it can also create more load on an already broken service.
• Circuit Breaker: The broken service is no longer called for a certain amount of time. The drawback is that calls made during this time will always fail even though the formerly broken service may already be up and running again.

Which resilience patterns are used depends on the decisions made by the software architect. Only with resilience patterns in place will the microservice architecture be highly available and robust.

Scalability

Scalability is of concern for applications which need to be able to handle high volumes of traffic. If this is a main requirement for your application, microservices are typically the better fit. They are scalable independently of each other, which is significantly more cost-effective than scaling a monolith, as you will need to scale the whole application.

Backward compatibility

Backward compatibility is usually not an issue in monoliths, as the application is always delivered as one unit.

As microservices are deployed independently, it is important to keep in mind that if one service receives an update, all other services which depend on it need to be able to work with this updated version. Alternatively, the old version can be kept running in parallel until every service that uses it has switched to the new one.

Testing

Monoliths tend to be easier to test, since the whole system can be tested as one unit. 

To test the interactions between microservices, a service needs to be tested against a mock of the service that it uses. The expected behavior of the mock should be communicated between the teams of both involved services.

Tech Stack

In monolithic architecture, there is a predetermined tech stack for the whole application.

In microservices, it is possible for each service to use a different tech stack as the interfaces are language independent. However, the more different technologies are being used, the more documentation and maintenance of dependencies needs to be done, so using a similar tech stack across all services is advised.

‍

Conclusion

In conclusion, microservices are the way to go for large, built-to-scale applications. For smaller applications, a monolith can suffice, especially considering that monoliths require less overhead and are generally easier to test.

If you are looking to build a web or mobile from scratch, it might be worth using a professionally constructed starter template from flightpack.io. Our app templates save you hundreds of hours of time and thousands of dollars on development costs by giving you pre-built code for things like server logging; email, push, and sms notifications, photo upload and storage, in-app message threads, user signup and paid subscription management, app performance monitoring, user activity profiling and more!