System ArchitecturesReactive Architecture: Towards Microservices

Jonathan Thaler

Department of Computer Science

1 / 24

Motivation

In the early days of software development, asingle developer, or a small group, would buildan application to support a small number ofusers.

In this environment building a monolithic styleapplication made sense. It was the simplestthing we could do.

Today, multiple teams are working with manydifferent technologies, supporting millions ofusers. In this environment, the monolithicapplication becomes a burden, rather than abenefit.

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 andmicroservices on the other, with actual applications somewhere in between.

A Microservices vs. Monolith mindset does not make sense as both microservicesand monoliths have advantages and disadvantages.

It is a big part of a software architects job to look at the differences betweenthem 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 othercharacteristics 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 clearisolation in the application, where everythingdepends on everything else.

Due to this complex dependencies, and lackof isolation, the application is very difficult tounderstand and even harder to modify andmaintain.

Such architectural styles produce workingsolutions very quickly but then stagnate andchanges become exponentially expensive.

In the Software Engineering Project youlearned how to avoid this and architect a cleanand well designed monolith.

5 / 24

Monoliths

Figure: A Monolith

Deployed as a single unit.

Single shared database, usual relational andtransactional.

Communication with synchronous messagecalls.

Deep coupling between libraries andcomponents, often through the database,where all rely on the same data from thedatabase.

Big Bang style releases. Releasing andupdating the application is all-or-nothing.

Teams have to carefully synchronise featuresand releases (as you have seen in the softwareengineering project).

6 / 24

Monoliths

Figure: Scaling a Monolith: multipleindependent copies are deployed, which do notcommunicate directly with each other, so amonolith does not know there are other copiesdeployed.

Figure: Scaling a Monolith: ”communication”happens implicitly through the database, whichprovides consistency between deployedinstances.

7 / 24

Monoliths

Advantages of Monoliths:

Easy cross-module refactoring. All code is in one project, therefore refactoringwith the help of an IDE is quite easy.

Easier to maintain consistency due to a single ”shared” database. When writingsome data and don’t make any other modifications, you will be reading back thissame data.

Single deployment process. Although there is this big bang release, you are onlydoing 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 physicalmachines 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 lessresources, however as it is a single unit application it is not possible todifferentiate.

Deep coupling leads to inflexibility. For example changing the structure of atable becomes hard due to database data dependencies.

Development tends to become slow with changes becoming increasingly difficultand 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 causecascading 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) eachdomain boundary, implemented as a library,represents a service.

The idea with SOA is that those servicesdon’t share a database.

Anybody who wants information from a servicehas to go through the services API.

This creates isolation as now each independentservice can have its own database, which couldalso be of different type than the others.

No coupling between different parts of theapplication and the database.

11 / 24

Service Oriented Architecture

While SOA says that services don’t share a database and that they have tocommunicate 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 thoseservices as one application, communicating through some clearly defined API.

On the other hand some SOAs choose to go the other route where each service isdeployed as an independent application in which case it more closely resemblesmicroservices.

SOA is not necessarily the same as microservices although in some cases it maybe.

12 / 24

Reactive Architecture: Towards Microservices

Microservices

13 / 24

Microservices

Figure: Microservices

Microservices are a subset of SOA thedifference is that ...

... microservices require that each of thoseservices are independently deployed

All of the rules around SOA are kept:maintaining a separate datastore andensuring that our services communicate onlythrough a clearly defined API.

The main point of microservices is thatindividual services are deployedindependently.

14 / 24

Microservices

Figure: Microservices

Each services is deployed independently.

Multiple independent databases (just as inSOA).

Communication is asynchronous (ReactiveMicroservices).

Loose coupling between components. Thereare no database dependencies, possiblyasynchronous communication, no sharded code.

Rapid deployment, possibly continuousdeployment.

15 / 24

Microservices

Figure: Scaling Microservices: eachmicroservice is scaled independently and youcan have as many microservices as are required. Figure: Scaling Microservices: on one machine

there could be one or more copies of a servicesdeployed (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 nocommon, single code base and services are not going to be deployed at the sametime.

Requires to support older API versions. This follows immediately out ofdeployment, 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 responsiblefor 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 isall about understanding responsibility.

A service should have only one responsibility (Single Responsibility Principle). Achange to the internals of one microservice should not necessitate a change toanother microservice.

An excellent place to start building microservices are Bounded Contexts fromDDD.

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 abouthow 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 mustgo through its API.

There is no backdoor access via thedatabase.

This allows the microservice to evolveinternally without affecting any outsidedependencies.

21 / 24

Microservices

Figure: Isolation of Space.

2. Space: Microservices should not carewhere other microservices are deployed.

It should be possible to move amicroservice to another machine, possiblyin another data center without issue.

This allows the microservice to be scaledup/down to meet demand.

22 / 24

Microservices

Figure: Isolation of Time.

3. Time: Microservices should not waitfor each other.

Requests are asynchronous andnon-blocking. This leads to moreefficient use of resources and resourcescan be freed immediately, rather thanwaiting for a request to finish.

Between Microservices we expect eventualconsistency which provides increasedscalability. Total consistency wouldrequire a central coordination which limitsscalability.

23 / 24

Microservices

Figure: Isolation of Failure.

4. Failure: Microservices also isolatefailure.

A failure in one microservice should notcause another to fail. This allows thesystem to remain operational in spite offailure

24 / 24