Deep dive into fundamental knowledge about microservices and background information about the concepts behind the microservices architecture approach.

Microservices Architecture

In this module we’ll learn about microservices in depth and understand the reasons for using and not using microservices. We’ll also learn about micro and macro architecture, strategies for migrating old systems, the role of Docker in this architecture, and technologies for implementing microservices like Spring Boot and Go.

After this module, you’ll be better equipped to implement microservices.

An Introduction to Microservice Principles and Concepts

[Chapter 2](https://www.educative.io/courses/introduction-microservice-principles-concepts/introduction-N7Y2ZzKNl1p) defined microservices as separately deployable units. The separate deployment not only results in a decoupling at the architectural level, but also in regard to
technology choice, robustness, security, and scalability.

## OS processes for microservices

If microservices are supposed to have all these characteristics, the question arises as to **how they can be implemented**. Microservices must be scalable
independently of each other. In the event of a crash, a microservice
must not be allowed to make other microservices unavailable, too, and
thus endanger the robustness of the whole system. Therefore,
**microservices must at least be separate processes**.

**Scalability can be guaranteed by multiple instances of a process**. When an application is started, the operating system generates a process and allocates resources such as CPU or memory to it. Therefore, more processes
can use more resources. 


But processes are limited concerning
scaling. If the processes all run on one server, then only a limited amount of hardware resources are available.
Instead, the microservices should run in a cluster. Kubernetes and Cloud
Foundry support running microservices in
a cluster.

**With processes, robustness is guaranteed to a certain extent** because
the crash of one process does not affect the other processes.  However, a server failure still causes a large number of processes, and thus microservices, to fail. 

But there are also other problems: 

- **All processes share one operating system**. It must provide the libraries and tools for all microservices. Each microservice must be compatible with the operating system version. It is difficult to configure the operating system to support all microservices. 
- In addition, the processes must coordinate in such a way that each process **has its own network port**. If you have a large number of processes, it becomes increasingly
harder to find unused ports. Also, it's hard to figure out which ports are used by which process.


[Chapter 2](https://www.educative.io/courses/introduction-microservice-principles-concepts/introduction-N7Y2ZzKNl1p) defined microservices as separately deployable units. The separate deployment not only results in a decoupling at the architectural level, but also in regard to
technology choice, robustness, security, and scalability.

# OS processes for microservices

If microservices are supposed to have all these characteristics, the question arises as to **how they can be implemented**. Microservices must be scalable
independently of each other. In the event of a crash, a microservice
must not be allowed to make other microservices unavailable, too, and
thus endanger the robustness of the whole system. Therefore,
**microservices must at least be separate processes**.

**Scalability can be guaranteed by multiple instances of a process**. When an application is started, the operating system generates a process and allocates resources such as CPU or memory to it. Therefore, more processes
can use more resources. 


But processes are limited concerning
scaling. If the processes all run on one server, then only a limited amount of hardware resources are available.
Instead, the microservices should run in a cluster. Kubernetes and Cloud
Foundry support running microservices in
a cluster.

**With processes, robustness is guaranteed to a certain extent** because
the crash of one process does not affect the other processes.  However, a server failure still causes a large number of processes, and thus microservices, to fail. 

But there are also other problems: 

- **All processes share one operating system**. It must provide the libraries and tools for all microservices. Each microservice must be compatible with the operating system version. It is difficult to configure the operating system to support all microservices. 
- In addition, the processes must coordinate in such a way that each process **has its own network port**. If you have a large number of processes, it becomes increasingly
harder to find unused ports. Also, it's hard to figure out which ports are used by which process.


In this lesson, we'll look at some reasons for using Docker for microservices.

Microservices

Micro and Macro Architecture

Migration

Docker

Technical Micro Architecture

Appendix

Conclusion

Docker for Microservices: Reasons

OS processes for microservices #