Many organizations have started to break up a portion of their monolith applications and systems, transitioning to sets of smaller, interconnected microservices.
A recent survey by TechRepublic, found that organizations who used microservices were reaping clear benefits: 69% were experiencing faster deployment of services, 61% had greater flexibility to respond to changing conditions, and 56% benefited more from rapidly scaling up new features into large applications.
But when are microservice architectures the best option? When can they offer the most value to an enterprise? And how do they fit in the enterprise architect’s toolbox?
The Benefits of Microservices
Consider a car production assembly line, where task specialization has been introduced to manufacture each part. Individual tasks become more efficient due to dedicated resources, operations, and labor. These newly generated efficiencies drive greater productivity and output, benefiting the overall process.
Similarly, in microservices, or microservice architectures, separate modules are responsible for building and maintaining different components of the end-product. Individual units can be modified and scaled without disrupting the other parts. In contrast, implementing changes to a single, large “monolith” module, can be difficult to manage and can quickly become complicated.
Microservice vs. Monolith Architectures
The O’Reilly Microservices Adoption in 2020 report found that “77% of respondents have adopted microservices, with 92% experiencing success with microservices.”
While the advantages of microservice architectures are plentiful, there are also tradeoffs to consider when comparing to monoliths.
In short, microservices still need to be “architected”:
◉ Communication between separate services is more complex. As large applications can contain dozens of services, managing the interactions between modules securely can add extra challenges.
◉ While microservices allow for different programming languages to be used, the deployment and service discovery process is more complicated. A broader knowledge is needed to understand an application’s full scope.
◉ More services equal more resources. For the car manufacturing example above, each task station requires individual tools, workers, and processes. Likewise, a single service may call for a dedicated database, server, and APIs.
How and when to Migrate a Monolith to a Microservices Architecture
When deciding if a microservice architecture is the right option, enterprise architects need to consider their organization’s goals and concerns.
As it’s uncommon for new architectures to be built from the ground up, a migration from one state to another is the most likely scenario. This transition begs the questions: What does the current architecture allow? What does it limit? What are we trying to achieve?
Sam Newman, author of Building Microservices: Designing Fine-Grained Systems, suggests starting with Domain-driven design or DDD. This modeling exercise enables an organization to “figure out what is happening inside the monolith and to determine the units of work from a business-domain point of view”.
Considerations when Building a Microservice Architecture
Once an enterprise architecture practice has settled on migrating from one architecture to another, the team can ensure the process is heading in the right direction by:
◉ Determining the level of modelling detail;
◉ Deciding on the applied properties, and;
◉ Setting appropriate KPIs.
The Process of Mapping Microservices
Posts
0 comments:
Post a Comment