Working towards microservices with a defined scope

In the work that I’ve done recently for evangelizing the principles behind our DevOps movement, it was interesting to hear the question of how microservices has anything to do with DevOps at all. It seems my blogging and marketing within the company is working as neither concept was widely known at the time I had started there and now people are getting to get the concepts well enough to know the difference.

They are very much correct in stating that microservices is an architectural concern and not something that DevOps dictates or even talks about. Even today, I am still marketing both DevOps and microservices in almost the same breath in most conversations. I have changed my messaging a to remove the confusion and put more emphasis on what each aims to resolve.

The concept of DevOps which I’ve blogged about before is essentially the application of the manufacturing principles defined in the Toyota Production System (TPS) to information technology or the software development life-cycle while removing all barriers in the three areas defined by ITIL (people, process, and technology) that affect the production of goods. In our instance, it’s a SaaS product instead of a Camry.

The usage of microservices in our particular scenario is directly related what our initiative is scoped to include and as a result of applying DevOps principles to the situation. Given that the scope of our initiative is the entire company and all products within it (including a closely held third party), the decisions need to be able to answer to what makes the most sense in tying these silo-oriented products into a suite.

You can very much implement DevOps principles with a monolithic application without the conversation of a microservices architecture ever coming up. There is a level of complexity that microservices brings with it that aren’t necessary unless you have a need to require it. Unless there is a need for it now, you aren’t gonna need it. The use of a microservices architecture comes when you are having issues with scale in certain components of an application, or you have a ton of overlapping back-end functionality which need to converge into simple, centralized services.

Each of the applications within scope of our initiative has their own concepts that overlap in areas dealing with authentication, authorization, identification, tracking corporate/business unit entities, tasks, and notifications. None of which are unique or novel in comparison to the next. Implementation details removed, they all perform the same function with relatively similar properties and workflows.

This is a great example of an inefficiency that is covered as a type of waste in the Toyota Production System as ‘overproduction’. For every product we have, and with multiple products adopted by the same customers, it equates to an overwhelming amount of data duplication to fall out of synchronization between each other, and require replication and backup. In addition to that, any requirement in the future for a new feature requires efforts to be multiplied for inclusion into each parallel implementation.

Given that DevOps dictates that we shouldn’t be duplicating our efforts, and that we need to take a stepped approach in getting our overlapping functionality centralized for certain domains, the requirement for microservices is here. We have hit that threshold for the microservices architecture given the multiplicity of data and functionality, and given that it’s in scope, it’s in the roadmap.