What are microservices

A microservice architecture is a software architectural style in which an application or application stack is built and deployed as a collection of small, independent services which communicate among them through APIs using well-defined interfaces. Each service performs a specific business function and can be developed, deployed, and scaled independently of the others.

The microservice architecture enables an organization to deliver large and complex applications rapidly, frequently, reliably and sustainably - all qualities necessary in a competitive environment.

This approach became quite popular in the last decade and it emerged as a response to the limitations of traditional monolithic architecture, which made it difficult to build and maintain large, complex applications; the rise of cloud computing and containerization technologies such as Docker and Kubernetes further fueling their emergence.

One of the earliest adopters of this style was Netflix, in 2009, even before the term "microservices" existed, which was coined by James Lewis and Martin Fowler in a blog post describing a new architecture style deriving from the SOA based on small, independently deployable services that communicate via lightweight protocols.

Although they aren't a "silver bullet", some of the key characteristics and advantages of the microservices are:

• Independently deployable - a service that is packaged as a deployable or executable unit, and which is production-ready after isolated testing, typically requiring a well-defined specification
• Loosely coupled - the degree of interdependence between two components - a loose coupling enabling flexibility, modularity, scalability and even reusability
• Owned by a small team - enables increased ownership and accountability, stack flexibility, increased development rate, communication and collaboration
• Decentralized - there is no central point of control or coordination. Each microservice is independent and can be deployed and scaled separately from the rest of the system
• Service orientation - microservices are built around the concept of service-oriented architecture (SOA), meaning that each microservice is designed to perform a specific business function or capability.
• Polyglot: they can be built using different programming languages, frameworks, and tools. This allows developers to choose the best technology for each microservice and to update or replace a microservice without affecting the rest of the system.
• Organized around business capabilities - they support specific business functions or capabilities, rather than being organized around technical or functional boundaries.

As mostly everything in software architecture is a trade-of, this approach unfortunately comes with some disadvantages too, like:

• Infrastructure costs - as every microservice can have its own cost for test suite, deployment, hosting infrastructure and monitoring tools
• Inherent complexity - as they consist of multiple independent services that must be designed, developed separately
• Operational overhead - they require more sophisticated management and monitoring tools to ensure that each service is performing correctly and communicating with other services correctly
• Organizational overhead - the teams require and extra layer of communication and collaboration for the coordination of updates and interfaces
• Lack of standardization - as a common platform does not exist, they are prone to proliferation of languages, logging standards, and monitoring

When to migrate to a microservice architecture?

It depends on the business. But generally, the moment to consider such migration is when your organization is growing, and is facing productivity and scalability issues. Also, when facing disrupted communication between different teams might be a signal that the migration would be necessary.

In most cases you will be migrating from a pre-existing monolith which evolved over the time and hit a limit on agility, scaling, application of new technologies, and difficulty applying changes.

However, you shouldn't migrate to microservices without having a good reason. A monolithic approach has it's advantages at the beginning of a new project, when the scope is not yet sufficiently defined, and business processes just aren’t clear enough. Personally, a higher degree of maturity in both business and organizational level, and a clear definition of the domains of each microservice are fundamental prerequisites before considering such migration.

Which are the questions to be asked before?

1. Do we need to migrate? Normally, the choice to migrate to a microservice architecture is one usually made from necessity
2. Do we have the necessary tooling? The correct tooling for managing the system checks, quality, service design, privacy, security, and reliability are fundamental to the mission success
3. Do we have a strong grasp on the business domain? It is crucial to identify the bounded context of each service
4. Can we manage expectations? A large infrastructure migration requires support for multiple areas of the business, and sponsorship at executive level
5. Do we have a framework for migration? Such migration is not a simple or easy task, but having a framework for the migration process will allow for a seamless experience
6. Are we ready for a cultural shift? There’s a good chance that some teams have become entrenched in their old businesses processes

Which are the steps for migrating to microservices?

1. Understand the current system: It is essential to understand the current monolithic system, its architecture, and its dependencies
2. Identify business capabilities - Break down each capability and define individual microservices.
3. Design the microservices architecture - Design the architecture based on the identified business capabilities and define the interfaces between the microservices, the communication protocols, and the data models.
4. Develop and test - Develop and test each microservice independently of the others, using modern development practices.
5. Integration - Once all of the microservices have been developed and tested, integrate them into the larger system.
6. Refactor the codebase - Refactor to remove any dependencies that are no longer needed with the new microservices architecture.
7. Deploy and maintain - Once the microservices have been integrated into the system, deploy and maintain them using modern deployment and monitoring tools.

In summary, migrating from a monolithic architecture to a microservices-based one involves understanding the current system, identifying the business capabilities, designing the architecture, developing and testing the microservices, integrating the newly formed components, refactoring the codebase, and deploying and maintaining the code base. It is a complex process that requires careful planning and execution, but it can provide significant benefits in terms of scalability, flexibility, and agility.

Previous Post