5 DESIGN CONSIDERATIONS WHILE BUILDING MICROSERVICES

The above was my topic at the microservices day held in Bangalore few weeks back. I thought of summarizing 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 separation 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 dependencies 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 Initialization

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 dependent 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 dependent 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?

Comments

Post a Comment

Popular posts from this blog

Agile and The Moving Train

Back into the Blogging mood after long years! The reason is simple, I did not have much to share than the mundane stuff that kept on running for the last few years. I am back because I am now beginning to implement agile development process for a large team and am discovering wonderful stuff as and when I plough through the details of the agile delivery model. There are a lot of anologies that comes to my mind and I will keep writing these as a beginner trying to unravel a new world. First is an anology that I draw to a moving train. In agile you make timeline constant but scope the welcome variable (which is exactly the opposite in Waterfall), this means how often you deliver to the outside world is constant, but what you deliver is what you play with. A moving traing has stations and their locations constant (where/when) and how many people you move across is a variable. When you start with this basic analogy, there are a lot of things you can draw and ensure various roles are unders...
Read more

The joy of the journey

The software industry in India has really taken a toll on the IT employees. There have been plenty who are talking about exhaustion , retirement and moving out of the industry after 15+ years of hard experience. These are some of the stalwarts, greats who have done well for the IT service industry. The key reason has been that they have put in long midnight hours to bring a new project, work on bring the the projects into control and just executing this cycle with different pace, complexity and size but the cycle has been the same. When you take a step back at these instances, it is very evident that the industry will very soon take the exhaustion path unless we device a mechanism to bring in the joy of the IT journey at everything we do in IT. I have found less and less people who enjoy what they do, and always have a reason why they do not like what they do. The key is 'What is the joy factor of the Indian IT industry?'. Improving this is hard both individually and collectiv...
Read more

HOW SHOULD MANAGEMENT ENGAGE DEVELOPERS?

It was in one of those meetings, a senior leaders from a large company told me, ” You know, when I was a team lead, I had such a good time interacting with the team – I knew exactly what they are working on, how they were working and how I could support them. And I knew exactly how I can make a difference in their life. Today, I have a much bigger organisation under me, but I don’t know exactly what those individual contributors are working on? and no clue on how I can make a small difference to them and hence multiply those small differences to affect change in the company.” This got me thinking. He was absolutely right, the higher you go, the less you know about the individual contributors, but you have more individual contributors under you! “The larger your ability to make a difference, the lesser visibility will you have to bring that difference. An irony of life!” But I believe, you can actually make a big difference to these individual contributors even when a large orga...
Read more