 OK, we're going to get started with the next session. This is the Cloud Containers and DevOps track. Our next speakers are Nam and Dai. They're both software engineers at Fujitsu. They're going to be talking about rolling upgrades in microservice systems. So without further ado. So hi, guys. So thank you all for being here. Today we come here with the topic of rolling upgrades in microservices. And by the way, I'm Dai. And I'm working as an upstream developer for OpenStack in Fujitsu. And this is Nam, my co-worker. And if you want to know what the world is, it's an open stack user, open stack community in Vietnam. So in this talk, we want to talk about microservices. And we want to talk about the rolling upgrades. And we really want to show you a big example for rolling upgrades in microservices. And we also want to get more questions and more comments from all of you. But feel free to interrupt at any time. So let's start with the first part. OK, guys. Before we are understanding the what is rolling upgrades, I would like to introduce about what is microservices. And as you can see, microservices is an approach to application development. And with a large application, it's built as a set-up of model service. And each of services will take care of specific function or function. And if your application converts to the microservices approach, you will get a fixable, more stable, and faster, and easier to update. This is a funny picture. You can see that this is a microservices approach. And with many goldfish, and you can see it sucks. And what is sucks? So before we have a microservices, we have a monolithic architecture. You can see immediately that if you want to build an application. And with the monolithic architecture, you will build some function in the single service. And this is the interactive with other APIs. But there will be problems when your application corrupt. Because with monolithic architecture, if your application is very big, so at that time, it's very hard to scale out and or scale up and or maintain the code. Because at that time, the code is very huge. However, with microservices architecture, instead of building the single service, we will split the many services. And each services will take a specific function. With microservices architecture, we can get some benefits like independent development. One single team, we can focus on developing, testing, and deploy the each microservice. In independent development, it means that each team can deploy the other edge service with a small focus team. Each team, each team, we can take care of specific with the smaller code. That means it's easy to get started with when we have a new employee to join the service. Failure isolation with microservices, normally we have a S.A. solution for each service. So it means when each service dies, it will not affect the whole application. Mixed technology is that you can decide to choose what technology to get the best performance for each service. Independent scaling, when we have a lot of users using the application, you can scale out each service to respond to API requests from user. That is the microservice. And we have the benefits of microservice. After that, we will show you what is your rolling upgrade feature. OK, so in this part, I want to show you about the rolling upgrade and some sensitive point during your rolling upgrade process. So I saw that one of you agree with me that no matter what programming language are you using, and no matter what platform is our application running on. And someday we need to upgrade our application. So for some upgrade common way, we have the blue, green, and we have carry. And for blue, green, we need to prepare new similar one clutter like the old one and just switch on the user to from old version to new version. And with carry, we do the same thing, but we just start with a small, so small clutter, and we gradually switch user from old clutter to new clutter. And both of these, we need to interact to the external layer like LB or SA. And so now I want to introduce about the new solution for upgrades that we don't need to prepare. We even don't need to prepare new clutter. So actually, we have so many definitions about rolling upgrade from Oracle, from VMware, or from something else. But basically, rolling upgrade allow a distributed system running well while we upgrade part by part of system. And so what new in rolling upgrade? With rolling upgrade, we don't need to use the new database. And we use the same database for both of the old version and new version. And we also don't need to interact with the external layer. And we also don't need to require many physical resources for the upgrade process. But for that, we need to require some compatible, quite compatible in self-service. And we may have some doubt time. So how rolling upgrade work? Amazing, we have two service, service A and B. And both of us communicate with each other via HTTP. And inside each service, we have some components that communicate with each other component via MSQ. And when service A and service B is serving the user, we can upgrade the system part by part. And this is transferred with the user layer. And be aware that during the upgrade process, we will have two versions. Both of the versions will communicate with each other. So we need to care about the API interface. And we need to care about the database. And that's why during upgrade, we have some sensitive point around API and MSQ. I mean, HTTP API and MSQ interface. And we need to care about the database because we are using the same database for both of the versions. And we also need to take a look on some changes in backend. So what's the problem? We can change the HTTP interface or some MSQ interface. And we also need to add some column or some table for the database. And maybe we're using some backend just to change something in the new version. And during upgrade process, we need to care about that. And maybe we can solve the problem with some Cosplay. And this is solution. That we need the multi-version interoperability for some interface like HTTP and MSQ interface. And we need a mechanism like online schema migration to minors the database between the old schema and new schema to get to for both of the versions working well in the same database. OK. And now we need to show you a very, very big example about this rolling up in microservices. OK. I believe here, anyone here familiar with cloud computing and OpenStack? Our view of OpenStack is an open-source community to implement the cloud computing and provide some resource like storage, network, and compute via API. And most projects in OpenStack already implement the microservice architecture. For example, we have a Cinder project. And Cinder project is a project to manage volume in OpenStack. And you can see here, with Cinder, we have four main components. First, it's an API, Cinder API, to explore API and get requests from the other project or user. Cinder scale to scale when we create a new volume. And Cinder volume to create new volume. And Cinder backup to backup volume. You can see here, each component in Cinder interact with each other by AMQP. AMQP and interact with other projects via RESTful API. This is the microservice architecture. And for now, Cinder already implement the rolling up rates in Cinder. So what's the main point Cinder needs to solve to get the rolling up rates? The first thing, it has a multi-version interoperability and organize schema migration. First, the multi-version interoperative with the API versioning. In the beginning of Cinder, Cinder already implement the Cinder v2. But for now, Cinder already Cinder v3. However, user still can send Cinder v2 to the Cinder v3. It means that Cinder v3 already support the Cinder v2. And you can see here, if the user sends version 3, this is the code, and Cinder v2, this is the code. That is the code in Cinder with the multi-version interoperability API micro-versioning. Inside of Cinder v3, we have the different Cinder version, like Cinder v3.2 and Cinder v3.22. You can see here, if the user sends the Cinder version, this code is checked, the Cinder. If the user sends the version 3.0.2.1, Cinder version will append some information like that. With the AMKP, as I mentioned that, Cinder Scaler will interact with Cinder volume via AMKP. It means that in scale-up, we're rolling up rate feature, we will update each component at that time. So it means that if the Cinder Scaler already updates the code in Cinder, we will check. In scale-up, Cinder Scaler wants to send a message with the version 3.5. But we don't upgrade the Cinder volume. It means that Cinder volume is only available with Cinder 3.0. At that time, the Cinder Scaler at the new version needs to check before sending. And you can see here, here's the code. If we can send the Cinder, if Cinder cannot send the version 3.5, it needs to round out the version before sending. You can see here. With online schema migration, normally we have two solutions to solve this problem. The first is trigger bay. It means that we use trigger function in database. And the trigger less means that don't use a trigger. And normally, we have three phase. The first is expand phase to when we want to create a new volume or new table in database. The second phase is migrate phase to myro data from old schema to new schema and contact phase to delete old table or column, which are not no longer used at end release. That is three phase. And however, the online schema migration instead, we compile the three phase into one phase. It means that Cinder needs to create a new two rule. The first rule is scale up. If the column at the end release, if the column A will be not used at the end release, and we need to add a new column or table at the end release. But however, at the end plus one release, there will be two rules. The first rule is don't allow to remove A, and the rule two is can add a new table or column, but the default value of them must be none. When we upgrade to end plus two release, the column A will be no longer used. So at that time, we can remove the A column or table. That is something Cinder already shown to get the rolling update. And we already tested the rolling update in Cinder, and the result is quite good. And maybe during update, we have only one or two requests to fail requests. That's only one or two fail requests. With that on, Cinder gets a rolling update. That is our presentation. Thank you for listening. And do you have any question? Is there any question? Thank you again. OK. Well, we have a bit more time to the next speaker, but if they're here and want to get set up a bit early, we'll.