Microservices are the answer to the challenge of keeping up with business growth as monolithic architecture is no longer sufficient.
Microservice architecture is an approach to building an application based on the division into multiple modules. Each module has its own individual responsibilities but communicates with others to form a larger, cohesive whole. This approach allows independence in the development and freedom of choice of tools (language, framework) within each application.
In their assumptions, microservices are similar to service-oriented architecture, but with a group of features that clearly distinguish it from the standard approach.
Microservice is a small application that is dedicated to performing just one specific task. It is a small component that can be easily replaced, independently developed, and independently installed, but it is a part of a larger system. It works together with other microservices to accomplish what would otherwise be done by a standalone application.
What are the benefits of microservices?
There is no problem with scaling the application based on microservice architecture.
While monolithic applications scale hard, as it typically requires complete transformation, we can scale only the most heavily loaded part within microarchitecture. It reduces maintenance costs significantly.
Why is this approach more convenient (even though on the surface it may seem more complicated)?
- First, it’s easier to design a single microservice because it is smaller and has a well-defined interface. There is an excellent chance for "grasping" the logic within more elegant architecture.
- Secondly, microservices are characterized by high efficiency and speed of operation, even with numerous queries and processes.
- Thirdly, microservices don’t force a full-blown revamping at once, as we can change only one particular service.
What (if any) are the downsides of microservices?
Even though convenient in the long run, microservice architecture is also more complex because it is the architecture of distributed systems. It can complicate the project, including the need to select and implement communication mechanisms between processes. It is unprofitable when implementing small projects because it requires a good organization and business infrastructure.
Also, although easier in individual units, testing the entire system requires a significant expansion of integration testing, given that microservices may be unprofitable when implementing small projects.
Microservices versus SOA
SOA (Service-Oriented Architecture) consists of building large systems out of many integrated, logically divided services. In principle, this was to eliminate the main problems related to monolithic architecture.
Most SOA implementations were based on or migrated over time towards using the integration bus (Enterprise Service Bus). It was responsible for communication routing, document mapping, handling various endpoints, auditing, and security.
The idea was good, but the solution's versatility meant that the rail turned into another monolith after some time. Centralization, performance bottleneck, and a single point of failure contributed to the growing criticism of the solution.
The microservice architecture is a de facto implementation of the SOA style and is based on the conclusions drawn while using this model. The way of communication, however, has changed significantly.
The solution's core is no longer an omnipotent rail, but a point-to-point information exchange intended to eliminate the bottleneck and allow the independent development of projects. Instead of a monolithic-like application, we get N independent applications developed by several separate teams.
Microservices feature elements characteristic of SOA - the application is divided into services, the individual elements of which can communicate with each other. However, the microservices architecture is also distinguished by loosely coupled services - this means that they can function even when one part of the services are unavailable. For the user, it should not result in the unavailability of the entire system.
Microservices compared to monoliths
The fundamental difference between a monolithic application and a microservice is that a monolithic application contains all the features and functions in one application and one codebase. That assumption leads to potential repercussions such as:
- any bug can potentially crash the entire system in an instant. If the system is extensive, finding the hot spot requires scanning hundreds of lines of code and could take weeks.
- centralized system does not allow many dev teams to work independently.
- it forces the use of only one technology, which often makes integration with other systems or APIs difficult.
However, a monolithic system can be a suitable solution for businesses that don't have a great need to implement changes quickly and don't have their goals set yet. It can also be a good choice if you wish the system you need to be relatively small and support only one process.
What companies have moved to microservices?
Netflix was one of the first companies to realize that a monolithic architecture doesn't work well for a complex application.
Back in 2008, when a single bug caused a massive data corruption and resulted in several days of downtime, Netflix architects decided to move the entire application from a monolithic architecture to AWS cloud-based microservices.
By splitting the application into over 700 microservices, each responsible for one functionality, engineers could make changes to any part of the system and be confident that the application would never wholly fail. It helped Netflix to minimize downtime, achieve better availability, and scale the business growth.
In fact, the same story was told many times over in different major companies. Zalando, Twitter, Amazon hit a similar wall at some point in their business growth and decided that transformation towards microservice is the best possible way to secure the future.
How do they compare to Composable Commerce?
Because they are similar - and complementary - these two terms can become confusing. Microservices are a way in which an application is or can be broken down into small functions or features. Packaged Business Capabilities - components of Composable Commerce - are an aggregated set of microservices organized around business functions.
Composable Commerce, built with PBCs, makes it easier for business teams to participate in the development and delivery of new experiences. When components are easily identifiable by their function in the business, both the business and IT can articulate how their requests and requirements feed into the application roadmap.
Microservices and Composable Commerce are both component-based and can be incorporated into your architecture in the same way, but PBCs are not limited by their size - they can bring micro- or macro capabilities. Essentially, a PBC could be an aggregation of microservices into a PBC unit to reduce complexity and fragmentation.
Summary / TL;DR
- Microservice architecture is an approach to building an application based on breaking them into multiple modules, where each module has its own responsibilities and functions.
- Particular microservices can be produced by different teams in different locations, using different tools, and technologies.
- Microservices can be unviable when implementing small projects, as they force a complex business infrastructure.
- The fundamental difference between a monolithic application and a microservice is that a monolithic application contains all features and functions in one application and one code base.
- Packaged Business Capabilities - components of Composable Commerce - are an aggregated set of microservices, grouped by features and business strategies.