Microservices principles

In this article, I am going to talk about fundamental principles that we need to consider while we design microservices at scale.

1. Think about Unified and not uniform: This is the ability to create and coexist diverse solutions on shared platform.
2. Think Platform to handle diversity : enabling others to to use, configure and extend on top of a set of microservices. This principle helps us to build the platform which can perform at scale and able to build the microservices on top of the platform. For example — Think of Android OS. Android made few solutions. Android Mail (read Gmail), Google maps etc. But Android OS also supports alternate solutions too such as Yahoo mail, AOL etc.
3. Unbundle — Breaking the design of the system to many microservices which are atomic, independent and reusable. This principle recommends to unbundle the problem (why behind the why and why behind the why) to small atomic and independent units which can be reusable.
4. Design for replaceability — Ability to refactor the services with minimal impact to the rest of the system. When we build the system for the first time, we never know how the system (or the entire ecosystem) going to evolve. So the services needed to be evolvable or refactorable. Think what is going to get it right. Think about designing the interface right without having to bother about implementation. Interface is an abstraction and Implementation can still evolvable.
5. Design interoperability through specifications — Ability to connect different microservices from different actors. Microservices connect with each other using interfaces. Interfaces take an input and perform action and return output. Different actors can build microservices but all of them can still connect to each other through interoperability and solve the purpose of any business problem. Example — When you are building a house, your requirements are very personalised. Using the same components, the houses can be built differently by different actors.
6. Adapt through configurability — ability to adapt microservices across different contexts. How much of options(or components) can be configurable, without having to make any changes, across different contexts. This is one of the 12 Factor principles too :-)
7. Scalability via design — Think about scaling the system by design and not with any product. This principle recommends to design the system in such a way that it’s scalable and not to depend on any product which takes care of scaling the system. Today the microservices is being consumed by one customer (or one client). Tomorrow it can be 10 or 100s or 1000s (or millions) customers. The fundamental principle is no matter how many customers use the service, there shouldn’t be any performance impact. When each microservice is scalable, the collective microservices in the ecosystem will be scalable.
8. Build observability through telemetry — Every interaction and event should emit telemetry to sense and act. This goes to the fact that you don’t get it right for the first time and you don’t know how it’s going to be used. So having the system observable will help to fix it. It will also be helpful when we have many microservices in the ecosystem, when each service emits data, telemetry will help gather small chunks of data (that is needed).
9. Build resilience — Anticipate failure and and build failure resiliencein every microservices. Example : We go to a long drive by car. One way of thinking is — My car never breaks down or the tyre will never burst. Another way of looking at it is, if any of the tyre bursts, do i have any backup tyre. Anticipate failure (at scale) and think about how to address failure.
10. Privacy and security by design — Data minimalism and data protection should be before thought. Whenever we design microservices, one of the questions to be asked is : are all the data attributes needed? If so why? once we ask “why”, we will know the need for that attribute. In the end we will find only those attributes which are absolutely needed for the microservice. This will help us to “minimalize” the data. When we design the services within an ecosystem, we should always ask how do we ensure the microservices are secure and trustable when they are used by various other systems.
11. Adopt extreme automation — Every repeated task should and API testing should be automated. Anything that is repeatable and anything that is sustainable, that needs to be automated so that it will not be error prone. In the microservices world, automation is no more Good To Have. It’s Must To Have. It’s almost impossible to test all possible scenarios with manual testing. Automation is the only way. It helps us to give the confidence that the service doesn’t breakdown while honouring the contract.

12. Keep it simple — If you don’t need it, don’t do it. Period !! The above principles actually help us whether we need to build anything. If we need to build anything, keep it minimal and keep it simple.

If you have any questions, on this article, feel free to reach out to me through my email id : kiran.mvv@gmail.com or LinkedIn — https://www.linkedin.com/in/kiran-mushnuri-7b09a73b/

I am going to publish all the latest trends, architecture related posts going forward. Please like, subscribe so that you will receive automatic notifications as soon as i publish the articles.