 Okay, last up in this module, we'll talk about the recent hype topic of microservices. So this derives from the SOAR architectural style, and as I said in the previous recording, SOAR never really took off because it was more heavyweight, more difficult than expected to standardize all these interfaces, so therefore people added this micro to somehow indicate we still would like to have services, something that provides a value. One component has a certain value, but it should be rather small. Should be rather small things, and they're easy, they're somehow lightweight. Now there is some kind of disagreement in practice what this actually means, as it's often the case with these topics that become very popular. So somehow it's a micro, it's a small service, and your application is composed of all these different ones. But generally they agree the different people that a service should be a component, so some kind of component that can be deployed independently. It should somehow be organized around this idea of capabilities, so it offers some kind of business value, some kind of functionality, every single of these services, and then the product is a composition of these different services. And there are a number of things, I'm using the list from Fowler here, also if you look at the slides I would very much recommend you to read his blog post and maybe look at the YouTube videos, because he's definitely better than me at explaining this, but essentially there are a couple of concepts that he considers central, and one of them is for example something that is called smart endpoints and dump pipes. And that basically means that while the value, the functionality, the smart implementation is in these components, in the services, the connections between them should be rather straightforward, rather easy. And that's for example to make this composition of services very easy, to not have this problem that the interfaces have to be standardized and you have to provide all this semantic information, so they should be as simple as dump as possible, the actual logic is then all in the endpoints. They should somehow be decentralized in the sense that there's decentralized governance, there is not one unit, like one architect that says this is how we put everything together, but it should be dependent on the components, the teams that implement these components they discuss, okay, this is how we have our communication between us, this is how we compose our services together. And the other thing is decentralized data, so ideally every component, every microservice should have its own data, that you don't suddenly run into the problems that everyone is accessing the same database, because then you have to agree for example on how does the data look like. So that's one issue. Another concept which is very important in practice is design for failure. So the whole system should be designed and tested in a way that single components, single services can fail, can drop out for a duration and the system should still be able to recover and to run. So this overall concept is very impressively demonstrated for example at Netflix where you have a huge amount of small microservices, you have tests that take services, crash them essentially and see whether the system recovers from it. So there is a very high, a large focus on design for failure and there is a large focus on automating, for example testing, automating feedback from users and all the infrastructure that you need, automated builds, automated deployment. Now why do we do this? So you still have the idea that every team has one service, has one component and the good thing here is independence. So if you are responsible for one thing that gives customer value, business value, you can decide how to do it, you can get feedback from the user when it runs, you can decide to deploy whenever you are ready, you are essentially independent of the others. If you for example manage these dump pipes very well, you can make your own implementation decisions without having to communicate all the time, how should the interface look like? How do we change this? Similar with the decentralized governance. So if there is not a single database, you don't have to have these discussions about okay we need to change the database schema, how do we do this? You can decide that yourself. You can also have technology independence because if you have your own data, if you have your own service and if the interface between is generic, you can actually implement in whatever language you like. So you could have a Python microservice, you could have a Java microservice and a JavaScript microservice all running and communicating with each other. You could have the database that fits because different databases are suitable for different kind of applications. So it could be that someone has a no SQL database, someone has an SQL database and they still work together. So you are quite independent on the technology level. You have independent deployment and this is an extremely important thing. So one team can deploy their service whenever they want 100 times per day without having to wait for the others. So in many applications you have to wait for the others to complete and that's something you don't need in this case. And then finally we have the concept of elasticity in the cloud that you can have multiple of these services and they can run in parallel if you need more resources. So that's all I will talk about in microservices and this concludes the architecture module.