 Hello, thank you for being here My name is Noris Samo Sarenko. I'm a DevOps on cloud architect at SVA GMBH is a company in Germany. We are doing professional services and server via migrations and managed services a huge bit of portfolio and Currently a double-mosing the area of containers OpenShift and distributed systems in the public sector Today the talk will be about using OpenShift serverless to kick-start cloud native adoption and patents in a regulated environment and the government organization a German one I can't name the specific client and Details about the architecture technology. So bear with me if you have any questions regarding that come directly to me And I can open a channel to you for you to contact our client Yeah, so that's me if you want to connect there are the contact information so you can scan the QR code and write me a message and we can chat up and Do some other if you have detailed questions. Just hit me up or you can find me downstairs So SVE just to share it wrap up what what is SVA or as for our in German and we are company Mainly come coming from the service side to the managed services and now going more and more into professional services And we are big wretched partner and also working with a lot of specialists in the area of wetted OpenShift currently And here is some some of the achievements We have we have two different partner on levels with wretched as well as in Germany There is an award for the best service provider and we're from one dot three times in a row so far The last three years and just a slide so that you know who we are and then we write type right deep into the The problem or this the why do we use OpenShift serverless? So first of all it's in to understand that the public sector they have they are not similar to a startup the organizations You're usually very complex So there is a functional divide about everything that someone has to do so the responsibilities who does what that makes it very hard to To do some collaboration, especially in the agile field So in essence if you look at in a public sector or government organization, I would from USAGO You will see like you have a structure like departments. You have groups in that departments units in that departments and application teams and At the moment it was like historically like that that Some of these applications have to adhere to specific laws So they are very strict in how they get deployed and which laws they have to apply to Adhere to and how they get implemented and also the life cycle is very how do you say very stale So you can't do much innovative work because the laws are kind of limiting you how you do stuff And in that sense, especially in the sense that we're building more the customer the client is building more and more Applications going into the cloud native route. So as Mr. TK showed the German Government agencies or organizations are more and more also going that route with cloud native adoption and microservices there is like Conflict of the applications. How do you do this in the organizations as strictly divided into hierarchies and functional? responsibilities and during the years with the introduction of microservices and server oriented architectures You might see applications connecting to each other So the measure of applications gets more and more complicated because everyone is calling each other and soon You will have a mothball of applications You cannot really manage anymore or you don't even know who is connecting to who anymore and One big use case we identified The client is the use case of notifying about like applications. So Like state and data changes. There are big data systems At the client side and most of the applications have their own Data approval because they need to be separated and then if something changes like a case or so They get to notify the other applications and You can imagine if these are like hundreds or thousands of applications calling each other to rest courts it gets quite complex So for that specific use case of notifying all the applications about state and data changes. We introduced something to to help with all the even driven and application driven notification Processes and we sat together with the architecture team and then came up with requirements Like it has to be HTTP base because most of the apps are already rest base. It has to be even driven It has to use maybe an open standard because what's important is that the standard outlifts the product So that we might introduce another product in the future And it has to be highly available has to work with Kubernetes because that's the standard platform abstraction that we're using And maybe also to cloud native best practices So we provided we talked about it But we also realized we cannot just present this to the developers in the organization because that will not bring us any fun Because then they will look at it and be like, okay nice I'm quoting so we had to do it in a iteratively Nice to adopt way so that it's an opt-in and that had a solution has to be So good I call it developer experience that they themselves want to use it because it helps them achieve Better results than they already do. So it has to be somehow or it's good in the enablement process um and solution The would be one platform to rule all these requirements at once And the requirements are central hosting. So we want to do it with one team That's responsible for the central platform like AWS Lambda, but on an on-prem system It has to be Cuban at this native Support for cloud events because that's the standard we have set up for to use for eventing and it's it's being a standard It's also adopted by the industry. So like Azure, AWS are all using that to promote events in their systems Support for HTTP based bindings is one horizontal scalable supports Kafka For example order message brokers is underlying persistence technology and support for observability and tracing And or it's important for us, of course, it's a big organization. It has to has enterprise support So there has to be a supplier who can support this in an enterprise way So we found it that's Knative the open source project. It's I think still incubating in the CNCF and It offers all the features that we were looking for we started first with a field test on a bare metal Kubernetes in the rancher to just see if it really fits our needs and also like stress test it in the way that it works for us and then we Transitioned from like the bare metal installation to the custom one with an open shift and where we customize it to the needs of the customer or the client And it just ticked all the boxes we had and it also allowed us to kind of customize the ways We didn't have the product already that we wanted to and so that was our lot of the ring ring we found with Knative and Especially with open shift serverless we have them found the the equivalent on the enterprise side and It added the benefit that it tightly integrates with open shift gives a nice interface and nice visualization for the developers So they get a very good developer experience in that sense And that's what's the goal the developer should feel like they're using a cloud-ready product as if they are on AWS or Azure on the on-prem system and That changed the initial graphic where you saw all the connections going haywire and if south of west directions to one central Yeah system that we can scale and all the connect Yeah, all the applications can connect to it. We can then also make it auditable like what kind of events past the system Make for example provide other applications the information what kind of event events are already Available in the system so that they can discover what they want to subscribe to and Also enforce that policies if we wish to for some data or some events hmm, and That helps us greatly to like simplify also the entire architecture and also in the sense that we saw in the previous talk by The Ministry of France it helps us also to get gradually the all the teams that have like the multiple years experience of the customer to Adopt cloud native patterns in a way that is approachable for them So they can learn about integration patterns that's a usable in the enterprise field for events like I'm at least once delivery or the impotency and then double into that area and then on their own a speed experience more and more So how does the solution look in the like high-level view first of all we have the Canadian eventing part So Knative is an open-source project it consists of two sub-products. It's Canadian eventing and creative serving eventing is the part that does the Eventing flows and serving is the part that enables like scale to zero and horizontal auto scaling in a more approachable way We are focused first of all only on Knative eventing and the blue box is more or less the platform the central platform we are hosting in the open-shift environment and That's the main focus of our team that we had to customize the configuration to adapt it to the needs of the customer and then also, we had the challenge in this project that the Hosting of the central platform was divided between three units of departments So one department we were Responsible for the configuration to customization another was responsible for the open-shift platform and another one was responsible for the Kafka systems Beneath it so that was also a specific challenge. We had to overcome And when we look into the blue box and open it we see something like this We have the hypervisor. We have open shift on top of it open shift servicemen for the communication then Apache Kafka and open shift serverless on top of that which is then the Knative equivalent of red head And on top of that the consumers and producers interact with the system to well-known API's as Knative provides or rest API's directly and some other more abstract functional interfaces and If we look into the data flow of the blue box, it would look something like this Traffic comes into the ingress or the sidecar from Istio into the traffic components Then we see the ingress the broker from Knative. That's a component of Knative provides That's where forwarded to a Kafka receiver so that the events get persistent in the case the system has an outage It comes back and we can we pull it out of the persistence And we have to dispatcher who then does the consuming the polling for the events into the back into the Open-shift system onto the broker filter which then interprets Interprets the different subscription that don't trigger us onto that event So for example if I want to only have blue events that have to type blue then I will only get the events of type blue And that's the data plane the bottom if we look at the The entire upper part. That's the all the control-paying components that make the Knative system easy to use In open shift so custom resources to main interfaces that I will show in the next slides So, yeah, so how does a project really use the event grid now or the how we call the project event grid? it's starting with Having a project namespace where they can come yeah host their deployments and And they start by deploying a broker the broker is the part that gives the interface to submit five minutes things To submit the interface is the events. That's a project base ingress point And then you get a broker the next part is then to also subscribe to events that you want to receive or all events for that You create triggers so that you can register your subscription and which events you want to have you can do that Either by subscribing to all events of that broker or to the subset of events of the broker and Finally you deploy your workloads which you then put into like URLs or subscriptions into your triggers to point to that services and pots You can also like point to URLs HTTP services outside of the cluster if you do the networking right And the integrated details of that is like currently we have multiple clusters for each stage So it starts like this we have a producer down here in this project and that producer Then publishes an event here that you see the application event on top with a one and that application event then Gets persisted to a global broker URL So we have always one low balance a URL for all the clusters and currently we always point it to one cluster site where we then receive The events so that the cluster itself from the project's view is like an isolated environment And we then do some internal magic to forward it to the different clusters So even in the case of the connection severed there will be a delayed polling so that is already in sync again later Mm-hmm That means from the project perspective They don't really do a different workflow if they work here or there. It's always like an internal cluster for them And and then you can see here the Kafka Part where the persistence happens. I'm worried because of the cuts. That's just the part that had to black out for the graphics Yeah, and the systems view if we go into the Kafka details more We have on top the producer producer gives an event by HTTP into the broker ingress That goes to the channel receiver from the channel receiver We go to the Kafka topic that gets the events or messages and for then the trigger that we Deploy we get a Kafka consumer group that gets up from the channel dispatcher to back to the broker filter with Then pushes that to the example consumer And then all the parts we deploy anything we configure with the system is done Over our CD and we only touch the git repository. We never go directly into the open shift or patch than you think That's very important because with open shift server isn't all the triggers and events and brokers You get quite a lot of yeah custom resources to manage if you scale up into the bigger applications Like you can see here some example and also of course observability monitoring is big topic, so we have Grafana dashboard and I'm almost over time. So let's wrap things up We also have here the yoga view where can see then the start from the event producer down to the trigger Which then gives it to back to the service the last step And the takeaways just when summarized here open shift service was in our sense the perfect solution for our requirements We also a great support. I don't see nine out there. She is from Nina who helped us also to Debug some bucks we had and also like improvements. We had from the project to prepare that back. So thank you minor and team and We've wrote all open shift service with our customizations to production already We're seeing engagement and great Greatly improve and increase we have created what's very important blueprints for the different product teams to how to use it Because that's a very important part in a company that is or a client that is more from the legacy side give them tools to help them to onboard and to systems that are new and on that sense we also have multiple communications channels like chat ops and stuff like that or Anything they can contact us any way they want and we help them And the other thing with that is also start such a product with one or three application teams and learn from them And get their requirements great and test it be open to testing youth off and getting feedback from the application teams Themself who use it in the future Yeah, automate everything in the open is shift serverless version. That's important and Spend time on Observability and for example if you're an egg at the environment consider like how do you get the images? How do you work with a private certificate authorities and serve science certificates when you have consumers? And if you have a multi cluster concept consider these as well so And the last part is about PII maybe That's important if you have a system that should be in nature open And you want to want everybody to subscribe potentially think about what you do with classified or Sensitive data and we have choose to not transfer any data that is tied to any business data into the system just notification references to other data systems Because it's almost impossible in open system that is by nature open to do the right policy So all the business data is behind secure data. So the events are just notifications and not stay transfer Yeah, that's it for my part Thank you for listening and you can find more about us in the SVA and the zone daffodil and move s105 in the Cubecon Hall. Thank you