 My name is Fei Yao. I am chief architect for SAP. I have been working on cloud and cloud data for a long time. I'm really passionate about using cloud-native technology to build highly available, highly scalable, and secure applications for enterprise. Today, I'm with Nick. Nick, you want to introduce yourself? My name is Nick Niles. I'm a field engineer at SoloIO, and we've partnered with SAP to help them design and implement their ServiceMesh strategy organization-wide. I'm going to hand it back over to Fei to talk about what they're doing with ServiceMesh today and what they're going to be doing in the future. SAP as a technology company includes a wide range of verticals from IoT to machine learning, artificial intelligence from blockchain to big data, from cloud computing to intelligent cloud, and a couple of wide range of application and services, which includes EIP, finance and CRMs, spend management, people management, supply chain management, and many, many more. We offered over 50 plus data center globally, running our workloads across multiple hyperscalers, AWS, GCP, Azure, and Ali cloud, together in our hyperconverged data centers. We have heterogeneous environments. It's a hyper cloud environment. We use our Kubernetes service called GUNNER as open-sourced Kubernetes service to manage all our Kubernetes workloads. We have over 7,000 clusters across globally. All of those services and application rounds on top of Beniz technology platforms, short for BTP, really is a try to bring about intelligent applications with database and data management, analytics, integration, extension capabilities into one platform. That one platform for both cloud and hybrid environment, it truly makes us the best Beniz cloud in the world. Yeah, many live Beniz currently either has been using service mesh already or in the journey of adopting service mesh, such as Concur. Concur has been using service mesh way before its deal, Concur using envoy-based proxy to manage all the workloads. Ariba is our e-procurement source to pay in a supply chain cloud solution. Ariba will use service mesh to bridge the multi-cloud hyperscader clusters to build that service mesh fabric for the interconnectivities. CSE is our intelligent cloud suite. It has been using STO for its production workload. Kima is our open-source solutions extending application with service function and micro services, which is run on top of Garner. SuccessFactor is our faster growing human resource solutions in market. It is in the journey of adopting service mesh as well. The artificial intelligence framework is using service mesh as well. For example, so SuccessFactor is one of the forerunners to try the technologies to bring this technology to the bigger organizations. Currently, SuccessFactor is only a small part of it. One of their services, micro services running in the hyperscader and another part of it, machine learning service, runs in the virtual machines in our converged cloud environment. This is truly hybrid cloud solutions. Right now, there are a lot of complexity components we're using console. We build a service discovery into the applications, but we want to move more and more of this network, a related function such as service discoveries, low balancers out of the application and let engineering teams focus more on building features for our customers. More importantly, for the workloads that are not suitable to run the container as environment, in this case, be able to join service mesh and benefits from the service mesh or the benefits that service mesh provides like containers running in the Kubernetes. AF is another front-runner project which is run in 250 workloads. It has over 3,000 parts per cluster. It's running the KF serving and the service environment. It is using Istio to manage all their traffic internally. I think you showed off some of the lines of business here at SAP that are using service mesh, but they're using a wide variety of technologies to achieve that service mesh solution that they want. Can you talk about how a business technology platform is getting involved with these lines of business in terms of service mesh and adoption? You can tell various lines of business at a different stage of either using or adopting service mesh. As a company, we really want to step back, think about how should we standardize service mesh with various capabilities including routing and security, etc., and really remove the burden for each line of business and build a service mesh as a service. Great, thanks. You mentioned security. I'm sure as most of our audience has seen and read this article from the NSA about adopting a zero-trust security model. I'm assuming SAP has a top of mind when adopting, probably a reason why you're adopting service mesh is to solve some of those problems. Can you go into more detail about what SAP is thinking about in terms of security and what you think about the zero-trust security model? On the next slide, I know this document talks about pretty much the hardware all the way up to the software, but we know with service mesh how SAP is dealing with limiting access to applications and sensitive data. Yeah, absolutely. Security is paramount in our industry. The world has changed from trust by verify to never trust always verify. That assuming bridge has happened and bad actors has already in your network is essentially the mindset of their trust. Following DevSecOps and shift left security principles, service mesh allows us to build security from a get go without the heavy lifting from product engineering teams. Of course, security should always be later approached. There are other aspects such as application security, data security should be taken care of outside of service mesh. For SAP at a minimum, we want to use service mesh to enforce zero-trust policies. For example, service-to-service communication must enable mutual TRS, and user authentications must be enforced before getting to network, and all workloads must implement non-passable policy enforcement points to deploy fine-grained access control policies. It is still worth such as authorizing policies has to be in place in all workloads. Last but not least, access logs must be enabled for the later forensics logging and auditing, etc. And a couple of things to really stand out. Fundamentally important, one of the PKI's at SAP, we have our tiered PCA infrastructures, and we have our off-light root CA from SAP. Then we have intermediate CAs for various landscapes, one of the service mesh. Then we have a tier two CAs to drive the certificate change, essentially issue the certificates to the workloads. Do you want to talk a little bit about why having a really strong PKI infrastructure in place really enables you to utilize service mesh to a greater extent? Yeah, I think that most of the secure bridges are at exploitation of the old trust model, and without identity, there would be no trust. Identity has to be given and verified and authorized and also tracked. Hence, there is authentication, authorization, and auditing. And tools such as spires can help issuing universal identities and build a trust and scale. So we've talked about a lot of it, what SAP is doing and architecting in terms of service mesh, but how do you actually plan on delivering service mesh to these lines of business in a unified fashion? That in itself sounds like a pretty tall order. Yeah, absolutely. It involves many, many parts. Ideally, at a BDP, we want to offer a given holistic architecture or technology guidance across the whole landscape. And in particularly internally, we have a project called ATOM. The goal here is really is to build a mesh and a service to build that dedicated infrastructure layers that can take care of all the network functions for service-service communications within the clusters, among clusters, and across clusters, across AZs or geographic boundaries. And if we go one layer deep, this is of course, the core of the ATOM is really built around service mesh. And we also want to bring the API gateway into this as well to bring traffic north, south, east, west as a whole to get a provide token services and a private identity as certificates to build this as a service as a managed service provided for our online businesses. If you let's dive one layer deep on this typical building block we have as a single cluster, all workloads will have ingress and egress. All workloads will have full observabilities building to track to have metrics, logins and metrics. And policy can be either enforced through a steel authorization policy or through external authorization such as OPAs. And we will use our existing PCA infrastructure to issue certificates. So this is a building block for mesh and services. From this building block, we have multiple layers of meshes. From the very left, we can consider it as a single cluster mesh. Then move up to the right depends on the organization structures and the team structures and responsibilities. There is a need to have multi-cluster meshes. And then move to the layer two, to see that even bigger LBs have geographically distributed for multi-clustered environments such as Arriba. Arriba runs in the GCP also at the best as well. We need to provide the capability to use the service mesh to bring those together. And last but not least, we want to we want to view this, view the traffic from north to south, from east to west as a one network fabrics. In other words, traffic typically before for one LBs, we have to go egress, outbound, internet, come back to another line of business, not only has security challenges into the compliance, but also increased latencies. We want to use service mesh to be able to bypass that, allow new 2TS amount, line of business, without going outbound during the data come back. If you look a little bit deeper on that, what we try to achieve here is one line of business on the left, the traffic workloads, if they intend to reach another workloads into another line of business, doesn't matter its geographic location, it all goes through egress of its own mesh and go to SAP managed edge gateway. And those edge gateway will be provisioned through SPIR, which is speed implementation with federation to provides mutual 2TS, which provide a universal identity on those line of business and a traffic from one line of business to another line of business, also mutual 2TS. So we are very exciting for the service mesh journey, definitely still a work in progress. We are continue looking forward working with communities and industry leaders. With that being said, I want to also thank many technology and engineering leaders and architects for their visions and continue the efforts around a service mesh for SAP. And with that, I will conclude our talk and thanks for your audience. Let us know if you have any questions. Thank you very much.