 TheCube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to Valencia, Spain, a KubeCon CloudNativeCon Europe 2022. I'm your host, Keith Townsend, and we're continuing the conversation with community, with startups, with people building CloudNative, a KubeAlarm joined by a CTO, and as the CTO advisor, I really appreciate talking to CTOs. Kapil Thongvalu, don't forgive me if I'm the name, that's a tough one, I'm getting warmed up to the Cube seat, but don't worry, when we get to the technical parts, it's going to be fun. And then a KubeAlarm, Umair Khan, director of marketing. Kapil, you're the CTO, so we'll start out with you. What's the problem statement? What are you guys doing? So, we're building on top of an open source project, CloudCastodian, that is in CNCF, and that I built when I was at Capital One, and just as they were going, they're taking those first few steps, it's a large regulated enterprise into the cloud. And the challenge that I saw was, how do we enable developers to pick whatever tools and technologies they want, if they want to use Terraform or CloudFormation or Ansible, I mean, the cloud gives us APIs. And we want to be able to enable people to use those APIs through innovative ways, but at the same time, we want to make sure that the, regardless of what choices those developers make, that the organization is being well managed, that all those resources, all that infrastructure is complying to the organization's policies. And what we saw at the time was that, what we were getting impediments around our velocity into the cloud, because we had to cover off on all of the compliance and regulation aspects, and we were doing that, not as one-offs. And so, taking a step back, I realized that what we really needed was a way to go faster on the compliance side, and clock study was born out of that effort at the side of desk that we took through enterprise-wide, and it was really about accelerating the velocity around compliance, but doing it in the same way that we do application and infrastructure as code. So, doing policy as code in a very simple, readable YAML DSL, because, you know, any time we write code, more people are going to read that code than are going to need to be able to write it. And so, being able to make it really easy to understand from both the developers that are in the environment, from the compliance folks, or auditors, or security folks that might want to review it, it was super important. And then, instead of being, at the time we saw lots of verandah products, and they were all just big walls of red in somebody's corner office. And getting that to actually back and information back in the hands of developers so that they can fix things was problematic. So, being able to do real-time remediation and real-time collaboration and communication back to developers. Hey, you put a database on the internet, it's okay, we fixed it for you, and here's the corporate policy on how to do it better in the future. So, this is an area of focus of mine that people, I think, don't get right a lot. The technology, hard enough by itself. The transformation cloud is not just about adopting new technologies, but adopting new processes. The data and information's there automatically, but when I go to an auditor or a compliance and say, hey, we've changed the process for how do we do change control for our software stack, I get a blank stare. It's, what do you mean? We've been doing it this way for the past 15, 20 years. That's resistance. It's a pain point and projects fail due to this issue. So, talk to me about that initial customer engagement. What's that conversation like? So, we start off by deploying our platform on top of Bacchus Studio and it stars our customers and we give them a view of all the things that are in their cloud, what is their baseline, so to speak. But I think it's really important, like I think you bring up a good point, like communication, the larger challenge for enterprises in the cloud, and especially with regards to clients, is understanding that it is not a steady state. It's always, there's always something new in the backlog. And so, being able, and one of the challenges for larger orgs is just being able to communicate out what that is. I remember changing a tag policy and spending the next two years explaining it to people what the actual tag policy was. And so, being able to actually inform them via email, via Slack, via any communication mechanism as they're doing things, it is so powerful to be able to help the organization grow together and move and get in alignment about what the new things are. And then additionally, from a perspective of tooling that is built for the real world, like being able to, as those new policies come into play, being able to say, okay, we're going to segment into stopping the bleeding on the net new and being able to then take action on what's already deployed that now needs to become into compliance. It's really important. But coming back to your question on customer engagements. So we'll go in and we'll deploy a second platform for them. We'll basically show them all the things that are there already in Extant. We provide a real-time SQL interface that customers can use that is an asset inventory of all their cloud assets. And then we provide policy packs that sort of cover off on compliance, security, cost optimizations and opportunities for them. And then we help them through get ops around those policies, help deploy remediation activities and capabilities for their environment. So walk me through some of the detail of the process and where the software helps and where people need to step in. I'm making, I'm talking to my security auditor and he's saying, you know what, Keith? I understand that the AW that the VM talking to, the application VM talking to the Oracle database. There is a firewall rule that says that that can happen. Show me that rule in Cloud Custodian and you're trying to explain, well, there's no longer a firewall. There's a service and the service is talking to that and it is here in Cloud Custodian and where does Stacklet help come to either help with the conversation or where do I inject more of my experience and my ability to negotiate with the auditor? So, Stacklet, from the audit perspective, and if we take a step back, we talk about governance as code and the four pillars around compliance, security, cost optimization, operations that we help organizations do. Then we take a step back, what is Cloud Custodian? Cloud Custodian is really a cloud orchestrator, a resource orchestrator. What Stacklet provides on top of that is UI, UX, policy packs, at scale execution across thousands of accounts, but in the context of an auditor, what we're really providing is, here's the policy that we're enforcing and here's the evidence, the attestation over time and here's the resource database with history that shows how we got here, where we compliant last year to this policy that we just wrote today. So, shifting the conversation, you just mentioned operations, one of the larger conversations that I have with CIOs and CTOs is, where do I put my people? Like, this is a really tough challenge. When you look at moving to something like an SRE model or, let's see, even focus on the SRE. Like, where does the SRE sit in an organization? How does Stacklet, at all, help me make those types of strategic decisions? So, I'm talking about governance overall. So, I think, in terms of Persona, if you look at, there's a cloud engineer, then SRE, I think that what, at this core, Stacklet and cloud custodian does, is a centralized engine, right? So, your cost policies, your compliance policies, your security policies are not in a silo anymore. It's one tool, it's one repository that everyone can collaborate on as well and even engineering, a lot of engineering teams run custodian and adopt custodian as well. So, in terms of Persona, Stacklet really helps bring it together. All teams have the same simple YAML DSL file that they can write their policies, share their policies and communicate and collaborate better as well. Can you feel anything on that? Yeah, so, I mean, cloud transformation for an enterprise is a deeper topic. Like, I think there's a lot of good breast practices establishing a cloud center of excellence. I think investing in training for people, getting certifications so everyone can speak the same language when it comes to cloud is a key aspect. When it comes to the operations aspect, I very much believe that you should have, you know, try to devolve and get the developers writing some of the DevOps and so having SREs around for the actual application teams is valuable. But you still have a core cloud infrastructure engineering group that's doing potentially any of your core networking, any of your, you know, IAM authentication aspects. And so, what we found is that, you know, Stacklet and Cloud Custody and get, primarily get deployed by one of three groups. You know, you've got the CIO buyer within that cloud infrastructure engineering team. And what we found is that group is because they're working with the application teams in a read-write way, they're very much more used to doing and open to doing remediation in real time. And so, and then we also have the CISO teams that want to get to a secure compliance state, be able to do audit and validate that all the environments are, you know, secure, frankly. And then we get to the CFO groups. And so, and this sometimes is part of the Cloud Center of Excellence. And so it has to be this cross-team collaboration that really focus on the, that cost optimization, finding the over-provision underutilized things, establishing workloads for dev environments to turn them off at night. And of course, respective of time zones because we're all global these days. And so, those are sort of the three groups that we see that sort of really want to engage with us because we can provide value for them to help them accelerate their business goals. So, that's an expansive view. Cost, compliance, security, operations, that's a lot. I'm thinking about all the tools, all the information that feeds into that. Where does Cloud Custodian start and stop? Like, am I putting Cloud Custodian agents on servers or pods? Like, how am I interacting with this? So, the core Cloud Custodian is just a lot. It's stateless. It's designed to be operationally simple. And so, you can run it in Kubernetes, in Jenkins. We've seen people use GitLab. We've seen people run just as a query interactive tool just from investigations perspective on their laptop. But, when you write a policy, a policy is really consists of a couple of core elements. You identify a resource you want to target, say an S3 bucket or a Google Cloud VM, and then you say, you establish a set of filters. I want to look for all the EC2 instances that are on public subnets with an IAM role attached that has the ability to create another IAM user. And so, you filter down, you ask the arbitrary questions to filter to the interesting set of things you want, and then you take a set of actions on them. So, you might take an action like, stop an EC2 instance, and you might use it as an incident response. You might use it for off hours in that type of policy. So, you get this library of filters and actions that you can combine to form, you know, millions of different types of policies. Now, we also have this notion of an execution mode. So, you might say, let's operate in real time whenever someone launches an instance, whenever there's an API call. We want to introspect what that API call is doing. You make sure that it's complying to policy. Now, when you do that, Kistodi will, when you run it with the CLI, Kistodi will actually provision a Lambda function and hook up the event sources to it. And sorry, Lambda, really the serverless, we bind to the serverless native capabilities of the underlying cloud provider. The Google Cloud function, as are serverless functions, and AWS Lambda and AWS. And so, now that policy is effectively hermetically sealed running in the serverless runtime of that cloud and responding to API calls in real time. All with structured outputs and logs and metrics to the native cloud provider capabilities around those. And that really ensures that, you know, it's effectively becomes operation free from the perspective of the user of having to maintain infrastructure for it. So, let's talk about. Agentless and API based. Let's talk about like the non-developer use case, specifically finance. The, you have the ability to deploy SAP in a EC2 instance, but it's very expensive. Do it only when you absolutely need to do it, but you have the rights to do it. And I want to run a check to see if anyone's doing it. Like, this isn't a colder developer. What is their experience? So, primarily we focus on the infrastructure. So, load balancers, VMs, you know, encryption address on disks. When we get into the application workloads running on those instances, we don't spend that, that's on our target focus area. We can do it, and it really depends on the underlying cloud provider's capabilities. So, in Amazon there's a system called Systems Manager, and it's basically running an agent on the box. We're not running the agent, but we can communicate with that agent. We can introspect the inventory that's running on that box. We can send commands to that box through those serverless functions and through those policies. And so, we see it commonly used for like, incident response in a security perspective where you might want to take a memory snapshot of the instance before putting it into a forensic. Yeah, adding to that, like these days we're seeing the emerging personas of a FinOps engineer or a FinOps director as well, because cost in cloud is totally different. So, what custodian and stackler allows to do is again, using the simple policy files. Even if they have a non-developer background, they can understand this DSL. They can create policies. They can better target developers, better get them to take actions on policy as well. If they're overspending in the cloud or underspending in the cloud, especially with stackler, they get a lot of out-of-the-box dashboards and policy packs too. So, they can really understand how the cost has been consumed. They can have the developers take actions because a lot of the FinOps finance people complain. Like, my developers does not understand it, right? How do we get them to take action and make sure we're not overspending, right? So, with custodian policies, they're able to send them educational messages on Slack or open a Jira ticket and really enforce them to take action as well and start saving cost. Like, if you met a cloud custodian as, you know, cleaning staff for your cloud environment, like it's, you know, if you go to a typical, you know, cloud account, you're going to see chairs that are 10 feet tall sitting at the table. You're just, because it's been over-provisioned and obviously no one can use it. You're going to find, like, the trash is overflowing because no one set up a log retention policy on the log group or set up S3 lifecycle rules on their buckets. And so, you just have this sort of this explosion of things that people now, you know, beyond application functioning, like beyond, you know, getting to, you know, high performance, DR-capable SLAs around your application model, you don't have to worry about the lifecycle of all those resources and helping people manage that lifecycle and making sure that they're using the, just the resources and consumption that they need because we're all utilization based in the cloud. And so, getting that to be more in line with what the application actually needs is really where we can help organizations in the CFO, cost context. So, Emile, you got 10 seconds to tell me why you brought me a comic book. We created this comic book to explain the concept of governance as code in a simplified fashion. I know Keith, you like comic books, I believe. So it's a simple way of describing what we do, why it's important for FinOps, for SecOps teams and it talks about custodian and stacklet as well. Well, I'm more of an Iron Man type of guy or Batman. Cloud governance or governance is your, cloud native governance is a very tough problem. I can't under-emphasize how many projects get stalled or fail from a perception perspective even if you're technically delivered what you've asked to deliver. That's where a lot of these conversations are going. We're going to talk to a bunch of startups that are solving these tough problems here from Valencia, Spain. I'm Keith Townsend and you're watching The Cube, the leader in high-tech coverage.