Designing services as monolithic while keeping Microservices in sight — Part 2

It took me while to think about the surprise technical team would have given to management.

I think I have made up enough stories and can tell you now that technical team told management that they would be taking somewhere between 3–6 months to refactor the existing application suite in order to cater to the growth company is seeing, and in order to build products and integration around existing suite of service.

Why would they need much time to refactor something? I think this time, technical team can’t make this another backlog task which they can keep on postponing, in order to live up with the growth of different teams and giving them full autonomy, it’s important to separate them not only at Human resource level but also at technical level.

So what are we talking about here?

We are talking about creating suite of micro services, that will allow teams to delivery and ship products independent of each other, this is important if you are shipping to the production every few hours or days over months, in this example — Holo tech team would first de-couple order management system and warehouse system from application level to database level.

This separation will allows teams to be formed around these two domains, who will be building and scaling these two products independently, some level of integration will be there via REST Calls or via Messaging services, however form logical and physical standpoint they can operate as independent business units.

The question now arises, how could have Holu tech team avoided the 3–6 months of time to move from monolith to micro services?

Honestly, at this time I am also struggling to answer this, however, I have some points in mind that around which a case can be created —

1. Think of systems as business units from the beginning For example — I know if any of the system OMS or WMS fail, business can’t earn $$ or it would affects it bottom line.
2. Once we have an idea of business function and its users, organize code by keeping long term business goals in sight; I think we should be developing and writing applications by having some sight of where business is going and wants to go in 3–5 years, tech should not be entirely separated from business long term goals, having this clarity bring good vision to the organization of code and infrastructure in general.
3. De-coupling from the beginning? This is bit controversial because coupling brings it own merits and its not possible to maintain good separation of concern since the beginning. However, if we have answered the 1st point than it somewhat helps to think and maintain decoupling.
4. Change is inevitable — This is very true, and even after keep everything in mind, there always comes a point in growing and early age start-ups where you thinking of swapping tech stack in its entirety or you think of trying something different. This is no issue, but having some idea of long term goals of business helps in taking some strong tech decisions which bear fruits later.

I am not sure if I have done justice to the title of this article, as you might have been expecting some golden rules, I think there are no golden rules, we do what seems best at a given instance of time, however, if tech team align itself with how management perceives business then it answers most of the questions.

Let me know in comments if you think this is a good idea or should we just focus on solving short term goals with as much efficiency as possible?

15.100