by Tony Harris • October 19, 2021
Microservices are a popular and modern organizational software engineering practice. The guiding principle of any microservices implementation is to develop an application by dividing its business components into smaller services that can be deployed and operated independently of each other. The separation of concerns between services is defined as “service boundaries.”
Service boundaries are closely tied to business requirements and organizational hierarchy boundaries. Individual services may be tied to separate teams, budgets, and roadmaps. Some examples of service boundaries may be “payment processing” and “user authentication” services. Microservices differ from legacy software development practices in which all components have been bundled together. In this article, we’ll look at five best practices for microservices and how you can leverage their value for your organization.
Sign up for our free 14 day hosted trial to learn how.
It is important to set up good architecture. This technical base will support your microservices. Think scalability, circuit breaker, service discovery from the beginning of the project, especially not one month before going into production with thousands of potential users. You always have to keep this in mind from day one.
You’re dealing with many distributed requests on the network, which is generally not very reliable. So you have to come up with a resilient design. This is a mindset that the team needs to adopt. Think about retries (several attempts, if they fail, you try again on another instance, for example), idempotent calls, and so on. Setting up retries is not as easy as explaining it, especially when the call is not idempotent. At some point, you will need to refine the configuration of retries. For example, avoid retries at the lower level if you are already retrying at the upper level, or adjust the timeout between retries at the upper level; this should be larger than the timeout at the lower level, and so on.
It is also important to test the infrastructure. For example, what happens if this microservice instance goes down? You should do some monkey testing (i.e., turn off some microservices at random). The system should react positively and still process and serve requests (in degraded mode).
If you want to break a monolithic application into a set of microservices, avoid doing it all at once; the big bang way is the best way to blow everything up. Try to group all the similar functionalities that can be included within a microservice. Make sure that all these features are well tested before you start refactoring. If the code coverage by tests is low, you should start writing tests. This will not only allow you to improve the code of the monolith, but you will also reuse this code in your future microservice.
So, to summarize, write integration tests around the code you want to extract, then you can start extracting the functionality to create a microservice. Your integration tests should still be green, but the plumbing behind them will have changed.
Start small and easy at first. Once your microservice is plugged in and working well, you can remove the duplicate code from the monolith. Doing A/B testing can also help; you can gradually reroute traffic to the new microservice and see how the system reacts.
Learn more about the key differences between microservices and monolith.
Avoid creating a microservice when a simple library is enough. You don’t want to have too much call depth (number of nested requests). If you have over three nested requests, you are probably doing nanoservices. One call implies network latency and possible failure. A library will be directly integrated without any operational overhead if a microservice has to be deployed with an API. So there is a balance between DevOps cost and monolithic complexity.
Read more on when to use Microservices architecture.
You can be more flexible on the type of data store. However, it’s an external dependency, and it should be adapted according to the needs (relational database, NoSQL, in memory, read-only access, etc.).
Keep your data stores independent; each microservice is a guardian of its data. You should never bypass this by linking a microservice to another’s data store. If you are limited to one database, this will not be a problem because you can define different schemas for each microservice to limit access.
Try to limit yourself to a common technology stack for all your microservices. Although a great advantage of microservices is building them with any language or technology, passionate developers will tend to use the latest trendy framework. In the long run, and with the inevitable turnover, the maintenance of your microservices will become painful and turn into a nightmare. Switching microservices between teams will become very difficult, if not impossible.
There are many technologies available to do microservices. You need to use something reliable, maintained, and so on. Which serialization, text, or binary? REST, Thrift, SOAP? Open-source solution or homemade? Compare the different technologies, the pros, and the cons, and use the most appropriate solution for your needs.
At the same time, this limitation should not prevent you from innovating. Don’t limit yourself to what you already use and master if you think there is a better solution on the market. Instead, try it on a new microservice (preferably not system critical) with a POC; then, if successful, you can propagate it to the whole system.
DreamFactory is a modern, easy to use, no-code auto API generation platform that is tailor made to support microservice development, making it easy to stay on top of all the microservices trends. Interested to learn more about how DreamFactory can help spearhead your adoption of microservices architecture? Start your free trial!
Microservices Trends: The Top 4 Trends That Will Shape Microservices Development In 2022
Join the DreamFactory newsletter list.