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 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 of 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. Figure: Big Ball of Mud In the Software Engineering Project you learned how to avoid this and architect a clean and well designed monolith . 5 / 24

Monoliths 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 . Figure: A Monolith 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 Figure: Scaling a Monolith: ”communication” monolith does not know there are other copies happens implicitly through the database, which deployed. 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 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 Figure: Service Oriented Architecture 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 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 Figure: Microservices individual services are deployed independently . 14 / 24

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. Figure: Microservices Rapid deployment, possibly continuous deployment. 15 / 24

Microservices Figure: Scaling Microservices: each microservice is scaled independently and you Figure: Scaling Microservices: on one machine can have as many microservices as are required. 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 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 Figure: Isolation of State. dependencies. 21 / 24

Microservices 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 Figure: Isolation of Space. up/down to meet demand. 22 / 24

Microservices 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 Figure: Isolation of Time. consistency which provides increased scalability . Total consistency would require a central coordination which limits scalability. 23 / 24