 My name is Wei Min Lu. I'm from Ankara Information Technologies from Shanghai. I'm glad I have this opportunity to talk about our effort on DevOps with Co-Foundry. First, the outline of the talk. Actually, DevOps is one of the components of our effort to provide a solution called SRE, Service Reliability Engineering. We replace site by service from the term coined by Google, Site Reliability Engineering because it's something we think is the right philosophy for operating cloud-based services. First, I would like to talk about customizable DevOps services. Why we should customize DevOps? People like pipelines because they make the automation easy. However, we don't want the pipeline restrict our solutions to really limit the scope for that. We would like to have very flexible DevOps services for the cloud service. Because DevOps, also, we heard about CICD, continuous integration, continuous delivery, continuous deployment. Those two groups of concepts are closely related. We would like to discuss that. Next, I would like to talk about DevOps with Co-Foundry and why we should do DevOps with Co-Foundry. Finally, I would like to share with you guys our more past practice on DevOps. After that, I would like to get into a broader concept, SRE, for cloud services. We would like to emphasize the importance of process management in SRE. Then, I would like to talk about framework for us to deal with SRE for the cloud service. Which means we adopt by model framework because SRE is not just a technology play. It's also maybe more than that on the management how to make the pipeline work for the cloud services. Finally, because we are dealing mostly with the IT system, however, the concept could be easily understandable towards industrial systems, which are like industrial IoT and some other type of solutions because they share a very similar concept to maintain, to ensure the reliability of the services. Let's first talk about customizable DevOps services. Basically, DevOps come to this stage in a long way. Initially, people get used to the waterfall development process, which is very systematic. It's good for a large-scale application development. They need a systematic way to deal with it. However, when the market changes rapidly, this type of waterfall approach really shows some drawbacks to achieve a viable solution to meet the market needs. This whole agile process is come to play. Once we are getting into the cloud era and the cloud services, which promote the rapid changes of the requirements because the user is more accessible to the apps and the apps should be more customized to meet the user's changing needs. People talk about lean development or it fits very well into the DevOps because of very small improve circle and fast iteration and so on. The problem with DevOps, as we experienced before because of the importance, they come up with a lot of tools available in a different stage like build, test, development and so on. It's not very easy for the user to choose which tool is best to meet the needs. For the DevOps, it's traditionally involved three groups of team members. One is developers, another group is QA, and for the service part is an operational team. They really need to have close collaboration once they get into the cloud service area. They need more communication and more importantly, we really need convergence among those groups. There is no clear boundary among them. This is the key assumption or key understanding for us to really develop some flexible DevOps solution. DevOps involves multiple phases in the application software development lifecycle from the planning to development to testing to build to release. Because when we talk about CI CD, there are multiple definitions. What we see because for each group, their understanding about DevOps might be slightly different. For the development team, maybe they can work on the continuous delivery. Their scope is limited from planning to testing of the software they do. They have a lot of control in the later stage for the deployment. For the continuous integration, that's the job for the QA team and for the continuous deployment of the operational team. Of course, that's some view from the past. But as I said, we need to really break up the boundary among these kind of limitations. Why we work on DevOps with Cloud Foundry? Because Cloud Foundry is a very flexible framework. In a sense, they provide a very easy way to integrate tools and services by their open service broker API or some other kind of mechanism. For the DevOps, we have multiple available tools and services like GIT, GITOP, SVN, Jenkins, and also some other type of process and pipeline and services can be built into the Cloud Foundry. Also, for the application delivery or deployment, they have deployed multiple frameworks and runtimes, or you can easily integrate new runtimes into the platform. Always multiple environment support to make the application, the deployment, very flexible. With that, DevOps with Cloud Foundry for our solution, basically we provide a DevOps engine, try to really manage and integrate all the necessary tools, services, runtimes around Cloud Foundry, and then make them flexible when you define your own pipeline for your DevOps. Talking about customized DevOps, we are talking about customized every aspect of the DevOps process. For example, we should be the requirement for the customizable DevOps. We should, flexibly define the process or the pipelines, and we should also be able to define our own tasks, the interface of in the defined pipelines. And also we should have some control, full control, flexible control over the process to make sure a control gate enabled in order to really review the execution results of the pipeline in order to prevent something bad thing happening. And also we need to track the process or the pipeline to the extent we could unlock any execution for the task results and the status so that they can easily display it for people to try to get a picture about how the pipeline is executed. And also we should be able to review all the faces, the key faces of the pipeline in order to make sure the execution is under control. And finally, so we should provide notification functions. So whenever there is something abnormal happens, the relevant parties should be notified. And so if we put things together, a very simple DevOps process can be demonstrated by this figure. And so there are several components are involved like Jenkins, Moven, the GIT gate, SVN, and so on. So let's first define a very simple pipeline for the code release. And so we first need to construct a release process to meet your own needs. So which follow this path. And then for example, they would relate the relevant code with this pipeline, with this release process. And then so depends on the needs, we should be able to set the process or the tasks on the involved. And then we can check the, enable the process to check the code updates and so on. So before release, we should be able to do A-B testing or some rollback or something like that. Anything related to that could be flexibility defined. So with all this, so we should be able to change our previous DevOps process, which as you can see, there's always broken links everywhere. And with this self-defined DevOps services, and so we should be able to really connect them, streamline the process. So in summary, for the customizable DevOps, we could provide options for the customer to define their own standard tasks with customization and extension. And also provide a virtual tool for self-defined faces and tasks in the pipeline. And also support multiple deployment environment to meet different requirements for after release. And also we should provide other necessary tool like logs, analytics, and the visualization for the necessary control. So those are the UIs for different components. And so if anybody is interested and we can talk afterwards about what to schedule a demo for that solution. So far, I just talked about the DevOps. And now I turn to the bigger effort we're working on right now is called service reliability engineering for cloud services. So we change the word site to service because we want to relate this concept to a more broader scope. So for the cloud services and what the basic requirements for the in the production environment. First, we should guarantee service reliability. We should ensure user experience with the cloud service. And also we should be able to provide a cost efficient approach towards the solution. And finally, we should be able to provide operational productivity. So in order to achieve this goal, and so we suggest by model framework for SRE. And of course, the core is technology, but more importantly, in some sense, management is the key to ensure the service reliability. So as you can see the major breakdown of the cloud service like from AWS, Google, Azure, as you can see is mostly related to the management process. How to ensure that? And so we need to build this kind of concept when we design the solution. We really need to talk to the end user and what is their needs. And we need to look into their database for their record for their breakdowns for the services. And we find out and we need to really deal to build the management process into the solution so that it can automate these kind of services. For example, in majority of the situation, once you have some sort of fault, the reboot is the most effective way to deal with some kind of breakdown. And so if the process is not in place and it's hard for the operational team to really wait to reboot the system. But once you have some kind of rule predefined, once some condition is satisfied, you immediately initiate the reboot process. And so they could solve the problem quickly. And the majority of the problem can be simply done by reboot about some kind of services. So this is why we emphasize the management aspect of the solution. For the technology and the most of the people here in this event talking about the DevOps, the operation aspect, they are more or less from the technology point of view. And so for the solution to be really effective, and so we should be equally emphasize the management aspect, even though it's just some simple rule to trigger some action during the problem. So when we talk about operation management, and so what's the problem right now with operational management in the cloud service? Because the tool available right now, we have many tools like I-Tool, E-Tom, Copy, and so on. However, the tools are very comprehensive and complete. They are good. However, for the cloud services, in a lot of cases, they are too heavy and very restricted. And it's hard to really initiate the solution like that during the problems. So again, why the process management is important? Because we really need to provide the management ability, not just tools. Because the tools are something can be defined. But for the management capability, there are something more need to be done. So for, because as I just mentioned, most service outage are due to the management issues. You can never have too much on that. So for the SRE management systems, we should also, because this part is very complicated, it's hard to standardize. So the customizable procedures are important. Just like what I just described, the customizable DevOps. And in this case, all the steps and the forms and so on should be able to customize, customizable. And so that's some kind of, we define some drag and drop approach to that. And we could integrate the operational automation tools with CMDB and some other type of available solutions. So that's our SRE architecture. As I can, we can see the purple part, mostly like with a management aspect about the SRE solution. So we provide the process management engine, so which help the customer automate their management process. And so on. Finally, our effort is to build a more broader SRE solution for general systems like industrial system, because the service reliability is not just required for the IT system. So it's also a very big challenge to all other industry, industrial systems. So the principle for production operations are very similar, all similar among IT systems. And also, for example, the manufacturing system, the nuclear plant operational system and so on. So SRE, even though the initial was designed, I mean the SRE original concept was proposed by Google for the internet services, so it can be easily applied to the industries. So basically that's what I would like to talk about this afternoon. So any questions? And basically there's a very high level of description. And so we, if you want to learn more, and so we can talk about this. And that's my email, and you can drop me an email, and then we can set up some discussion afterwards. Even we can do a remote demo for you guys. Thank you very much.