|
1 | 1 | --- |
2 | 2 | title: The World is Distributed |
3 | | -description: Gain an understanding of the challenges of distributed applications |
| 3 | +description: The benefits and challenges of distributed applications with a look at monolithic and SOA approaches. |
4 | 4 | author: robvet |
5 | | -ms.date: 09/17/2020 |
| 5 | +ms.date: 11/07/2020 |
6 | 6 | --- |
7 | 7 |
|
8 | 8 | # The world is distributed |
9 | 9 |
|
10 | | -Modern, distributed systems are in and, monolithic apps are out! Just ask any 'cool kid.' |
| 10 | +[!INCLUDE [book-preview](../../../includes/book-preview.md)] |
11 | 11 |
|
12 | | -But, interestingly, they aren't the only ones saying it. More and more, corporate architects and IT leaders are designing new and replatforming existing enterprise applications to fit this mold. |
| 12 | +Just ask any 'cool kid': *Modern, distributed systems are in, and monolithic apps are out!* |
13 | 13 |
|
14 | | -As a developer, architect, or IT leader... |
| 14 | +But, it's not just "cool kids." Progressive IT Leaders, corporate architects, and astute developers are echoing these same thoughts as they explore and evaluate modern distributed applications. Many have bought in. They're designing new and replatforming existing enterprise applications following the principles, patterns, and practices of distributed microservice applications. |
| 15 | + |
| 16 | +But, this evolution raises many questions... |
15 | 17 |
|
16 | 18 | - What exactly is a distributed application? |
17 | | -- Why is it important? |
| 19 | +- Why are they gaining popularity? |
18 | 20 | - What are the costs? |
19 | 21 | - And, importantly, what are the tradeoffs? |
20 | 22 |
|
21 | | -For years, we designed, developed, and deployed applications as a single, monolithic unit. Figure 1.x shows a monolithic architecture. |
| 23 | +To start, let's rewind and look at the past 15 years. During this period, we typically constructed applications as a single, monolithic unit. Figure 1-1 shows the architecture. |
22 | 24 |
|
23 | 25 |  |
24 | 26 |
|
25 | | -**Figure 1**. Monolithic architecture. |
| 27 | +**Figure 1-1** : Monolithic architecture. |
26 | 28 |
|
27 | | -In the previous figure, note how modules for Ordering, Identity, Marketing, and others, all reside in a single-server process. Application state is stored inside a shared relational database. Business functionality is exposed via HTML and RESTFul interfaces. |
| 29 | +Note how the modules for Ordering, Identity, and Marketing execute in a single-server process. Application data is stored in a shared database. Business functionality is exposed via HTML and RESTful interfaces. |
28 | 30 |
|
29 | | -Although straightforward, monolithic architectures present many challenges: |
| 31 | +In many ways, monolithic apps are `straightforward`. They're straightforward to... |
30 | 32 |
|
31 | | -- Coupling |
32 | | -- Deployment |
33 | | -- Scaling |
| 33 | +- build |
| 34 | +- test |
| 35 | +- deploy |
| 36 | +- troubleshoot |
| 37 | +- scale vertically (scale up) |
34 | 38 |
|
35 | | -As the application grows in size, complexity, and volume, these challenges become more pronounced. Eventually, you enter the `Fear Cycle`. The *fear cycle* is a state in which you have lost control of your monolithic application. |
| 39 | +However, monolithic architectures can present significant challenges. |
36 | 40 |
|
37 | | -The Microsoft guidance eBook, [Architecting Cloud-Native .NET Apps for Azure](https://docs.microsoft.com/dotnet/architecture/cloud-native/), provide the obvious giveaways: |
| 41 | +Over time, you may reach a point where you begin to lose control... |
38 | 42 |
|
39 | | -- The app has become so overwhelmingly complicated that no single person understands it. |
40 | | -- You fear making changes - each change has unintended and costly side effects. |
41 | | -- New features/fixes become tricky, time-consuming, and expensive to implement. |
42 | | -- Each release as small as possible and requires a full deployment of the entire application. |
| 43 | +- The monolith has become so overwhelmingly complicated that no single person understands it. |
| 44 | +- You fear making changes as each brings unintended and costly side effects. |
| 45 | +- New features/fixes become time-consuming and expensive to implement. |
| 46 | +- Even the smallest change requires full deployment of the entire application - expensive and risky. |
43 | 47 | - One unstable component can crash the entire system. |
44 | | -- New technologies and frameworks aren't an option. |
45 | | -- It's difficult to implement agile delivery methodologies. |
| 48 | +- Adding new technologies and frameworks aren't an option. |
| 49 | +- Implementing agile delivery methodologies are difficult. |
46 | 50 | - Architectural erosion sets in as the code base deteriorates with never-ending "special cases." |
47 | | -- The consultants tell you to rewrite it. |
| 51 | +- Eventually the consultants come in and tell you to rewrite it. |
| 52 | + |
| 53 | +IT practitioners call this condition `the Fear Cycle`. If you've been in the technology business for any length of time, good chance you've experienced it. It's stressful and exhausts your IT budget. Instead of building new and innovative solutions, the majority of your budget is spent maintaining legacy apps. |
| 54 | + |
| 55 | +Instead of fear, businesses require `speed and agility`. They seek an architectural style with which they can rapidly respond to market conditions. They need to instantaneously update and individually scale small areas of a live application. |
| 56 | + |
| 57 | +An early attempt to gain speed and agility came in the form of [Service Oriented Architecture](https://en.wikipedia.org/wiki/Service-oriented_architecture), or `SOA`. In this model, service consumers and service providers collaborated via middleware messaging components, often referred to as an [Enterprise Service Bus](https://en.wikipedia.org/wiki/Enterprise_service_bus), or `ESB`. Figure 1-2 shows the architecture. |
| 58 | + |
| 59 | + |
48 | 60 |
|
49 | | -Instead of fear, businesses need speed and agility. They seek an architectural style enables them to rapidly respond to market conditions. They can instantaneously update small areas of a live, complex application, and individually scale those areas as needed. |
| 61 | +**Figure 1-2** SOA architecture. |
50 | 62 |
|
51 | | -Many organizations are mitigating the monolithic fear cycle. They are gaining speed and agility by adopting a distributed architectural approach to building systems. Figure 1 shows the same system built applying cloud-native techniques and practices. |
| 63 | +With SOA, centralized service providers registered with the ESB. Business logic would be built into the ESB to integrate providers and consumers. Service consumers could then find and communicate with these providers using the ESB. |
| 64 | + |
| 65 | +Despite the promises of SOA, implementing this approach often increased complexity and introduced bottlenecks. Maintenance costs became high and ESB middleware expensive. Services tended to be large. They often shared dependencies and data storage. In the end, SOAs often resulted in a 'distributed monolithic' structure with centralized services that were resistant to change. |
| 66 | + |
| 67 | +Nowadays, many organizations have realized speed and agility by adopting a distributed microservice architectural approach to building systems. Figure 1-3 shows the same system built using distributed techniques and practices. |
52 | 68 |
|
53 | 69 |  |
54 | 70 |
|
55 | | -**Figure 1**. Distributed architecture. |
| 71 | +**Figure 1-3** : Distributed architecture. |
| 72 | + |
| 73 | +Note how the same application is decomposed across a set of distributed services. Each is self-contained and encapsulates its own code, data, and dependencies. Each is deployed in a software container and managed by a container orchestrator. Instead of a single database shared by multiple services, each service owns a private database. Other services cannot access this database directly and can only get to data that is exposed through the public API of the service that owns it. Note how some services require a full relational database, but others, a NoSQL datastore. The Basket service stores its state in a distributed key-value cache. Note how inbound traffic routes through an API Gateway service. It's responsible for directing calls to back-end services and enforcing cross-cutting concerns. Most importantly, the application takes full advantage of the scalability, availability, and resiliency features found in modern cloud platforms. |
| 74 | + |
| 75 | +But, while distributed services can provide agility and speed, they present a different set of challenges. Consider the following... |
56 | 76 |
|
57 | | -Note in the previous figure how the same application is decomposed across a set of distributed services. Each is self-contained and encapsulates its own code, data, and dependencies. Each is deployed in a software container and managed by a container orchestrator. Instead of a large relational database, each service owns it own datastore, the type of which vary based upon the data needs. Note how some services depend on a relational database, but other on NoSQL databases. One service stores its state in a distributed cache. Note how all traffic routes through an API Gateway service that is responsible for directing traffic to the core back-end services and enforcing many cross-cutting concerns. Most importantly, the application takes full advantage of the scalability, availability, and resiliency features found in modern cloud platforms. |
| 77 | +- How can distributed services discover each other and communicate synchronously? |
| 78 | +- How can they implement asynchronous messaging? |
| 79 | +- How can they maintain contextual information across a transaction? |
| 80 | +- How can they become resilient to failure? |
| 81 | +- How can they scale to meet fluctuating demand? |
| 82 | +- How are they monitored and observed? |
58 | 83 |
|
59 | | -But, while distributed applications can help bring agility and speed, they bring many challenges. |
| 84 | +For each of these challenges, multiple products are often available. But, shielding your application from product differences and keeping code maintainable and portable become a challenge. |
60 | 85 |
|
61 | | -| Challenge | Description | |
62 | | -| :-------- | :-------- | |
63 | | -| State Management | Maintaining contextual information during a transaction | |
64 | | -| Interservice Communication | Communicate with other independent services | |
65 | | -| Messaging | | |
66 | | -| Obseraviblity | End-to-end monitoring of processes executing on different machines | |
| 86 | +This book introduces Dapr. Dapr is a distributed application runtime. It directly addresses many of the challenges found that come along with distributed applications. Looking ahead, Dapr has the potential to have a profound impact on distributed application development. |
67 | 87 |
|
68 | | -So, what exactly is Dapr? Sit back, relax, and let us help you explore this new world. |
| 88 | +## Summary |
69 | 89 |
|
70 | | -In this chapter, we introduced Dapr. Blah. We provided a definition along with the key capabilities that drive a cloud-native application. We looked at the types of applications that might justify this investment and effort. |
| 90 | +In this chapter, we discussed the adoption of distributed applications. We contrasted a monolithic system approach with that of distributed services. We pointed out many of the common challenges when considering a distributed approach. |
71 | 91 |
|
72 | | -With the introduction behind, we now dive into a much more detailed look at cloud native. |
| 92 | +Now, sit back, relax, and let us introduce you the new world of Dapr. |
73 | 93 |
|
74 | 94 | ### References |
75 | 95 |
|
|
0 commit comments