Sharding, loose coupling, scalability... and these are just some of the clear advantages. It's a fact: microservices-styled, container-based architecture is the (not so) new way of building modern applications! One contrasting the traditional “monolithic” approach to app development. And so, adopting the very best practices for building microservices becomes crucial for you, the microservices-based app developer, right?
And this is precisely what I'll do my best to achieve with this post:
To reveal to you the 2018 standards to adhere to and the methodology to stick to when you're building an application on a microservices-styled architecture.
So, without any further ado, here's my list of 15 best practices to consider following:
1. Set Up, Implement and Stick to a Predefined Strategy
And putting together an effective strategy comes down to:
Having your business architects collaborate closely with your software-oriented IT architects and properly assess the value of the technology implemented in your app.
2. Automate Code Building & Testing: Enhance Individual Deployment
Your microservices should be easily deployed independently! This is one of your “ultimate goals”, and should go on top of your list of best practices for building microservices!
And the way to achieve it is by automating... as much as possible:
- automate code building and code testing
- automate build and release
- automate deploy to production
With nicely designed, cloud-native microservices, wrapped in containers, that can be deployed independently, release time shortens dramatically.
And deploying your microservices, to any given environment (and I'm stressing the cloud one here) gets conveniently easier.
3. Model Your Services Around Your Business Domain
Domain-driven design, in short: DDD.
It's the business domain that should “dictate” your microservices' design. Do keep that in mind!
4. Define Each Component's Lifetime
Make sure you have everything planned out, your components' lifetime here included.
And this means answering some key questions:
- “Will one of your app's components no longer be used, at some point?”
- “Will it be replaced or closed down?”
- “With what impact on the entire infrastructure of microservices?”
5. Isolate Failure With Independent Microservices
One of the best practices for building microservices is adopting isolation of failure. In short:
Opting for independent microservices
For this, there are certain tried-and-tested design patterns and principles for basing your microservices-styled architecture on, such as:
- loose coupling
- stateless design
- circuit-breaker design pattern
- self-contained services
- asynchronous communication
- event-driven architecture
6. Consider Making Data Private to Each Microservice
Separate data storage! Making each microservice “owner” of its own data and ensuring that this data gets accessed only via APIs is crucial.
Why?
Because if not multiple services have access to the database owned by a specific service, causing unwanted coupling between them.
And the best architecture style to go with, in this respect, is the CQRS one (Command and Query Responsibility Segregation). Especially when there's data in your microservices-based app to be read by different types of users.
7. Forbid Configuration Changes Made Manually
Instead, this is the correct sequence of actions to consider when you need to apply changes to your app's configuration:
- describe each change
- then document the reason why such a configuration change is needed
- deploy it as if it would be code
8. Prevent Your Development Team From Making Production Changes
Developers in your team should “stay out” of the production environment and stick to their development environment instead! One of the very best practices for building microservices.
And the same “rule” applies the other way around, too!
9. Cross-Cutting Concerns Call for Separate Services
Just think authorization and authentication, for instance.
It's separate services that you should design for such cross-cutting concerns.
10. Design Your APIs with the Business Domain (Always) in Mind
Also, another good practice is not to integrate implementation details into the API design.
11. Get the Business Stakeholders Actively Involved in the QA Process
… and in the UAT testing!
They can perform their testing in a separate QA environment/separate test time box.
Word of caution: as already mentioned here, developers should stick to their development environment; in other words, the QA environment, as well, should be “out of their reach”!
12. Best Practices for Building Microservices: Document Everything
"Everything" components-related!
In a few words: document everything related to your app components' functionality!
People, dependencies to other projects, systems, processes, technologies here included! Do not underrate the power of rigorous documentation (or of the risks that come with the lack of it)
13. Assign One Different Team to Each Microservice
Another one of those best practices for building microservices that will future-proof your app is separating teams for different microservices:
- DevOps people (QA, Ops staff, development)
- product manager
14. Create a KPI for Each Component
A KPI that would identify whether each software part of your application is being used, how often and by whom.
And creating KPIs becomes particularly useful if your app features components depending on other components' condition. Using KPIs is an effective way for you to closely monitor them.
15. Consider Grouping Multiple Functions into Single Units
Designing cohesive services is another one of those best practices for building microservices that you should follow.
And this comes down to grouping, into single units, all the functions that need to be changed together.
The major risks you avoid by doing so? Having a lot of inter-service communications leading to hard-coupling.
The END! I'm curious now: what other best practices regarding the microservices-styled architecture would you have added to this list here?