 Okay. So, let's start. Hello, everyone. Thank you very much for coming, our session. I am Kenji Kaneshige. I'm in charge of OpenStuff Software Development team in Fujitsu. And I also work in OpenStuff community with you as a board member to expand OpenStuff system. And he is Wolfgang Lee. And Fujitsu is building and offering the digital business platform called Meta-Arc, which covers both existing business work load, so called system of record, and the new digital business work load, so called system of engagement on top of OpenStuff technology. Today, we'd like to talk about the requirements for enterprise crowd and the challenges we meet in OpenStuff from SOR and SOE perspective. And this is the first session of our breakout sessions. So, first of all, I'd like to introduce Fujitsu itself briefly. Fujitsu is Japan's largest IT service provider and number five in the world. There are about 160,000 Fujitsu people working in more than 100 countries. And Fujitsu has a long history, more than 80 years. Fujitsu was founded in 1935 as communication device manufacturer and expanded its business field to computer systems. And now, we are providing technology solutions, ubiquitous solutions and device solutions. Those are our principal business areas. Our thought for the future is human centric. We think the most critical technology is empowering people to work more creatively. Our human centric vision is about putting people at the center of everything. In the era of cloud computing, the border of existing industries are becoming blurred and fluid. The value will be co-created by suppliers, partners and customers. We need a comprehensive platform for this. Last year, Fujitsu began providing digital business platform called MetaArk. It is designed to offer the capabilities of mobile, IoT, data analytics and AI as a service. This comprehensive framework has been designed for our customers to enable their digital transformation. MetaArk is not just focusing on growing new digital business workloads, so-called system of engagement. It covers both existing business workloads, so-called system of record and new digital business workload. It will allow various applications from various industries to work together and create new values. MetaArk is based on scalable cloud infrastructure. We are providing public cloud service called K5. And we are also providing private cloud solution, Prime Flex family, based on the same architecture as K5. Fujitsu has chosen OpenStack to be a foundation of this scalable cloud infrastructure. The OpenStack ecosystem is growing very fast. And Fujitsu can directly participate in the development through the open community. Those are the major reasons why Fujitsu has chosen OpenStack. Last year, Fujitsu has announced that Fujitsu will migrate all internal systems to a new cloud platform K5 based on OpenStack within five years. It consists of 640 systems across 13,000 servers globally. In other words, Fujitsu is migrating all internal systems onto OpenStack and all the Fujitsu employees will work on top of OpenStack. By doing the cloud migration by ourselves, we can continuously improve our platform based on our experiences. And we are offering them to the customers. This is our approach. Based on our experiences, we are trying to feedback the requirements for enterprise cloud to OpenStack through the open community. Fujitsu's activities in OpenStack community is increasing. In fact, we made top seven called Contribution in Newton release. Now, let's take a look at enterprise cloud requirements for system or record and challenges in OpenStack. A cloud native application model is growing. But at the same time, we need to support existing business workers continuously. The goal of computing for existing business work load is to maximize the efficiency. In order to maximize the efficiency by migrating the work load to cloud, we need to continuously provide enough performance, reliability, and serviceability in addition to reducing cost by automation and consolidation. I'd like to talk the requirements for enterprise cloud from compute, maintenance, and supportability point of view today. The first one is compute. There are several demands of cloud offering in enterprise systems. The first one is virtual machine on shared server model. That is the most cost effective and it is used for the workloads which don't require severe performance such as web or development systems. The second one is virtual and physical computing environment on dedicated server model. Some enterprise workloads need physical servers, especially to meet performance requirements for such as database and ERP. Additionally, there is also a requirement to separate the workload from the impact by the other users sharing the same cloud system. For this purpose, there is a requirement of running virtual machines on dedicated physical servers. Most of enterprise or mission critical system in production require this model. The last one is dedicated cloud service platform model. This model provides cloud service platform itself as a cloud service. Users can build their cloud system without having their own data center. OpenStack has capabilities for virtual on shared server model, but it still needs some effort to provide virtual and physical on dedicated server model. Today, I'd like to share the requirement in this model. There are three major requirements in virtual and physical on dedicated server model. The first requirement is capability to provide various computing environments to workloads. The second requirement is the capability to connect workloads running on various computing environments. And the last requirement is unified operation. The first requirement are various compute. OpenStack has developed on top of virtualization technologies, but enterprise workloads need physical server environment, especially to meet performance requirement. And some workload would be migrating to container. So we need to be able to provide various computing environments, virtual, physical, and container. OpenStack already has capabilities to provide various computing environments. Today, bare metal provisioning by Ironic has been officially supported since Kilo. And container provisioning by Magnum has been officially supported since Liberty. The second requirement, connect workers. Enterprise system consists of a lot of workloads. Some of them would want virtual machines. And the other would need physical. And some would be migrated to container. Provisioning various computing environment is not enough. Those workloads need to be connected and work together in order to function as a system. We had a big progress about this in Newton release. Tenant networking for bare metal servers is supported in Newton. Thanks to this feature, we are able to connect virtual and physical servers via network and we can create them for each tenant. The third requirement, unified operation. In order to maximize efficiency, operation for system administrator should be as simple as possible. In addition to that, it would be great if we can enjoy all the cloud capabilities even on physical and container environment as well as virtual machine environment. For these reasons, users should be able to use and operate the cloud functionalities transparently in every compute environment. Since OpenStack has been developed based on virtual servers, a lot of features are available only for virtual servers and not available for physical servers or containers. One example is security group. Security group was developed on top on virtual port concept. And it is widely used in cloud environment. It would be great if we can use this useful feature even on physical servers transparently. And another example is failover. If virtual machine became unavailable for some reason, it would be taken over by evacuation mechanism. If we do it in bare metal, we need additional efforts. Some build is one example. Currently, bare metal can only build from a local storage. So if a user wants to failover to a new bare metal server, the user has to detach the storage and attach it to the new server by hand. Some build enables the software controlled failover even on bare metal. Fujitsu will continuously work with OpenStack community to realize the one platform which allows users to enjoy OpenStack functionalities in every virtual, physical and container transparently and maximize the efficiency. The next one is maintenance. Since there are a lot of different users and workloads working on the cloud, the system failure would have more impact than before. So the maintenance to keep the cloud system healthy becomes more important. When we compare traditional system and the cloud system, there are two major differences regarding the system maintenance. The first one is about the type of workload. In the traditional system, the workload is basically fixed. So the stability of the system is monotonously increased. And once the system gets stabilized in the test phase, users generally don't want to touch the system anymore. On the other hand, the workloads are not fixed in the cloud platform. The users and workloads on cloud are valuable. So the stability oscillates when new workloads come. Another difference is about ownership. In the traditional system, the system is owned by a single customer. All the components or workloads are updated at the same time based on the system lifecycle. The system lifecycle is usually decided based on hardware lifecycle. On the other hand, there are multiple owners on the cloud. There are multiple players running their workloads on the system. They are not related to each other. And there are also an owner of cloud itself. Each owner has its own system lifecycle. And it is no longer possible to align all of those life cycles for system maintenance. So because of those characteristics, the importance of nonstop maintenance becomes much higher on the cloud rather than a traditional system. Workloads are valuable in cloud systems. So we need to update the system continuously and proactively. And there are multiple owners in the cloud system. So it is no longer possible to have maintenance period. Nonstop maintenance is essential in enterprise cloud. OpenStack already has the capability of updating or applying fix with no downtime. But OpenStack still needs some more effort to realize nonstop upgrade. So cloud providers need special aid outside OpenStack for this. However, nonstop upgrade is a common requirement for enterprise. So it should be provided as OpenStack standard feature. Fujitsu would like to work with OpenStack community to realize this requirement. The last one is supportability. In traditional enterprise system, it is required to identify the root cause of any issues in order not to cause the same problem again. This requirement doesn't change even in the cloud system. But troubleshooting in OpenStack is not so easy, as you know. One major reason is OpenStack has a distributed architecture. To achieve the reliable root cause analysis in the distributed OpenStack architecture, logging is the first target to work on. There are three points here. The first one is we need sufficient log information in each component. For example, when we encounter the network trouble, we usually try to identify how far the packet arrives. It is a time consuming job. Fujitsu is now working with community to add packet logging at security group and firewall. These efforts will make the job much easier. Anyway, the first thing to do is enrich log information. And the second is we need unified log format. For example, to know how the request was processed in entire system, request identified across components is necessary. And when we analyze the log information using software, we need standard log header across components. The last one is we need to integrate log information distributed in different nodes and analyze them. Fujitsu is working in monaska project to achieve this. And offering a solution best on monaska. We will discuss it later in our presentation. So first of all, I think my mic is on, so you can hear me. Thank you, Kenji. So first of all, let's do a quick poll. Who of you knows about the monaska project? Can you just... Okay, so it's actually... Okay, that's in a way good. So please stop me if I'm repeating stuff that everyone knows already. What my part in this presentation is to tell you a little bit about the project contributions that Fujitsu is doing. We are saying for the systems of engagement, we're not really religious about this distinction between systems of record and systems of engagement. But it's a useful paradigm to distinguish a little bit, as you know, between the stuff that is in the long-term databases and that constitutes the, let's say, stable knowledge of an enterprise as opposed to the systems of engagement, which are your interactions with your customers, which are your data visualization and their collection apps. And so the requirements for that, of course, can be a bit different. Not so much on the monitoring part, though. And that's why it's maybe a good idea to start with the discussion about monaska. But as an overview for what I'm going to talk about now, you can see here a little bit where we're trying to add value to the OpenStack project in Fujitsu. We're focusing on basically the area of cloud management. At previous conferences, you could see that we are still contributing also to the container orchestration area of work. So we are contributors to the Kubernetes project. At this point in time, we probably will not focus on bringing out our own project in this area. That's a little bit why this area is shaded in gray. But our main focus is on things like the self-service portal. So making applications easily consumable. You'll see more about that in a moment. About the cloud monitoring based on monaska. And we'll start with that because it's the bridge between the SOR and SOE topic. And the third thing that we've gone into recently is to support users of hybrid clouds in managing the cost of their hybrid clouds. So more and more, you can see that using various clouds, it can become quite challenging to keep a tab on where do the costs come from, which projects generate them, how are they going to develop into the future, what would happen if I move a workload from one cloud to the other and all these kind of things we address with a solution that's called Cloud Service Pickle. So after this overview, let's start with the monaska. So monaska is the OpenStack Pick 10 project. Cloud Monitoring Manager or CMM is our Fujitsu version. So it's the basis for our monaska is the project that's a basis for our cloud monitoring manager. Our contributions are mainly in the area of log management and then complex event processing. And we are also official core reviewer. If you are interested to learn more about the details of monaska, there is a monaska bootcamp this evening at five o'clock. We're doing this together with HP and others and our guys are going to be there and you can also get some nice giveaway that contains all the information that you need about monaska. Yeah, you have the list of main contributors here. But since many of you are already have had contact with monaska, I think we don't really need to talk too much about the general stuff. But yeah, so why or what is really the reason why we need a special version of monitoring in OpenStack? I mean, there's so many open source monitoring projects available already today. And so there's basically two reasons why monaska is important for the OpenStack community. The one thing is that OpenStack systems are built to scale. So you need a monitoring system that's also able to scale along. And that's really from the beginning built to be able to scale. Otherwise, the storage and processing of larger amounts of data eventually is not going to work. And the second thing is that you need a cost-efficient way to also handle it for tenant users, for multiple tenants. And I'll show a little bit more in the coming slides what that really means. So first of all, okay, generally speaking, monaska is the turnkey solution in OpenStack configured to collect and present all the important management data. If you go to our booth, our Fujitsu booth, you can see for example, that we deploy, we use a catalog to deploy an application onto monaska, sorry, onto OpenStack virtual machines or also onto containers running on OpenStack. And the monitoring part is simply integrated in that deployment. So when you deploy the application automatically, your monitoring gets deployed along with it. And so while other things like sort of what kind of alarms and notifications you can get, maybe the same for other open source monitoring project. This part of it being built into the OpenStack, being native to OpenStack is something that's very specific to the monaska project. Of course, it has the possibility of, well, and this is, the log management is now the part that Fujitsu has been working on and has been contributing to the monaska project, the collection and management of logs for services, middleware and operating systems using based technologies that are relatively well known, especially since we saw that there's many people here in the room who know about the monaska project. We don't have to say so much about that. The important thing now is, as I tried to say before, is how it's integrated into OpenStack. So it's basically monitoring as a service. It has full support for a tenant model, and the possibility to monitor these VMs is basically configuration less. So you deploy a VM with the, and you immediately can see it or can get the monitoring data in the dashboard. So because it's a cloud offering, it's ready to use. It's out of the box. Of course, it's an open source project. I think in this context, it's nothing special. And it's, and in the distribution that we provide as Fujitsu, it also has enterprise great support. So now, I think I owe you some explanation about how we achieve this scalability. And if you look at how, for example, systems like Zabx do the scalability, when you grow your application, eventually we'll get to a point where you have too many users on one Zabx server, so basically you just have to create a separate server and separate island, and then that island will manage a separate project. And it will not be possible for users from one project to use to view data from another project. So what that means is that you cannot have users monitoring applications in different projects. You have the situation that maybe the way that an operator monitors your applications looks different from the way that the user monitors this application. And here in Monaska, actually everything goes through the same dashboard, through the same monitoring functionality, which means that the operator, of course, has more functionality than a normal user, but he sees he has the same dashboard environment, the same look and feel. And that, of course, makes it easier when we're in a systems of engagement, development, where sometimes in a DevOps environment, there is the borders between the guys doing the development and the operations are not so clear anymore, right? So, and the second thing is that when the number of projects is growing, you simply don't need to eventually, you don't need to build new environments, sorry, new islands when the number of projects becomes too big. So cloud native scalability is the important part here. So if you, we have, as I said, we have the Monaska boot camp. You can see at our booth, we have experts about the product who can show you more details, sorry, this is moving ahead on its own. The second part that I wanted to focus on a little bit is a project that Fujitsu, it's a Fujitsu-owned project that we put open source a year ago in October last year, the open service catalog manager. This project is intended to drive enterprise use of consumption-based IT. So that's really what systems of engagement is all about, right? You want to, you want to make it as easy as possible for your app users to consume those cloud-based services. Most of the work, we are actually also working with the cloud native foundation here to test our open source project here, our open service catalog manager with the goals of the cloud native foundation. Most of the work today in cloud native applications is focusing on making easy execution environments, easy development environments, past environments. Not so much thought is being put into, at the end of the day, how will people be able to consume these applications in a user-friendly way? Yeah? And what we have built is software that's already tried and true in various tasks and infrastructure as a service environment that effectively is a service catalog or it looks like a web shop. You could think of it as a web shop for, as a service environment and it does a various, a number of things. So for the users, it basically, you can see here, looks like a, like a web shop for software enables the users to obtain and launch those resources with one click and a self-service mode. So really intuitive, few parameters, still it can be configured to have whatever complexity you need for a specific system. It's open stack compatible, by the way, certified as open stack compatible. If you use the software inside a corporation, it allows you and some, this is actually one of the important use cases of the software to set up and manage a business-friendly catalog for any type of cloud service, no matter whether it's infrastructure as a service platform or software as a service. And often it's also used by service providers. So companies who have a software and they want to bring it out in a software as a service mode, yeah? For example, one of our customers using it to provide services for their multifunction service printers, right, and actually distribute them over resellers. So you can quickly define cloud services, you can assign pricing plans to it, and of course also change them very flexibly when the market changes, and you can also service reseller models with this software. You can see here a list of, this is more, this slide here is more centered on the infrastructure as a service part, because in the, let's say, last two years, most of the use cases have been about how to provision infrastructure as a service template in corporate environments using the software. And you can see that, of course, we support open stack, we support Amazon, TPS5, VMware, Azure. We also support our own Fujitsu public cloud, obviously, TPS5 and K5. So, and, well, the different, you can see that in every case, every use case, we've been addressing slightly different versions of the API of that, of that, as a service system, depending on the specific customer use cases that we had. So, yeah, okay, before moving ahead too quickly here. So this is an open source project, openservicecatalogmanager.org. If you go there, you can actually, you can download it, you can find Docker image, you can find the GitHub, you can find a virtual experience center to try the system out, you can find a community to join and ask questions. And recently at the Linux con, we also, in Berlin, we also started to develop a workshop, because in terms of external contributions, so far the contributions have been mostly coming from different areas within Fujitsu, but now we're also moving ahead to attract external contributors to this project. Okay. Then, in terms of, well, what is Fujitsu contributing to open source, I still have like a few minutes, right? We also do work, as I said, at the beginning on container orchestration, we are, but again, not, this is a little bit under the hood, because we contribute to the Kubernetes project, we don't build our own project, product based on that. So as many others, we think that it's important for the industry to have this enterprise-ready Kubernetes, easy to deploy, pre-integrated and seamless integration into OpenStack. And actually, at our booth, we show you a demo where we use the Open Service Catalog Manager to provision both a VM-based application, we use WordPress in this case, and a container-based application, which goes on to our Kubernetes cluster. And in both cases, you can see how we also deploy the Monaska monitoring along with it, yeah? So going back to this initial picture that you showed, I showed you where we're trying to simplify the cloud services management above the existing OpenStack technology, making that easier to consume, easier to manage for the end user. And maybe this, by the way, this one container-based application that we show you at our booth is also, I didn't put it into this presentation here because it's not an open source contribution from Fujitsu at this point in time, but it's a quite interesting application to do multi-cloud financial management, okay? Checking how your different costs from different clouds come in, structuring them, analyzing them according to projects, doing forecast, and also doing what-if analysis. Okay. So just finally about where can you find our contributions? Okay, Monaska, that's clear. I mean, our contributions are in the official scope of the Monaska project, and for the Open Service Catalog Manager, as I said, so far we have created our own open source project. We're still thinking about where we can position it inside Linux Foundation. OpenStack Foundation may be, but it's not really limited to OpenStack, so you could see before it's addressing a broad range of hybrid cloud solutions. So for the moment, being at standalone, but we have Apache 2000 based CCLAs, so if someone wants to contribute, you're invited. If you just want to use it, go to openservicecatalog.manager.org. You can see all the use cases. You can see the documentation. You can download the code. And if you have challenges or problems trying it out, you have a really good forum. We'll be very careful to see who has questions and we'll be back to you very quickly if you find challenges. So please talk to us if you're interested. Thank you for your attention. Okay, now you can hear. So any questions about it? It doesn't seem to be the case. Okay, maybe you have some in private that you want to address to us after the presentation, so please feel free. Thank you.