Developers mindset over microservices vs monolith development
Designing application for a greenfield has been much simpler than transforming existing monolith application. Or is it?
In my discussion with friends recently, most of us assumed microservices’ development is easier bet in greenfield. And yes, this was my easy pick straight up in last couple of greenfield applications. However, over the phases of development, as we started peeling through the different requirements and governances, often stumbled on consciously thinking microservice turning into monolith. Does this mean the service boundary defined early on in the design does not hold right? Or the service intent is not clearly defined which leads to spaghetti code at later stages? In reality, either of these could have occurred. Hopefully, my opinion provides insightful information.
Here’s list of aspects which play major role in defining the microservice scope and design. These often trigger the developer thought process of making decisions.
Understanding the Domain
Knowing the domain of your service marks the very beginning of transformation. This would encourage putting the right boundaries around the functionality and the services implementation. For example, payment processing in ecommerce works differently from payment processing in financial service. There should be well thought decision on data segregation during design with loosely coupled services provides better resiliency.
Technology Selection and Impact
First question in any development is the technology stack used for development and this is primary step towards achieving high development throughput. For any developer, it is important to understand the tools and the technology to build microservices. Organization should have a strategic plan towards build to make the most out of developed software. Which means, the organization should define the development context with development language, tool & licensing, framework. Development setup and guidelines assists in various ways, minimises the time to learn and operational cost.
Few of the basic considerations in selection process:
1. Choosing a language which simplifies coding
2. Larger support group
3. Faster builds with ease to learn
4. Simple to create libraries and binaries
5. Ingrained security assessment of libraries
These are not the only criteria but the starting point in consideration.
Deployment Model
Not just development stack but the deployment stack too plays crucial role in delivery and management of the product. Developers need to understand and be part of deployment model definition and management for seamless delivery and support. If the service development takes a week and the deployment set-up is complete traditional which requires another week to set-up to see a working software, it would not be the best environment. CI/CD needs to be baked into the development process and part of service implementation. The organization can benefit faster agile delivery with fast deployment strategies. Minimize the dependencies from first step of development to the step of making it available to customers is achieved with well thought out deployment stack. The microservices can be resilient only if the underlying process of shipping is resilient. Deployment model has these key roles to play in the world of microservices:
1. Services can be deployed independently
2. Each service should be able to scale up/down based on the requirements
3. Service environment isolation, so one service failure wouldn’t impact the rest
4. Faster deployment of services
There are multiple different ways of achieving this. There has to organization adopted deployment strategy defined for any microservices development to deliver fast results.
Security Requirements
In traditional monolith implementation, security is covered outside of the application layer as a common component. It could be user management module which defined who can access the application and what is available for any given user. When it comes to microservices, there needs to be similar security module defined which addresses the ‘who’, ‘what’ and ‘how’ of microservices. Organization should have a defined pattern for service authentication and authorization. There are few ways of implementing the same using — API gateway, OAuth or OpenID, JWT authorization and others. Developers need to have an understanding of the strategic security requirements to better finegrain it into microservices implementation.
Scope to Refactor
Delayed definition of microservice boundary is beneficial. However, the question is how much delayed. The earlier the understanding of these requirements better for the service scope. In reality, this is not always true. It is advisable to start defining the wider service boundary just to avoid tightly coupled services. So, start with as simple as, service with no shared resources or database. There is always scope to refactor once we gather most of these information.
I have to agree, refactor phase has assisted delivering better manageable, resilient system. There was an instance where two of the microservices ended up merged into a single one. And the other time where we ended up with building a gigantic microservice or should I say monolith in microservice. It turned out to be toughest refactor as this one turned into single point of failure and there was need for redefining the service boundary and scope.
Support and Ownership
Often times there are external factors which influence the way microservices evolve. One of them being the organization’s support model. For example, we can see services’ recovery being one of the core design aspect if developers have control over the way services are deployed and monitored. On contrary, there would be significant compromise in service design if developers are blinded by the way they operate in real life.
Conclusion
Organization and the team structure does play a role in making some of these decisions earlier on. As defined in Conway’s Law, application structure pretty much depends on the structure of the organization and its systems. So are the services and their boundaries. Often times this also influence developers to self doubt their design decision in due course.
Application can be split into Microservices based on integrity and maintainability within the given context. The intent of microservices is to be able to scale the application and operate with minimal dependency. As long as these primary objectives are achieved, it is advisable to start with defining services with wider boundaries.
Resources
Domain Driven Development - https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/
REST Api RMM Model- https://martinfowler.com/articles/richardsonMaturityModel.html
