Everything started with a monolith, being too big, too complex, too slow to develop, and scaling for bad reasons. We used domain-driven design to subdivide an ecommerce application into several subdomains. Covering different business functionality, each subdomain right-sizes its team. Being independent, each team versions its source code and its documentation at its own pace. This agile in devops team is solely responsible to develop, test, and deploy the user interface, the microservice, and the database. But at the end of the day, the UI components will all be aggregated into a single user interface that needs to be responsive and displayed on different devices. That's when the separate teams need to be coordinated to get a final product. For that, we need a gateway, so the user interface accesses the different microservices in a united way. Microservices need to exchange information. This starts at the database level where information has to be synchronized in an eventual consistency manner. Then this communication goes up to the microservice, which can use synchronous or asynchronous remote method invocation or messaging. To be able to document the APIs, microservices need to expose API contracts, so the other microservices know how to invoke them. And become remote communication can fail, circuit breakers should protect each call. The gateway is the perfect entry point to deal with cross-cutting concerns such as service registry, authentication, and authorization. But remember that authorization has to be done by all microservices, passing an access token on each call. Then comes monitoring. This is a very important part in a microservice architecture. For central monitoring to be efficient, your microservices need to expose a health check API, write logs and exceptions, measure each call, and correlate each invocation to create a chain, audit any user activity, and protect the APIs with rate limiting. Monitoring needs to be automated to generate alerts depending on the behavior of the entire system. All these microservices, the gateway, the broker, the databases, everything will get deployed on physical or virtual servers, on-premise or in the cloud. That's when you start using containers, orchestrators, and continuous integration to help you deploy all these complexities frequently. And of course being a distributed system, the microservice architecture will use every network equipment you already know, such as firewalls, switches, or routers, for example. One advantage of microservices is that you can scale them independently depending on the needs. But you also need to make sure that the entire system is reliable. So any single point of failure needs to be duplicated such as the gateway, the monitoring system, or the service registry. You will have some of these moving parts in your development or test environment, but you will definitely bring all these together in your performance and integration environment, so you can get as close as possible to production. Yes, you will need most of these boxes and arrows to get your ecommerce application up and running. It looks a bit complex, doesn't it? But in the next module, you will see the benefits and drawbacks these can bring