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


## Increased operations effort

- The *operation* of a microservice system **requires more effort than running a deployment monolith**. 
    - This is due to the fact that in a microservice system, many more deployable units exist that all have to be deployed and monitored. 
   - This is feasible only when the operation is largely automated and the correct functioning of the microservices is guaranteed via appropriate monitoring.

## Must Be Independently Deployable

- Microservices have to be **independently deployable**. For example, dividing them, into Docker containers is a prerequisite for this, but it is not enough on its own. 
- Changes to interfaces must be implemented in such a way that an independent deployment of individual microservices is still possible. 
    - For example, the microservice which implements the interface has to offer the new and the old interface. Then this microservice can be deployed without requiring that the calling microservice be deployed at the same time.

## Testing must be independent
- Also, **testing must be independent**.  When all microservices have to be tested together, one microservice can block the test stage and prevent the deployment of the other microservices making testing much harder. 

- Due to the split into microservices, there are more interfaces to test, and **testing has to be independent for both sides of the interface**. 





# Increased operations effort

- The *operation* of a microservice system **requires more effort than running a deployment monolith**. 
    - This is due to the fact that in a microservice system, many more deployable units exist that all have to be deployed and monitored. 
   - This is feasible only when the operation is largely automated and the correct functioning of the microservices is guaranteed via appropriate monitoring.

# Must Be Independently Deployable

- Microservices have to be **independently deployable**. For example, dividing them, into Docker containers is a prerequisite for this, but it is not enough on its own. 
- Changes to interfaces must be implemented in such a way that an independent deployment of individual microservices is still possible. 
    - For example, the microservice which implements the interface has to offer the new and the old interface. Then this microservice can be deployed without requiring that the calling microservice be deployed at the same time.

# Testing must be independent
- Also, **testing must be independent**.  When all microservices have to be tested together, one microservice can block the test stage and prevent the deployment of the other microservices making testing much harder. 

- Due to the split into microservices, there are more interfaces to test, and **testing has to be independent for both sides of the interface**. 




In this lesson, we'll look at possible challenges involved in a microservice architecture.

Microservices

Micro and Macro Architecture

Migration

Docker

Technical Micro Architecture

Appendix

Conclusion

Challenges

Increased operations effort #

Must Be Independently Deployable #