Microservice Architecture

When the database change in data is made, it is recorded on a

'pending updates' log. the other service instances can check this log and indicate the change made

Two types of inconsistency in the data

1. Dependent data inconsistency: the actions or failures of one service can force the data managed by another service to become inconsistent 2. Replica inconsistency: several replicas of the same service may be executed at the same time/ each copy will update the service data. You need a way to make these databases eventually consistent so that the data is the same for all copies

Modern web services initially started in... and the idea of "big" web servers emerged in...

1990s and early 2000s

What is a microservice

A small-scale, stateless, services that have a single responsibility (can have more than one functionality). They are completely independent with their own database and UI management. Also, the software products that use microservices has a microservice architecture. They are also helpful because the testing is quite easier. You don't have to test the whole service.

Synchronous microservice system

A system processing service A will issue a request to another service (B), which then waits for B to end process and return the required information

Asynchronous microservice system

A system processing service A will send a request to another service (B), which then does not wait for B to return the required information. Hence, a queue is created for processing. Sometime later, B completes request and queues the result to be retrieved by A. The additional step is that Service A (and B) checks its queue periodically. Therefore, this is more complex than synchronous

4 Decomposition guidelines/rules

Balance fine-grain functionality and system performance: changes should be limited to a few services. if the service is very specific, it is inevitable that you will need more services to implement user functionality. This will load down a system by bundling and unbundling messages Follow the 'common closure principle': elements of a system that are likely to be changed at the same time should be located within the same service Associate services with business capabilities: consider an example, the provider of photo printer system will need a group that provide photos back to user (dispatch team) also set of printing capability machines that need to be managed. Another example, for authentication from the business POV, we create this microservice with high importance. Also need someone to manage the transactions Design services so that they only have access to the data that they need: this will help with overlapping between services and data so that we can maintain the change of data in a service will not change the data in another service

We can identify smaller features from a microservice. Can take a microservice and break it down more. Let's take the authentication microservice as an example. Explain.

Can break down authentication into three microservices: UID management, Password management, and User info management. All of these microservices have their own data.

Password management functionality from the supporting perspective

Check password validity Delete password Back up password database Recover password database Check database integrity Repair password database. You can see we have many functionalities in this one microservice

Password management functionality form the user perspective

Create password Change password Check password Recover password

Using pending transaction/updates log

When a database change is made, it is recorded on this log. Other service instances look at this log and update their own database. When all instances update according to the log, that update is removed from the log.

We can functionally breakdown authenticating using password

Get login ID Get password Check credentials Confirm authentication

Indirect service communication

Interacting services do not know each other's addresses. They send their request to a message broker (message bus). The message broker is responsible for finding the service that can fulfill the service request. This is not as fast and requires additional software

Microservice data design approaches

Isolate the data with each system service so sharing is little. It sharing is unavoidable, design micro services so that most sharing is 'read-only.' If services are replicated within a system, you must include a mechanism that can keep the database copies used by replica services consistent

Microservices architecture is..

an architecture style with logical software architecture. the style addresses two problems of monolithic applications

Two problems of monolithic application's

Rebuilding and re-deploying. if the demand is increasing, we need to rescale. If a particular microservice is used, only that microservice has to be scaled

Three key decisions for service communcation

Synchronous or asynchronous? Should services communicate directly or via message broker middleware? What protocol should be used for messages exchanged between services?

What is included in a photo printing system that is based on microservice architecture

The API gateway isolates the microservices from the mobile app. it translates requests into calls to the microservices. The application does not need to know which service protocol is being used. The gateway can change the service decomposition by splitting or combining services without affecting the mobile app

Direct service communication

Requires interacting services to know each other's addresses. Message is sent directly to their address. Uniform Resource Identifier = address

Characteristics of microservices

Self-contained: microservices do not have external dependencies. they manage their own data nd implement their own user interface Light-weight: microservices communicated using lightweight communications Implementation independent: they may be implemented using different programming languages and technologies Independently deployable: microservice runs on its own process Business-oriented: do not just simply provide technical service. how small do we have to go to consider it a microservice? We do all this to create an application out of multiple microservices

We can functionally breakdown user registration into microservices

Set up new login ID Set up ne password Set up password recovery info Set up two-factor identification Confirm registration

Microservices architecture key design questions

What are the microservices that make up the system? How should microservices communicate with each other? How should service failure be detected, reported and and managed? How should the microservices in the system be coordinated? How should data be distributed and shared?

Messages that are sent between microservices include

We have input and output messages. Messages are sent in packets. Administration information, service request, and data required to deliver the requested service

Service communications for microservice architecture:

You need to astablish a standard for communication that all microservices follow

A software service is

a software component that can be accessed from remote computers over the internet

Example of communication between microservices

authentication inputted by user. the service responds with a service request message and data representation and a reply if the authentication worked or not. We want low coupling and high cohesion

Component decomposition is important because...

components can be developed in parallel with a team.

One of the most important decisions for a software architect is..

deciding how to decompose a system into components

Microservice development has a general rule

each microservice manages its own data and is completely independent. Although, complete data independence is impossible. There will always be data overlap in different services. Hence they are interacting services instead of individual units

Problem of replica inconsistency

given two identical instances of a management service. each has its own database. they are updated independently of one another. there needs to be a way for each instance so that all replicas of the data become consistent, this is called eventual consistency

Microservice support code has four important components

message management: responsible for monitoring incoming and outgoing messages. we need to check the validity of the message and data. we need correct format for outgoing messages Failure management: code has two concerns, it has to cope with circumstances where the microservice cannot properly complete an operation. second external interactions are required and it has to handle the situation where the interaction does not succeed because of an error. So, it depends on if the failure is on your end or the network end. UI implementation Data consistency management: data used in the service is also used in other services. If they share the data, this data must be consistent. we must check that this is the same

Software as a Service can be broken down into...

microservices

Modern web services were initially based...

on XML-based standards and protocols

Inconsistency management

the databases used by different microservices need not be consistent all of the time: inconsistencies. There are two types

Most software services don't need..

the generality that's inherent in the design of web service protocols

Software services don't have a local state, therefore...

the services can be dynamically reallocated from one virtual server to another and replicated across several servers

When a service request is made...

the state info may be included as a part of the request and the updated state information is returned as part of the service result

Eventual consistency is a situation where...

the system guarantees that the databases will eventually become consistent. You can implement eventual consistency by maintaining a transaction log