 Okay, now as a final thing we'll discuss, we'll essentially revisit a lot of the things we did in this course. Now, if you have paid close attention to all the recordings, you might have noticed that what we did most of the times where we talked about the planning of the software, we talked about the coding, about the implementation, maybe smaller design decisions. We talked sometimes about that we need to build the product, for example, compile it, integrate it with dependencies, get it to run, for example, in continuous integration. And then, of course, we talked regularly about the testing. So we need to make sure that the software has the right quality. And once we have done that, we are ready to release. So we put everything together and we can deploy. We can actually send it out to the end users. And this is something that is quite traditional in software engineering. It's usually what we talk about in the V model, for example. You plan something over a number of steps, you implement it, you test it, done. What has been recognized over time is that the actual operation of the system. So running the system, getting feedback, that's not so much talked about here. But there is a lot more to that. So once you have deployed it, you actually need to operate it. You need to run it on a server or on the cloud. You need to make sure that it runs smoothly. You need to monitor it. Are there any changes? Is anything wrong? Are things crashing? Do you need more resources maybe? And, well, usually, this leads to feedback. So you end up in the planning again. And what you see here is this eight or this continuous loop. This is a figure that is rather popular in the area of what is called DevOps. So that's a word that is simply a joint word of development and operation. So the focus here is to highlight that operations are actually really important. We should not separate that. We should integrate that into our development. The idea of DevOps is basically to put those things together. The team that implements something, that plans, codes, builds, and tests also is responsible for releasing, deploying, operating, and monitoring the system. So there is a loop. They don't throw away the software to the customer. And the customer does whatever he or she wants. They are doing that as well. And, well, the idea is that, first of all, it's continuous. You actually get feedback. You can improve things over time. And the idea is that we kind of close the gap here. That feedback does not take as long as it might have taken otherwise. For example, the user, the customer realizes something. And a month later, you get some feedback. By that time, the team has long forgotten what they did. Even worse, the team is usually busy doing something else. So they don't directly have time to react to that. So DevOps essentially should address this. Now, DevOps, similar to things like microservices, like Agile in the beginning or Lean, is one of those words that is being used in a lot of different ways. And it's a bit of a hype. So be careful whenever you read DevOps. But it's essentially about this loop. It's in practice. If you read blog posts, industrial posts, it's very often reduced to the technical level. So what kind of tools do we have? But it's not all about that. It's a lot of practices as well. So it's important to recognize. The other thing that is quite important is that it actually has consequences to the architecture of the product. Because if you want to do this, then you need to ask yourself, how do I design a product that I can deploy regularly? So you want to release, get feedback. Once you have finished with the feedback, you want to deploy again on a regular basis. How, if I do something wrong, for example, you do a cannery test, cannery release, how do I actually roll back changes? So can I undo a feature again? Can I kind of hide a loop? Is there a way to do that? And then finally, we have monitor here. How do I actually do that? How do I get the right data that gives me valuable information? And these are things we have discussed. So continuous deployment, we have discussed. It's not only on an architectural level, but it's also the practice. Do you have the right tests to do that? Do you have things like, for example, feature toggles that are easy without rewriting the entire code? Is it easy to take a feature out again? Monitor, that's essentially the measurement. So how do you measure the things that you want to measure? And what are those? What is relevant to know? And then something we haven't talked much about, is of course the technical aspect. How do you get that monitoring data in an efficient way? So there are consequences to this. Very often, and that's why you will hear these words together, very often this gets associated with the microservice architectural style. So microservice, if you remember that from the architectural lecturers, are small services that are separated, that are essentially independent, they can be deployed independent, they can be rolled back similarly. The team, one team is doing one service, so exactly one team is doing this entire loop. It's a service, so it has direct customer value, so they can actually get new requirements in here and put them into a feature, release them, and essentially this style fits the idea of DevOps very well. So that's why often these two concepts get associated and get mentioned in the same blog post or whatever you read. It doesn't mean that you have to do microservices to do DevOps, but the reason why you read them together is that they are a good fit, supposedly. Now, a lot of topics you want to talk about in DevOps are about technological things, and in particular about the infrastructure as the same goes for microservices. You have this loop, how can you support it? What are the right tools that you can actually deploy and release regularly, that you can operate it, you can maybe scale easily, that you can do these kind of, for example, A-B testing in a good way. So it's a lot about tools, and that's why they were such a high important focus on that in the industrial discourse. There is a lot about testing because you want to automate things, you want to test and then deploy ideally in a continuous way to use continuous deployment. So a lot of it is about how do we test this in an efficient way. And then we get into also techniques such as continuous experimentation, how do we actually get the right monitoring data. And I've already mentioned this, it's about configuration management because in the end of the day, all the infrastructure you're using, there is a lot of configuration tools. So as for example, how do you actually set the right scripts for your CI solution here? How do you configure the monitoring? How do you configure, for example, how the cloud operation runs? That's very much also a focus here. So you will encounter these things. Those are more kind of the technological challenges, I would say. There are definitely also social or human challenges in here that you might want to look at. For example, if you go for a DevOps process, your team roles might change. So suddenly you have to consider how to operate things. And that we have discussed that before organizational change is very often resisted by people. So this can be very hard because they might not want to adopt this or they might not let go of their old focus that they had. Microservices or if you have any other solution, how do we actually coordinate things? So my team wants to deploy something. Is your software product ready that you can deploy without messing with someone else's code, for example, with someone else's service? So this is something that is a matter of coordinating between teams, communicating, discovery. So how do you actually get the time and the practices to regularly get new requirements to get new ideas what to release and deploy? Is there a good process for that? So that's again something that can be difficult. And then something that is always on the table since we started doing agile development is how do you actually get regular customer feedback? So maybe in some solutions you can actually monitor the end users in a very good way in a web-based system, for example. But generally how do you ensure that you get this continuous feedback from the customers? And that might not be trivial at all. In particular if they actually resist this, if they don't want this. So are the customers accepting this that you want to go for a DevOps solution? But overall I think this is actually a good wrap up for the course because it brings a bit everything together, that you need the architectural considerations here. You of course need all the practices we have discussed in design and implementation. You have a requirements circle, a cycle that you get new requirements in constantly through monitoring, but maybe also through talking to your customer on a regular basis. And of course topics such as security are always an issue here so they don't go away. And finally just as everywhere else we have the human factors that affect how well this works. So this concludes module 10 and thank you for your attention.