5 Design Considerations while building Microservices

The above was my topic at the microservices day held in Bangalore few weeks back. I thought of summarising the discussion in this post.

The motivation for this talk was to share our experiences while migrating our platform as a set of microservices.  We implemented them using Docker containers and deployed both on Kube and ECS. So some design directions do take containers into account.

So here I go with the top 5 design considerations, in no specific order. I don't expect any of these to be new but thought of bring a few that I thought as important to think about.

Self Containment

We have been talking about seperation of concerns as a architectural pattern for a long time now. This extends the same principle in making each microservice self-contained.

Self containment can be achieved by various dimensions. The first one is around requirements - each requirement are such that a microservice can pick it up independently. The second is on teams - each team can independently take a requirement and build towards it. The above two has been in practice for sometime under the convention of agile and modular design.

However, the key thing to keep in mind is self containment with respect to deployment. Each microservice should be "deployable" independently. This helps is bringing continuous delivery opportunity to each microservice irrespective of its dependancies on other services.

Defaults

When a microservice is created as a package to deploy, in our case it was a docker image, it should carry the default configurations such that it can come up with minimal need for configuration. At the same time, allow these defaults to be "inherited" and customized at an installation level or at the tenant level. This helps each version of the microservice to come with new configuration as defaults, and the new configs are either used as defaults in the installation or is available for further configuration at deployed instance or tenant level. 

This design really helped us separate the concern of deploying images with defaults without worrying about the customization done at the target systems.

Service Initialisation

When a microservice is deployed, it needs to initialize itself with the contextual information so it comes up appropriately to the context. It needs to be aware of what are the services it is dependant on, how to discover them, how to perform handshake with these services so it can start communicating from the word go, how to test the dependant services if they are responding, identifying alternatives when the necessary services are not responding or providing information via alerts or logs any inability to perform its function.

This one design consideration itself can bring a lot of value in bringing the need for independent deployment to reality. 

Storage as a domain model - Domain Volumes

Another important need that we found as we deployed our platform as microservices was to ensure the storage mapping are done in such a way that each container gets a slice of the storage that is "necessary and sufficient" for its operation. This helps to limit the amount of data that a service has access to perform its functions. This also helps in ensuring there is enough security in place to shield the necessary services from not accessing data that it does not need to.

To bring the above need, one important design consideration is to consider the mapped volumes broken by domain model so it is easier for new microservices to come and participate in the application architecture. Wrap all configurations, meta-data and even data into what I call as "domain volumes" to make it easier to design new services.

Image as build

I have debated this multiple times earlier. I am now becoming more and more confident having lived through that. Creating images for every "good" build becomes an important consideration for you to deploy seamlessly be it for a SaaS service or even distributing for on-premise deployments. Consider moving your build process to spit-out an Image into your repository when tagged for such a thing so everyone can use these images from the work it comes out of the oven for testing, validating, and finally releasing and deploying.

Hope the above makes sense. Thoughts?