 It's a beautiful day, and again, I would like to thank Red Hat for having us here. Much appreciated, and thanks to the community. I think we're all here as part of the overall Red Hat community, the OpenShift community. So my name is Ganesh, Ganesh Janakiraman. I lead the SAS operations and delivery team for Broadcom. And with me is my colleague Jose Chavez, who heads the platform engineering for SAS. You may be wondering what the heck is Broadcom doing here. So Broadcom is typically known for its chip design, hardware, infrastructure. If you've not noticed, Broadcom has been acquiring companies like Brocade, CA Technologies, and Symantec recently. So we have a multi-billion dollar software business, a thriving one at that, that encompasses infrastructure software, enterprise software, mainframes, security software, and we have a fairly large presence in SAS. So both of us, Jose and myself, we come from the CA acquisition. So what we will talk about today is our journey with Red Hat OpenShift, where we started, why did we even pick OpenShift, where we are today, what we are doing today, and where we are headed. So this is a flashback of about four to five years back in terms of where this whole journey started for us. We were growing SAS through acquisitions. So there were several products that were coming to the SAS table through acquisitions that were already pre-baked, pre-built, that was revenue-generating products, not greenfield ones that we were absorbing. So the problem that we had was this heterogeneous sets of products that we had to run and operate. And each one of these was an island by itself. And the landscape looked something like this. So we had products that were built back in the late 90s, early 2000s that were monolithic. If you can recall the old Java J2E days, we had these massive war files that we used to run. To the latest microservices-based products that uses the latest technologies and tools. So the common joke in the floor was that we literally had everything from Pascal to Haskell and C to R. So we literally ran everything. So the other important part is the development methodology. So we had products that were doing your old waterfall model. And there were some that were doing agile. So eventually, we kind of standardized on agile. We follow the safe framework. The reason why I bring that is the delivery of the software, the release management of the software were all totally different. The last part is the application infrastructure. So some of these products were built, ground up, multi-tenant, even 20 years back, well-architected. I wouldn't say the same about everything. Some of these were actually hosted services. They were not even true SaaS services. Some of them ran in our own data centers in private cloud. And some of them were built public cloud native, wherein they could consume all of these nice elastic. I mean, the only one's swaying. So that could consume all these new services that are available in the public cloud. So the issue that we had, the problem that we had was a problem of plenty, a plethora, a wide gamut of these products, that we had to find a common way to run and operate. It was not possible for us to scale the resources, both in terms of infrastructure, as well as people, to be able to manage these services. So that was the problem that we went about solving. So how could we assimilate these products in a way wherein I don't need to linearly grow my teams? So the goals that we had for the SaaS delivery were the following. As you can see, we had to make it less complex, easy to manage, and reduce the operational costs. So obviously, I mean, it's all driven from there. And we were essentially looking for a common operating model, a common console where I can go look and manage all of these products. So that's where OpenShift actually came into play. So we, in CA, we're one of the oldest partners of Red Hat in the OpenShift journey. Somebody talked about four and at three, we can talk about two as well, the OpenShift version two. I don't know how many of you here have used OpenShift version two. Oh, my goodness. OK, my commiserations, actually. So if you've dealt with the cartridges and gears, it was not fun to work with. So back in 2015, I think the pivot was made to adopt Docker and Kubernetes. I think I'll be preaching to the choir here if I start explaining the benefits of Docker and Kubernetes. But essentially, the problem that we wanted to solve, we said that if you're a developer and if you're able to deliver your software in a box called this Docker image, we need to find a way to run this in an orchestrated environment. So as long as the developers were able to come to this form factor of software development, a unit for software delivery as a Docker image, we would be able to run that in a common model. So for us to start, stop, scale, the operations team does not need too much of expertise on the product to manage these diverse technologies. As long as they're able to, they know OpenShift and they're able to manage the platform, we should be good to manage these. And the other thing, the important thing, I think I mentioned in the earlier slide, was an edict. I think the earlier speaker talked about ING. We had to automate everything. That was one of the ground rules. From automating everything to, we are at a point where we are moving towards a declarative of everything, where everything needs to be declared in Git and that's what triggers the automation. So Jose will talk more on that. And today we run OpenShift in, we run large clusters of OpenShift, both in our private cloud and different public clouds. And we are in the process of consolidating them, but we still do see a need for having a combination of both. I'll talk a little bit about the scale in the later part of the presentation. And I think similar to what the ING use case was, we run our service in a high security environment. So we need to go through the InfoSec regime. We have, all our environments are SOC2 certified. We have a couple of environments that are PCI certified. So we do have a FedRAM setup as well, right? So that gives you an idea of the scale that we are running. So without much ado, I'd request my colleague Jose to talk about the technology stack, what we run at a high level and take it from there. Thank you. Thanks guys. So our technology stack, obviously running in production, there's some common components that need to be incorporated, starting with the infrastructure layer. As shown here, various cloud providers, VMware could be put in there as well. The ultimate goal was to be as flexible as possible and where we could deploy to. So starting with that layer, then adding OpenShift on top of that with Docker and Kubernetes to host our services, of course. And some of the SaaS applications that we're hosting on top of OpenShift, that are, you know, Broadcom, IP, the AIOps, API Management, CDD, Atomic, MRA, PPM, more to come. Then in order to support those services, we had to have, you know, infrastructure services as well. On the left-hand side, you have your monitoring pieces. Again, Broadcom, actual applications, APM, ASM, UIM, DOI. To the right of the SaaS applications, you would have your common services that are like, you know, integration or needed by the actual SaaS services like Kafka and ZooKeeper. Then we have our logging stack based on Elastic Search Log Stash, Kibana with some file bead agents that are essentially scraping the logs and forwarding onto Elastic Search. It is actually running as a stateful set that Elastic Search is, and just by a show of hands who runs, you know, stateful sets in production today. Okay, so yeah, that was one of the concerns for us is a lot of the reading that we had been doing was, you know, yeah, stateful sets for like database technologies like MySQL, Postgres, things like that are good for development purposes, but once you incorporate basically shared resources, there's a risk involved there, you know, with performance and things like that. So that's kind of a leap of faith we had to take with Elastic Search, but it's worked out so far. We have our DB layer as shown here, Mongo, Postgres, MySQL. I'll talk a little bit more about where we're going with those. Right here, they're depicted as standalone services. And then of course, you can't be without security. So, you know, QALIS for OTScans, TwistLog for scanning container images. You have your alert logic for network, you know, packet inspection, and then of course, semantic for antivirus. So that pretty much summarizes what our current generation stack looks like today. And I'll turn it back over to you, Ganesh, to go into more detail about the workloads that we run in production today. So we've been running OpenShift, the 3.x OpenShift, I think the first version we went live was the 3.1, we quickly moved to 3.4. We went live 2016, November, it's been three years actually. Right now, most of the production workload we have is in 3.11, and we are testing four actively and we should be there someday. The kind of applications that we run again, I kind of already talked about the breadth, right? So we have a lot of web applications, as you may guess, again, different hues, we run everything, we run from your NGNX, Apache, HAProxy, kind of, I mean, we have like, you name it. So the important thing that we, from what I recall from my pre-OpenShift tool, where we are today, is our ability to scale, right? So with, we are able to scale dynamically based on the number of requests, we are able to scale up, scale down, as needed, and I think the support from Kubernetes there has helped us enormously in terms of managing these web apps, which used to need operators going and spinning up VMs, and after the Cyber Monday is over, scaling them back. So we don't need to do any of these right now. So we have the other workloads, like project and portfolio management and continuous delivery management. These are large database intensive, more of a workflow management kind of applications. The, again, the most important part that we achieved with OpenShift was, literally, we run thousands of containers, okay? We run thousands of containers just for these kind of workloads, and the staff, the operational staff that we needed to manage these, right? Work was enormous. The kind of, the operational efficiencies that we've achieved by moving these workloads into containers is amazing. Both from a resiliency perspective, self-healing, the ability for these applications to recover, I think that alone, I mean, has helped us tremendously, actually. Then we also run a data science platform where we have these workloads, there's a lot of machine learning and AI that we do for different products. So one of the products that we have is the payment security platform. We run the largest online authentication system. It used to be a protocol called Verified by Visa or Mastercard Secure Code, if you're familiar. So we run that workload and that, so there's a real-time fraud detection that we do that uses OpenShift as well. Again, this is, the ML AI here is more homegrown proprietary. It's not any of your TensorFlow, but again, this one runs in our OpenShift platform too. And then we have other enterprise security applications. Again, we have applications like API gateways, API management portal and things like that. And Jose talked about analytics. We run, when we started this journey, we were kind of hesitant to do anything on the stateful applications. We are still running them on VMs. Recently, it's been like about over six months now. I think we've moved completely to stateful sets and then the whole new storage class has helped us big time there as well. So we run our complete elastic search and Hadoop to a small scale. We have some Spark workloads that we run on a very small scale in the OpenShift environment as well. The last one I kind of mentioned in the earlier slide about AI operations. AI operations is basically a suite of monitoring tools that we actually run, that we host on behalf of our customers. We use it internally as well. So this is again a very useful part of our overall platform wherein we have this monitoring both inside out and outside in that we do. So when I say outside in, we have pops that are running all over the world and those that are running on OpenShift that kind of monitors and sends metrics. And we have NetFlow analysis that we can do. And we do have application performance management that goes right to your container, to your pod, to your service, to your namespace and then to your cluster, right? And there is the other microservice versus the application view. So there are different levels of monitoring and metrics that it collects. And there is an AI engine that actually does the correlation and that gives us a very good visibility into what's going on on the environment. So the other part that we wanted to talk about today is I think the earlier speaker kind of touched upon this one as well, in terms of how we manage this environment, what kind of automation we have to make sure that we have automated provisioning separate out the infrastructure provisioning and the application provisioning and the application deployments. So Jose will talk about what we do on the automation on the CD side. Okay, so thinking about the technology stack that I showed earlier, as you start to build these out, you realize how much effort time goes into building even just one stack. And if you want to be able to scale, obviously the importance of automation comes in. So as the product evolved, as the common stack that we call it evolved, we started to introduce new tools, new processes to make the job easier and also obviously be able to keep up with the demand of building out multiple environments as more and more teams or services were introduced. So the provisioner, this is more of a high level and I'll go into more detail in a minute, but we leveraged a packer to start building out whether it was like an AWS image or VMware image, Google image, we had some standards or some security practices that we wanted to apply to the images, basically creating like a standard or golden image, if you will, and then leveraging it as part of the provisioning process that would get fed into ultimately the instances that would get spun up in the VPC and that's what that bottom layer shows there. And basically deploying or distributing that image to the various GCP or AWS accounts in order to leverage it for deploying the Terraform. So you can see here the end result is being able to deploy the full stack, the infrastructure, the Docker Kubernetes OpenShift platform on top of the various cloud providers. So here's basically a couple of use cases that we identified when we were building out this latest generation of what we call our deploy or platform provisioning, the GitOps way. It was actually before we realized we were doing it the GitOps way, but ultimately we used Git as the source of truth, if you will, for storing like various input files that have all the configurations about the stack, the state file that's needed for tracking, essentially everything you needed to build the stack, to identify its state and be able to expand on that stack. So on the upper left where you show Git, it's more of an automated flow going through where somebody does a Git commit with the state they want. They ultimately do a Terraform apply, plan apply, and that kicks off deployment, whether it's in cloud or on-prem, like a VMware type deployment, but it goes through the whole flow leveraging, Ansible is one of the core pieces there. And the key part there is when you build the stack, not all stacks are gonna be built the same, so you need the flexibility to alter the size, right? And we designed it in such a way that you could, there's a set of defaults, but you can modify how many OpenShift nodes, masters, utility servers you ultimately need in the stack. And since it's a different Git repo for each stack, you can manage those separately. But we also realized that there was a need for testing as well, quick iterative testing of our own code and our own automation, which is the lower left-hand side workflow, if you will. And that's simply a developer doing a Git pool, modifying, his changes, then pushing those out to like a testing environment, if you will, and being able to repeat that process. But ultimately, through a combination of Ansible and Terraform, we're able to spin up stacks pretty much as quickly as the cloud vendor allows and a variant sizes, and it's all pretty straightforward. And it's easy to kind of train like new individuals that aren't used to automation of infrastructure to say, hey, here's what we have packaged as a deployer. This is really how you use it, even if you don't necessarily want to understand the inner workings, and that was the goal. So that was for the platform deployment, but you also have the services deployment side of things. Again, here, we actually use Git as the source of truth as well. In this particular case, pretty much every development team has their own form of CI. We give them the flexibility to build and automate how they compile and ultimately do their local testing and building of artifacts. But once they're ready to actually test in our sandbox environment that we provide for them or even go into deployment, they effectively do a Git commit, which triggers this whole CD pipeline flow. Part of the Git commit specifies things like your target environment, the services that you want to deploy, and expose ports, things like that. The common attributes that you would find that describe your service and how it's gonna be rolled out. And we support Docker Compose format as input, but we're actually focused more on the Helm side now. And just by show of hands, who here uses Helm for the majority of their deployments? Oh, okay. So yeah, that's actually one of the newer features we introduced into our CD pipeline and support for Helm. But ultimately the flow is user commits a change to the input file, a Helm chart, a Docker image in something like Artifactory. And we pick it up, we copy it into our own local space. We wanna do a security scan of that Docker image, make sure it meets the standards that we've set and there's no glaring critical issues there. And we use Twistlock to scan those images and provide any feedback. You can put gates in place, security gates, so that if there are vulnerabilities, you can actually fail the pipeline right there and send back the report. If it turns out it's good, it passes the security scans, then it goes and syncs with Bintray. Because Artifactory is actually only accessible internally, we needed a way to access Docker images externally. Bintray stores that and then ultimately the deployer communicates with the endpoint OpenShift service and tells it it's ready to pick up the images from Bintray into the local registry in OpenShift and ultimately deploy those services. So, I mean the bottom line here is that we wanted to empower developers to deploy on their own schedule, whether it's once a day, once a week, a month, whatever it was, without actually getting in the way, having operation, the typical operations model where they have to wait a certain period of time in order to get these deployments out. So now it's literally on their schedule. There's still security gates in place as well where this pipeline, as part of the input, they can dictate like an approver chain, if you will. And when they submit, it has to go through like a couple layers of approvals. And finally, if those are approved through the pipeline, it ends up getting deployed into production. And one of the other important pieces that ties into here, it's not actually mentioned, is if it is in a production environment, you wanna have a paper trail of what's happening. We integrate with ServiceNow, create a ticket, put the necessary details in there, ultimately close the ticket and deploy. So that's all tracked and audited. But you can see on the right hand side, it doesn't matter where OpenShift is running, as long as we can reach it through a network, we can actually deploy to it. So whether it's on the cloud or it's on-prem. Yeah, that's pretty much it there. Okay, so we've kind of talked about where we've been, where we are today, but where are we headed, right? So where we see ourselves in the next three, six months, we wanna be able to leverage operators to manage the life cycle of services like Postgres, MySQL, Kafka, those are gonna be critical for us and we wanna start providing essentially self-service, a self-service model for development teams to be able to plug in or bring in database technologies, for example, quickly without having to wait for the traditional, let's get some infrastructure and deploy the database there. Number one is time consuming, two, it doesn't scale well. And three, if you can have operators actually managing the full life cycle of that, it simplifies things, right? That's part of the whole automation story. So that's one big piece. The other thing is, we want developers to focus on what they're good at doing, right? Developing services and not focused on actually how they deploy, like a Kafka cluster, a Zookieber cluster, things like that, right? And that can be time consuming, their time can be better spent elsewhere. So I think that operator's story kind of blends in well with that. We wanna incorporate a service mesh for multiple reasons, but one of them being, we wanna standardize on the security model there. And finally, multi-cluster management for various reasons, but we definitely see the benefits of that and having a single pain of view, if you will, for how things are operating, especially the health of clusters, excuse me, health of clusters, and even like a chargeback, modeling usage and things like that. It's definitely beneficial. So I know, Diane, you were looking for some honest feedback, so I just put a couple of things here. Ganesh, feel free to add anything else that you see fit. But basically, we just wanted to highlight, we're hoping that Red Hat can bring some focus back to OKD on 4.x. Right now, we're running on 3.11, but there's definitely features, including some of the newer operator features that we wanna take advantage of. Node management and patching and things like that. So, and definitely the chargeback stuff. One of my engineers actually made a comment that he was trying to install code-ready containers, OpenShift 4.2 on his local laptop, and it consumed like 20 gigs of memory, which brought it to a crawl, so maybe take a look at that. We're looking for a similar experience to how many shift operated. It is a pretty quick, very small install. And ultimately, simplify the upgrade process, which I know that you guys are kinda working on, but we haven't seen yet with the OKD. So, anything else, Mitch? That's it. So.