me is Solius from Smanthus. I work as an SRE at SDX. My name is Marcel Harri. I work as a cloud architect in the services team at Red Hat. I mainly focus on customers within the Alps region and their own infrastructure and OpenShift worktop. Hello. My name is Raghu Domno. I work as a cloud consultant in the services team as Marcel in the Alps region. I'm focusing mostly on OpenShift and cloud native ecosystem. Okay. Thank you guys. So we all work at SDX at the moment. This is a six group company providing financial market infrastructure services in Switzerland. There are over 200 employees and we build PLT-based solutions. We're part of Blockchain Network. Primarily, we use i3 Quarta, but as you can see, we also partner with Hyperledger and Enterprise Ethereum Alliance. So we build a number of products where we provide trading infrastructure. I will give the word to Solius to do the run month. Thank you, Radu. So just to finish a few takeaways. So auto scaling, as you can see, it works, but it requires proper configuration and some tuning to be done. GitLab turns out to be a very flexible framework, which allows us to configure building software for developers. And we found that container-based hybrid infrastructure suits very well for these kind of work. So thanks a lot. Thanks for tuning in. And see you in the next one. So hello everybody and welcome back. And as everyone can probably figure out, we're running about 20 minutes behind schedule, which is pretty normal for a gathering. But I really wanted to take a moment and thank Solius and Marcel and Radu for joining us today. There have been some questions in the chat. I'm looking to check in the Q&A to see if anybody's come up with anything. Vishy is asking, why can you just taint one known exclusively for this purpose instead of this priority scheduling? Prove that one and release it out to the wild. I'm wondering if that's something Marcel or Radu could answer. Radu, you want to take it over? Oops, Radu, you've got yourself on mute. Let me unmute you. I'll unmute for everyone. There you go. Well, keep trying. Hit the unmute button. Okay. So the question was about the white priority. Yeah, maybe or so basically by tainting a node, you would not allow any workload to be provisioned and then it would not be part of the standard Kubernetes scheduler selection. Thus, it would not count into the autoscaler position of whether it needs to add new nodes or not within the machine set. And so you need a way where there is workload that cannot be provisioned and then when a new node gets in, it needs to get provisioned. So also if you have a taint, you would need to remove that taint at the moment when all the other nodes are full. And this is not something that the cluster of the scheduler works on. It basically looks at is the Kube scheduler able to fulfill all the requested resources. And if not, I'm adding new machines to the machine set. Or I'm removing ones if there are more than enough resources available. I think that probably answers his question. I'm looking to see if he's asking again any follow-up on that, Vishy, in the chat. No, I thought maybe Salas, if you had a few words, someone's asking another question in chat. Here we go. How do you handle secrets for jobs? That's a question for Solius. And Solius, you need to unmute. Unmute as well. So there you go. See if I can unmute for you. And you're still muted. All right. I think you have to click in Solius and unmute yourself. Maybe not. Maybe we'll have to pause and answer that question in the actual typing of the chat. And thank you very much for the presentation. You guys, if you can hang out in the chat and answer any further questions, we'll queue up our next group of speakers here. And thank you very much for taking the time and joining us today and answering the questions. And thanks, everybody, for your patience with the Hop-In platform. We are running about 20 minutes behind, at least. And next up, we have the Bank of Oklahoma Financials. It's going to talk about modernizing a banking application using the IBM CloudPak for automation on OpenShift. So if you're up for that, however, we're going to stage that now and get that running. So take care, Solius, Marcel, and Radu. Thanks. And we'll talk to you all soon. Thank you. Bye. Bye. Thank you. We're going to try that again. Hello, all. I'm Faisal Kader. I'm a specialist essay in the sales team that manages this account. I specialize in OpenShift and related red-hot technologies. I'm Kubernetes and OpenShift certified. I closely work with Lance Preston, the infrastructure architect from BOKF, in setting up the different OpenShift clusters until production and grounded. On these clusters, IBM CloudPak for automation with its file-net product is posted. I closely work with him, helping him navigate through all the challenges with the infrastructure and provided the necessary enablement to help him complete this effort. Working together, we managed to tackle all the roadblocks and have led to this great success story for the bank and red hat. I'll hand it over to Lance to share his experience. Hello. My name is Lance Preston. I am an infrastructure architect with BOK Financial Corporation, which is headquartered in Tulsa, Oklahoma. I'm here today to talk about linking app modernization via the IBM CloudPak for automation on the OpenShift container platform. We started our app modernization journey basically in the fall of 2019 when we began planning to replace our legacy file-net platform. I believe I'm sharing that information on the screen now. I'll talk about what our legacy platform looks like here in just a minute. Basically, at that time, what we needed was a solution that was going to be supported for the foreseeable future as well as being more easily scalable and that could support the needs of our business, which included adding some additional products within that content management platform provided by IBM. In the fall of 2019 is when we really began talking seriously with IBM and red hat about building out a new environment for our content management platform. It was at that time that they suggested that instead of just upgrading the components in our legacy platform that we look at going with containers and Kubernetes and specifically the OpenShift platform. I'll talk a little bit about what our legacy environment looks like. We basically had the IBM FileNet P8 platform, which was version 5.2. We were running the IBM content navigator separately as a front end to FileNet for our users to access the documents and the content within FileNet. This was all running within the WebSphere application server network deployment edition version 7.0 and 8.5. We had a combination of both and these were connecting to an Oracle database that was clustered within PowerHA. All of these were running on our IBM Power8 hardware running the AIX72 operating system. I will show you what that looked like from a visual perspective here. I'm not sure if I can get that any larger. Basically, all of these are AIXL pars in our IBM Power platform, our Oracle database, that these L pars, which are the content platform engine, which is where the majority of the content is served up. It is stored on our network storage platform on site. This is all on-premise, by the way. Then the content navigator application, which were load balanced and would front end the content platform engine applications. We also have a legacy piece that's called the application engine, which is used by a couple of other lines of business. All of these are the 8.0 servers, the application engines were running WebSphere network deployment edition version 7.0. The CPE servers were WebSphere, ND85, and the content navigator was also WebSphere, ND85. These are all separate AIXL pars in our on-prem Power8 environment. Growing this and expanding this is a little bit of a chore. We can obviously add additional resources to each of these servers as needed, but if we need to stand up another server to scale out the environment, that's obviously a lot of work. We have to build another AIXL pars, we have to install WebSphere, we have to join that into the existing cluster and get the applications deployed to that. The solution that we came up with, with IBM and Red Hat, was to deploy what we consider our modern environment, which is basically the IBM CloudTact for Automation. We are currently at release 20.0.3 6.2 for the CloudTact for Automation platform. That is running in Red Hat OpenShift 4.6 environment on our on-prem VMware VSphere 7 platform. All of our Red Hat OpenShift nodes are just essentially Red Hat Linux Core OS VMs running in our on-prem VMware platform. We have the IBM CloudTact for Automation deployed to that environment. We are still running the Content Platform Engine, which is the IBM FileNet P8 product, but it is the later version. It's version 5.5. It also is still front-ended by the IBM Content Navigator, which they refer to as the BAN application within the CloudTact for Automation. But these are now running WebSphere Liberty within the containers within this application. Here's a visual of what that looks like. All of these environments are still connecting to an Oracle database on-prem that still resides in our AIX platform in the IBM Power 8 hardware. This now looks like this, essentially. We have our on-prem VMware cluster, which is a couple of dozen servers, at least, in our production environment. Those VMs are our Red Hat Core OS nodes. We've got the three master nodes. We currently have four worker nodes that are all running Red Hat 4.6.16, I believe is the version we're currently at. These are all on-prem VM data source in our VMware environment on our enterprise stand. We have a management node that is used to deploy the applications. That's where we run the OC or the kube control command line interface for the cluster. We do also use the OpenShift GUI for management of that cluster from time to time but a lot of the tasks that we do, we do command line through this management node. This all is still front-ended through our on-premise load balancer appliances, and then all of the cloud pack for automation applications, those containers and pods, they reside within this cluster. They run on various nodes within this cluster and then the persistent storage for those applications as well as our content within the file net platform is still on our NAS platform, our network attached storage. And then those environments still connect to our on-prem Oracle database instances which are clustered together in a PowerHA environment running on our AIX72 platform. And again, this is all on-premise. So it took us quite a while to actually get to this point, to get this environment stood up. There was a pretty steep learning curve from our perspective to be able to get this environment in place but we did receive a lot of help from both Red Hat and from IBM. Red Hat specifically on getting the OpenShift cluster stood up and working and any problems we had with that and then of course IBM with the cloud pack for automation packages that we got deployed. We struggled with it a little bit but we were able to overcome any issues or difficulties that we had with assistance from both of Red Hat and IBM and have a test dev cluster stood up as well as a production and a disaster recovery cluster stood up. This image is depicting our production cluster but now that we have this in place and now that it's stood up, scaling out these applications is much easier. We can just scale up the deployment and immediately have additional instances of the application that are serving our customers as well as upgrading the cluster itself is relatively straightforward. It's a very simple process and then upgrading the cloud pack for automation packages themselves, that bundle, it's a much easier process than the legacy platform. When we used to have to do an upgrade for file net or for content navigator, that was pretty much an entire weekend. Several employees working together for the majority of a weekend which is when we could take the downtime for the application to have it offline for hours or half a day at a time in order to do the upgrades and test it out and make sure everything is working before we went back into production Monday morning. Now that upgrade process can occur basically within a couple of hours at most, generally less than an hour and it can be done with the applications online. We just deploy the new application, apply a new configuration file, a YAML file and the upgrade kind of happens by itself in the background with the old version of the application still available until the new application is fully deployed and those containers come online and it's just like flipping a switch and then backing it back out is just as simple. Much easier in the new environment than the legacy platform. I can't really speak to the performance of the new environment yet while we do have this production environment built out. We were still in the process of loading content and data to the file net platform to serve to our customers. So they currently are still using the legacy platform but as we migrate that content to the new platform and make that available, more users will eventually cut over to this new platform and we will have a much better idea at that point of load and the performance that the new environment can provide. We're optimistic. We don't have any reason to believe that the new environment won't perform as well as if not better than the legacy platform but we have yet to have any concrete data on that. That's basically what I wanted to present to you. So thank you for your time. I appreciate you paying attention. I hope you find this information useful. Have a great day. Thank you. Thank you Lance for sharing this wonderful insight on this topic and thank you all for listening. Lance, myself and my associates are available to take any questions in the chat. All right then. Lance, thanks again. Really thrilled. It's really nice to see someone using the IBM cloud packs for apps in this manner and to help migrate some of this legacy efforts here. Do you have any words to add now that you've seen this? I've seen a couple of questions in the chat but I think they've all been answered Faisal. So thanks again for this talk with us. Any final words? Faisal, can you unmute yourself? I can't see your video but I know yeah. So this has been a tremendous experience so far. Is there anything Lance that that could have made it a little easier for you during this journey? Do you think of anything top of your mind right now? Yeah. So specifically I think it would have been much more beneficial to take some of the the the OpenShift training classes ahead of time right before the project had started so that we had a little bit more experience and knowledge of the platform prior to you know going down that road. You know we pretty much learned it from scratch and kind of on the on the job experience as we went along. So I think having a couple of training classes under our belt prior to starting the process definitely would have been helpful. I have since since we've started the journey I have taken a couple of training classes and they've all been very very useful and very beneficial. So I think having that knowledge you know a year ago definitely would have been helpful before we started the project. All right well that's a good plug for the some of the OpenShift training. There's lots of opportunities with online stuff with TryOpenShift.com and LearnOpenShift.com as well as all of the great classes and courses that are available. So thanks for that tip Lance and Faisal thank you for organizing today's talk. I really appreciate it. If you can stay on in the chat we'll queue up the next final talk from Anthem on their Health OS system and I know we're everybody thanks for bearing with us we're barreling through this content today to get to the the end of our journey and so you can all continue on yours with KUKON this week. So the next talk is coming from a group that have been doing some really interesting work with SPIFI and other projects. It's a talk is called Health OS Enabling Standards Based Healthcare Interoperability with Cloud Native and Zero Trust. That's a lot of words but I've got to queue up that talk now and thank you guys for for joining us and bring in the next group of speakers. So thanks again and we'll look forward to seeing you at the rest of KUKON today. My name is Bobby Samuel and I've got Frederick Couts here with me and we're going to talk to you today about Health OS and Enabling Standards Based Healthcare Interoperability using Cloud Native and Zero Trust. So first of all I'm Bobby. I work at Anthem. I lead up the Health OS development as well as precision insights. Frederick would you like to introduce yourself? Hello I'm Frederick Couts. I am a Director of Software Engineering at Sharecare and I collaborate with Bobby and Anthem on Zero Trust and a variety of architectures and systems. So the way we're going to walk through this today is we'll start with the business case or the business challenge and then we'll we'll move into the technology and then be here to answer any questions. So first of all you know what's what's the challenge? What's the what's the point of all this? So Health OS is something that we've created internally here within Anthem and payers are seen as the middleman pain point across the ecosystem and causing abrasion across various user segments whether it's provider member or even to other payers. But we also sit in a position where we have the richest longitudinal view of data and that's whole health data about the person. So Health OS helps us operationalize our health health data to drive improved outcomes and reduce costs and overall you know increases efficiency. So we'll talk to you about how we do that but at the foundation of it all Health OS is a platform. It's a hub whose primary emphasis is interoperability and then driving world-class experiences and uses machine learning and AI to drive insights and also actions. So just to talk about the business architecture and how the pieces fit together. At the bottom we've got the data layer and that data layer it focuses on integrations with EHRs. It's got payer and clinical data and then our data about members or our constituents is based on fire or the fire standard. On top of that layer and this is where we'll get into cloud native and zero trust but in that space in the security layer and our platform layer we've got a number of things that are running and happening. So insights and action apps live here and are created here. We've got tool sets or IDEs and tool sets to rapidly build, validate and or deploy health apps and then this is where we'll talk about where we're implementing zero trust to do workload identity management and then on top of that we've got interaction layer. So the the cool thing about Health OS is that or one of the many things about Health OS is that whether it's a UI UX that Health OS manages or a UI UX that someone else manages whether it's another EHR or a homegrown app that we have those all plug into and have the benefit of connecting back into all of these health apps and back into the place where we've got the the rich data stores. So this is the ecosystem that we've been putting together with our client end point client application end points to connect as well as SDK our SDKs to build and rapidly deploy apps. So in our ecosystem what what's the what are we trying to do this for and at Anthem we have a number of partners we work with we have a number of partners that we connect with in various lines of business but the big problem is is they're not connected. Anthem's connected to them but they're not connected to each other and what this allows us to do is to connect all the apps to each other. So Health OS allows us to connect to Anthem's data ocean. It allows health apps insights and actions to run and connect all these different apps. So we bring our digital ecosystem together and we bring our EMR systems together that we connect with as well as internal systems that exist within Anthem. All of these things working together focused on better outcome for the for the member and so let me like zoom back out into what's our ecosystem and where Zero Trust kind of fits in. So we've put Health OS in the center once again action apps and inside apps. So an example of an inside app would be what benefits are covered by for Bobby or does Bobby have this in his formulary this particular drug in his formulary or treatment in his formulary and action could be scheduling an appointment it could be one click prescriptions or you know painless prior off one click prior authorizations and so those things run together and then using Zero Trust connections we connect to various clients like the desktop or it could be and I'm going counterclockwise right now but like the desktop it could be on AI ML tooling that we've got running that we can make insights available third-party health solutions and then even to clients like third-party clients like Telehealth OS which Telehealth has seen a huge rise in popularity and usage due to the pandemic and then EMR apps or or apps that that do payment acceleration as well as just traditional EMR platforms like in large hospital systems Epic, CERN or Athena Health and all of these connected together working together once again focused on our member's health and improving the health of humanity and so what we'll do is we'll dive a bit more into how we're putting all of these things together on a cloud native Zero Trust foundation to deploy this ecosystem so Frederick let me turn it to you thank you Bobby so before we jump into Zero Trust let's talk a little bit about some security basics very often when you speak with a security or information security person you'll often hear about the CIA triad we actually look at four things now but the first three in the CIA is what traditionally people would look at those three are confidentiality is the information protected against unauthorized viewing or access we look at integrity has the information been modified in a way that was unauthorized how do we protect it from being modified we also look at availability is the information available when you need it to be and there's a fourth thing that has been added in in more recent times called non-repudiation which is how can you ensure that a entity that has performed a transaction cannot back out of that transaction and there's multiple reasons for this which could include at the business layer how do you prevent fraud how do you how do you ensure that you can observe the system and know that that's what the state was likely to be it could also be based upon trying to make sure that the that when you're looking at security systems that you know exactly who you're connecting with and that it hasn't been swapped out with with someone else so in general there's now four main categories that people tend to look at there's a couple others that people will bring in as well but these are the the main four that that you tend to see so using this particular framework we then take a look at what are the business requirements what is the what is it that we're trying to to protect what is changed so when we look at at the zero trust space and why it's important one of the things that we want to look at is what is what is the what are the previous assumptions that we've made and what is the reality that we're seeing today what is what has changed and the differences between that assumption and reality can be seen in the form of cyber attacks where people will perform data breaches will run ransomware denial service attacks forging identities or so on and the policies that we tend to apply in from a regulatory or policy perspective may also end up ossifying some of those assumptions end up entrenching those assumptions in such a way that they can be difficult to respond to so zero trust is about realizing that we have these gaps and then building up a new framework that is more flexible in order to allow for response to these type of of conditions and to allow for additional controls to be put in in such a way that it enables other organizations other parts of your organization your digital organization or your developers to be able to make the changes necessary to meet your mission but at the same time still maintain that control to hit your confidentiality your integrity your availability and your non-recreation goals so what is your trust I try to distill it down into a into a small image and this is the simplest I was able to find in the very in the top half of this you have perimeter defense which is the common gold standard that you see within many environments that is where you have a trusted network in that network you have your services if you need to connect to another network you may have a firewall that you put in between them in order to protect entities in one network in from entities in another network but the problem is that if you end up in attack with an attacker in one of these networks then there's a lot that they can do there a lot of damage that can that can be done in the zero trust model instead what we say is well what if that network was not trusted no it's not implicitly trusted that doesn't mean the firewalls go away it doesn't mean that you're that you're not trying to protect the network but it means you're no longer saying this network is the implicit thing in which we base our trust so once you no longer trust your network then you have to look at where you push the controls and the controls end up being at the services themselves so if you look at the bottom half of this you can see every service when it connects to something else has some form of a of something resembling a firewall something that is a control that allows you to determine what you want to send over those links to those other to those other devices if an attacker enters into your network again that doesn't mean you're no longer at risk but it's yet another layer of security that you have that doesn't allow for implicit access to things simply because they're on the network so to build our zero trust framework we started with three main foundations this is identity policy and automation identity is what is it that identifies your service what is it identifies your user or identifies your data how do you know that what you're looking at is the thing that you are that you're looking for how do you attest that identity policy is how do you develop the rules and apply those rules and enforce those rules across the across identity from the automation perspective is how do we take this from let's say you have a single system and you can put a person on that system to defend it when you say when you start to try to scale this out to a large number of systems hundreds of systems thousands of systems tens of thousands of systems you need to have automation in place that is able to help you assign the identity and enforce the policy but also bring in things like observability so you can audit what's going on and to have controls over well what the automation is capable of doing or what it's not able to do so it ends up being three intertwined primary pillars that that have to be put together in order to build a zero trust framework so we've been working on a reference implementation for this in a in the cloud native environment and we focus around three primary things so if you notice i in the triangle i actually made them link up so you can see identity we're using spiffy inspire for policy we're using open policy agent for automation we're relying heavily on things like network service mesh now these aren't the only things in the infrastructure but they're the representative of the type of things that we're trying to accomplish so we'll go over each of these in more detail soon we also build this on top of kubernetes we build it on top of systems like open shift we build it we we build in automation on the infrastructure side we have getoffs style processes that we're bringing in and underpinning all of this you still need observability across the whole stack you still need patrol over the over the whole stack so it ends up becoming this this model that that this particular thing represents that all works in coordination to deliver the infrastructure that is part of help less so what spiffy inspire are is that they provide identities to your workloads so most people are familiar with the user identity you put in your password you log into a online service you have that user identity in this scenario we're looking at workload identities so every workload receives an x519 certificate this is the same type of certificate that when you log into your bank your bank will use an x519 certificate to identify who it is so we're relying on the same type of of primitives and principles in order to secure the workloads when a workload connects to another they use a new feature within tls that is available in tls 1.3 and presumably above as those are released and that is mutual tls mutual tls is where your client is able to validate your server like you typically can from a browser validating your bank but simultaneously the server is capable of validating the identity of the client so you have this two-way validation that occurs within a trust domain so we're able to create these identities that live within a trust domain that allow them to establish their identities and these identities are constantly rotated out every hour they get rotated out and by default if you're using spiffy inspire and every time that you assign a new certificate you perform a verifiable attestation and what we mean by that is that the system will ask for an identity we will look at the properties of that system you might have a tpm module that you're working with you might have a identity document that is within aws or within gcp or other similar systems that have some cryptographic material inside of them that help prove something about that system so we are able to build our spiffy identities with attestation that is rooted in these cryptographic materials from from these types of systems this also has a very nice effect because since we're performing this mutual attestation and validation between systems in many scenarios it reduces or also eliminates the need for long-living bear children so in other words you don't need to pass in a secret the fact you're connecting in with a specific identity is enough for the system to recognize what type of a system it is and what type of policies need to be applied in terms of policy we're looking at things like open policy agent and open policy agent allows you to to consume the identities that are produced by a system like spiffy inspire and allows you to decide what does this system allow to do what is what are its capabilities that that it is able to fulfill and when when you when you create these particular systems or the properties we're looking for and that led us to open policy agent is has to be something that's human readable has to be something that is that meets the the look and shape of common policies so in other words you could have how do you classify data how do you classify workloads how can you say this system as phi and create defaults that say don't allow them to connect the systems that don't have phi or vice versa and then from there we can carve out patterns that the system is allowed to perform in this example we took this from open policy agent orgs it's one of their it's one of their examples they have on their front web page and you can see a request that says pet owners are allowed with a specific id that is verified by the jwt which is which is something that identifies the user cryptographically is allowed to receive information or is allowed to make a request against against this api in a specific way if and only if the request comes from like say this is in front of a database if and only if the request comes from a client that we that or a workload that we have identified so it gives us a lot of flexibility to define the exact type of shape and policies that that we want in a human readable way that also allows us to get this policy into get it allows us to to have code reviews on these policies to share them with with other stakeholders so we can get their opinions on whether this policy meets their requirements or not and it gives us that that change over time so we can see how the policy has changed when did it change because it's all checked into into get we also rely on a new technology called network service mesh network service mesh is another cncf project that is looking to automate low level networking systems so we're looking at if you're familiar with the osi model we're looking at layer two layer three we're looking at frames in ethernet and ip and other similar level areas and what it does is it facilitates the underlay to services so typically when you're running in kubernetes you'll often have multiple clusters you want to connect together in some way and when you connect them the assumption is there's are there's already connectivity established between both systems what network service mesh allows you to do is to acknowledge that there may not be a connection that's there and you may need certain things in place in order to make that connection work so this allows the operator to say in order for this connection to occur i needed to have a firewall an intrusion detection system needs to go through a certain vpn gateway a certain vpn concentrator so network service mesh allows you to automate these processes through a cloud native api with native support from spiffy inspire and open policy agent and it provides you a cryptographic non-repudiation of that connection chain so in other words in this example we have on the left health os app going through a specific vpn gateway to a specific vpn concentrator to a specific health app we can get the cryptographic identity of everything in between and see what is a system connecting through is it connecting through systems that we trust is it connecting through systems that that are required to do we have everything in here that we need in order to establish the connection by policy and enforce it on an ongoing basis finally we look at get ops and from a get ops perspective the workflow this is more of a process side that is then committed as a as a service so from the process you have a developer developer will make some form of a commit into the source code uh system like such as get then the c i c d system your continuous integration system will see those changes that have been put into get and will then render them into your your test environments into your staging environments your production environment the every change goes through source through source control every change goes through get which gives us that audit auditability it gives us that chain as to who made the who made the change we also have control from the qa side so in fact through when you're looking at regulatory concerns in this space it's it's important that your developers are not allowed to push into production you have to have a separate group of people a separate team that is able to look at what changes are there and decide whether or not those changes should hit production so when you start looking at things that are pci compliance or hippocompliance systems you tend to see this pattern quite common so that you don't have a single place or a single person who is able to push these type of things in so the qa team is then able to determine at what rate and when something is promoted from testing the staging or staging to to production a really great example of a system that you can use to achieve this in your own infrastructure is flux so highly recommend that you go look at flux and give it a try it hooks up to github and gives you that initial path towards automating in in this style so with that i want to thank you all for joining us and learning a little bit about health os and zero trust you please consider that these are the type of technologies that we're using we're using open shift with kubernetes we're using spiffy inspire open policy agent network service mission envoy please join these particular communities there's a lot of things that you can work on in those particular spaces and if you're interested in the type of things that we're working out please reach out to either bobby or i and we'll help you navigate the the path whether it's coming to work with us directly or whether it's trying to work in the same area in your own industry so please please come and join us with that we have time for questions and thank you very much well hello all and let's see if we can get ourselves unmuted um there we go bobby there you are stew i hear track two has ended successfully thank you very much for that um we have you know a bit of time left here before the clock runs out on us so um i'd be curious fredrick and bobby um i know um i had asked you earlier there is not quite yet a landing page for health os anywhere itself how can people get in touch with you if they're interested in this initiative and get get going here so there's multiple ways to to get in touch with us but um fredrick why don't you start with um look at the open source it depends on the level of interest what where are you interested in working and what is it that you're just learning more about so fredrick you want to start with the open source and then i can i can talk about the the other pieces sure so in the open source space there's a few communities that have been focusing on building the core components so starting from the top we have spiffy and spire if you go to spiffy.io there's a range of of places where you can interact including github there's a slack channel for and all of these have a have their own slack channels as well and there's also in the policy side there's an open policy agent which i believe is open policy agent.org network service mesh is is another community which is focusing on the automation of the of the layer two layer three components that you saw which is network service mesh.io and we also we also have the broader communities as well such as scuba netties cncf and the open shift commons that you can join in and help in the various the various levels and there's also a variety of other downstream communities that are consumed so for example in network service mesh there is now support for wire guard and wire guard has its own community that's attached there as well so there's there's a lot of different places where people can focus on on helping out a variety of different levels if you're interested in the open source area and you're feeling overwhelmed with like where to get involved or you want to know like based on your use case if in the context of zero trust where a good place to start with me like don't hesitate to reach out to to me and i'm also happy to to help guide you through with introductions or or meeting people as well so we want people to get involved and and uh if your interest isn't in maybe specifically one of those areas and you've got a use case or you you you want to learn more about what we're doing to Frederick's point you can reach out to us connect with us we're happy to have conversations talk about we'll fit in we're looking for people and want to work with people that are mission driven because this work is not easy um changes as we we saw in the previous few uh examples presentations changes difficult and we kind of glossed over that we're at the end of a change process but changes is top of the middle of the transformation so mission driven um and people that you are committed to um come into the journey is what we're looking for and we'd be happy to chat with you about it awesome well i i did mention uh i did notice a mention of GitOps in um in your presentation and yesterday's present conference those GitOps con i'm not sure if any of you attended that um that are in the chat but i'm wondering bobby if you can talk a little bit about where you are in the journey around GitOps at Anthem because i think that's top of mind for a lot of us so i've i've i've been in other past and other history so um we haven't always had the luxury of starting with the green field um in some in most of my career we've started with uh legacy applications or applications that existed before i i was part of the team in this case for health os we were able to start um it was green field um in in the spaces that we were working with um in the area so we are complete cloud native and so we had a great chance to just start foundationally from the first teams we built was our dev ops or git ops team and uh we started with automation in mind so our ci cd pipeline is uh is is continuous the the d part isn't cd isn't something that we subscribe to but the uh we went from um releases that were once a quarter um to now uh we are down to uh they're they're big feature releases because it's a platform and when you release you have to be careful what you're putting out there but some of our teams are are now um releasing monthly and then we've got actually one team that is releasing you know seven to ten times a week through their uh through their git ops pipeline their ci cd pipeline so it's been um it's been interesting it's been um a journey and automation things don't always work the way that you would want them to or imagine them to so we engineer around them uh but it's taken some resilience and um we're we're thankful for those tools but um we also want them to get better is that it's another way to say why don't we get better and um one of the places that we have struggled is that in the management console space um in in this and just creating awareness around the clock so when something isn't going to work or something's uh has failed that we're the first to know um and that's been a lot of our focus it's not just getting the pipeline but it's the monitoring of the pipeline so that of the pipeline so that um we can every event is is becoming less and less an event every every push becomes less and less event and um it's it's scriptable and we we also look for tools where we can script and it's not um you know manual intervention and typing in um uh you know ip numbers to you know whatever else you might imagine so it's been it's been a journey and um I we'd love to showcase it at some point show you how we're doing it oh well we'll definitely give you the podium to do that um again because um I think that that sharing of those stories improving the tools those are all really what we're here about today um trying to make sure it happens and um your feedback is sort of essential and um I know like especially with the get-off stuff um and the stuff that we're doing here at Red Hat and in the open source world that's that's been top of mind for a lot of stuff the the monitoring and the notification pieces are essential um so Frederick any final words of wisdom I know um we've had you on many times before and it's always interesting and it's always kind of bleeding edge um stuff that that you kind of bring us to uh and are there any things going on at KubeCon since that's that's first of mine here too that we we ought to be watching for so uh yeah KubeCon is quite a it's quite an event there's I know it's still pretty hard to do some of the engagement because of because of COVID-19 I highly recommend if you're not on the on any of the Slack channels get on them people are on them all the time they have a set of channels that are related towards KubeCon and if you want to meet people and have conversations strongly recommend that you hop on and and just say hey I want to talk about zero trust or and jump into the appropriate channel or I want to talk to the people from from Spiffy or Opa or similar and find find the room that has the most people in that that has adjacent uh relations to those topics and just ask away and uh see who see who answers and establish establish some form of communication with them we don't have those hallway tracks anymore right now and at least not until the next one and this the hallway tracks are one of the most important parts of KubeCon so it's we need to find ways to to work around the work around the issue other than that there's a lot of really amazing talks there there always are just depends entirely on your interest so definitely find the ones that interest you I think I think that was some of the best advice too is like the Slack channels around KubeCon if you're in the Kubernetes Slack in the OpenShift users or the OpenShift Dev Slack as well channels there are really pretty key and if you're not yet an OpenShift Commons member you can always go to commons.openshift.org and and fill out the little form there and we'll onboard you into yet another Slack channel OpenShift Commons which is where Frederick and I and others hang out and chat all the time and it's a great way to meet people who are doing these things inside of OpenShift but all of it's being done in the open so please do reach out connect with your peers and definitely keep keep us involved on Bobby and the HealthOS stuff that definitely put you back on stage and give you a venue. All of the talks from today will be now published via YouTube shortly and we'll tweet out a little notice that they're all live and I wanted to take a moment and say what Stu has probably been saying all day long may the fourth be with you all thank you for sharing may the fourth with us it's been a very Star Wars kind of interesting day for for us on the main stage quite a few little glitches there here and there but thanks for sticking with us we really appreciate it we so appreciate having end users come and talk about these technologies rather than having Red Haters talk about it it's wonderful to hear it from the people who are actually on the front lines using the stuff and what I'm really loving about today is how many of the end users people like Bobby and Frederick and Solis from Six and everybody else from and the folks from Discover and I think you saw Stu in your track the folks who are working in the open source now I think that's the really big change that we're all seeing is how many more of our end user organizations are now participating out there in the open and working on and contributing directly to these projects and driving a lot of them so I think that's really the big change in open source for us it's not really of as much of a vendor driven space as it was in the past though all of us vendors are out there and contributing to if you heard from Clayton and the all the folks talking about the different projects that Red Haters are involved in so there's plenty of us out there but there's even more end users now getting involved and kicking off new initiatives and you know Health OS for example about every single time we host a gathering the last time it was the Enterprise Neuro Systems AI ops in the telco space they had their foundation and they were all coalescing around that it's a it's an amazing world out there right now and I'm really grateful for everybody for sharing their their stories and their contributions it's always enlightening and much more interesting than hearing me blather on and Stu as always you're new to this game in the commons you've been doing the cube and all kinds of other things and market insights thanks any final words from the Star Wars fan that you are well Diane hey it was great to be a part of this I always loved going to cube con as you said that kind of user created in collaboration so many of the projects out there was I had a challenge nothing existed I created something found out other people had the same problems you know listening to like the Argo CD it's like oh hey into it let's you know hear what they had I had interviewed them you know back in the past so that co-creation you know loved all the sessions over on track two especially Diane I know you've got a special place in your heart for the okd content there so that really good discussion just how much effort and work and giving back eventually before they got things in production so had a lot of fun over there and yeah had some good Star Wars humor as part of it too as the joke is most people are like hey today Star Wars day in my household you know it's Star Wars day every day so yeah well it was the red hat version of the Darth Vader mask that behind you that was really the thing that they got me going when we first started talking about all this so I'm totally grateful I can't wait till we can all be back in person again and a huge shout out to everybody Chris Short who's out there still streaming on OpenShift TV for us and producing us in the back I'm really grateful for that support and now we have three more days of KubeCon and KubeCon is rolling behind us in the background as well so jump into those KubeCon Slack channels look for us in the red hat expo booth or whatever it is that they set up for us and we'll be taking your questions there and if you're interested in having the podium my favorite thing to do is make other people talk so if you have a talk or a project or a tech initiative that you're looking to get some awareness of please reach out to us and we'll definitely give away the podium that is the whole point of OpenShift Commons it's all about the end users and getting everybody connected so once again thank you all Frederick and Bobby and Stu for all your efforts today totally appreciate it now it is now officially 7 a.m. where I am so I am going to get another cup of coffee and try and stay awake for the rest of today so thanks guys much much appreciated