System Architectures Reactive Architecture: Towards Microservices - - PowerPoint PPT Presentation

System Architectures Reactive Architecture: Towards Microservices

Jonathan Thaler

Department of Computer Science

1 / 24

Motivation

In the early days of software development, a single developer, or a small group, would build an application to support a small number of users. In this environment building a monolithic style application made sense. It was the simplest thing we could do. Today, multiple teams are working with many different technologies, supporting millions of

• users. In this environment, the monolithic

application becomes a burden, rather than a benefit. This is where microservices enter the picture.

2 / 24

Motivation

What exactly and how big a microservice is is not clear. Microservices and monotliths exist on a spectrum with monoliths on one end and microservices on the other, with actual applications somewhere in between. A Microservices vs. Monolith mindset does not make sense as both microservices and monoliths have advantages and disadvantages. It is a big part of a software architects job to look at the differences between them and look at the benefits or disadvantages to each and try to balance them. Ultimately, a single system can have some characteristics of a Monolith and other characteristics of Microservices.

3 / 24

Reactive Architecture: Towards Microservices Monoliths

4 / 24

Monoliths

Figure: Big Ball of Mud

In the Big Ball of Mud there is no clear isolation in the application, where everything depends on everything else. Due to this complex dependencies, and lack

• f isolation, the application is very difficult to

understand and even harder to modify and maintain. Such architectural styles produce working solutions very quickly but then stagnate and changes become exponentially expensive. In the Software Engineering Project you learned how to avoid this and architect a clean and well designed monolith.

5 / 24

Monoliths

Figure: A Monolith

Deployed as a single unit. Single shared database, usual relational and transactional. Communication with synchronous message calls. Deep coupling between libraries and components, often through the database, where all rely on the same data from the database. Big Bang style releases. Releasing and updating the application is all-or-nothing. Teams have to carefully synchronise features and releases (as you have seen in the software engineering project).

6 / 24

Monoliths

Figure: Scaling a Monolith: multiple independent copies are deployed, which do not communicate directly with each other, so a monolith does not know there are other copies deployed. Figure: Scaling a Monolith: ”communication” happens implicitly through the database, which provides consistency between deployed instances.

7 / 24

Monoliths

Advantages of Monoliths: Easy cross-module refactoring. All code is in one project, therefore refactoring with the help of an IDE is quite easy. Easier to maintain consistency due to a single ”shared” database. When writing some data and don’t make any other modifications, you will be reading back this same data. Single deployment process. Although there is this big bang release, you are only doing it once. Single thing to monitor. Simple scalability model: just deploy more copies.

8 / 24

Monoliths

Disadvantages of Monoliths: Limited by the maximum size of a single physical machine (big physical machines are often much more expensive than small ones). Scaling depends on the database. Components have to be scaled as a group. Some components might need less resources, however as it is a single unit application it is not possible to differentiate. Deep coupling leads to inflexibility. For example changing the structure of a table becomes hard due to database data dependencies. Development tends to become slow with changes becoming increasingly difficult and build times increasing. Failure in one component of the monolith brings down the whole application. When multiple copies are deployed and one fails, redistribution of load can cause cascading failures.

9 / 24

Reactive Architecture: Towards Microservices Service Oriented Architecture

10 / 24

Service Oriented Architecture

Figure: Service Oriented Architecture

In a Service Oriented Architecture (SOA) each domain boundary, implemented as a library, represents a service. The idea with SOA is that those services don’t share a database. Anybody who wants information from a service has to go through the services API. This creates isolation as now each independent service can have its own database, which could also be of different type than the others. No coupling between different parts of the application and the database.

11 / 24

Service Oriented Architecture

While SOA says that services don’t share a database and that they have to communicate through their API’s, it doesn’t say how they are deployed. As a result some SOAs are built in a monolithic style which deployes all of those services as one application, communicating through some clearly defined API. On the other hand some SOAs choose to go the other route where each service is deployed as an independent application in which case it more closely resembles microservices. SOA is not necessarily the same as microservices although in some cases it may be.

12 / 24

Reactive Architecture: Towards Microservices Microservices

13 / 24

Microservices

Figure: Microservices

Microservices are a subset of SOA the difference is that ... ... microservices require that each of those services are independently deployed All of the rules around SOA are kept: maintaining a separate datastore and ensuring that our services communicate only through a clearly defined API. The main point of microservices is that individual services are deployed independently.

14 / 24

Microservices

Figure: Microservices

Each services is deployed independently. Multiple independent databases (just as in SOA). Communication is asynchronous (Reactive Microservices). Loose coupling between components. There are no database dependencies, possibly asynchronous communication, no sharded code. Rapid deployment, possibly continuous deployment.

15 / 24

Microservices

Figure: Scaling Microservices: each microservice is scaled independently and you can have as many microservices as are required. Figure: Scaling Microservices: on one machine there could be one or more copies of a services deployed (hosting a subsystem).

16 / 24

Microservices

Advantages of Microservices: Individual services can be deployed / scaled individually as needed. Increased availability. Serious failures are isolated to a single machine. Isolation / decoupling provides more flexibility to evolve within a module. Supports multiple languages and platforms.

17 / 24

Microservices

Disadvantages of Microservices: May require multiple complex deployment and monitoring approaches. Cross-service refactoring is (much) more challenging and harder. There is no common, single code base and services are not going to be deployed at the same time. Requires to support older API versions. This follows immediately out of deployment, as services cannot be deployed literally at the same time. APIs need to be evolved without breaking changes. Organisational change to microservices can be challenging.

18 / 24

Microservices

Microservices often come with an organizational change: Teams operate more independently. Release cycles are shorter. Cross team coordination becomes necessary. These changes facilitate increase in productivity. Teams release features when they are ready. Teams often organise around a DevOps approach, where the team is responsible for the application from implementation (Dev) to deployment (Ops). With microservices one team is responsible for everything.

19 / 24

Microservices

A fundamental question is how big a microservice should be: A big part of understanding where to draw the lines between your microservices is all about understanding responsibility. A service should have only one responsibility (Single Responsibility Principle). A change to the internals of one microservice should not necessitate a change to another microservice. An excellent place to start building microservices are Bounded Contexts from DDD. In many ways the core of what reactive microservices is about is isolation. Don’t ask how big a microservice should be. The right question is more about how a microservices can be isolated. There are 4 main principles of microservice isolation.

20 / 24

Microservices

Figure: Isolation of State.

• 1. State: all access to a microservice must

go through its API. There is no backdoor access via the database. This allows the microservice to evolve internally without affecting any outside dependencies.

21 / 24

Microservices

Figure: Isolation of Space.

• 2. Space: Microservices should not care

where other microservices are deployed. It should be possible to move a microservice to another machine, possibly in another data center without issue. This allows the microservice to be scaled up/down to meet demand.

22 / 24

Microservices

Figure: Isolation of Time.

• 3. Time: Microservices should not wait

for each other. Requests are asynchronous and non-blocking. This leads to more efficient use of resources and resources can be freed immediately, rather than waiting for a request to finish. Between Microservices we expect eventual consistency which provides increased

• scalability. Total consistency would

require a central coordination which limits scalability.

23 / 24

Microservices

Figure: Isolation of Failure.

• 4. Failure: Microservices also isolate

failure. A failure in one microservice should not cause another to fail. This allows the system to remain operational in spite of failure

24 / 24