Finding the perfect balance between your needs, the risk, the effort, and the added value of the solution depends on the precise understanding of every component that constitutes your current architecture and the one to come.
Many decisions will be needed to find the perfect fit, especially when choosing to transition from a monolithic architecture to a microservices.
Setting your goals
When choosing to modernize your application (whether being a microservice of monolithic architecture), you need to establish clear and SMART goals to guide the selection of the best solution. These goals will often be related to these desired benefits: enhancement of productivity, risk reduction and mitigation, enhancement of reliability, scalability, and security, creation of better operational visibility, etc.
Finding your definition of a good application
When thinking about modernization, you should ask yourself: what is a good application? This question should be analyzed by keeping in mind the specific needs of the development team and the operations. For devs, a good app should increase productivity, which means that it should be easier and faster to develop and deploy. For ops, it should give them operational visibility to facilitate diagnostic and patching manipulations. The idea is to find a balance between these needs.
Selecting the architecture
The majority of today’s companies are using what is called a monolithic architecture for their systems, that combines the UI, the business logic, and the data access layer. Being one big system, it’s easier to diagnose a problem. It’s also safer since it doesn’t require data duplication. Unfortunately, it is a very stable form that doesn’t allow a lot of flexibility, turning every little modification into a very difficult task.
On the other hand, a microservice architecture is a set of fully independent applications with a short life cycle (which accelerates deployment) controlled by one user interface, which provides a huge variety of services while being extremely easy to update and modify. It’s also harder to diagnose problems because every separated module needs to be scanned. Since data is duplicated among the different services, the risk of security breaches is greater than those associated with a monolithic architecture.
Choosing the right approach for the right solution
First, you need to choose the approach (the method that will be used to realize the implementation of your solution). Three things must be considered when selecting the right method: the risk you are willing to take, the value you want to create, and the effort needed to achieve the transition. This step requires a lot of transparency toward your risk appetency and the current capacities of your organization. After reflecting on risks, efforts, and value, you should have the required data to select the appropriate approach: a one-shot development methodology (a.k.a. waterfall), or an incremental development methodology (a.k.a. agile).
The first one is best suited to a solution that doesn’t require the creation of a new architecture (like rehosting your services) but will deliver little to no value to your company. You could, of course, opt for the middle ground solution of re-platforming your systems, which will give you the best balance between value, risk, and effort. While it is possible to deploy a whole new platform using the waterfall approach, the risks related to the complexity of such a system and the waterfall’s natural resistance to scope and requirements changes are very high. This is why the incremental approach (born from the agile practices) is the safest (and most demanding) methodology to achieve a successful and high-value architectural transition.
In summary, when choosing your app, you will need to find the center of gravity between network, security, application team, platform, operations, DevOps, quality assurance, and release management.