Gain insights into microservice principles, their pros and cons, Micro and Macro architecture, migration strategies, Docker's role, and technologies to effectively implement microservices.

docker_ms2_v3.tar.gz

SpringBoot

test

SpringMain

ms-1-scs-esi

SpringMain-copy

scs-esi

scs-esi-copy

scs-esi-up

Microservices are one of the most important and popular software architecture trends. This architecture forms the base for a lot of companies including: Amazon, Netflix, Spotify, and Uber. 

In this course you’ll learn microservices in depth and understand reasons for and against microservices. Beyond that, you’ll learn about Micro and Macro architecture, strategies for migrating old systems, the role of Docker in this architecture, and technologies for implementing microservices. 

After taking this course, you’ll be better equipped to implement microservices for your own use.

An Introduction to Microservice Principles and Concepts

Microservices provide technological isolation. Therefore, it is possible to extend the concept of micro and macro architecture to **technical decisions**. 

For deployment monoliths, these decisions, inevitably, must be implemented globally. 

So, only for microservices, technical decisions can be made *within* the framework of macro or micro architecture. However, some decisions have to be part of the macro architecture. Otherwise, the integration will be compromised.


# Micro and macro architecture decisions
Decisions can be taken in the context of **either micro or macro architecture**. Let's discuss each.

## Programming languages, frameworks, and infrastructure

Programming languages, frameworks, and infrastructure can be defined for each **microservice** individually at the **micro architecture**.

- Then each microservice can also be implemented with a different language.
- Technology, such as the application server, that best suits the specific problems of each microservice can be used.

Programming languages, frameworks, and infrastructure can be defined uniformly for all microservices in the **macro architecture**. This is useful if:
- a company's technology strategy allows only certain technologies 
- therefore, only developers with knowledge in certain technologies are hired



## Database

At first glance, this decision seems to be comparable to the decision concerning the programming languages, frameworks, and infrastructure but databases are different because:
- They store data. 
- The loss of data is usually unacceptable. 
   - Therefore, there must be a backup strategy and a disaster recovery strategy for a database. 
   - Setting these up for many different databases requires considerable effort.

**Micro**: Each microservice can also have its own instance of the database. If databases were defined at the **micro architecture**.
- A crash of one database will cause only one microservice to fail which makes the entire app **more robust**.
- However, the **higher effort involved**, especially concerning operation, is an argument
against individual instances.

**Macro**: To avoid needing many different databases, the database can be defined as part of the **macro architecture** for all microservices.
- Even if the database is defined in
the macro architecture, **multiple microservices must not share a database schema**. That would contradict the [bounded contexts](https://www.educative.io/courses/introduction-microservice-principles-concepts/domain-driven-design-bounded-contexts).
- The domain model in the database schema would be used by several microservices. This would couple the microservices too strongly. Even with a unified database, the microservices must have separate schemata in the database.

In this lesson, we'll study some key decisions and at what architecture level, micro or macro, they should be taken.

Preface

Microservices

Micro and Macro Architecture

Migration

Docker

Technical Micro Architecture

Appendix

Architecture Decisions

Micro and macro architecture decisions #

Programming languages, frameworks, and infrastructure #

Database #