While there is no silver bullet that solves the monolith conundrum industry pundits are increasingly advocating the Micro services architecture style. And many organizations are still viewing this as a “leap of faith” because of the lack of sufficient empirical evidence to prove that the value-addition of micro services is enough to overcome the:
- Cost of transformation
- Governance challenges of managing overhead of multiple teams working in parallel
- Operational challenges of building and managing an environment that can support hundreds of micro services
To conclude, the above challenges can be dealt with pragmatically by opting for a transitional approach such as:
- Re-factoring the application to resolve the most critical pain-points. For example, if reliability of payments transaction is the top-most problem then a solution to address the same is required rather than a big-bang adoption of micro services.
- Adopting a “semi” micro services architecture in which small, “right-grained” services are built to introduce service orientation. Some of the services may still share the same runtime and/or the same database. This approach serves as a checkpoint to ascertain which functionality is really required to be built as a truly independent micro service.