 Thanks, Handis. Hey, everyone. I'm glad that you're spending some part of your Wednesday with us and, you know, we're really excited to share, you know, our vision for enterprise communities done right. And, you know, just wanted to throw out a couple of takeaways to get, you know, get this agenda rolling. What we intend to doing over the course of the next few minutes is just taking you on a journey and just trying to understand, you know, what some of the common challenges with adopting communities are some of the common deployment patterns that we've seen challenges that customers run into as far as adopting complex, you know, deployment patterns that meet the business requirements, and also really, you know, focus on the importance of an open source in a communities in a strategy right and how that's going to help you achieve that multi cloud strategy and help your organization be successful with cloud native adoption. So, hopefully, the takeaways from this webinar are going to include what it takes to transition platform built on communities that is what we call enterprise grade and production ready. And also how you can be an active participant or someone who is an advocate for the adoption of smart cloud native in our applications within your organization. Right. With that, let's dive straight in. So, one of the key topics that we wanted to kick off with is a fact that communities has become the de facto standard for building modern cloud native applications that are out of the box, you know, scalable and are resilient to failure, right. So communities has seen massive adoption over the course of the last few years, and has become the de facto standard for building modern cloud native applications. An interesting trend that we're also seeing is the fact that communities is almost kind of being likened to what, you know, Linux was, you know, many, many years ago, which is just the abstraction layer for your underlying infrastructure so communities is being positioned as almost a cloud operating system that allows you to build applications in a very decorative way and allow you to deploy those applications in a wherever, whether it's on-prem in your data center or in, you know, a public cloud provider. Should we talk, Shafiq, a little bit about why Kubernetes is the one, why it's, as you, I like your reference here, why it is the way, as they would say in the Mandalorian. Yeah. What made Kubernetes win? Yeah, let's, we could definitely talk a little bit about that. Do you want to leave that off and, you know, I can chime in. Yeah. Well, I think, I think you hit on some of it. I think that it was built to mimic some of the patterns that we saw at the hyperscalers that allowed them to build very scalable and very resilient applications. You know, they realized that their lifeblood, their very business depended on that site, that app always being up. And so they had to come up with ways that were very resilient, that prevented human error, that prevented hardware error from taking down the site. And so this move to containers really started there as they realized that if we, if we say, hey, forget the server, no one ever deploys anything to a server. We're using containers, those containers can be scaled effectively. They could be up and Kubernetes really takes those patterns and makes them accessible to everybody. So I think that's one of the big reasons you want to hit on another one or two. Yeah, absolutely. Right. So the way, you know, the deployment patterns for applications, you know, what Kubernetes enables you to do is I use the term declarative, you know, a minute ago, right. So what I mean by that is you really don't need to have any human intervention when you're, you know, deploying your applications. So you simply define the resources that your application needs. Resiliency is factored in through maybe the use of like replicas where you're able to deploy applications in a highly available fashion. So what do Kubernetes as the orchestration platform to ensure that your application stays online right so there really isn't any room for, you know, human error or you know there really isn't any intervention needed as far as you know the application is concerned right or maintenance of the application is concerned and then fast deployment when it comes down to operations and when it comes down to like maintaining your applications, it's much more simpler to lifecycle manage, you know, applications leveraging in a way, you know, through Kubernetes APIs, you know, through automation right. There are capabilities that exist within communities that allow you to, you know, deploy applications using, let's say a rolling strategy which really ensure that you're able to gracefully update versions of your applications without having to go through traditionally changes, it's like, you know, it's not your traditional maintenance windows you need to be worried about right that we've had stories, you know, you know, people adopting communities in production and making changes, you know, significantly without having to like really factor in this or, you know, one of the value propositions we talked to customers about our operators about is the fact that you really are not going to be spending, you know, the same amount of time on maintenance windows as far as, you know, application rollouts and deployments are concerned right. It really challenge your developers to think about, you know, application deployment or modern software development lifecycle in a different way right and you're really getting all the goodness of, you know, just like you mentioned the hyperscaler culture, it's something that could be adopted within your own enterprise. And I want to hit on one other thing before we get on the next slide and that is that. So we talked about why people adopt the technology and of course it is portable because you can run kubernetes anywhere you're usually move to the cloud you can run it on premises you can run it on any cloud. But I want to point out one thing which is really encapsulated in both of those those bottom bullets which is the innovation in app deployment the innovation operations the innovation in in developer experience is all around kubernetes today. If you choose another platform, then you would be missing out on that innovation and even if you look at what the major networking vendors look what, what, say at five Cisco is doing what what Palo Alto networks is doing, they are all innovating on top of kubernetes now. And so if you want to be able to take advantage of what's happening in technology, you have to be in this space. So kubernetes is the way I think I think I think we can agree. No, completely right and it just the ecosystem is just so rich and there's just a vibrant from the perspective of all the innovation that's going on in there right and you hit on networking. Just think of any other capability that you would use to like you know build out a platform right whether it's something that's you know security related or you're talking about integration with your existing storage fabrics or integration with your existing in a network solutions that allow for, you know, in a layer seven capabilities right, all of these ISVs were like working in this ecosystem and unlocking all of these capabilities for customers are definitely ensuring that they do have a solution for kubernetes and kubernetes is almost becoming that substrate to like you know build, you know your platform on and you know deploy your applications on just purely because there's a lot of community engagement and a lot of where the innovation is happening right. So, so if I'm a CIO and I'm attending this webinar and I say okay great I should be convinced we're going to kubernetes we're done. Should they sign off now. Yeah, yeah, or should you get to the next slide. Okay, alright so yeah that's that's a great that's a great lead and right and thanks for that and like. I was I was joking when I said yes right so kubernetes by itself again kubernetes by itself is just giving you the container orchestration capability right so we're seeing a lot of. adoption of a mindset of building teams that are you know engineering platforms right so what constitutes a platform. You know, coming going back to my you know solution architect days and consulting days it's it's always about like you know building something that makes sense to the business that's going to accelerate. The business outcomes for you know a specific organization and almost just kind of being very laser focused about adopting innovation to really move the needle when it comes down to solving challenges for your organization right. So that being said if I'm looking to build a platform and I'm looking specifically to build a kubernetes based platform. kubernetes just gives me this one capability which is what we just talked about a discuss in the previous slide which is robust. In a container orchestration a resilient way to deploy your applications in order to build a feature complete platform that allows you to really meet those requirements that you know your business might have you need to like start figuring out what some of the other capabilities you're going to also build alongside kubernetes right so it could be something along the lines of. Figuring out how you integrate with storage how you do secrets management what your application deployment. The formats are going to look like how do I you know provide my developers, you know a service mesh technology how do I handle networking whether it's load balancing or trying to like you know figure out how I'm going to secure. applications using you know certificates or trying to like ensure that all of the applications that I deploy, have, you know, HTTPS, you know encryption for their mode of communication, or if my platform is going to be serving or providing multiple teams do I have robust you know multi tendency included right so it's not just about communities it's much more complicated than that because you really need to like figure out how I'm going to unlock all of those additional capabilities and those were just some examples and they're by means a complete list, but the idea is, you really need to look at what's out there in the ecosystem and which vendors you're going to work with whether it's you know commercial vendor or the graphic out here is the CNC of landscape right to which projects you're actually going to like, you know cherry pick and choose, because you have multiple options for each of these capabilities I call them like technologies that underpin a capability right. The concept here is you need to do a lot more work in building out that feature complete platform or quote unquote a batteries included platform when it comes to the communities. Yeah, I think that I think that's really important to note because you, as you said, Kubernetes is a container orchestration platform right that's what it does. And the reason that the cloud native landscape is so complex is that there are many things you need to do for security for all of those things you notice on top of it. So if again like let me put myself in the shoes or that that's CIO. I'm thinking, Okay, so I have to settle on Kubernetes and yes I do need to secure everything I might need to figure out do I need mtls what do I need do I need smart you know l seven load balancing. What am I going to do about secrets. Does that mean that. Well, it seems like the decision to adopt Kubernetes was an easy one, but there's a lot more research in front of me because I'm going to have to learn what each of these icons means what's behind the project what what purpose is it is it filling. How does that fit with my requirements, and then choose each one is that what you're telling me I've got another six or nine months of work ahead of me to try and figure out how to turn this container orchestration platform into a real, you know enterprise ready cloud smart cloud platform is that right. Yeah, it's going to cost me an extra nine months. Yeah, that's that's exactly what it looks like right that's typically the journey that you go on once you've decided to you know go down the path of like you know Kubernetes right so it's a significant amount of research and yeah it takes it takes a significant amount of investment from you know a people time perspective to figure out you know what your you know end state technical stack looks like. Okay, but let's say I do that right so it's so I put in that nine months then then then am I ready, then can I just turn my application developers loose where my operations people were set. Yeah, that was that was going to be my next question or my lead in was going to be great we figured out now, hopefully you're long for the journey right you know the story that we're trying to paint here so we figured out the technical stack. We made our choices. We decided that the business needs a platform with all of these capabilities we picked all of these different in our technologies to underpin those specific capabilities. Does it end there that's just your that's just your day one. What happens after right is the question right significant operational challenges ahead right and what do we mean by that right. Installation. Great, you've got one stack ready to go. What if you get massive success and you know everybody wants in on the platform and you decide to roll out this technical stack. Multiple geographies for example right you know we deal, you know, largely distributed world nowadays and you know you really want to provide the same experience or a consistent experience across your organization across multiple geos. So, there is still a challenge associated with have you figured out the automation or like just generally the installation aspect of how you can manage this technical stack. And I think it's important to note that that you've got not just one thing you know as you just said we've got Kubernetes and many of those things run on top of Kubernetes some of those things are running underneath Kubernetes right you're now in each of those projects has its own release cycle. So this this process itself is is going to be significant right as you say it's going to be significant every time you turn something up every time you turn up a new. Yeah, new data center new region even a new cluster, but now you've got all these different components with dependencies between them, possibly reliance on each other, and they each have their own life cycle, right, upgrade, etc. Yeah, exactly and upgrades that's that's another key part of it right so if day one signifies you know just getting a technical stack up and running based on the design that you put together. What does you know subsequent days look like or what does post day one look like. Let's say you know quarter down the road you decide. I really need a specific capability that one of these projects is getting me what is your upgrade strategy going to look like and then it's not just for a single cluster because you were so successful and you saw massive or you've seen massive adoption with your platform that you've just built. You need to like figure out how you're going to roll out or what your upgrade strategy is going to look like you know globally for all of the clusters that you have running in production right so upgrade is a key aspect Dan alluded to the whole interoperability bit right so now we have all we all know the benefits of you know leveraging you know open source, but then just like Dan mentioned each of these projects you know they really isn't any synchronization when it comes down to. You know the release cycles or you know whether someone's a unit really need to be meticulous about you know going through documentation and figuring out whether you know a specific you know project or a specific. A technical capability is compatible with maybe the underlying version of communities that you're running on you know breaking changes happen right you know that's that's something that we've seen often as operators or someone who's been an ID for a while, you know that breaking changes happen and just reading the fine print and just ensuring that you're managing all those moving pieces from an interoperability perspective is another key challenge from an operational perspective. And that's what not least security right we are dealing with complex you know distributed systems Kubernetes by itself is a distributed system with multiple moving parts. Then we're not even we haven't even started talking about the workloads right so it depends on the workloads to deploy in the platform. What is your strategy to secure, you know the workloads as a platform itself and then the workloads that run on the platform. So I think I think one important thing is you said the workloads are your business and you're going to have to you know you got to figure that out but the platform, I think that's a really important thing right we just showed that open source landscape. And, and you know, you're going to need a dozen two dozen of those of those projects at least right, you're going to become very acquainted with the letters CVE common vulnerability exposure right. And, and each of those will have to be something that you are paying attention to, because when some of these CVEs come out, they will affect you and they will affect the you think you might think you're in control of your upgrade and your interop interoperability. And then all of a sudden you've got a patch a component that you didn't know you were going to have to patch right again. So, aside your from your own code, you're reliant on open source project and open source project so security becomes a very important operational challenge that you have to solve right. Yep. This is this is what leaders and you know architects and everyone you know working in this ecosystem are constantly thinking about right how do I, you know the term that's being flow that's being floated nowadays is reducing the cognitive load associated with operations right just making it simple. It's about figuring out how I can minimize the amount of time that I'm spending on operations. Right. So, I've solved that then right or I have a strategy or I work with somebody to figure out how I reduce my cycles on my team cycles spent on operations. What's next what's next in the journey. So I think that the thing that we have to bear in mind as we're as we're doing this is we're thinking about adopting Kubernetes we're adopting this new technology. One thing to understand is that you have to solve this in a way that you've solved it in more than one place. I think there was. I spent a lot of time working at Google cloud and when we spent a lot of time and the other vendors as well trying to get people to move to the cloud thinking, eventually it's all going to run up there right eventually people are going to choose a cloud they're going to move everything up there. But what we're seeing increasingly and and what every every attendee of this of this call is seeing is that it's never going to be 100% in the cloud and in fact, CIOs are saying and CTOs are saying no no no no hybrid cloud isn't a way point along the destination hybrid cloud is where we're going to end up. So as you're choosing your kubernetes solution, unless you want to double your work, double your operation staff increase there I love that that term they're they're cognitive load, you are going to have to solve it in a way that it's solved both for what you run in a cloud and on prem and chances are, it's not just one cloud right. It's, you know, a lot of organizations, even if they do not start off directly with a multi cloud strategy, they definitely want a hybrid cloud strategy which is a combination of their own private data centers with a primary in a cloud provider right and that's a you know, that tends to be, you know, significant, you know, investment that they're, you know, they're definitely exploring outside outside. So what are what do you think are some of the common use cases for you know multi cloud management this is this is a conversation I love having. And maybe I'll throw in a couple of those use cases so outside of you, you mentioned that everyone's looking at a multi cloud strategy or a hybrid cloud strategy because the data is not going to move right so the data gravity or governance requirements might dictate, you know, a multi cloud strategy or a hybrid cloud strategy what else what else are we thinking here. Well, if you're if your company is big enough, if you're if you're, you know, working at a fortune 2000 company, one of the reasons is that one of the ways you got to be a fortune 2000 companies was through you're acquiring companies and they're already deployed somewhere and it might be deployed somewhere in such a way that it is very difficult or expensive for them to move they might be dependent on services. They're absolutely there. Other companies refuse to be dependent on single vendors, absolutely and financial services I would hear about the four cloud strategy, and the four cloud strategy is the three major players plus our own. They are all very very clear that they for sometimes for bargaining reasons sometimes for resilience reasons and just not wanting to be dependent on a single company, they wanted to ensure that they could always choose. So there are a bunch of reasons sometimes you're running a workload that someone really does have a proprietary technology technology running in their cloud, and it makes sense for you to run a workload near that near that technology. A couple of other common use cases that I've come across is just as it could be as simple as just business continuity or DR right we've definitely seen a disaster recovery right so it's just all about leveraging multiple cloud providers just to ensure that your business is not impacted in the event of an outage right so that's that's one common strategy. The other one is with the rise of just being a distributed world that we live in today is just all about you know what I call the pop architecture right which is a point of presence right it's just about having you know your services running as close to your user as possible right or your end users as possible. So the idea of just having that point of presence, you know, in a global world, in a world that's you know increasingly getting digitized you know that makes a lot of sense right so you definitely want to have, you know multiple cloud providers in a certain cloud providers might not have the regions that you know in a market that you're potentially looking to tap into so that's that's another in a great in a use case as well. So, to the headline. Are we both are going to both transition here. You go ahead you transition. Yeah. Yeah. All right, so we discussed a little bit about you know multi cloud, and we talked about why multi cloud is a challenge a little bit we touched on that the reason we are kind of like transitioning to this slide is we want to talk about what some of what it really looks like at the deployment level right when you decided that okay multi cloud or hybrid cloud is something that you really want to do. What are some of the challenges associated with actually getting that working right so that's Kubernetes is open source right doesn't didn't we already choose open when we chose Kubernetes. I don't understand. Yeah, we did we did you know that's that's the aspect right you know that's the aspect that we wanted like you know really talk about here Kubernetes is supposed to be open source. So, you know, are we connecting the dots, yes we are right so you know we really want to be able to use a Kubernetes based solution in order to like you know help, help with some of those challenges that really, you know are tied to, let's say a multi cloud strategy right so the first pillar being here. Let's talk about portability. Basically when you decide to go hybrid cloud. The idea here, I'm, we're trying, trying to tie a couple of concepts here where if the objective is to have a hybrid cloud strategy, and then as a CIO, I want to reduce the time spent on operations. I really don't want to have multiple, you know modes of operation when it comes down to maintaining. My platform in a private data center or in one of the cloud providers and you know have a different experience all over the place right. The idea about, you know, leveraging Kubernetes to do this is a fact that you have the portability of just having a unified experience across any infrastructure that you might be leveraging in order to build out this multi cloud strategy or hybrid cloud strategy that you're looking for. I think it does and I think there's more too because I think that Kubernetes is absolutely open source and there are lots of vendors who will package a Kubernetes into a essentially a platform for you. But they don't all really allow plugability at every layer right there are some say oh you can use Kubernetes but you have to use it on our operating system for example. Or we've got we've got a monitoring system built in and we don't allow you to plug that in and one of the beauties of Kubernetes and one of the reasons that Kubernetes one is that not just that it was open source, but that it had plugability everywhere. Right. If you want look at service mesh I used to work on the SEO project right there's probably for service meshes in in in the cloud native landscape. So when you're choosing Kubernetes done right when you're building not just Kubernetes but that platform and you're and you're choosing a platform to build on you want to ensure that your platform allows you to plug in what you want to plug in. Right. And I think that that's really important because you are cutting yourself off from some of the innovation in this cloud native landscape. If you're building a platform that when something innovative happens you can't plug it in your vendor says oh no no we don't we don't allow you to do that. I think that's that's really important. Yeah, exactly right it's it's not it's not so that's the key difference here right it's it's not a pass right a pass is a very opinionated way of doing things the philosophy the ethos behind building a platform leveraging Kubernetes is the whole plugability aspect right you know we have conversations. All the time with folks who have like certain opinions on you know how a capabilities delivered like let me give you an example when we're talking about logging for example right so they're a bunch of solutions out there or there might be an enterprise standard that says this is how you have to do logging right you know and therefore very good reasons you know it could be for audit purposes or you know it could be for just ensuring that you're able to go you know figure out you know forensic information based on access to your applications or data. So there are very good reasons why enterprise standards exist for a specific you know capability. And you really want to like be able to, you know have a platform that can readily plug into those standards or plug into those specific requirements or meet those requirements right and you know we're, you know that's that's a pretty exciting thing about you know communities and building out a platform that is based on communities you just have the plugability aspect, and then talks on this a little bit you know the innovative aspect or the innovation aspect right there's always something innovative going on as far as you know the communities ecosystem is concerned you know everyone likes talking about the service mesh and then touched on that a little bit but it's very exciting you know for developers you know because a service mesh allows you to you know not really impose the limitations on your developers right so it's a polyglot way world where you know developers have their preference for you know what they're developing in and you really want to like decouple some of the non-functional capabilities from your application code right so if you're looking at you know building a capability that's you know then referred to mutual TLS you know just ensuring that the applications communicate in a secure way or you really want to like implement a circuit breaker pattern just to ensure that you're able to like you know meet certain SLOs or you know cut off traffic when you know there's an incident you know those are capabilities that a service mesh brings to the table and that's just one example of like some of the innovation that's going on in the ecosystem right. Okay so I'm going to devil's advocate again. All the cloud providers now have managed Kubernetes. Again if I'm that CIO CTO, can I just take that manage Kubernetes and assume that that's okay right it's all managed for me doesn't that solve this problem. Not really. And we'll talk about why right. So the question here is, you know, all the cloud providers or is managed Kubernetes a solution. Everyone's, you know, got a, you know, managed Kubernetes solution now, it only solves part of the problem right so you know going back a few years typically if you when you were getting started in this cloud native journey that hopefully we've been doing, you know, a current job of just kind of taking you on. You start off with like figuring out what makes sense to me from a technology perspective you land on communities you understand that this is the future this is how I want to develop my applications I want to really get away from the business of managing servers I want to abstract my underlying infrastructure and provide my developers a great experience alright fantastic. But then, you know, there was a period of struggle where you know customers typically or you know folks working with communities they go through a bunch of challenges when it comes down to like you know figuring out how to run this in production right that cloud managed in a community services right they really abstract away some of the really hard parts of operating communities in production right like for example the common in a punchline of the tagline Dan like a few years ago was like and I'm just so worried because I have to operate at CD in production right or you know I'm troubleshooting you know problems with the you know raft protocol or just trying to like you know figure out you know what's going on here. You know, why did I, you know lose my cluster right so that's a challenge. The manage community services definitely solve for right they make that aspect of operating communities or that component of communities which is the central of the system almost a black box right so the idea is you focus on figuring out what your business outcomes are figuring out the other aspects of the design that you need that you need to be spending your time on as far as a platform is concerned right you know choosing the appropriate, you know instances of which machine types that you need in order to like you know support your workloads and figuring out the other things that we just spent the last few minutes talking about which was you know building out rest of the stack. Then was right so yeah yeah I think I think I think that's exactly right your manage Kubernetes are fantastic offerings I think the best advertisement they ever got was Kubernetes the hard way by Kelsey high tower right because it showed installing running Kubernetes is tough, you can get Kubernetes out of the box from any of the cloud vendors and never have to worry about any of that aspect again, but those limitations that we talked about Kubernetes at its heart really is container orchestration. You still need to layer and all those pieces and and while different cloud vendors have done different things to make that a little bit easier. For the most part, it is not a platform out of a box and you still need to put a lot of pieces in place on top of it to take that manage Kubernetes into a you know complete integrated automated platform and now is when you get to talk about why D to IQ and and something like AWS EKS are better together. Yeah, so we're going to, you know, use our, you know, friends and our partners at AWS as an example here and EKS is, you know, a great distribution as far as great, you know, cloud managed, you know, Kubernetes some in a service that you know you can run in production. And just like Dan mentioned at the end of the day is still Kubernetes and you still need to spend a significant amount of time trying to like figure out how you're going to build out this feature complete platform right so there there are a couple of, you know, patterns that we've seen, you know how customers or you know folks working in this domain, try to like solve for this problem right one is a pure do it yourself approach so great. So the scenario that I described right, I really want to like make the operations related to Kubernetes simple so I'm going to go with the case. But then I decide to curate the rest of my, you know, technical stack using open source competence perhaps in a word from the CNC of landscape right. So then we're back to the same problem right what are we doing for figuring out a strategy that's going to allow you to consistently install these on multiple clusters. Then it becomes challenges related to you know upgrades, it goes back to interoperability challenges it goes back to security challenges right so it's that circle that we had like earlier in the presentation. So that's the first approach you're, you know, using a case plus just completely doing it yourself, as far as you know the rest of the capabilities are concerned. The second approach we've seen is obviously the crowd vendors have managed services that unlock, you know, some of these capabilities right so for example, in a thing within the AWS ecosystem. You might have in a cloud watch for your in a logging and metrics, there is, you know, a solution available for maybe in a continuous deployment on Kubernetes. You could decide to like you know stitch all of those together and integrate all of them with EKS to get that feature complete platform that you need, right but then obviously you're going to be, you know, if your CFO is watching. It's going to be on point in terms of just understanding what costs all of these represent, and just be able to like you know build out the appropriate, you know, in a cost model, just to ensure that you know it meets your, you know, business requirements or if you have specific TCO ROI targets you know you really need to be in a cognizant of the fact that each of these services costs their own, you know, money right. And you need to be aware of costs, I mean you need to be aware of portability right because if you're dependent on a cloud service, and you need to run your, you know, you're in that hybrid cloud world or that multi cloud world. That means now you're using different services, right. And, and one thing we haven't talked about very much is that there are many use cases, including on-prem in the cloud and on-prem especially where you need to run an air gap cluster. You can't use a cloud based solution for any of these in those cases. So, so I think yeah, the point here is a great one that that the managed Kubernetes services are fantastic. And when you're in the cloud, they're a really good way to get Kubernetes. Be aware that everything else that you need to do in terms of security in terms of networking in terms of backup in terms of, by the way incomplete list here is still something that needs to be done on top of those. And you need to solve those problems. And you want to solve those consistently organization-wide so you don't have individual teams solving them in individual ways, especially differently in individual clouds and on-prem locations. Exactly. A unified operational experience, right. We touched upon that a little bit earlier in the presentation, right. You really want to have a consistent experience, especially if you're trying to tackle a hybrid cloud deployment or a multi-cloud strategy. You really want to strive for having a unified experience irrespective of what your underlying infrastructure looks like, right, whether it's on-prem or bare metal. Dan mentioned air gap, right. If you have workloads that are running in your private data center, are you going to, something to think about is are you going to have a different operating model when it comes down to like, you know, versus what you have in the cloud. And then the third approach that I was going to touch on a little bit is the fact that the cloud vendors obviously being very customer-first, you know, they are working towards like enabling some of these capabilities, you know, with EKS, right. So we definitely want to acknowledge that and, you know, that is something that's, you know, gathering ahead of steam. Again, it more or less aligns with what the challenges are as far as, you know, the second scenario was concerned, which is you end up using, you lose a little bit of portability there, just purely because you're using opinionated tooling which will, you know, just work in a specific cloud vendors ecosystem. And, you know, it's really not something that you could just kind of pick up and use when you decide to like either move your workloads back on-prem or you decide to, you know, leverage a different cloud provider for whatever reason, right. So the loss of portability is, you know, pretty key there as well. So the graphic on the right, what it just meant to articulate is with DTOIQ's, you know, Kubernetes platform with EKS, it's a complete integrated in-outernity solution using open source technology that allows you to like, you know, standardize your experience across any infrastructure. That's the key takeaway here. All right. Should we kind of wrap up the technology portion? Yeah. Yeah. So, sum it up for me. How do you do Kubernetes, Ray? Yeah. Let's put it all together. Let's put it all together, right. So this is the key takeaway here, right. Committing to open source. We really, again, we heart on the open source aspect of, you know, the benefits of open source and why, you know, portability matters. We really want to get to a point where there is a standardization of operations, right. And you really want to start looking at clusters themselves as cattle, right. You know, the concept, the initial concept of like cloud native, back in the day, people talked about, you know, cattle versus pets, right. And now it's gone to a point where you can significantly automate your operations where you can start looking at your Kubernetes clusters themselves as cattle, right. So how do you do that is through the use of, you know, GitOps and declarative APIs, just like you would, you know, deploy workloads on Kubernetes using deployments. Adopt a mindset that just allows you to declare the state of a Kubernetes cluster and get up and running, you know, really quick without any human intervention. You really don't want to be running scripts all over the place and, you know, using something that's really custom and, you know, run into like operational challenges every time you decide to, you know, either stand up in your deployment or upgrade, you know, existing, you know, Kubernetes. I can't emphasize that enough. I was at a company that was looking at opening a new region, and they were budgeting a quarter to open up their new region. And the reason is that that bottom, it's all run by humans. Yes, yes, they're scripted stuff they bought me some things, but they are literally yeah it's going to take months to ensure everything is installed in that region the clusters are created properly they were running some Kubernetes and some VMs, but that's not the way you want to be when it's time to turn up another cluster somewhere that should be as simple as it change in a config file, and everything else happens. Everything, every bit in that stack from the deployment of Kubernetes whether it's a managed Kubernetes or not to every everything else that happens should be declarative and opening up that that new region, or, you know, falling over to it it might just be a new it might just be a new availability zone right it doesn't have to be you're opening a new region should be should be done in that way. Yeah, exactly. And the power and then yeah, go ahead and say and make sure that you're ready for your deployment patterns right, you might have some things that needs to run in a particular place you might have some things that need to run on Prem. Understand those those going in so as you're choosing your solutions, they will work there. If you have a reason to run air gap clusters whether on Prem, or, or in the cloud or you know moving vehicle for example, make sure that you're choosing a solution that's going to work in those those different deployment patterns. Yeah, exactly working way backwards from you know what your business needs right you know that's that's I that's that's kind of like my line you know just working. Don't do not make you know decisions that are really not going to serve your organizations in a purpose right so figure out like if it's an on Prem strategy that you need or if they're for specific reasons you need to have an air gap deployment or you're deploying a platform to the edge you know we've seen some pretty cool in a use cases where you want to move the computer towards the edge you know where the data is right and you can definitely enable or you can use Kubernetes to build a platform that enables that deployment pattern right so I think we find that like pretty exciting it definitely lends itself to enabling really cool use cases in a going going forward right you know I made this comment earlier the world is you know increasingly apps centric and getting digitized and you know people want to build applications that you know unlock new streams of revenue or whether it's just engaging new customers or like you know figuring out ways to you know optimize on how experiences for your end users might look like right and all these lend themselves to like different deployment patterns and we think you know a Kubernetes based platform obviously done right is you know a way of definitely tackling those in a business challenges right and then I'll okay be Hold on being cognizant of time I think we should say okay so this is how you do it right from a technology perspective yeah but I know that there's one last point you want to hit and that is is it just technology it's not just technology right so this is you know for folks who have worked with me in the past is like they always say for me success is a function of you know people process and technology right so while we spent the lion share of this presentation you know just talking about you know the technology challenges or how we we solve for some of these technical problems. You know be cognizant of the fact that we really need to involve people and build the appropriate processes in order to be successful as well. So you know this graphic again just talks about you know some of the common you know user challenges that you know organizations grapple with in order to like you know get this right. So some of this includes you know just making some of these cultural changes right in order to have a DevOps mindset or start building a you know practice around you know get ups. You need to have transparency and collaboration right so highly siloed organizations you know where think of it as you know development teams not talking to the operational teams or vice versa. You know that really doesn't you know really lend itself or like putting in a position where you're going to be successful with this initiative that you're taking on. Right, so I think that that's the most interesting thing here is that when you ask users what their challenges is number one is culture. Yeah, number one isn't isn't a technology and this is what you ask the people the issues and if we go look at the organizational challenges on the next slide. I think you see something else very interesting, which is when you ask organizations. What's the biggest problem for you adopting adopting Kubernetes. Look over there monitoring health and performance of Kubernetes cluster seems like that be important it's relatively small. More important is the thing we all hear about is how do I refactor my monolith to actually run in Kubernetes. And even that more important than that is the thing that should be we've talked a lot about today, which is how do you manage Kubernetes itself and that ecosystem all the components. But the most important thing is the people right the number one challenge people are having. And what I find that's interesting in this two thirds people say their biggest problem with cloud native is finding attracting and retaining qualified Kubernetes talent. My opinion Chavik is there they're looking at this the wrong way that you can't look at how do we hire all new people who understand Kubernetes. I think that the lesson that I'm hoping that CIO CTOs are CEOs are learning here is that we've got to bring our people along. We've got to give our people the practices the tools the training what they need to adopt to this new world because if if you're going to be trying to replace all of your developers all of your operators. You're going to fall farther behind. Yeah, exactly. Investing new people. There's great training available from an operator in a persona perspective. There's great training that you know allows developers to adopt a cloud native mindset and leverage you know communities effectively right so that's definitely in a part of the solution right. Which will say you perfectly into hey look at that. Yeah that's that's what it is it's it's all about you know people process and technology right it's about organizing for success you know you know the making the cultural changes are probably the hardest right but that's something that you definitely have to take a look at you know if you really want to become you know a devops or get ups you know process based organization, you know, changing your organization to reflect that is something that needs to happen right training and enable me to ski. If you don't have, you know the cycles or you know you are struggling to like you know really get your enablement programs or your cultural change programs off the ground. You know, engage with an expert or you know just figure out if there's a vendor out there that can you know help you with your journey right and you know they can come to the table give you the best practices, known practices and you know that way Excel radio journey for cloud native maturity right. Yeah. That's it so this is going to be the real final slide here right which is just tying all of this together. So what do we mean by doing communities right. You know adopt a complete platform right so communities is just communities if you're looking to build a future complete platform. There's a lot more that you need to think about. You know, leverage open source it gives you the benefits of all the innovation that's going on in the ecosystem gives you the portability associated with like using open source technology, but there is a significant amount of automation in the automation space as well which just allows you to like really treat the platforms or your clusters as cattle right you know declare everything. Allow you know the automation to do its work right and hybrid and multi cloud is the destination you know a lot of you know common deployment patterns nowadays are hybrid and multi cloud and nature. It all comes down to what your business needs and it's just not about the technology so think people process and technology right. There are some questions that we've got in Domenico Vigiani asked, does get ups add too much complexity, which is, which is his first impression. Having seen get ups really done in practice, I, because I did spend seven years at Google and again a lot of these principles come from what was already working at Google. I will say, no, get ups removes complexity and I know that's counterintuitive because we're not working that way. But when you when you get to the point that everything the deployment of your application the deployment of your infrastructure is declarative. It becomes much, much easier to to operate things and that's, you know, that's the real lesson to learn is that there is a learning curve with get ups and that's why we have you have to bring your people along and understand them. But when you have that declarative nature of your application. It makes running an application much easier right you tell the system hey, this needs to run it always needs six pods up. Right. That's it. You no longer have to have someone who's operating an operator who knows if something's going wrong in the middle of the night, they've got to figure out okay who pressed what button to do the wrong thing so that this isn't working anymore. The system has a checked in state that says no we need six parts, how's running the system will handle that. And the example I gave of turning up a new, a new region is is very is is really really you know how to do it today. So we can enumerate say yeah we know how to do that it's going to it's going to take us three months but we can we can get the clusters turned up the right servers turned up the right things installed, or you move to a complete get ups way and and and the deployment is all automatic from the clusters themselves, every component on top of the clusters including your application so there's a learning curve, but it's when you when you know you you learn this new way of doing things and you realize no it's not more complicated it's just different. Yeah. Yeah. Yeah, then go ahead. I was going to say do you want to take the next one out this this is not an advertisement. This is a real real question. What other advantages are and tool sets are available with the D2 IQ Kubernetes platform other than the ones that were shown on that slide. We had that that slide with all those votes what else. What else does D2 IQ bring thank you for the question. What else is D2 IQ bring so D2 IQ, the D2 IQ Kubernetes platform to be specific. Again, under the covers the technology that we use in order to like help out our customers with this decorative way of approaching both operations and application deployments is, you know, through the use of you know cluster API and in a flux CD right so if it's getting into the one level lower the way we orchestrate or obfuscate the underlying infrastructure is through the use of in a cluster API right so if it's EKS or it's another managed in a community service. It works consistently and you have that similar experience you know either through the CLI or through the UI to be able to orchestrate any of the underlying in a cloud infrastructure is right. So how we deploy what we call those you know applications or you know what we the applications that you need in order to be platform ready is through you know the use of get ups right through the use of flux CD where you know we are able to give you an opinionated stack and I think this will answer the other question. You know that just came in as well right which is a list of technologies that work with DKP and you know, and whatnot right. So, we have DKP has gotten an opinionated set of like applications that make you production ready. But then, again, it goes back to the value proposition that we just discussed with communities which is the whole plugability aspect right you can choose to like you know turn off like you know one of those applications and you know just deploy your own right and we do have a list of you know vendors that we've worked with to like you know, get those applications supported and you know certified. But we have a pretty rich in a partner ecosystem as well that we work with you know to ensure that you know their solutions in a work on, you know the communities platform that D2IQ bills right and again at the end of the day it's open source communities. So if there are instructions, perhaps on how do you deploy let's say Lumio here for network segmentation on communities you know there's a very high probability is just going to work out of the box right. So, we can definitely discuss a little bit more. Yeah. So thank you very much for the questions. I really appreciate it. Oh, question last one last one came in from Luis Felipe. What what option is better open stack on top of Kubernetes or Kubernetes on top of open stack. That is that is interesting I don't know if I have an opinion on that right when I've worked with open stack in the past you know I've always looked at open stack as an infrastructure is a service solution, right. And the container orchestration piece that sits on top of the infrastructure is a service solution I know that they're there are a couple of solutions that look at it a little bit inversely as well. But I don't know if I have an opinion on that that is something that we have to you know look into my immediate reaction is I'm just aware of open stack as just being an infrastructure as a service provider that you know Kubernetes could potentially you know sit on top of and you know orchestrate you know containers for right but you know there needs to be some research that we need to do to figure out the pros and cons of the other topology. I'm certainly hearing customers again talking about Kubernetes running on top of open stack because they look for what goes between Kubernetes and the bare metal are you going to install something there or not. And if you're in open stack certainly is a possibility. So thank you for the question. And with that, I'd like to thank everyone for their time today should fake thank you very much for walking me through this and help me out, help me learn a little bit. And with that, why don't we turn this back over to can this at the Linux Foundation. Thank you so much if you can Dan for your time today and thank you everyone for joining us. As a reminder, this recording will be on the Linux Foundation's YouTube page later today. We hope you join us for future webinars have a wonderful day.