Digital Library

Microservices Patterns, Second Edition MEAP V05 (Chris Richardson) (z-library.sk, 1lib.sk, z-lib.sk)

Share E-Book
Read Without Registration

Microservices Patterns, Second Edition MEAP V05 (Chris Richardson) (z-library.sk, 1lib.sk, z-lib.sk)

Author

Cloud Native
Language English

The definitive guide microservices architecture, updated with modern patterns, approaches, and tools. Microservices Patterns has helped tens of thousands of developers build effective and stable microservices applications. In this totally revised second edition, author Chris Richardson builds on his experience helping countless organizations use microservices, delivering new insights into design, modern testing techniques, refactoring approaches, and deployment strategies to help you deliver scalable software quickly and reliably. In Microservices Patterns, Second Edition you’ll learn how to: Define the requirements for your microservices application Design a microservice architecture Test and deploy a microservices application Refactor a monolith to microservices Microservices architecture—in conjunction with Team Topologies and DevOps—has become an essential approach for developing large, complex enterprise applications using fast flow: the continuous delivery of a stream of small changes and rapid feedback on each one. This unique book collects, catalogues, and explains dozens of patterns that solve common microservices problems—from service decomposition, to inter-service communication. You’ll soon be benefiting from increased technology diversity, incremental upgrade capabilities, and no other teams stepping on your toes! about the reader Written for enterprise developers and architects familiar with standard application designs. Code examples are in Java, but the architectural principles apply across technology stacks. about the author Chris Richardson is a Java Champion, a JavaOne rock star, author of Manning’s POJOs in Action and the first edition of Microservices Patterns, and creator of the original CloudFoundry.com.

Format PDF
Size 12.7 MB
1
Views
(First 20 pages)

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

