Well, I'm looking forward to the conversation we're having today. You know, I used to work on some kind of similar software, or at least I was reading through the docs for the Tanzu Mission Control, and I came upon the part that had a discussion of RBAC. And I was like, ah, yes, I remember back when I was a programmer having to implement RBAC for the management software I was working on. And it's always thrilling to meet my friend RBAC and give a distinction of, like, you know, the groups that people belong in, the users, all of the thinking that goes into setting up the right permissioning for stuff. And that's perhaps, well, I'm sure there's several thousand people who are, you know, developers and work in this space, but it's always nice to, like, you know, get excited about permissioning systems. And you're setting those up as a developer? Yeah, well, I used to work on, like, you know, way, way back when, like, some systems management stuff. And, you know, in, in, like, you know, one of the early versions of our software, of course, we had to implement not just hard-coded security groups, but actual, like, you know, RBAC stuff to integrate with the Active Directory or whatever wacky system you might have. Right. Which, you know, it's inexplicable that it's some sort of memory lane to go down. But anyways, why don't you introduce yourself? Well, thanks for that trip down memory lane. My name is Corey Dinkins. I am a technical marketing architect for VMware Tanzu. And I guess to translate that into real-world terms, that just means, you know, I show you how to do cool things with the products. So instead of showing you how to build the skis, you know, I'm showing you how I can do cool jumps with it and, you know, flips and all that good stuff, right? So all the fun things. That's right. And I suppose if we were to continue the metaphor out, you can kind of hang out at the bottom of the hill in the club, the lounge, the lodge. With the cool guys, right?
2:01Sure. And, you know, whoever is recovering from the ski patrol, helping them out, you know, to figure out what's going on there. I don't know how far we can carry this. I'm not actually a big skier. That's about it, though. You hit the end of it there, so. Well, you know, there's a new version of Tanzu Mission Control out, so I thought, you know, it'd be a good time to kind of just check in and see what's going on there. And, I mean, first of all, like, what is Tanzu Mission Control? Like, give us an overview of, like, the features that it has, what it does, like, what it's trying to solve, basically. Sure. And I'll try and give you the summarized version because I could really be here probably for the rest of the podcast if I want to just listing out everything it does. So, sure. I think we'll hit some of the more high-level points that I care about. You know, just a quick side, you know, sidebars to my background. You know, prior to this marketing role, I was a systems admin slash platform engineer slash, you know, everything else under the sun when it came to networks and managing the help desk for the companies that I worked at. So, my framing for a lot of this is kind of like, how would I have used this tool in my past jobs to really, like, get my job done? So, that's kind of how I approach this kind of, you know, tool when I explain it. So, I think to get into what Mission Control actually does, the whole point of it is to help users manage their Kubernetes clusters. Because right now, it's a pretty big challenge for a lot of people. Most of it is still done with command line. Most of it is still done with a lot of YAML files. And for people that are coming from, like, the vSphere type background, and maybe there are Windows admins and aren't quite used to as much command line. And I know there's a lot of people using PowerShell out there, so I don't want to forget that community.
4:03But there's still a lot of people that aren't into command line, right? So, beyond that, there's still a lot of people that aren't quite sure of, they're kind of intimidated by Kubernetes, right? Because they keep hearing it's this new big thing, that it's everywhere, and it, you know, it does all this stuff for them. They just don't quite get, you know, what it's doing or how it's getting there. And so, we won't dive into all that. But, you know, I guess the way I look at it is they're just really small VMs, right? And there's just a bunch of them. So, right. The point of Tanzu Mission Control, again, is to really help you manage these clusters in such a way that you don't really need to go into command line and helps you structure things in such a way that you can kind of use the set it and forget it type model. You know, I like to think of Active Directory as a good, like, mental model for how Mission Control structures all of its internal resources. So, the way that you primarily group objects is that you have cluster groups. And I think the name is pretty obvious, right? Like, you can group up clusters and you can do things with those. And for a lot of companies, what the cluster group view is for is more like the platform ops slash platform engineering type role. So, you know, really focused on the users that are going to manage the infrastructure, you know, define policies for those. So, things like security policies. Can we have pods running as root? You know, where do we want our images to come from? Should it only be a trusted registry? You know, do we want Bitcoin miners coming from the Docker registry? Probably not. You know, so, doing little things like that. Even as simple as, this is a commonly overlooked problem, but just disallowing the latest tag. Like, a lot of people don't realize how many issues that's caused
6:03in production environments where, you know, admin doesn't check, they just leave the latest tag on a deployment and a big update breaks everything, right? So, I've seen it. I don't know if you have, but it's not uncommon. So, oh. Right, because you have this, like, you have this unplanned, potentially unexpected, just, like, new thing enters to grossly simplify it. And, you know, you would like the chance to verify that it works with what you have instead of it just automatically deploying. Yeah, that's the ideal. Exactly. That's the ideal scenario, right? Test it before you deploy it. Make sure things don't break. I mean, pretty standard stuff. So, you can apply all those to your cluster groups. You can even have specific policies that are called mutation policies, where they kind of are one step above the standard security policy that just denies workloads and says, nah, you know, you don't have the right properties. You know, this is denied. This will actually take the workload in and it will configure the settings that you've defined and inject those into the workload YAML. So, a good example of that is developers, a lot of times, don't necessarily care about, like, run as users, security context, constructs, things like that. They just want to build their app, send it on, and get results, right, and test the app, essentially. So, security teams or operations teams can define, you know, a default run as user, default, you know, do I want to allow pods to run as root? You can configure all these settings, and when they submit the workload YAML, if those are not present, they will automatically be added to that and present when the workload arrives. So, you know, kind of removing the burden at lower levels to have to fill out these YAML manifests with, like,
8:03oh, you know, we got Joe Kubernetes who accidentally added a tab instead of, you know, four spaces again and broke everything, you know, like, we don't have to worry about little issues like that, and they can, you know, developers can focus on just doing development stuff, right, like, kind of getting out of the security game if they don't need to be. So, those are some of the things that you can do, and there's a few other different policy types that you can apply, but what I wanted to go over next is the other construct that you can also use to kind of group your different clusters together, and the construct's called workspaces, and it gives you the ability to group different namespaces together across different clusters. So, for example, if you have an application, we'll just say application A, and that's your line of business app, you can have an application A namespace across a cluster in your vSphere environment on-prem, you can have it running in, you know, Amazon, EKS, you can have it in Azure, et cetera, and this workspace will group together all those clusters, and you can apply an access policy to that workspace so a developer can say, or not a developer, but a developer would then get access to all of the namespaces within that workgroup across different clusters, right? And that essentially allows you a way to authenticate one time against an endpoint, and you're able to then interact with all the different clusters in your environment that you have access to. So you no longer have to pull down a bunch of kube configs and, you know, switch context a whole bunch. So it's a pretty and I guess to clarify, right, this is more of an application operator slash like developer type view where you would generally grant them access
10:03to these namespaces so they can deploy things, right, or do things. Troubleshoot, check logs, et cetera. So just those two groupings alone offer you quite a bit of flexibility as far as like how you can structure your environment or even how you can mirror, you know, Tanzu Mission Control to meet your existing environmental settings, right, and kind of how your existing model, you know, your, I guess, resource model works. Yeah. Yeah, so let me let me try to rephrase back to you a lot of what you've been saying there because I think I think there's something interesting I hadn't really thought of before and that is well, so first of all, you got, you got, you're running your Kubernetes stuff here and you've got some developers who are going to be running their applications in it and like at a minimum what's required there and not required for like hygienic good practices but just to achieve that goal is, you know, the developers need to have like basically have made a bunch of container images of what their application is and then they're going to have a lot of configuration, a lot of YAML that basically says, yeah, exactly, that basically says, here's how you take these containers and the developer is talking to Jane Kubernetes, I guess this is Joe Kubernetes talking to Jane or Joe, you know, whoever. sure, jkubernetes and basically the developer says, all right, in all of this YAML, this is describing how I want you to take these containers and deploy them into the cluster, you know, the terminology gets a little loosey here, but deploy them into the overall runtime environment and here's how they'll communicate with each other, here's the permissions that they have, here's how they connect databases, so forth and so on, right? Exactly. So, everyone who has investigated Kubernetes for, you know, three to five minutes knows that there's
12:03a lot of YAML and no one likes that, right? It's a lot, right? And, you know, it is like, it is a, it is almost an interesting peculiarity, I think, of Kubernetes that this YAML is both the configuration and to some extent like the API for how to interact with it, which I always find bizarre that you wrap those things together, but whatever, no one, no one asked me to be involved and I did not volunteer either. So, and so that's, I think, where a lot of the complexity comes from. So, in a, in even, you don't have to be that large of an organization, right? But in kind of any size organization where you're trying to not have one team do everything, and especially in much larger organizations, you want to make sure that people are not only following best practices, but also not like creating problems through just not knowing what they're doing. Single point of failures, Michael. That's exactly, not a good thing. And so, even though this, you've got this peculiar, at least to me, like, YAML thing, what it affords you is this opportunity that before, not before, but when a developer goes to jkubernetes and says, here's my application made up of images and stuff, and here's the configuration in the YAML, you can kind of give that over into Tansu mission control land, whatever the kind of port is there. And what's going to happen is that the people who are running kubernetes and trying to defeat the single point of failure, so to speak, essentially they're given the chance, and not manually, but like, this is all what ends up happening is they've established some policy as you were saying about like, you know, what kind of security
14:03rights are done, how things are configured, so forth and so on. And because of that nature of YAML, basically you can just go in and like not only add to what's in the YAML, but you can kind of like modify it and mess around with it and make sure that how you want things to be configured, the way you want applications to run in Kubernetes are like enforced, right? And that's kind of like the nice part, that is one of the nice parts about the API as plain text file nature of Kubernetes, is you're given all these points as people who are running Kubernetes to like make sure it's running well and in the policy that you've set up. Yep, and kind of where that comes into play, right, is when you're looking at doing kind of securing an environment, right, lowering blast radius for breaches, and if you're designing an application, it's generally your best practice to have, you know, you have different run run as users for your web app as you do for your database app, right? So being able to architect an application in such a way where you're saying, you know, all of our web applications, we ensure always get this specific run as user, they always get this, you know, FS group, you're really able to start to do things like, wait a second, why is a web username trying to access app, you know, like database data? Like we have a serious problem here, right? Like little things like that you can use as very big indicators of, you know, greater issues throughout the org. So, right. It's kind of an important point to be able to, I guess, understand what you are expecting and what you know something should be, right? So that you can track what happens with it as a result. Yeah, yeah. No, that's an interesting point too, that you're given the chance to like inspect what the configuration is, essentially. And, and particularly as you're going over, like, you know, in the second
16:03part of you're saying, right? Like this ability to modify, change, or, or you just set the configuration means that you have, as long as the developers haven't done some wacky thing like hard code things or hide what they're doing from you, like you essentially have the, the ability to have full control over all of your permissioning and the security things you would care about. Because you can go in there and set things and, and, and make them work well, which, all right. So that makes sense if I'm not talking crazy. No. And I think the other point here is, right, is you can do all this through the GUI, right? This doesn't have to be with YAML, doesn't have to be with CLI. You can, those are all options, but, you know, again, this is kind of like AD for clusters where you can go in, define your policy, set it one time, and, and kind of to your point about, like, you know, I guess you being able to utilize the different Kubernetes constructs and existing stuff there to work for you. You don't even have to scope your policies to individual cluster groups or workspaces. You can just use, like, labels if you would like to. So, you can exclude stuff based on label, you can include it based on label. So, if you really wanted to, you could set things just at one organization level and just have them apply based on label types, right? Right, right. And, you know, you're highlighting a very important thing again at like, when you start managing a lot of Kubernetes or a lot of anything, which is three, like, even more than three. I talked to someone at, you know, Explore last year and, you know, they kind of were like, what is this product? What does it do? You know, and I explained it to them and they're like, wow, you know, it takes me anywhere between, you know, five to eight hours to set up a new cluster. And, you know, we only have five of them. Right, so,
18:03you know, multiply that. As they grow, you can imagine this person's like, oh my goodness, like, I have, I've got a road in front of me, right, that I have to walk down and it's going to be tedious, right? right. And as we were saying, that's where the concept of being able to group together clusters and, you know, also like, you know, treat, I mean, having the nesting eggs go up so that you can deal with things as an administrator and aggregate and groups and name them and then also like the flexibility of adding tags or labels. So like, I mean, anyone who's worked with something where you can tag things, it's just another angle to slice things up basically. It's a necessity. And then, yeah, in this case, apply policy to it. Yeah, okay, so we've got that policy enforcement going on, like, what else, and again, the fact that it's in a UI, like, what are some other components of Tanzu mission control? I think, for me, the two biggest, I'd say, quote-unquote, well, three, so we hit one, which is RBAC and policy, that for me is huge. I think the second one is being able to utilize Flux continuous delivery under the hood. So we have integrations with Flux where you can configure this for individual clusters if you would like, or cluster groups. And what that will allow you to do is, and I guess we'll pause briefly for those that don't know what Flux is. So it's a continuous delivery tool that you connect to a Git repo. It inspects the repo and pulls down all the YAML objects that you have there, and it will do, I want to say do things with those YAML on the cluster. That's a good technical phrase. Yeah, because it can be install a package, it can be create a config map, right? It can be a number of different things, and as long as it's a native Kubernetes object, it can be ingested.
20:04the other part that powers this engine is the customized engine, that's with a K. So essentially Flux will synchronize these YAML files, and then it will reconcile them against what is running in the cluster. So if you make a change to one of those YAML files, that change will get reflected in the cluster after a certain synchronization period of time. what you can really do with this, if you expand this to your operations and how you can actually use this in the real world, a pretty common example that I would look at using this for is I want my logging agent on every cluster that I deploy. So whether it's prod, dev, test, whatever, I need this logging agent on it. Now, the level of logging on that might be different per level, so I might only set it debug and the dev environment and something else in the other environments, but you can essentially define applications, settings, or sets of configurations that get applied to groups of clusters. So any cluster you move into that group or any new cluster that's created in that group will then assume or receive all these new settings or packages that you've defined for it. So you can define ingress controllers. There's a number of different things you could do. Another common example I would use is probably if you want to have ingress controllers that reside in multiple different regions, so we'll just say you have one in the US, you have one in Europe, et cetera, you can configure that group in such a way that any new cluster added to it automatically gets ingress. So you can turn up new regions much quicker than you would have been able to if you have to manually apply all
22:04these settings and test them and configure them, et cetera. So there's quite a bit of power in being able to just define these different groups and apply these different sets of configs or applications to them based on those groupings. to add to what you're saying there, the word policy often seems like overloaded rules. Here's rules and constraints, but it can also mean defaults, so to speak. As you're saying, whenever a new cluster comes up, here's how we want ingress set up. That's the policy that we have, which is just the defaults, how we want things to run. I think also what you're getting to there with Flux is if you like this continuous delivery idea and this idea of GitOps where you basically say this is what and of course you put it in Git or whatever or your image repository, but it's at the end of a pipeline and now here's the state that I want production to be in. Essentially that's what you can hook that up to everything and have it just magically be deployed into Kubernetes. I guess it's not really magic. It's not. That's the other thing that I think is interesting about Kubernetes is built into it is this idea of you don't have to turn it off and turn it back on to deploy something new. it's more I'm sure you can tune this however soft or hard you want it to be but it's like as things get updated add a new agent to it or you can force the config to go out but in theory it should enable you to do rolling upgrades more or less effectively which is great. It just means that
24:04you have better availability and uptime if your applications are written appropriately to know here's the new version and here's the old version I can cope as the upgrade pans out there. It's good to pull all that together into one thing instead of having to cobble it together yourself. What else since we're doing the Corey's personal favorites That's one of them for sure. To your point to achieve what we're talking about you have to go to the CNCF website look at their landscape I don't know if you've looked at it but it's pretty big there's a lot of stuff on it so you have to go and pick and choose which of those components you want you have to manually configure them and deploy them so what we're offering is a pretty significant time saver over what you would be looking at of just manually piecing all these components together. Yeah you know the word I've started to use in my head is things are integrated right you have to integrate all this stuff already because there's so many you know there's almost too many choices you could also look at it as like oh there's so many options paralysis analysis whatever type of functionality I want you know it's available it's the classic I forget who wrote this up but in the 90s there was the analysis of like American consumer culture that like there's too much cereal and you just get overwhelmed by the choice but but you know I think I think there's a tremendous amount of value especially people who are just operating platforms of infrastructure of just like it'd be cool if this stuff was just integrated together instead of having to do it and I think even like even like having someone else make that decision I always
26:04envision it saves you a lot of annoying meetings where you debate what you should do it does I mean it really does because there we've seen year over year the state of Kubernetes report that we publish like DIY tooling is on the way out people are over it they're over having the single point of failure of jKubernetes is you know they manage the tooling and they're the only one that seems to know how all this stuff works right and like we can't companies can't have that right like that's just not a way of operating efficiently so yeah I think it's an important thing to really get under control and I'd say a point that a lot of people kind of miss too is when it comes to like training up teams and like you know junior members of teams and help desk teams to like support and like be able to help like spread the load right across teams this this GUI methodology is a way that users can actually do quite a bit of Kubernetes stuff without ever touching a CLI right if they really wanted to you can have a runbook that walks them through adding a flux repository that adds your debug tracing tooling right they don't have to know Kubernetes really they just have to know how to input a couple directories and you know a couple of values for a git repo but they can then become part of your troubleshooting process and team process of hey before we escalate this all the way up to you know engineering or you know these higher levels we can do these things prior to doing all of that right and and get to a resolution hopefully quicker so so so tell me you know I want to get to the the newest version like the of of Tanzu mission control what's fun about that but tell tell me the other things that just we haven't gone over yet just kind of give us
28:04a little preview for everyone who wants to dig into it more what are the other major areas I'd say other major areas to look at are so we have support for the Bitnami helm app catalog so the public catalog that you see at Bitnami.com is fully available through and within the Tanzu mission control GUI so you can deploy helm charts to any cluster that's in your environment right that's pretty simple and pretty powerful I think because you can do it through the GUI you do have to configure some YAML depending on the app or the package but you know I think that's another huge step forward and you can also deploy those helm charts to a cluster group if you would like so the next iteration is here so we'll hopefully be allowing you to do that with the Bitnami public app repo but that's coming soon so I'd say that's another good area to look out for and then the data protection we've got a lot of great features coming out for that and a lot of new functionality so that's a space that I would keep my eye on because we're going to be having some pretty cool announcements soon and then so what are the types of Kubernetes that are supported so as far as lifecycle management goes the Tanzu Kubernetes distribution is fully supported and Amazon EKS any other CNCF conformant distro supports all the other functionality or rather mission control supports all the other functionality within it except for lifecycle management so if it's a CNCF conformant cluster you can do all the things except lifecycle manage if it's Tanzu Kubernetes or Amazon EKS you can lifecycle manage and do all the other stuff is that because lifecycle
30:04management is not part of Kubernetes and so it's unique to each of the different services or distros so extra work is needed for that it is yeah and VMware has tried to help smooth some of that out by contributing the cluster API and cluster class I guess we'll just say code to the Kubernetes official code base and so that was one way that we're trying to essentially address that disparity between cluster types so yeah hopefully that will help smooth some of that out but well we'll find out in the future where we all shall live so okay all right so tell us tell us about the new version yeah so I guess one of the most important things that I want to talk about is the new version that's coming out the existing version is completely SaaS based and it's hosted in Amazon AWS and for some of our customers and companies that either are a competitor to Amazon or they have data sovereignty laws that are local to that country there's a whole number of reasons why many companies just said sorry we would really like the package version rather we need the package version so once that's available let us know and we'll take a look at the product right so we've had a lot of companies that just we couldn't really service as customers because of how the product is built and and operated essentially so as a SaaS as a SaaS software yeah yeah and so that has just changed and we're looking at offering a package version we're not looking at but we'll be offering the package version of the software and you'll be able to install it in the environment of your choice so whether that's air-gapped whether that's in your private data center basically outside of Amazon if you'd like to inside of Amazon you know it's really going to be up to you but the point is download it
32:04deploy it where you want it manage Kubernetes with it right yeah and like you're saying it is well especially if you've I don't know to put it in a super corny way if you've got your head up in the clouds like it's often astonishing how many people are just like there's just a brick wall of running something in the cloud and you know often for good reasons sometimes for evolving reasons but it's essentially like there's you know why limit the functionality but yeah I mean I've already talked with several people who are very thrilled about the option to be able to do things on premises or under their own control and I think you know the whole you know the point of it being an easier way to manage things rather than having to hand craft stuff right like that just that means having it available to as wide amount of people as possible is great because everyone wants things to be easier they do and that was one of the challenges again you know some companies just their laws just say they can't run stuff where our stuff is hosted I mean I don't know if what the laws look like where you're at Michael but I'm sure they've got their own data sovereignty laws you know for their citizens and companies that operate across these you know national borders or international borders it's very difficult for them to try and solve this data locality issue and in many cases it was very expensive so I think you know one of the other components of this self-managed release is that this is going to become part of the sovereign cloud providers offering that we have here at VMware so a good example is companies that you know operate out of EMEA right most of them if they're operating in multiple countries they need to have data data services
34:04and you know data retention local to those countries and in many cases what they're looking to are these sovereign cloud providers of those different countries so soon these cloud providers will be able to say hey we now have a version of Tanzu mission control that we can offer you we guarantee it's local you know data localities here data sovereignty is met and you know you're able to meet these regulations that you're required to abide by I think as we saw with Facebook they got dinged what one billion dollars or something for for not following those exact laws so it's really not something that companies can't ignore right they just can't afford to can't afford to just ignore it and do nothing right yeah yeah no I mean the way I always think about it right is like I I don't know I think in the tech world and the cloud world right like we have a very let's say American centric view and so like it's easy just to be like ah it's the public cloud whatever but you know it's it's always a good thought exercise if it see if if sovereign cloud concepts seem weird like one to like rethink it in your mind of like you would like to control the jurisdiction that you you operated right and because that's how jurisdictions in the law works like like you have this agreed upon set of laws and regulations that you're cool operating under versus not and then and then the other thing is like well you know there's probably plenty of like uh American companies that really like it that their stuff runs in America they just don't have to think about it right because it's already there so it's like you know the whole notion of like sovereign cloud stuff is perfectly understandable because like you want stuff under your jurisdiction you know the one that you've agreed to operate in and of course as you point out like there's also legal requirements but that's that's just the
36:04same side of the same thing so it's nice to have have that flexibility well great make sure to register for VMworld goodness gracious VMware Explorer it's coming up in August I'll be out there in the booth so if anyone wants to stop by and talk about infrastructure and clusters and Tanzu mission control come and find and get some demos are you going to be at the Barcelona one I'm not sure if I'll be there yet but definitely we'll be in Vegas so we'll be doing demos and all the things demos in the desert that's what we need to think of it yeah yeah well and so how could people just like look up and kind of like see how Tanzu mission control works so you can go to the VMware website tanzu.vmware.com slash mission dash control and there's information on there for how you can access the hands-on labs that we have there's other content like blogs that you can see and then if you're looking for just technical information on how to use Tanzu mission control I've written a number of different blogs and articles on our Tanzu tech zone website so things like how to build API commands for it you know how to do automation with flux you can find all that there so check it out perfect well great well that that was fun thanks for going over that and putting up with some slight education of me happy to yeah yeah that was good stuff well as always you've either watched the video of this or listened to it in podcast form and if you want to subscribe to the podcast or find I'll put links to many of the things we mentioned you can go to tanzutalk.com and look that up put it in your podcast subscriber I don't even know what they're called nowadays and listen to it in your ears while you're doing whatever you're interested
38:04in and with that we'll see everyone next time bye bye thank you