From monolith to microservices
Legacy monolithic applications cause significant challenges during the implementation of DevOps, continuous delivery and SRE best practices. One of the biggest challenges that monoliths bring is a lack of organizational scalability. Often, hundreds of developers are working on the same codebase, causing a high risk of collaboration issues and reduced performance across the organization. Microservices architecture helps solve these problems. Small services facilitate breaking down big and risky releases into smaller ones, and allow big groups of developers to implement new features in parallel without conflicts.
Extensive expertise with large enterprises
We have been working with microservices architectures for years, helping large enterprises migrate from monoliths to microservices. To get the most benefit from migration, we often advise combining such migrations with the adoption of open source, cloud, continuous delivery, DevOps, test automation and SRE practices. After years of building microservices in various environments, we have developed a number of best practices and reusable blueprints, which we bring with us in new engagements to reduce the risk and effort of migration.
Our approach to microservices architecture
Identify candidates for early adoption
It is best to start adopting microservices architecture with the applications that can benefit the most from the new approach. These are usually either new services that businesses need to build, or replatforming candidates migrating from legacy monolithic applications. When choosing candidates for migration, we look for services that satisfy the following criteria:
- Are closely coupled with the rest of the system
- Have plans for significant changes due to functional or performance requirements
- Can take advantage of dynamic scalability and on-demand cloud resources
Choose the right size and boundaries
A microservice should solve one well-defined business task, or a single bounded context (if discussing in terms of domain-driven design). Artificially breaking business logic into many small services can therefore cause more harm than good. However, the "two pizza rule" size should also not be exceeded. Two microservices can only integrate with other services via API, messaging or ETL, and should never use data in the same database.
Invest in a management platform
While the first microservices may be built without a special platform, when the number of them exceeds five, we recommend investing in a management platform. Without it, the complexity of managing hundreds of services will become too large, and may outweigh the benefits of microservices.
Building blocks
Databases
Caches
Messaging
Middleware
API management
Feature flags management
Service mesh
Upgrade and release policies
Versioning
Authentication
Technology stack
Engagement model
When working with a new client that is beginning their journey towards a microservices architecture and the cloud, we start with a hands-on analysis of the application portfolio, the requirements for the new application development and the plan for transformation. Such analysis and consulting leads to the creation of a recommended architecture, design and implementation plan. After that, we get to implementation, typically starting with several applications which we qualify as the best candidates for transformation based on our expertise and evaluation criteria.
When working with clients who are in the middle of the migration journey, we may jump into the implementation or consulting stage depending on the need of the client. In these cases, our analysts, architects and engineers will start working with development, operations, or release engineering teams to build new microservices, or replatform existing monoliths to microservices in an Agile way.