Page 1
(This page has no text content)
Page 2
MEAP Edition Manning Early Access Program Microservices Patterns, Second Edition Designing applications for fast low and high reliability Version 5 Copyright 2026 Manning Publications For more information on this and other Manning titles go to manning.com. © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 3
Welcome Thank you for purchasing the MEAP for the second edition of Microservices Patterns. This book focuses on the architecture and development of microservice-based applications. It’s written for anyone responsible for developing and delivering software—whether you’re a developer, architect, CTO, or VP of engineering. My goal is to make this material accessible regardless of your technology stack. You’ll get the most from this book if you’re already familiar with the basics of enterprise application architecture and design—concepts like three-tier architecture, web application design, relational databases, inter-process communication using REST or messaging, and basic application security. Since the first edition of Microservices Patterns was published in late 2018, I’ve had the privilege of working with countless organizations on their microservice journeys. I’ve delivered many talks and had countless conversations with teams about how to think about microservices, how to avoid common pitfalls, and how to solve the real-world challenges that arise when implementing these architectures. This second edition is a substantial update that reflects what I’ve learned over the past several years and includes new insights, and techniques for applying microservices effectively in today’s complex software environments. The second edition also has a sharper focus on fast flow — the continuous delivery of a stream of small changes and rapid feedback on each one - as the primary motivation for adopting microservices is to enable fast flow. In the first edition, I touched on this idea, but it wasn’t explicitly named. Since then, my thinking has become much more focused on the fast flow success triangle, which describes the three essential elements necessary to achieve fast flow: Team Topologies - designing your organization to support independent teams DevOps - principles and practices for delivering software rapidly, frequently, and reliably Architecture - a loosely design-time coupled, highly testable, and deployable architecture that enables Team Topologies and DevOps practices. © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 4
For some applications, a monolithic architecture is a good choice. But for larger applications developed by many teams, a microservice architecture is often the better option. Understanding the elements of the success triangle and the role of architecture is key to high-performance software delivery. The second edition also emphasizes the importance of architectural fundamentals. A solid grasp of architectural fundamentals is essential for understanding what the microservice architecture is, when to use it, and how to apply it effectively. Most notably, the book explains several important software architecture concepts, including the multi- dimensional nature of software architecture; different flavors of coupling and why loose coupling matters; and the concept of software quality attributes and how they can enable fast flow. Finally, I have significantly expanded the coverage of architectural decision-making techniques. You’ll learn how to decide between a monolithic and microservice architecture based on your specific context. I introduce the ten dark energy and dark matter forces that serve as essential criteria for evaluating and comparing candidate solutions to the many design problems you will encounter when defining a microservice architecture. You will also learn a step-by-step process for designing and evolving a microservice architecture. It’s a big book about an important topic, and I hope you find it as valuable to read as I did to write. Please don’t hesitate to share your questions, comments, or suggestions in the liveBook discussion forum. Your feedback is essential to making this the best book it can be. Thank you again for your interest and support. — Chris Richardson © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 5
brief contents PART 1: INTRODUCTION 1 Microservices: an architecture for fast ow 2 FTGO: A case study in moving from one kind of development hell to another PART 2: ARCHITECTURE FUNDAMENTALS 3 Software architecture: what is it, why does it matter and who does it? 4 The importance of loose coupling 5 Architectural requirements for fast ow 6 The monolithic architecture 7 The Microservice architecture: enabling fast sustainable ow 8 Interprocess communication in a microservice architecture PART 3: SERVICE COLLABORATION 9 Implementing system commands with sagas 10 Implementing commands with sagas 11 Implementing queries in a microservice architecture 12 External API patterns PART 4: SERVICE INTERNALS 13 Service design 14 Developing business logic with event sourcing PART 5: TESTING MICROSERVICES 15 Testing microservices: Part 1 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 6
16 Testing microservices: Part 2 PART 6: MICROSERVICES IN PRODUCTION 17 Developing production-ready services 18 Deploying microservices 19 Deploying services on Kubernetes PART 7: ADOPTING MICROSERVICES 20 Assemblage: a process for designing a microservice architecture 21 Refactoring a monolith to microservices © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 7
1 Microservices: an architecture for fast flow   This chapter covers The primary motivation for using the microservice architecture  The key characteristics of microservice architecture  The obstacles to overcome when using the microservice architecture  When and when not to use the microservice architecture  A lot has been said and written about the microservice architecture over the years. There are conflicting claims about when to use it. Some in the community say it’s the future of software development. There are others who even argue it’s an anti-pattern. The reality, as always, is it depends. But upon what? When should you use the microservice architecture? What problems does it solve and how? The main motivation for using the microservice is to solve a problem that you are most likely facing: the need to deliver software faster, more reliably and with less risk so that your business can thrive in today’s world. While you might be able to accelerate development by, as a manager once put it, buckling down (or is it up?) and burning the midnight oil, any improvements are likely to be short-lived, and you will most likely burn out. For lasting improvements, you need to change the way you develop software, and, in some cases, the architecture of the software itself. To accelerate software delivery, you must adopt a style of software delivery known as fast flow and an architecture that enables it. As you might expect, for some but not all applications, the architecture that enables fast flow is the microservice architecture. Later in this chapter, I’ll define the microservice architecture, explain its relationship with fast flow and describe its drawbacks and challenges. But let’s start by looking at fast flow and why it’s needed. 1 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 8
1.1 The need for fast flow Fast flow is a style of software delivery where IT continuously delivers a stream of small changes and rapidly receives feedback from users and the production environment on each one. The need for fast flow is driven by two trends. The first is that to succeed in today’s world, businesses need to be much more nimble. They must innovate quickly, rapidly respond to changes in the market, and continually experiment to learn what works and what doesn’t. The second trend is that modern businesses are powered by software, which is, of course, built by IT. In order to support the business’s need for agility and experimentation, IT can no longer release software infrequently. Instead, IT must release smaller changes more frequently. In this section, I’ll explain why fast flow is needed. You will learn about its benefits, which, perhaps surprisingly, include more reliable releases. I describe to achieve fast flow using a combination of the right kind of development process, organization structure, and architecture. To understand why it’s needed, let’s first look at the feedback loop that is at the heart of software development. 1.1.1 The software delivery feedback loop At the heart of software development is the feedback loop shown in figure 1.1. During development, we determine (or quite often, guess!) what features the users need, implement them making many design decisions along the way and then release those features into production. And then we get feedback from both users and the production environment. From the users, we learn how well the newly released features meet their needs. And, from production, we learn whether the myriad of design decisions that we made during development are correct. We then do more development, release features, get more feedback, and so on. 2 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 9
Figure 1.1 The feedback loop at the heart of software development. Changes flow from developers into the production and the hands of the users. Feedback that guides future development flows back from the users and production back to developers. The speed of this feedback loop determines how often you can learn from users and have your technical decisions validated. The faster the feedback loop, the more quickly you can learn what works and what doesn’t. Unfortunately, there’s a large gap between the feedback loop that’s needed and the feedback loop that most organizations have. TRADITIONAL SOFTWARE DELIVERY HAS SLOW FEEDBACK LOOPS The problem with how many organizations develop software is that the interval between releases is far too long. I have, for example, encountered application modernization projects that release the first version after a year or more of development. More capable organizations release a new version of an application every month or so. In fact, the State of DevOps 2024 report found that around 80% of respondents released changes less frequently than once a day. While some domains, such as safety-critical domains, often require a long release cycle, for a typical enterprise application, slow feedback loops are far too long. 3 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 10
MODERN SOFTWARE DEVELOPMENT REQUIRES FAST FEEDBACK The problem with such slow feedback, especially when days or weeks, is that it’s at odds with the needs of modern software development. Modern development requires feedback early and often to avoid building the wrong application the wrong way. There are two reasons why this is the case. The first reason is that today’s world - including the market within which a business competes - is volatile, uncertain, complex and ambiguous (VUCA), or to put it simply, crazy and unpredictable. It’s often unclear what features users actually need. For example, a study by Microsoft (Online Experimentation at Microsoft, http://ai. stanford. edu/~ronnyk/ ExPThinkWeek2009Public. pdf) found that only 1/3rd of features improved the product, 1/3rd had no improvement, and 1/3rd made the product worse. To handle this unpredictability, businesses must continually experiment in order to learn what works and what doesn’t. The second reason that fast feedback is essential is that the technology landscape is also constantly evolving. We often build complex applications using new and unfamiliar technologies. For example, an application modernization project could very well be the first time that an organization is using a new technology, such as the microservice architecture. If the organization is not releasing early and frequently into production, then they are not validating the design decisions that they have made. They risk repeating the same mistake throughout their architecture, or even worse, constructing a house of cards where multiple bad design decisions are built on top of each other. 1.1.2 Fast flow: continuous change and feedback In order to deliver software successfully today, we need what is known as fast flow. An organization that practices fast flow delivers changes very frequently, ideally many times a day. As a result, there’s a continuous stream of feedback flowing in the opposite direction. With fast flow, an organization is constantly learning about both the user needs and the technologies that they are using. What’s more, the organization is able to run frequent experiments to determine user needs. Later I’ll discuss the three elements - process, organization, and architecture — that are necessary to achieve fast flow. But first, I’ll briefly describe the DORA (DevOps Research and Assessment) metrics that measure software delivery performance. I’ll also discuss the evidence showing that fast flow is essential for business success. Let’s start with the DORA metrics. QUANTIFYING FAST FLOW WITH THE DORA METRICS On the surface, the definition of fast flow software delivery might appear to be fuzzy. But it’s not, thanks to work described in Accelerate by Nicole Forsgren, Jez Humble, Gene Kim (IT Revolution Press, 2018). This book defines four key DORA (DevOps Research and Assessment) metrics that measure software delivery performance: Lead time - the time it takes to go from code committed to code running in production Deployment frequency - how often you deploy changes to production 4 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 11
Change failure rate - the percentage of changes that fail in production Failed deployment recovery time - how long it takes to restore service after a failure Figure 1.2 is reproduced from the State of DevOps 2024 report. It shows the metrics for each of the four clusters of software delivery performance along with the approximate percentage of respondents in each cluster. Figure 1.2 The four clusters of software delivery performance (reproduced from the State of DevOps 2024) and the approximate percentage of respondents in each cluster. Elite performers deliver software much faster and more reliably than low performers. As you can see, elite performers deliver software much faster than others. For instance, elite performers perform 182 times as many deployments per year at low performers. They are able to learn and improve their products and services at a much faster rate. And not only that, they also deliver software much more reliably. 5 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 12
MOVE QUICKLY AND DON’T BREAK THINGS You might find the idea that software delivery can be fast and reliable surprising. After all, the traditional approach to 'quality' is to proceed slowly and carefully. But, in fact, as the State of DevOps report shows, there’s ample evidence showing that the opposite is true. Delivering smaller changes more frequently improves reliability. Elite performers have a change failure rate that’s 8 times lower than low performers. It’s about moving fast and not breaking things! FAST FLOW MEANS HAPPY DEVELOPERS What’s more, the State of DevOps report describes how developers in fast flow organizations are generally happier and more satisfied with their work. They find deployments far less painful since they occur more frequently. There are far fewer stressful deployments at midnight. Developers spend much less time firefighting and much more time building new features. The report also describes how they experience far less burnout. FAST FLOW FOR BUSINESS SUCCESS The Accelerate authors have found that if you develop software this way, your business will actually be much more successful in terms of profitability, market share and productivity. Their research consistently shows that high software delivery performance is a strong predictor of organizational performance. McKinsey have also described similar findings in their report Developer Velocity: How software excellence fuels business performance (https://www. mckinsey. com/industries/ technology- media-and- telecommunications/ our-insights/ developer- velocity- how-software- excellence- fuels- business- performance). Let’s now look at how to achieve fast flow: the fast flow success triangle. 1.1.3 The fast flow success triangle = DevOps + Team Topologies + Architecture As I’ve previously mentioned, to achieve fast flow, an organization needs a combination of three things: development process, organization and architecture. Specifically, it requires what I call the fast flow success triangle. The fast flow success triangle is a simple yet effective graphic that I developed to describe the three elements and the relationships between them. As figure 1.3 shows, those three elements are DevOps as the development process, an organization structure based on the Team topologies patterns, and an architecture with the characteristics that enable DevOps and Team Topologies. 6 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 13
Figure 1.3 Fast flow requires a combination of three elements: DevOps as the development process, an organization structured using the Team Topologies patterns, and an architecture that enables DevOps and Team Topologies. Let’s look at each element of the success triangle in more detail starting with DevOps. SUCCESS TRIANGLE PROCESS: DEVOPS The first element of the success triangle is DevOps. DevOps, as defined by DevOps handbook, Second edition by Gene Kim, Jez Humble, Patrick Debois, John Willis, and Nicole Forsgren (IT revolution press, 2021), which is the go-to resource for understanding DevOps, is a set of principles and practices for delivering software quickly and reliably. It’s not, as in the case of many organizations, a team name or a job title given to engineers who work on primarily infrastructure automation and deployments. DevOps is a way of working that the entire engineering organization must adopt. DevOps has three groups of foundational principles, which are known as the three ways: First way - fast flow of changes from development into production. Second way - the fast flow of feedback from production back into development. Third way - a culture of continual experimentation and learning. 7 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 14
The first two ways embody the fast flow concept that I introduced earlier. The third way is also an essential ingredient of high performance software delivery. The three ways describe numerous principles. There are too many to list here, but I will mention a couple of them here that are particularly relevant to fast flow. One notable first way principle is reduce batch sizes. Software development consists of a series of steps, such as requirements gathering, design, implementation, testing, and deployment. The batch size refers to the size of the work item that flows through the steps. Traditional software development has large batch sizes and infrequent releases. The key idea of DevOps is that developers must practice continuous delivery. They must frequently commit and push small changes, ideally at least once a day. Each change is tested and then deployed into production. Another notable first way principle is reduce the number of hand-offs between teams. The key idea is that hand-offs between teams introduce delays. They can also cause knowledge to be lost. We can reduce the number of handoffs through a combination of automation, platforms and tooling and adopting the ideas of Team Topologies, which I describe next. SUCCESS TRIANGLE ORGANIZATION: TEAM TOPOLOGIES The second element of the success triangle is Team Topologies, which overlaps with and complements DevOps. The go-to resource to understand Team Topologies is the book Team Topologies: Organizing Business and Technology Teams for Fast Flow By Matthew Skelton, and Manuel Pais (IT Revolution Press, 2019). Team Topologies is a set of principles and patterns for structuring an organization for fast flow. Most notably, it emphasizes small (5-9 people), long-lived teams, to reduce communication overhead and increase trust and psychological safety within each team. As figure 1.4 shows, Team Topologies defines four types of teams and three ways that they may interact. The four team types are: stream-aligned team - responsible an end-to-end stream of work that turns requirements into code running in production platform team - provides a platform, which is an artifact, such as a tool, infrastructure, or library, that makes it easier for stream-aligned teams to get work done enabling teams - consults with stream-aligned teams to enable them to learn new capabilities and overcome obstacles complicated subsystem team - helps stream-aligned teams by developing software modules that require deep mathematical or technical expertise Most of the work is done by stream-aligned teams, which embody the DevOps first way principle of minimizing hand-offs between teams. All work is done within the team, so there are no hand-offs required. Stream-aligned teams are assisted by the three other team types. 8 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 15
Figure 1.4 The four types of Team Topologies teams and the three ways that they interact. Stream aligned teams are responsible for turning requirements into code running in production. They are supported by platform, enabling, and complicated subsystem teams. Teams primarily interact via the X-aaS interaction style: consuming the work of another team "as a service". But sometimes they work together to discover new things or help each other improve their ways of working. There are three interaction styles: X-aaS interaction style - one team consumes the work, such as an API or a tool, of another team "as a service". Collaboration - two teams working together to discover new things Facilitating - one team helping another team to improve their ways of working The teams mostly work independently of each other using the X-aaS interaction style. Sometimes, however, teams might temporarily use one of the other two interaction styles. A stream aligned team might, for example, collaborate with a platform team to develop a new platform feature. Similarly, an enabling team might facilitate a stream-aligned team’s learning of the new capability by providing expertise, structured guidance, and practical support. Now that we have looked at the DevOps and Team Topologies elements of the success triangle, let’s look at the third element, which enables them: the architecture, which, as the focus of this book, has its own section in this chapter. 9 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 16
1.2 Architectural requirements for fast flow The purpose of architecture - at least as far as fast flow is concerned - is to enable DevOps and Team Topologies. As you will see below, enabling the other two elements of the success triangle is the main reason to adopt microservices, and that you are unlikely to accelerate software delivery without them. In the same way that real world architects design spaces that meet the needs of people, software architects must create application architectures that enable the organization, which practices DevOps and is structured using Team Topologies, to deliver software quickly and reliably. In this section, we will explore the two main architectural properties that fast flow requires. You will also learn how for some applications the monolithic architecture can enable fast flow, whereas for others, it’s an obstacle. Let’s begin by looking at the architectural requirements for fast flow. 1.2.1 Architectural requirements for fast flow When we think of architecture, there’s a tendency to focus on those aspects of architecture that satisfy end-user requirements, such as scalability, availability, and security. The reality, however, is that the architecture must also satisfy the needs of the engineering organization that develops the software. A unique property of software is that its creators also live within it. The decisions that they make today influence the ease of development tomorrow. In particular, an application’s architecture plays a critical role in enabling or preventing fast flow software delivery using Team Topologies and DevOps. In order for a team to be able to quickly and easily implement a work item (feature, defect, etc.) and deploy the changes to production without needing to coordinate with other teams requires an architecture that has certain features. I describe these features in more detail in chapter 5, but for now, I’ll provide a brief overview of two key features: loose design-time coupling and a fast, automated deployment pipeline. Let’s first look at each of these features in more detail, starting with loose design-time coupling. FAST FLOW REQUIRES A LOOSELY DESIGN-TIME COUPLED ARCHITECTURE A key aspect of DevOps and Team Topologies is that teams are autonomous. Each team works mostly independently of other teams. It interacts with other teams primarily via the Team Topologies X-aaS interaction style. The team rarely needs to coordinate with other teams or wait for them to complete a work item. Hand-offs between teams are minimized in accordance with the DevOps first way principle. In fact, the need for team autonomy is one of the key findings by the authors of Accelerate who researched the characteristics of high performance teams. To achieve team autonomy, you must design teams that are aligned to a stream of work, the so-called stream-aligned team concept from team topologies. But this is insufficient. You also need a loosely design-time coupled architecture. 10 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 17
Loose design-time coupling, which I describe in detail in chapter 4, is an incredibly important property of architecture in particular and software in general. If an application’s architecture is loosely design-time coupled, then each team can change their part of the application without regularly needing other teams to change their code. Consider, for example, the architecture shown in figure 1.5. The Orders team owns the Order Management module, which uses the Consumer Management module that’s owned by Consumers team. If the architecture is loosely design-time coupled, then the Orders team can change their Order Management module without regularly needing to coordinate with the Consumers team. In other words, the Orders team can be autonomous. Figure 1.5 In order for teams to be autonomous, the software elements that they develop must be loosely design-time coupled If, on the other hand, the architecture were tightly design-time coupled, then a change to one module would frequently require the other to be updated. The two teams would constantly need to coordinate with each other. The endless meetings along with needing to wait for the other team to finish their changes would reduce both teams' productivity. FAST FLOW REQUIRES A FAST DEPLOYMENT PIPELINE The first architectural requirement for fast flow — loose design-time coupling — allows a developer to easily modify the codebase. The second requirement, however, focusses on what happens once that change is pushed or merged into the repository. To shorten the feedback loop, the push or merge of the change must trigger a deployment pipeline that rapidly compiles, tests, and deploys the update. 11 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 18
An automated deployment pipeline is a key part of the DevOps first way. It’s the path that changes take from a developer’s laptop to production. The deployment pipeline is triggered when a change is pushed to or merged into a code repository branch. It compiles, tests, and deploys the change. Figure 1.6 Fast flow requires a fast deployment that can handle the stream of changes from the development teams The lead time DORA metric is the time that it takes for a change to flow through the deployment pipeline. A low lead time is what is meant by fast deployment pipeline. The key architectural challenge is keeping the lead time low as the application and its organization grows. The lead time is the sum of two times. First, there is the wait time, which is the time that a change is queued until it can be processed by the deployment pipeline. Second, there is the processing time, which is the time that it takes the deployment pipeline to compile, test, analyze and deploy the change. For most Java applications, the compilation time is negligible. Most of the time is spent running the tests. The deployment time varies depending on the application and the deployment technology. The wait time is proportional to the frequency of changes and the processing time of the deployment pipeline. For large applications developed by large teams, there’s the double risk of long wait times and long processing times. 1.2.2 The Monolithic architecture can enable fast flow A monolithic application consists of a single codebase that’s deployed as a single deployable unit (e.g., executable JAR or WAR file) by a single deployment pipeline. Contrary to certain rumors, the monolithic architecture is not an architectural anti-pattern. Nor, is it inevitably a big ball of mud (Big Ball of Mud by Brian Foote and Joseph Yoder, http://www. laputan.org/ mud/), a tangled mess of spaghetti code. In fact, the monolithic architecture is a good choice for many applications and is fully capable of enabling fast flow. In chapter 6, I describe the Modular Monolith pattern, which is a fantastic improvement to the traditional three-layer monolith because it can improve team autonomy and reduce the deployment pipeline’s execution time. 12 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 19
The challenge, however, is that an application and its organization can still outgrow a modular monolith. If they continue to grow, then sooner or later team autonomy declines and the deployment pipeline becomes a bottleneck. Let’s look at each of these two problems in more detail, starting with the decline in team autonomy. TEAM AUTONOMY DECLINES AS THE APPLICATION AND ORGANIZATION GROW The first problem with a large monolith is that some changes can be very difficult to make because they impact numerous teams. Consider, for example, the application shown in figure 1.7. Most modules are loosely design-time coupled and can be changed easily. But there are, however, some changes that can have widespread impact, such as breaking changes to APIs of widely used modules; upgrades of widely used 3rd party libraries that have breaking API changes; and upgrades of the JVM. Figure 1.7 Even though most modules in this monolithic application are loosely design-time coupled, since there is a single code base, some changes can be difficult to make because they impact numerous teams. A change to a utility module might require simultaneous changes to many other modules. Upgrading 3rd party libraries or the language runtime might also require widespread changes. There’s also a risk that the deployment pipeline becomes a bottleneck due to the large codebase and large number of developers. If while implementing a new feature, the Orders team, for example, needs to make such a change then they would have the unenviable task of coordinating with the other teams. Since each team has their own priorities and schedules, coordinating these types of changes can be difficult. In some cases, it can be virtually impossible. The Orders team might need to find a workaround to avoid making a breaking change. 13 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
Page 20
THE DEPLOYMENT PIPELINE BECOMES A BOTTLENECK The second problem is that the monolith’s single deployment pipeline can become a bottleneck. As the application grows, it has more tests, which take longer to execute and so the deployment pipeline’s processing time increases. And to make matters worse, as the number of developers grows, the frequency of changes increases, which can overwhelm the deployment pipeline and result in long wait times. The deployment pipeline could batch changes to reduce wait times, but this violates the DevOps principle of reduce batch sizes and complicates troubleshooting build failures and production outages. Also, a monolith might even be so large that it’s not practical to test it thoroughly on a developer’s laptop. It might simply be too large and have too many dependencies to run locally. Or, even if the tests can be run locally, they might take too long. Developers might end up relying on the deployment pipeline to test their changes or have to ship them to a dedicated testing environment with sufficient resources to run them quickly. As a result, developers no longer receive fast local feedback about their changes. For large applications developed by large organizations, the solution to the lack of team autonomy and the slow deployment pipeline is to use the microservice architecture. 1.3 A brief introduction to the microservice architecture While the monolithic architecture has various benefits, such as simplicity, it’s often an obstacle to fast flow when the application and the organization are large. Teams spend too much time coordinating changes. The deployment pipeline is a bottleneck. In such cases, the microservice architecture is often a better choice. But what is the microservice architecture? Does it actually mean lots of little services, each 100 lines of code (LOC) or two weeks worth of work? How does it enable fast flow? What exactly are its drawbacks? When should you use it? In the remainder of this chapter, I will answer these and other questions. Let’s start by looking at a definition of the microservice architecture. 1.3.1 The microservice architecture: a definition The microservice architecture, which I describe in more detail in chapter 7, is defined as follows: The microservice architecture is an architectural style that structures an application as a collection of two or more loosely design-time coupled, independently deployable services. On the surface, this is a very simple definition. But there is, however, a lot of depth to it, since it’s a bundle of four key concepts. Let’s break down the definition one concept at a time. 14 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>
The above is a preview of the first 20 pages. Register to read the complete e-book.

Recommended for You

Loading recommended books...
Failed to load, please try again later

Tip the Site

Scan the WeChat Pay or Alipay code to tip. No login required.

WeChat Pay
Alipay
← Back to List