Avoiding Pitfalls in Microservice Architecture
While developing complex web applications, engineers always need to plan for scaling and evolving each component of the system independently. Meanwhile they also need to make sure the final product is working as expected and easy to debug.
The main benefits of microservices include:
a) Independent evolution and versioning of services
b) Can use different technologies and frameworks under the hood
c) Easy to test individual components
d) Each service can be scaled independently
e) Service can be independently deployed, monitored and released
There is a saying “Over playing strength might become a weakness.” This also applies to architecture.
You need to watch out for following pitfalls while going forward with microservices architecture:
To avoid pitfalls which come with microservice architecture, review the following points:
Start monolithic
It’s very easy to over design and make wrong assumptions around microservices while starting the platform.
Microservices are a significant investment in terms of:
a) Procuring tools to debug microservices
b) Creating environments for testing integrated solutions
c) Procuring DevOps tools to deploy, monitor and manage services
For Walmart Search, similar to Netflix, Facebook, and Nike, etc., we started as monolithic applications which later moved to using a microservice architecture, only after having a good understanding of the business requirements and features.
Divide right
a) Services have low coupling and high cohesion
b) Services can evolve independently — there should not be requirements to upgrading services in tandem. Each service upgrade should be backward compatible.
c) Team structure support service division — ensure service ownership is in sync with team structure. Conway’s Law is on your side.
d) Make sure source of record design is in sync with microservice division. Databases are not shared between services, resulting in complex synchronization and distributed transaction issues.
Tools
• Have the right tools to deploy, test, monitor and release a microservice integrated environment.
Integration Ownership
Mostly, teams end up owning their respective services and integration winds up suffering later. Make sure there is a clear ownership of integration layer and architecture. Everyone should be clear about integration responsibilities and accountability. If you have cross-team architects or senior engineers, then making them owners of integration as well as architecture is suggested, as it has worked for us.
Performance & Scalability
a) Make sure overall latency and throughput of product services is not degrading due to integration woes.
b) Each service scales to honor overall scalability promise of the system.
c) Keep an eye on overall CPU, memory, network and disk resource consumption of the platform. Make sure, due to explosion of services, that a lot of repeated computations and data processing are not dramatically increasing resource consumption of the platform.
Technology Used
Microservices are not an excuse for bringing multiple technologies into a platform.
Each new technology or language into production requires:
1) Tools to develop
2) Testing, monitoring and deployment frameworks
3) Upgrade and maintenance of technologies and language stacks
Hence, adding new technology stacks or languages in a platform, non-linearly increases the complexity and raises maintenance cost of a system.
Look deeply into why there are more than two or three technologies or languages required in the platform to solve similar problems.
If a new technology stack is required, see whether old stacks can be retired before adding new one.
Conclusion
Microservice architecture has a lot of benefits in scaling and building a complex system. But while designing the services, I suggest keeping the points discussed in mind.
Here are few articles which can help in making right choices. Please leave a comment if I can help answer any questions you might have. Thanks for reading.
