>>The cube presents, Coon and cloud native con Europe, 2022, brought to you by red hat, the cloud native computing foundation and its ecosystem partners. >>Welcome to Valencia Spain in Coon cloud native con Europe, 2022. I'm your host Keith Townsend. And we're continuing the conversation with community, with startups, with people building cloud native, a cube alum joint by a CTO. And not as the CTO advisor. I really appreciate talking to CTOs Capel. Th Lou don't forgive me if I murder the name, that's a tough one. I'm I'm, I'm getting warmed up to the cubey, but don't worry. When we get to the technical parts, it's gonna be fun. And then a cube alum, Umer K director of marketing Capel. You're the CTO. So we we'll start out with you. What's the problem statement? What, what, what are you guys doing? >>So, uh, we're building on top of an open source project podcast, custodian, uh, 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, you know, how do we enable developers to pick whatever tools and technologies they want, if they wanna use Terraform or cloud formation or Ansible? I mean, the cloud gives us APIs and we wanna be able to enable people to use those APIs through innovative ways. Uh, but at the same time, we wanna make sure that the, regardless of what choices those developers make, that the organization is being is being well managed, that all those resources, all that infrastructure is complying to the organizational'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 them as one offs. And so, uh, taking a step back, I realized that what we really needed was a way to go faster on the compliance side and clock custodian was born out of that effort side of desk that we took through enterprise wide. And it was really about, um, accelerating the velocity around compliance, but doing it in the same way that we do application and infrastructure is code. So doing policy as code in a very simple readable YAML DSL, um, because, you know, PO you have, we, anytime we write code, we're gonna more people are gonna read that code than, 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 wanna review it, um, it was super important. And then instead of being at the time, we saw lots of very under products and they were all just big walls of red in somebody's corner office and getting that to actually back the information back in the hands of developers so that they can fix things, um, was problematic. So being able to do 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 a area of focus of mind 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, or, uh, 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 what's that conversation like? >>So we start off by deploying our, our platform on top of buck custodian. Um, and as far as our customers, and we give them a view of all the things that are in their cloud, what is their baseline, so to speak. Um, but I think it's really important. Like I think you bring up a good point, like communication, the challenge, larger challenge for enterprises in the cloud, and especially with grocery compliance 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 the, 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. Um, and so being able to actually inform them, you know, via email, via slack, via, you know, any communication mechanism, uh, as they're doing things is, is so powerful to be able to, to help the organization grow together and move and get an alignment about what, what the, what the new things are. >>And then additionally, you know, from a perspective of, uh, 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 is, is really important. But coming back to your question on customer engagements, so we'll go in and we'll deploy, uh, a SAC platform for them. We'll basically show them all of the things that are there already and extent. Um, we provide a real time SQL interface that customers can use, um, that is an asset inventory of all their cloud assets. Uh, and then we provide, uh, policy packs that sort of cover off on compliance, security, cost, optimizations, and opportunities for them. Uh, and then we help them through, uh, get ops around those policies, help deploy remediation activities and capabilities for their environment. >>So walk me through some of the detail of, of, of the process and where the software helps and where people need to step in. I'm making I'm, I'm talking to my security auditor, and he's saying, you know what, Keith, I understand that the Aw, that the, uh, 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, well, there's no longer a firewall. There's a service. And the service is talking to that. And it, it is here and clouds, custodian and St is whether Stant 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 stalet from the perspective, uh, and if we take a step back, we, we talk about governances code and, and the four pillars around compliance, security, cost, optimization operations, uh, that we help organizations do. But if we take a step back, what is cloud custodian? Cloud custodian is really a cloud orchestrator, a resource orchestrator. What <inaudible> provides on top of that is UI UX, um, 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, 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 a SRE model, or, uh, let's say, even focus on the SRE, like what, where does the SRE sit in an organization? How does stack, like if at all, help me make those types of strategic decisions if I'm talking about governance overall. So, >>So I think in terms of personas, if you look at there's a cloud engineer, then SRE, I think that what at its core Stackler 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, and adopt custodian as well. So in terms of persona stack, it 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. >>Yeah. So I mean, cloud transformation for an enterprise is a deeper topic. Like I think, you know, there's a lot of good breast practices establishing a cloud center of excellence. Um, I, I think, you know, investing in training for people, uh, getting certification 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, uh, some of the DevOps. And so having SREs around for the actual application teams is, 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, IM authentication aspects. And so, uh, what we found is that, you know, SLA and cloud custodian get PR primarily get deployed by one of three groups. >>The, uh, you know, you've got the, 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 right way. Uh, they're very much more, um, uh, used to doing and open to doing remediation in real time. Um, 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, and validate that all the environments are, um, you know, secure, frankly. And then we get to the CFO groups. Uh, and so, and this sometimes is part of the cloud center of excellence. And so it, it has to be this cross team collaboration. And they're really focused on the, that, that cost optimization, finding the over provision, underutilized things, establishing workloads for dev environments to turn them off at night. Um, and of course, respective of time zones, cause we're all global these days. Uh, 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 their 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 custodians start and stop? Like, am I putting cloud custodian agents on servers or, uh, pods, like how, how am I interacting with this? >>So the core clock suiting is just to see lot it's stateless, it's designed to be operationally simple. Um, 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, um, investigations perspective on their laptop. But when you write a policy, a policy really consists of, you know, a couple of core elements. Uh, you identify a resource you want to target say an S3 bucket or, uh, a Google cloud VM. And then you say establishes that a filters. I want to look for all the C two instances that are on public subnets with an IM roll attached that has the ability to, uh, create another IM user. And so that, you know, 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 C two instance, and you might use it as an incident response. Um, you might, uh, use it for off hours in a, 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, uh, let's operate in real time. Whenever someone launches this instance, whenever there's an API call, we want to introspect what that API I call is doing and make sure that it's compliant to policy. Now, when you do that, custo will, when you, and you run it with the COI, cause you will actually provision a Lambda function and hook up the event sources to it. Uh, and sorry, Lambda really the serverless we bind into the serverless native capabilities of the underlying cloud provider. So Google cloud function, Azure serverless functions, uh, and native AWS Lambda native us. And so now that policy is effectively hermetically sealed, running, uh, in the Seus runtime of that cloud and responding to API calls in real time, all with, you know, structured outputs and logs and metrics to the native cloud provider capabilities around those. Um, and that really ensures that, uh, 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 >>Agent agent list and API based. >>Let's talk about like the a non-developer use case specifically finance. Absolutely. We, you have to deploy the ability to deploy, uh, um, uh, SAP in a, uh, E C two 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 wanna run a, uh, a check to see if anyone's doing it like this is this isn't a colder developer, what is their experience? So, >>So primarily we focus on the infrastructure. So low balancers, VMs, you know, encryption and address on discs. Um, when we get into the application workloads running on those instances, we spend, we don't spend that that's on our target focus area. Mm-hmm <affirmative>, we can do it. Uh, and it really depends on the underlying cloud provider's capabilities. So in Amazon, there's a system called systems manager and it runs, 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, I inspect the, 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 and a security perspective where you might wanna take a memory snapshot of, of, of the instance before, uh, um, yeah, putting it into a forensic cloud and adding >>To that, like these days we're seeing the emerging personas of a fops engineer or a fops 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, uh, target developers, better get them to take actions on policy as well. If they're overspending in the cloud or underspending in the cloud, uh, especially with St. You get, they get a lot of, out of the box dashboards and policy packs too. So say they can really understand how the cost has been consumed. They can have the developers take actions because a lot of the fops finance people complain like my developers does not understand it. Right. How do we get them to take action and make sure we are not over spending? Right. So with custodian policies, they're able to send them, uh, educational messages on slack or open a J ticket and really enforce them to take action as well and start saving cost. Like >>If you, uh, if you imagine cloud custodian as, um, you know, cleaning staff for, for the, your, your cloud environment, like it, it's, uh, you know, if you go to a typical, you know, cloud account, you're gonna see chairs that are 10 feet tall sitting at the table. You're gonna, because it's been over provision and obviously, you know, one can use it. Um, you're gonna find like the trash is overflowing because no one set up a log retention policy on the log group or set up S3, uh, life cycle rules on their buckets. And so you just have this, um, sort of this, uh, this explosion of things that people now, you know, beyond application functioning, like beyond, you know, getting to, you know, high performance, Dr. Capable, uh, SLAs around your application model, you now have to worry about the life cycle of all those resources and helping people manage that life cycle and making sure that they're using the, the, just the resources and consumption that they need, because we're all utilization based, uh, 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 and the CFO cost context. >>So, Emil, you got 10 seconds to tell me why you brought me a comic book. >><laugh> we created this comic book, uh, to explain the concept of governance scored in a simplified fashion. I know Keith, you like comic books, I believe. Uh, so it's a simple way of describing what we do, why it's important for pH ops for SecOps teams. And it talks about custodian and St. It as well. >>Well, I'm more of an Ironman type of guy or Batman cloud governance or governance 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 gonna talk to a bunch of startups that are solving these tough problems here from Licia Spain, I'm Keith Townsend, and you're watching the cube, the leader in high tech coverage.

>>The cube presents, Coon and cloud native con Europe, 2022, brought to you by red hat, the cloud native computing foundation and its ecosystem partners. >>Welcome to Licia Spain in Coon and cloud native con Europe, 2022. I'm Keith Townsend, along with my cohot Paul Gillon, who's been putting in some pretty good work talking to incredible people. And we have, I don't wanna call, heard the face of CNCF, but you kind of introduced me to, you don't know this, but you know, charmer executive director of CNCF. You introduced me to Kuan at Cuan San Diego's my one of my first CU coupons. And I was trying to get my bearings about me and you're on stage and I'm like, okay. Uh, she looks like a reasonable person. This might be a reasonable place to learn about cloud native. Welcome to the show. >>Thank you so much for having me. And that's so nice to hear >><laugh> it is an amazing show, roughly 7,500 people. >>Yes, that's right. Sold out >>Sold. That's a big show. And with that comes, you know, uh, so someone told me, uh, CNCF is an outstanding organization, which it, which it is you're the executive director. And I told them, you know what, that's like being the president of the United States without having air force one. <laugh> like you get home. I dunno >>About that. You >>Get, no, you get all of the, I mean, 7,500 people from across, literally across the world. That's true at Europe. We're in Europe, we're in, we're coming out of times that have been, you know, it can't be overstated. It, this, this is unlike any other times. >>Yes, absolutely >>Difficult decisions. There was a whole co uh, uh, I don't know the term, uh, uh, cuffa uh, or blow up about mask versus no mask. How do you manage just, just the diversity of the community. >>That is such a great question, because I, as I mentioned in my keynote a little bit, right? At this point, we're a community of what, 7.1 million developers. That's a really big group. And so when we think about how should we manage the diversity, the way I see it, it's essential to treat each other with kindness, professionalism, and respect. Now that's easy to say, right. Because it sounds great. Right. Old paper is awesome. Yeah. Yeah. Great >>Concept. 0.1 million people later. >><laugh> exactly. And so, uh, this is why like, uh, I phoned a friend on stage and, um, van Jones came and spoke with us. Who's the renowned CNN contributor, uh, commentator, sorry. And his advice was very much that in such a diverse community, there's always gonna be lots of perspectives, lots opinions. And we need to a always bring the version of ourselves, which we think will empower this ecosystem, BEC what are, what we are doing. If everybody did that, is that gonna be a good thing or a bad thing? And the other is we need to give each other space and grace, um, space to do what we need to do. Grace. If there are mistakes, if there are challenges. And so those are, those are some good principles for us to live by. And I think that in terms of how CNCF tries to enable the diversity, it's by really trying to hear from everybody possible, the vocal loud voices, as well as the folks who you need to reach out a little bit, pull in a little bit. So it's an ongoing, it's an ongoing challenge that we do our best with. >>How do you balance? And I've been to a lot of trade shows and conferences over the years, their trade organizers are very coin operated. You know, they're there, they're there for the money. Yeah. <laugh> and you have traditional trade shows and you have a situation here where an open source community that is motivated by very different, um, principles, but you need to make money. You need the show to be profitable. Uh, you need to sell some sponsorships, but you also need to keep it available and open to the people who, who don't have the big budgets. How are you balancing that? >>So I would actually like to, uh, share something that may not be obvious, which is that we don't actually do the shows to make money. We, um, as you said, like, uh, a lot of trade shows are coin up and the goal there is like, um, well actually they're different kinds of, I think if it's an independent event organization, it can be like, Hey, let's make as much revenue as possible. If it's part of a large, um, large company, like, like cloud provider, et cetera, the events tend to be lost leaders because they're like lead gen, I think, >>But they're, they're lost leaders, but they're profit makers ultimately >>Long term. Yeah. Yeah. It's like top of the funnel. I, I guess for us, we are only doing the events to enable the community and bring people from different companies together. So our goal is to try and break even <laugh> >>Well, that's, that's laudable. Um, the, how big does it get though? I mean, you're at the point with 7,500 attendees here where you're on the cusp of being a really big event, uh, would you limit it size eventually? Or are you just gonna let this thing run? Its course. >>So our inherent belief is that we want to be accessible and open to more and more and more people because the mission is to make cloud native ubiquitous. Right. Uh, and so that means we are excited about growth. We are excited about opening the doors for as everyone, but I think actually the one, one good thing that came out of this pandemic is that we've become a lot more comfortable with hybrid. So we have a virtual component and an in-person component. So combining that, I think makes it well, it's very challenging cause like running to events, but it's also like, it can scale a little bit better. And then if the numbers increase from like, if they double, for example, we're still, I think we're still not in the realm of south by Southwest, which, which feels like, oh, that's the step function difference. So linear increases in number of attendees, I think is a good thing. If, and when we get to the point where it's, um, you know, exponential growth at that point, we have to think about, um, a completely different event really. Right, >>Right. So 7 billion people in the world approaching 8 billion, 7.1 members in the community. Technology is obviously an enabler where I it's enabled me to, to be here and Licia Spain experiencing this beautiful city. There's so much work to be done. What mm-hmm <affirmative> what is the role of CNCF in providing access to education and technology for the rest of the world? >>Absolutely. So, you know, one of the key, uh, areas we focus on is learning and development in supporting the ecosystem in learners beginners to start their cloud native journey or expand their cloud native journey with training certifications, and actually shared this in the keynote every year. Uh, the increase in number of people taking certifications grows by 216% year over year growth. It's a lot, right? And every week about a thousand people are taking a certification exam. So, and we set that up primarily to bring people in and that's one of our more successful initiatives, but we do so many, we do mentorship programs, internship programs. We, uh, a lot of diversity scholarships, these events, it all kind of comes together to support the ecosystem, to grow >>The turning away from the events, uh, toward just toward the CNCF Brit large, you have a growing number of projects. The, the number of projects within CNCF is becoming kind of overwhelming. Is there an upper threshold at which you would, do you tighten the, the limits on, on what projects you will incubate or how big does that tent become? >>Right. I think, you know, when we had 50 projects, we were feeling overwhelmed then too, but we seem to have cop just fine. And there's a reason for that. The reason is that cloud native has been growing so fast with the world. It's a representative of what's going on in our world over the course of the pandemic. As you know, every company became a technology company. People had to like double their engineering staffs over without anybody ever having met in person mm-hmm <affirmative> right. And when that kind of change is going around the world cloud needing be being the scaffolding of how people build and deploy modern software just grew really with it. And the use cases we needed to support grew. That's why the types of projects and kinds of projects is growing. So there's a method. There's a reason to the madness I should say. And I think, um, as the world and, uh, the landscape of technology evolves cloud native will, will evolve and keep developing in either into new projects or consolidation of projects and everything is on the table. >>So I think one of these perceptions Riley Arone is that CNCF is kind of where the big people go to play. If you're a small project and you're looking at CNCF, you're thinking one day I'll get big enough. Like how should small project leaders or leaders of small projects, how should they engage CNCF? >>Totally. And, you know, I want to really change this narrative because, um, in CNCF we have three tiers of projects. There's the graduated ones, which are at the top. These are the most mature ones we really believe and put our sand behind them. They, uh, then there's the incubating projects, which are pretty solid technologies with good usage that are getting there. And then there's the sandbox, which is literally a sandbox and op open ground for innovation. And the bar to entry is low in that it's, uh, easy to apply. There's a mass boat to get you in. And once you're in, you have a neutral IP zone created by being a CNCF project that you can attract more maintainers, more companies can start collaborating. So we, we become an enabler for the small projects, so everybody should know that >>FYI. Yeah. So I won't be interested to know how that, so I have an idea. So let's say I don't have an idea, but let's say that idea have, >>I'm sure you have an idea. <laugh>, I'm >>Sure I have idea. And, and I just don't have the infrastructure to run a project. I need help, but I think it it's going to solve a pro problem. Yeah. What's that application process like, >>So, okay. So you apply after you already have let's a GitHub repo. Okay. Yeah. >>So you, I have a GI help repo. >>Yeah. As in like your pro you've started the project, you started the coding, you've like, put it out there on GitHub, you have something going. And so it's not at just ideal level. Mm-hmm, <affirmative>, it's at like early stage of execution level. Um, and so, and then your question was, how do you apply? >>Yeah. So how do I, so I have, let's say that, uh, let, let's talk about something I'm thinking about doing, and I actually do, is that we're thinking about doing a open store, a cloud native framework for people migrating to the public cloud, to, or to cloud native. There's just not enough public information about that. And I'm like, you know what? I wanna contribute what I know to it. So that's a project in itself, not necessarily a software project, but a IP project, or let's say I have a tool to do that migration. And I put that up on my GitHub report. I want people to iterate on that tool. >>Right. So it would be a simple process of literally there is when you go to, um, our, uh, online, uh, materials, there's a simple process for sandbox where you fill a Google form, where you put in your URL, explain what you're doing, or some basic information hit submit. And we batch process these, um, about every once a month, I think. And, uh, the TC looks at the, what you've filled in, takes a group vote and goes from there. >>When about your operating model, I mean, do, do you, you mentioned you don't look to make a profit in this show. Do you look, and I wanna be sure CNCF is a non-profit, is that correct? Correct. Do you look, what models do you look at in determining your own governance? Do you look at a commercial business? Do you look at a nonprofit? Um, like of ourselves? Yeah. What's your model for how you run CNCF. >>Oh, okay. So it's a nonprofit, as I said, and our model is very simple. We want to raise the funds that we are able to raise in order to then invest them into community initiatives that play the supporter enabler role to all these projects we just talked about. We're not, we are never the project. We are the top cheerleader of the project. Think of us like that. And in terms of, um, but interestingly, unlike, I, I mean, I don't know much about other found, uh, nonprofit session compare, but interestingly, the donating companies are relevant, not just because of their cash that they have put in, but because those companies are part of this ecosystem and they need to, um, them being in this ecosystem, they help create content around cloud native. They, they do more than give us money. And that's why we really like our members, uh, they'll provide contributing engineers to projects. They will help us with marketing with case studies and interviews and all of that. And so it, it becomes this like healthy cycle of it starts with someone donating to become a member, but they end up doing so many different things. Mm-hmm <affirmative> and ultimately the goal is make cloud native ubiquitous and all this goes towards >>That. So talk to me about conflict resolution, because there's some really big projects in CNC, but only some stuff that is changed, literally changing the world, but there's competing interest between some of the projects. I mean, you, you, there there's, if you look at service mesh, there's a lot of service mesh solutions Uhhuh. Yes. And there's just different visions. Where's the CNCF and, and kind of just making sure the community aspect is thought across all of the different or considered across all the different projects as they have the let's say inevitably bump heads. >>Yeah. So by design CNCF was never meant to be a king maker where you picked one project. Right. And I think that's been working out really well because, um, one is when you accept a project, you're not a hundred percent sure that specific one is gonna take over that technology space. Right. So we're leaving it open to see who works it out. The second is that as every company is becoming a technology company, use cases are different. So a service mesh service mesh a might work really well for my company, but it really may not be a fit for your code base. And so the diversity of options is actually a really good thing. >>So talk to me about, uh, saw an interesting note coming out of the keynote yesterday, 65% of the participants here at CU con are new to Kuan. I'm like, oh, I'm a, I'm a vet. You are, I went to two or three before this. So O GE yeah, OG actually, that's what I tweeted OG of Kuan, but, uh, who, who are they like, what's making up? Are they developers? Are they traditional enterprises? Are they contributing companies? Who's the 65%, >>Um, who's the 65%, >>Right? The new, new, >>Well, it's all kinds of C companies sending their developers, right? It's sometimes there's a lot of them are end users. I think at least half or a third, at least of attendees are end user companies. And, uh, then there is also like the new startups around town. And then there is like the, every big company or small has been hiring developers as fast as possible. And even if they've always been a player in cloud native, they need to send all these people to this ecosystem to start building the relationships start like learning the technology. So it's all kinds of folks are collecting to that here. >>As I, as I think about people starting to learn the technologies, learn the communities, the one thing the market change for this coupon for me over others is the number of customers, sharing stories, end user organizations. Mm-hmm, <affirmative>, mm-hmm, <affirmative> much of the cuon that I've been through many of the open source conferences. It's always been like vendors pushing their message, et cetera. What talk, tell me about that. C change. >>One thing that's like just immediate, um, and the case right now is that all the co-chairs for the event who are in charge of designing the agenda are end users. So we have Emily Fox from apple. We have Jasmine James from Twitter, and we have Ricardo Roka from se. So they're all end users. So naturally they're like, you know, picking talks that they're like, well, this is very relevant. Imma go for that and I'm here for it. Right? So that's one thing that's just happening. The other though is a greater trend, which is, as I was saying in the pandemic, so many companies has to get going and quickly that they have built expertise and users are no longer the passive recipients of information. They're equal contributors. They know what they need, what they want, they have experiences to share. And you're seeing that reflected in the conference. >>One thing I've seen at other conferences in the past that started out really for practitioners, uh, is that invariably, they want to go upscale and they wanna draw the CIOs and the, oh yeah. The, uh, you know, the executive, the top executives. Is that an objective, uh, for you or, or do you really want to keep this kind of a, a t-shirt crowd for the long term? >>Hey, everyone's welcome. That's really important, you know? Right. And, um, so we, and that's why we are trying to expand. It's like, you know, middle out as they had in the Silicon valley show the idea being, sorry, I just meant this a little. Okay. So the idea being that we've had the core developer crews, developer, DevOps, SRE crowd, right op over the course of the last virtual events, we actually expanded in the other direction. We put in a business value track, which was more for like people in the business, but not in as a developer or DevOps engineer. We also had a student thing where it's like, you're trying to get all the university crowd people, and it's been working phenomen phenomenally. And then actually this, this event, we went, uh, in the other direction as well. We hosted our inaugural CTO summit, which is for senior leadership and end user companies. And the idea is they're discussing topics of technology that are business relevant. So our topic this time was resiliency in multi-cloud and we're producing a research paper about it. That's gonna come out in some weeks. So BA so with, for us, it's about getting everybody under this tent. Right. And, but it will never mean that we deprioritize what we started with, which is the engineering crowd. It's just an expansion >>Stay true to your roots. >>Yes. Well, Prianca, we're going to talk to a lot of those startup communities tomorrow. Ah, tomorrow's coverage. It's all about startups. Why should CTOs, uh, new startups talk to these upstarts of as opposed to some of the bigger players here on the show floor, over 170 sponsoring companies, the show floor has been vibrant engaging. Yes. And we're going to get into that community tomorrow's coverage on the cube from Valencia Spain. I'm Keith Townson, along with Paul Gillon and you're watching the cube, the leader and high tech coverage.

>>The queue presents Coon and cloud native con Europe, 2022, brought to you by red hat, the cloud native computing foundation and its ecosystem partners. >>Welcome to Licia Spain, a Coon cloud native con Europe, 2022. I'm your host, Keith Townson, along with Paul Gillon senior editor, enterprise architecture for Silicon angle. Paul, we're gonna talk to some amazing people this week. Coon, what the energy here, what, what, what, what would you say about >>It? I'd say it's reminiscent of, of early year, uh, early stage conferences I've seen with other technologies. There is a lot of startup activity. Here's a lot of money in the market, despite the sell off in the stock market lately. Uh, a lot of anticipation that there are, there could be big exits. There could be big things ahead for these companies. You don't see that when you go to the big established conferences, uh, you see just, uh, anticipation here that I don't think you see, uh, you you'll see maybe in a couple years, so it's fun to be here right now. I'm sure it'll be a very different experience in two or three years. >>So welcome to our guest cube alum. Batam Tobar the founder and CEO of Upbound. Welcome back. >>Thank you. Yeah, pleasure to be on, on the show again. >>So Paul, tell us the we're in this phase of migrations and, and moving to cloud native stacks. Are we another replatforming generation? I mean, we've done, the enterprise has done this, you know, time and time again, whether it's from Java to.net or do net to Java or from bare metal to VMs, but are we in another age of replatforming? >>You know, it's interesting. Every company has now become a tech company and every tech company needs to build a very model, you know, modern digital platform for them to actually run their business. And if they don't do that, then they'll probably be out of business. And, um, it is interesting to think about how companies are platforming and replatforming. Like, you know, as you said, just a, a few years back, you know, we were on people using cloud Foundry or using Heroku, you hear Heroku a lot, or, you know, now it's cloud native and Kubernetes and, and it, it begs the question, you know, is this the end? That to your point, is this, you know, do we have a, you know, what, what makes us sure that this is the, you know, the last platform or the future proof platform that, that people are building, >>There's never a last platform, right? There's always something around the core. The question is, is Kubernetes Linux, or is it windows? >>That, that's a good question. Um, it's more like more like Linux. I think, um, you know, the, you know, you've heard this before, but people talk about Kubernetes as a platform off platforms. Um, you can use it to build other platforms and if you know what you're doing, you can probably put, assemble a set of pieces around it and arrive at something that looks and can work for your business, but it requires a ton of talent. It requires a lot of people that actually can act, you know, know how to put this stick together to, to work for your business. It is, there's not a lot of guidance. I, we were, I think we were chatting earlier about the CSCF landscape and, and, um, how there are all these different projects and companies around it, but, but they don't come together in meaningful ways that you have, they act the enterprise itself has to figure out how to bring them together. Right. And that's the combination of what they do there organically or not is their platform. Right. And that changes. It can change over time. >>Do you think they really do. They really want to put these things together? I mean, there's, that's not what enterprise is like to do. They want to find someone who's gonna come in and, uh, turnkey do it all for them. >>Yeah. And, and if there was, this is the, this is the things like EV every week now you hear about another platform that says, this is the new Heroku. This is the new cloud Foundry, this replaces every, you know, some vendor has, and you can see them all around here. You know, companies that are basically selling platform solutions, um, that do put 'em together. And the problem with it is that you typically outgrow these, like you are, um, it might solve 80% of the use cases you care about, but the other 20% are not represented. And so you end up outgrowing the platform itself, right? And the, the choice has been mostly around, you know, do you buy something off the shelf that solves 80% of your use cases, or do you build something on your own? And then you have to spend all your resources actually going through and building all of it. And that's been the dilemma, you know, people who talk about this as a platform dilemma, but it's been, it's been the way for a long time. Like you, every, we go through this cycle every few years and, you know, people end up essentially oscillating between buying something off the, you know, that's off the shelf or building it, building it themselves. >>So what's the payoff. If I'm a CIO and I'm looking at the landscape, I don't need to understand, you know, I don't know to know what a pod is to know that looking at 200 plus projects in co and at, in cloud native, uh, foundation and the bevy of, of co-located projects and, and conferences before they, even the start of this, what's the payoff >>Increasing the pace of innovation. I mean, that literally is when we talk to customers, they all say roughly the same thing. They want something that works for their business. They want something that helps them take their, you know, line of business applications to production in a much quicker way, lets them innovate, lets them create higher engineers that can, don't have to understand everything about every system, but can actually specialize and focus on the, the parts that they sh they care about. Um, but it's all in the context of, you know, people want to be able to innovate at a very high pace, otherwise they get disrupted. >>So I was at the, you know, my favorite part of, of Coon in general is the hallway track and talking to people on the ground, doing cool things. I was talking to a engineer who was able to take their Java, stack their, their, uh, net stack and start to create APIs between and break 'em into microservices. Now teams are working across from one another realizing that, that, that promise of innovation, but that was the end point. They they're there. Yeah. As companies are thinking about replatforming where like, where do we start? I mean, looking at the, the CNCF, the, the map and it's 200 plus projects, where do I start? >>Do you typically today start with Kubernetes and, and um, a lot of companies have now deployed Kubernetes to production as a container orchestrator, whether they're going through a vendor or not, but now you are seeing all the things around it, whether it's C I C D or GI ops that they're looking at, you know, or the starting to build consoles around, you know, their, their platforms or looking at managing more than just containers. And that's a theme that, you know, we're seeing a lot now, people want, people want to actually bring this modern stack to manage, not just container workloads, but start looking at databases and cloud workloads and everything else that they're doing around it. Honestly, everybody's trying to do the same thing. They're trying to arrive at a single point of control, a single, you know, a platform that can do it all that they can centralize policy centralized controls to compliance governance, cost controls, and then expose a self-service experience to developers. Like they're all trying to build what we probably call an internal cloud platform. They don't know, they talk about it in different ways, but almost everyone is trying to build some internal platform that sits on top of, on premises. And on top of cloud, depending on their scenarios, >>You make an interesting point, which is that everyone here is to some extent trying to do the same thing. And there's fine points of granularity between now they're approaching it as you walk around this floor. Do you understand what all of these companies are doing? >>I'm not sure I understand all of them, but I, I do. I do recognize a lot of them. Yes. >>And in terms of your approach, you, you use the term control plane, uh, what is distinctive about your approach? >>Very good question. So, you know, we, we end up out take a, um, we we're trying to solve, uh, this problem as well. We're trying to help people build their own platforms. Um, but let me, let me, you know, there's a lot to it. So let me actually step back and talk about the architecture of this. But if you were to look at any cloud platform, let's take the largest one. AWS, if you peek behind the scenes at AWS, you know, um, it's basically a set of independent services, EC two S3 databases, et cetera, um, that are, you know, essentially working on different parts of, you know, like offer completely different pricing, different services, et cetera. They come together because they all integrate into a control plan. >>It's the thing that serves an API. It's the thing that gives it all a common field. It's where you do access control. It's where you do, um, billing, metering, cost control policy, et cetera. Right? And so our realization was if the enterprises are platforming and replatforming, why shouldn't they build their platform in the same way that the cloud vendors build theirs? And so we started this project almost four years ago, now three and a half years, um, called cross plain, which is a, essentially an open source control plane that can become the integration point for all services. And essentially gives you a universal control plane for cloud. >>So you mentioned the idea of the orchestrating or managing stuff other than containers, as I think about companies that built amazing platforms, enterprise companies, building amazing applications on AWS 10 years ago, and they're adopting the AWS control plane. And now I'm looking at Kubernetes is Kubernetes the way to multi-cloud to be able to control those discrete applic, uh, services in a AWS or Google cloud Azure or Oracle cloud is cetera. >>We kind of have the tease it, the parts. So there are really two parts to Kubernetes and everybody thinks of Kubernetes as a container orchestration platform. Right? And, um, you know, there is a sense that people say, if I was to run Kubernetes on everywhere and can build everything on top of containers, that I get some kind of portability across clouds, right. That I can put things in containers. And then they magically run, you know, in different environments. Um, in reality, what we've seen is not everything fits in containers. It's not gonna be the world is not gonna look like containers on the bottom. Everything else is on top. Instead, what we're gonna see is essentially a set of services that people are using across the different vendors. So if you look at like, you could be at AWS shop primarily, but I bet you're using confluent or elastic or data breaks or snowflake or Mongo or other services. >>I bet you're using things that are on premises, right? And so when you look at that and you say to build my platform as an enterprise, I have to consume services from multiple vendors. Even it's just one major cloud vendor, but I'm consuming services from others. How do I bring them together in meaningful ways so that I can, you know, build my platform on top of the collection of them and offer something that my developers can consume. And self-service on. That's not a, that's not just containers. What's interesting though, is if you look at Kubernetes and, you know, look inside it, Kubernetes built a control plane. That's actually quite useful and applicable outside of container scenarios. So this whole notion of CRDs and controllers, if you've heard that term, um, the ability, you know, like there are two parts to Kubernetes, there is the control plane, and then there's the container container, uh, workloads and the control plane is generic. >>It could be used literally across, you know, you can use it to manage things that are completely outside of container workloads. And that's what we did with cross plain. We took the control plane of Kubernetes and then built bindings providers that connected to AWS, to Google, to Azure, to digital ocean, to all these different environments. So you can bring the way of managing, you know, the style of managing that Kubernetes invented to more than just containers. You can now manage cloud services, using the same approach that you are now using with Kubernetes and using the entire ecosystem of tooling around it. >>Enterprise have been under pressure replatform for a long time. It was first go to Unix then to Linux and virtualize then to move to the cloud. Now, Kubernetes, do you think that this is the stack that enterprises can finally commit to? >>I think if you take the orientation of your deploying a control plane within your enterprise, that is extensible, that enables you to actually connect it to all the things that are under your domain, um, that that actually can be a Futureproof way of doing a platform. And, you know, if you look at the largest cloud platforms, AWS has been around for at least 15 years now, uh, and they really haven't changed the architecture of AWS significantly. It's still a control plane, a set of control planes that are managing services. >>It's a legacy >>They've added a lot of services. They've have a ton of diversity. They've added so many different things, but the architecture is still a hub and spoke that they've built, right? And if the enterprise can take the same orientation, put a control plane, let it manage all the things that are, you know, about today, arrive at a single point of control, have a single point where you can enforce policy compliance, cost controls, et cetera, mm-hmm <affirmative>, and then expose a self-service experience to your developers that actually can become future proof. >>So we've heard this promise before the cloud of clouds, basically. Yes, the, the, to be able to manage everything, what we find is the devils in the details. The being able to say, you know, a load balancer issuing a, a command to, to deploy a load balancer in AWS is different than it is in Azure, which is different than it is in GCP. How do, how do enterprises know that we can talk to a single control plane to do that? I mean, that just seems extremely difficult to manage. Oh >>Yeah. That, um, the approach is not, you're not trying to create a lowest common denominator between clouds. That's a really, really hard problem. And in fact, you get relegated to just using this, you know, really shallow features of each, if you're, if you're gonna do that, like your, your example of load balancers, load balances look completely different between between cloud vendors. Um, the approach that we kind of advocate for is that you shouldn't think of them as you shouldn't try to unify them in a way that makes them, you know, there's a, uh, there's a global abstraction that says, oh, there's a load balancer. And it somehow magically works across the different cloud vendors. I think that's a really, really hard thing to say, to do as you point out. However, if you bring them all under a same control plane, As different as they are, you're able to now apply policies. You're able to set cost controls. You're able to expose a self-service experience on top of them, even, even if they are very different. And that's, that's something that I think is, you know, been hard to do in the past. >>So BAAM, we'll love to dig deeper into this in future segments. And I'm gonna take a look at the, the, the product and project <laugh> and see where you folks land in this conversation from Valencia Spain, I'm Keith towns. And along with Paul Gillon, and you're watching the leader in high tech.

>>The cube presents Koon and cloud native con Europe, 2022, brought to you by red hat, the cloud native computing foundation and its ecosystem partners. >>Welcome to Valencia Spain and CubeCon cloud native con Europe, 2022 I'm cube Townsend, along with Paul Gill, senior editor, enterprise architecture at Silicon angle. We are talking to some incredible folks this week, continuing the conversation around enabling developers to do their work. Paul you've said that this conference is about developers. What are you finding key as a theme running throughout the show >>That that developers really need a whole set of special tools. You know, it's not the end user, the end user tools, the end user access controls the authentication it's developers need a need their own to live their in their own environment. They need their own workflow tools, their own collaboration and their own security. And that's where teleport comes in. >>So speaking of teleport, we have Michael fork, chief marking our officer at teleport new world role for you. First, tell me about how long have you been at teleport now >>Going on seven or eight months now, >>Seven or eight months in this fast moving market. I'm I'm going to tell you a painful experience I've had in this new world. We've built applications. We've moved fast audits come in. The auditors have come in and they said, you know what, who authorized this change to the cluster? And we'll go into the change ticket and say, this person authorized the changes and the change ticket. And then they'll ask for trace back. Okay. Show me the change. What do it mean? Show you the changes. It just happened. >>Yeah. Check, check GitHub. >>Yeah, check GI, get, see, we, we, we, we said we were gonna make the changes, the change happen. That's not enough. What are CU, how are you helping customers solve this access control and audit problem? >>Yeah, that's a great question. There're kind of, there're kind of two, two sides to the puzzle. And actually I think that the intro hits it. Well, you you've talked about kind of developer experience needing needing tools to more efficiently do the job as a practitioner. And you're coming at it from kind of a security and compliance angle. And there's a tension between both of those teams. It's like, you know, there's, there's a tension between dev and ops before we created DevOps. There's also a tension between kind of security teams and developers. So we've created dev SecOps. What that means is you need an easy way for developers to get access, access to the resources they needed through their jobs. That's, you know, Linux hosts and databases and Kubernetes clusters and, you know, monitoring dashboards and managing all of those credentials is quite cumbersome. If I need to access a dozen systems, then you know, I'm using SSH keys to access this. >>I have admin credentials for my database. I I'm going through a VPN to access an internal dashboard, teleport, consolidates, all of that access into a single login via your identity provider, Okta active directory, but then on the security and compliance side, we make it really easy for that compliance officer. When they say, show me that change, we have all of the audit logs. That's that show exactly what changes Keith made when he logged into, into that system. And in fact, one of the booths behind here is talking about E B P F a modern way to get that kind of kernel level grade granularity. We build all of that observability into teleport to make the security and compliance teams happy. And the engineering teams a lot more productive. >>Where do the, the access control tools like Okta, you mentioned fall short. I mean, why, why is there a need for your level of, of control at the control plane? >>Yeah. When you, when you start to talk about authorization, authentication, audit at the infrastructure level, each of these technologies has its own way of managing what kind of in, in the jargon often and Ze, right? Authentication authorization. So you have SSH for, for Linux. Kubernetes has its own way of doing authorization. All of the database providers have their own way and it's quite complicated, right? It's, it's much different. So, you know, if I'm gonna access office 365 or I'm gonna a access Salesforce, right. I'm really talking about the HTTP protocol. It's relatively trivial to implement single sign on for web-based applications. But when we start talking about things that are happening at the Linux kernel level, or with Kubernetes, it's quite complicated to build those integrations. And that's where teleport extends what you have with your IDP. So for instance, Okta, lots of our customers use Okta as their identity provider, but then teleport takes those roles and applies them and enforces them at the actual infrastructure level. >>So if I'm a lay developer, I'm looking at this thinking, you know, I, I have service mesh, I've implemented link D SEO or something to that level. And I also have Ansible and Ansible has security, etcetera. What, what role, or how does that integrate to all together from a big picture perspective? >>Yeah. So >>What, one of the, kind of the meta themes at teleport is we, we like to, we like to say that we are fighting complexity cuz as we build new technologies, we tend to run the new tech on top of the old tech. Whereas for instance, when you buy a new car, you typically don't, you know, hook the old car to the back and then pull it around with you. Right? We, we replace old technology with new technology, but in infrastructure that doesn't happen as often. And so you end up with kind of layers of complexity with one protocol sitting on top of another protocol on top of another protocol. And what teleport does is for the access control plane, we, we kind of replace the legacy ways of doing authentication authorization and audit with a new modern experience. But we allow you to continue to use the existing tools. >>So we don't replace, for instance, you know, your configuration management system, you can keep using Ansible or, or salt or Jenkins, but teleport now is gonna give those, those scripts or those pipelines in identity that you can define. What, what should Ansible be able to do? Right? If, cuz people are worried about supply chain attacks, if a, if a vulnerable dependency gets introduced into your supply chain pipeline and your kind of Ansible playbook goes crazy and starts deploying that vulnerability everywhere, that's probably something you wanna limit with teleport. You can limit that with an identity, but you can still use the tools that you're, that you're used to. >>So how do I guarantee something like an ex-employee doesn't come in and, and initiate Ansible script that was sitting in the background just waiting to happen until, you know, they left. >>Yeah. Great question. It's there's kind of the, the, the great resignation that's happening. We did a survey where actually we asked the question kind of, you know, can you guarantee that X employees can no longer access your infrastructure? And shockingly like 89% of companies could not guarantee that it's like, wow, that's like that should, that should be a headline somewhere. And we actually just learned that there are on the dark web, there are people that are targeting current employees of Netflix and Uber and trying to buy credentials of those employees to the infrastructure. So it's a big problem with teleport. We solve this in a really easy, transparent way for developers. Everything that we do is based on short lift certificates. So unlike a SSH key, which exists until you decommission it, shortlist certificates by, by default expire. And if you don't reissue them based on a new login based on the identity, then, then you can't do anything. So even a stolen credential kind of the it's value decreases dramatically over time. >>So that statistic or four out of five companies can't guarantee X employees can't access infrastructure. Why is simply removing the employee from the, you know, from the L app or directory decommissioning their login credentials. Why is that not sufficient? >>Well, it, it depends on if everything is integrated into your identity provider and because of the complexities of accessing infrastructure, we know that developers are creative people. And by, by kind of by definition, they're able to create systems to make their lives easier. So one thing that we see developers doing is kind of copying an SSH key to a local notepad on, on their computer. So they essentially can take that credential out of a vault. They can put it somewhere that's easier for them to access. And if you're not rotating that credential, then I can also, you know, copy it to a, to a personal device as well. Same thing for shared admin credentials. So the, the, the issue is that those credentials are not completely managed in a unified way that enables the developer to not go around the system in order to make their lives easier. >>But rather to actually use the system, there's a, there's a market called privilege access management that a lot of enterprises are using to kind of manage credentials for their developers, but it's notoriously disruptive to developer workflows. And so developers kind of go around the system in order to make their jobs easier. What teleport does is we obviate the need to go around the system, cuz the simplest thing is just to come in in the morning, log in one time to my identity provider. And now I have access to all of my servers, all of my databases, all of my Kubernetes clusters with a short lift certificate, that's completely transparent. And does >>This apply to, to your, both your local and your cloud accounts? >>Yes. Yes, exactly. >>So as a security company, what's driving the increase in security breaches. Is it the lack of developer hygiene? Is it this ex-employee great resignation bill. Is it external intruders? What's driving security breaches today. >>Yes. >>It's you know, it's, it's all of those things. I think if I had to put, give you a one word answer, I would say complexity. The systems that we are building are just massively complex, right? Look at how many vendors there are at this show in order to make Kubernetes easy to use, to do what its promises. It's just, we're building very complex systems. When you build complex systems, there's a lot of back doors, we call it kind of a tax surface. And that's why for every new thing that we introduce, we also need to think about how do we remove old layers of the stack so that we can simplify so that we can consolidate and take advantage of the power of something like Kubernetes without introducing security vulnerabilities. >>One of the problems or challenges with security solutions is, you know, you there's this complexity versus flexibility knob that you, you need to be careful of. What's the deployment experience in integration experience for deploying teleport. >>Yeah, it's it, we built it to be cloud native to feel like any other kind of cloud native or Kubernetes like solution. So you basically, you deploy it using helm chart, you deploy it using containers and we take care of all of the auto configuration and auto update. So that it's just, it's, it's part of your stack and you manage it using the same automation that you use to manage everything else. That's a, that's a big kind of installation and developer experience. Part of it. If it's complex to use, then not only are developers not gonna use it. Operations teams are not gonna want to have to deal with it. And then you're left with doing things the old way, which is very unsatisfactory for everybody. >>How does Kubernetes change the security equation? Are there vulnerabilities? It introduces to the, to the stack that maybe companies aren't aware of >>Almost by definition. Yes. Kind of any new technology is gonna introduce new security vulnerabilities. That's the that's that is the result of the complexity, which is, there are things that you just don't know when you introduce new components. I think kind of all of the supply chain vulnerabilities are our way of looking at that, which is we have, you know, Kubernetes is itself built on a lot of dependencies. Those dependencies themselves could have security vulnerabilities. You might have a package that's maintained by one kind of hobbyist developer, but that's actually deployed across hundreds of thousands of applications across, across the internet. So again, it's about one understanding that that complexity exists and then saying, is there a way that we can kind of layer on a solution that provides a common layer to let us kind of avoid that complexity and say, okay, every critical action needs to be authorized with an identity that way if it's automated or if it's human, I have that level of assurance that a hacked Ansible pipeline is not going to be able to introduce vulnerabilities across my entire infrastructure. >>So one of the challenges for CIOs and CTOs, it's the lack of developer resources and another resulting pain point that compounds that issue is rework due to security audits is teleport a source of truth that when a auditor comes in to audit a, a, a, a C I C D pipeline that the developer or, or operations team can just say, Hey, here's, self-service get what you need. And come back to us with any questions or is there a second set of tools we have to use to get that audit and compliance reporting? >>Yeah, it's teleport can be that single source of truth. We can also integrate with your other systems so you can export all of the, what we call access logs. So every, every behavior that took place, every query that was run on a database, every, you know, curl command that was run on a Lennox, host, teleport is creating a log of that. And so you can go in and you can filter and you can view those, those actions within teleport. But we also integrate with other systems that, that people are using, you have its Splunk or Datadog or whatever other tool chain it's really important that we integrate, but you can also use teleport as that single source. So >>You can work with the observability suites that are now being >>Installed. Yeah, there, the, the wonderful thing about kind of an ecosystem like Kubernetes is there's a lot of standardization. You can pick your preferred tool, but under the hood, the protocols for taking a log and putting it in another system are standardized. And so we can integrate with any of the tools that developers are already using. >>So how big is teleport when I'm thinking about a, from a couple of things big as in what's the footprint and then from a developer operations team overhead, is this kind of a set and forget it, how much care feed and maintenance does it >>Need? So it's very lightweight. We basically have kind of two components. There's the, the access proxy that sits in front of your infrastructure. And that's what enables us to, you know, regardless of the complexity that sits across your multi data center footprint, your traditional applications, running on windows, your, your, your modern applications running on, you know, Linux and Kubernetes, we provide seamless access to all of that. And then there's an agent that runs on all of your hosts. And this is the part that can be deployed using yo helm or any other kind of cloud native deployment methodology that enables us to do the, the granular application level audit. For instance, what queries are actually being run on CockroachDB or on, on Postgres, you know, what, what CIS calls are running on Linnux kernel, very lightweight automation can be used to install, manage, upgrade all of it. And so from an operations perspective, kind of bringing in teleport shouldn't be any more complicated than running any application on a container. That's, that's the design goal and what we built for our customers. >>If I'm in a hybrid environment, I'm transitioning, I'm making the migration to teleport. Is this a team? Is this a solution that sits only on the Kubernetes cloud native side? Or is this something that I can trans transition to initially, and then migrate all of my applications to, as I transition to cloud native? >>Yeah. We, there are kind of, no, there are no cloud native dependencies for teleport. Meaning if you are, you're a hundred percent windows shop, then we support for instance, RDP. That's the way in which windows handles room access. If you have some applications that are running on Linux, we can support that as well. If you've got kind of the, you know, the complete opposite in the spectrum, you're doing everything, cloud native containers, Kubernetes, everything. We also support that. >>Well, Michael, I really appreciate you stopping by and sharing the teleport story. Security is becoming an obvious pain point for cloud native and container management. And teleport has a really good story around ensuring compliance and security from Licia Spain. I'm Keith towns, along with Paul Gillon and you're watching the cue, the, the leader, not the, the leader two, the high take tech coverage.

>>The cube presents, Coon and cloud native con Europe, 2022. Brought to you by red hat, the cloud native computing foundation and its ecosystem partners. >>Welcome to Licia Spain and cube con cloud native con 2022 Europe. I'm Keith Townsend, along with Paul Gillon senior editor, enterprise architecture for Silicon angle. We're gonna talk to some amazing folks. Day two coverage of Q con cloud native con Paul. We did the wrap up yesterday. Great. A great back and forth about what en Rico about yesterday's, uh, session. What are you looking for to today? >>I'm looking for, uh, to understand better, uh, how Kubernetes is being put into production, the types of applications that are being built on top of it. Yesterday, we talked a lot about infrastructure today. I think we're gonna talk a little bit more about applications, including with our first guest. >>Yeah, I was speaking our first guest. We have ish Degan CPO chief product officer at Hazelcast Hazelcast has been on the program before, but you, this is your first time in the queue, correct? >>It, it is Keith. Yeah. Well, >>Welcome to been Cuban. So we're talking data, which is always a fascinating topic. Containers are, have been known for not being supportive of stateful applications. At least you shouldn't hold the traditional thought. You shouldn't hold stateful data in containers. Tell me about the relationship between Hazel cast and containers we're at Cuan. >>Yeah, so a little bit about, uh, Hazelcast. We are a real time data platform and, uh, we are not a database, but a data platform because we basically allow, uh, data at rest as well as data in motion. So you can imagine that if you're writing an application, you can basically query and join a data coming in events, as well as data, which might have been persisted. So you can do both stream processing as well as, you know, low latency data access. And, and this platform of course, is supported on all the clouds. And we kind of delegate the orchestration of this kind of scale out system to Kubernetes. Um, and you know, that provides a resiliency and many things which go along with that. >>So you say you don't, you're not a database platform. What are you used for to manage the data? >>So we are, uh, we are memory first. So we are, you know, we started with low latency applications, but then we realized that real time has really become a business term. It's it's more of a business SLA mm-hmm, <affirmative>, it's really the, we see the opportunity, the punctuated change, which is happening in the market today is about real time data access to real time. I mean, there are real time applications. Our customers are building around real time offers, um, realtime thread detection. I mean, just imagine, you know, one of our customers like B and P par bars, they have, they basically originate a loan while the customer is banking. So you are in an ATM machine and you swipe your card and you are asking for, you know, taking 50 euros out. And at that point they can actually originate a custom loan offer based on your existing balance you're existing request and your credit score in that moment. So that's a value moment for them and they actually saw 400% loan origination go up because of that, because nobody's gonna be thinking about a credit, uh, line of credit after they're done banking. So it's in that value moment and we allow basically our data platform allows you to have fast access to data and also process incoming streams. So not before they get stored, but as they're coming in. >>So if I'm a developer and cuon is definitely a conference for developer and I, I come to the booth and I hear <inaudible>, that's the end value. I, I hear what I can do with my application. I guess the question is, how do I get there? I mean, uh, if it's not a database, how do I make a call from a container to, from my microservice to Hazel cath? Like, do I think of this as a, uh, a CNI or, or C CSI? How do I access >>PA care? Yeah. So, so we, uh, you know, we are, our server is actually built in Java. So a lot of the application which get written on top of the data platform are basically accessing through Java APIs. Or as you have a.net shop, you can actually use.net API. So we are basically an API first platform and SQL is basically the polyglot way of accessing data, both streaming data, as well as it store data. So most of the application developers, a lot of it is run done in microservices, and they're doing these fast get inputs for data. So they, they have a key, they want to get to a customer, they give a customer ID. And the beauty is that, um, while they're processing the events, they can actually enrich it because you need contextual information as well. So going back to the ATM example, you know, at that event happened, somebody swiped the card and ask for 50 euros, and now you want more information like credit score information, all that needs to be combined in that, in that value moment. >>So we allow you to do those joins and, you know, the contextual information is very important. So you see a lot of streaming platform out there, which just do streaming, but if you're an application developer, like you asked, you have to basically do call out to a streaming platform to get, um, to do streaming analytics and then do another call to get the context of that. You know, what is the credit score for this customer? But whereas in our case, because the data platform supports both streaming as well as data at rest, you can do that in one call and, you know, you don't want to have the operational complexity to stand out. Two different scale out servers is, is, is, is humongous, right? I mean, you want to build your business application. So, >>So you are querying data streaming data and data rest yes. In the same query >>Yes. In the same query. And we are memory first. So what happens is that we store a lot of the hot data in memory. So we have a scale out Ram based server. So that's where you get the low latency from. In fact, last year we did a benchmark. We were able to process a billion events a second, uh, with 99% of the latency under 30 milliseconds. So that kind of processing and that kind of power is, and, and the most important thing is determinism. I mean, you know, there's a lot of, um, if you look at real time, what real time is, is about this predictable latency at scale, because ultimately your, your adhering to a business SLA is not about milliseconds or microsecond. It's what your business needs. If your business needs that you need to deny or, uh, approve a credit credit card transaction in 50 milliseconds, that's your business SLA, and you need that predictability for every transaction. >>So talk to us about how how's this packaged in consumed. Cause I'm hearing a, a bunch of server Ram I'm hearing numbers that we're trying to adapt away from at this conference. We don't wanna see the onlay. We just want to use it. >>Yeah. So, so we kind of take a bit that, that complexity of managing this scale out, um, uh, uh, cluster, which actually utilizes Rams from each server. And then, you know, if you, you can configure it so that the hard set of data is in Ram, but the data, which is, you know, not so hard can actually go into a tiered storage model. So we are memory first. So, but what you are doing is you're doing simple, it's an API. So you do basically a crud, right? You create records, you read them through SQL. So for you, it's, it's, it's kind of like how you access that database. And we also provide you, you know, real time is also a journey. I mean, a lot of customers, you know, you don't want to rip their existing system and deploy another kind of scale out platform. Right? So we, we see a lot of these use cases where they have a database and we can sit in between the database, a system of record and the application. So we are kind of in between there. So that's, that's the journey you can take to real time. >>How does Kubernetes, uh, containers and Kubernetes change the game for real time analytics? >>Yeah. So, uh, Kubernetes does change it because what's hap first of all, we service most of the operational workloads. So it's, it's more on the, a lot of our customers. We have most, most of the big banks credit card companies in financial services and retail. Those are the two big sectors for us. And first of all, you know, a lot of these operational workloads are moving to the cloud and with move to the cloud, they're actually taking their existing applications and, and moving to, you know, one of the providers and to kind of orchestrate this scale out platform, which does auto scaling, that's where the benefit comes from mm-hmm <affirmative>. And it also gives them the freedom of choice. So, you know, the Kubernetes is, you know, a standard which goes across cloud providers. So that gives them the benefit that they can actually take their application. And if they want, they can actually move it to a different, a different cloud provider because we take away the orchestration complexity, you know, in that abstraction layer. >>So what happens when I need to go really fast? I mean, I, I, I need, uh, I'm looking at bare metal and I'm looking at really scaling a, a, a homogeneous application in a single data center set of data centers. Is there a bare metal play here? >>Yes. There, there, there are some very, very, uh, like if you want microsecond latency, mm-hmm, <affirmative>, um, you know, we have customers who actually store two to four terabytes in Ram and, and they can actually stand up. Um, you know, again, it depends on what kind of deployment you want. You can either scale up or scale out, scaling up is expensive, you know, because those boxes are not cheap, but if you have a requirement like that, where there is sub millisecond or microphone latency requirement, you could actually store the entire data set. I mean, a lot of the operational data sets are under four terabytes. So it's not uncommon that you could actually take the entire operational transactional data set, actually move, move that to a pure Ram. But, uh, I think now we, we also see that these operational workloads are also, there's a need for analytics to be done on top as well. >>I mean, we, going back to the example I gave you, so this, this, uh, customer is not only doing stream crossing, they're also influencing a machine learning algorithm in that same, in the same kind of cycle in the life cycle. So they might have trained a machine learning or algorithm on a data lake somewhere, but once they're ready, they're actually influencing the ML algorithm in our kind of life cycle right there. So, you know, that that really brings analytics and transactions kind of together because after all transactions are where the real, you know, insights are. >>Yeah. I'm, I'm struggling a little bit with this, with these two different use cases where I have transactional basically a transactional database or transactional data platform alongside a analytics platform. Those are two, like they're two different things. I have a, you know, I, I have spinning rust for one, and then I have memory and, and MBME for another. Uh, and that requires tuning requires DBAs. It requires a lot of overhead, there seems to be some type of secret sauce going on here. >>Yeah. Yeah. So, I mean, you know, we, we basically say that if you are, if you have a business case where you want to make a decision, you know, you, the only chance to succeed is where you are not making a decision tomorrow based on today's data. Right? I mean, the only way to act on that data is today. So the act is a keyword here. We actually let you generate a realtime offer. We, we let you do credit card fraud detection. In that moment, the analytics is about knowing less about acting on it. Right? Most of our applications are machine critical. They're acting on real time. I think when you talk about like the data lakes there, there's actually a real time there as well, but it's about knowing, and we believe that the operational side is where, you know, that value moment is there, you know, what good is, is to know about something tomorrow, you know, if something wrong happened, I mean, it, yeah, so there's a latency squeeze there as well, but we are on, on more on the kind of transaction and operational side. >>I gotcha. Yeah. So help me understand, like integrations. A lot of the, the, when I think of transactions, I'm thinking of SAP, Oracle, where the process is done, or some legacy banking or not legacy or new modern banking app, how does the data get from one platform to a, to Hazel cast so I can make those >>Decisions? Yeah. So we have, uh, this, the streaming engine, we have has a whole bunch of connectors to a lot of data sources. So in fact, most of our use cases already have data sources underneath there, their databases there's KA connectors, you know, joining us because if you look at it, events is, are comprised of transactions. So something, a customer did, uh, a credit card swipe, right. And also events events could be machine or IOT. So it's really unique connectivity and data ingestion before you can process that. So we have, uh, a whole suite of connectors to kind of bring data in, in our platform. >>We've been talking a lot, these last couple of days about, uh, about the edge and about moving processing capability closer to the edge. How do you enable that? >>Yeah. So edge is actually very, very relevant because of what's happening is that, um, you know, if you, if you look at like a edge deployment use case, um, you know, we have a use case where data is being pushed from these different edge devices to cloud data warehouse. Right. But just imagine that you want to be filtering data at the, at, at where it is being originated from, and you wanna push only relevant data to, to maybe a central data lake where you might want to do, you know, train your machine learning models. Mm-hmm <affirmative> so that at the edge, we are actually able to process that data. So Hazel cast will allow you to actually write a data pipeline and do stream processing so that you might want to just push, you know, a part or a subset of data, which applies by the rules. Uh, so there's, there's a big, um, uh, I think edge is, you know, there's a lot of data being generated and you don't want like garbage and garbage out there's there's, there is there's filtration done at the edge. So that only the relevant data lands in a data, data lake or something like that. >>Well, Monash, we really appreciate you stopping by realtime data is an exciting area of coverage for the queue overall from Valencia Spain, I'm Keith Townsend, along with Paul Gillon, and you're watching the queue, the leader in high tech coverage.

>>The cube presents, Coon and cloud native con Europe, 22 brought to you by the cloud native computing foundation. >>Welcome to ity of Spain and cube con coup con cloud native con Europe 2022 is near the end of the day. That's okay. We, we, we have plenty of energy because we're bringing it. I'm Keith Townsend, along with my coho, Paul Gillon Paul, this has been an amazing day. Thus far. We've talked to some incredible folks. You got a chance to walk the show floor. Yeah. So I'm really excited to hear what's the vibe of the show floor, 7,500 people in Europe following the protocols, but getting stuff done. >>Well, first I have to say that I haven't traveled for two years. So getting out to a show by, by itself is, is an amazing experience, but a show like this with all of the energy and the crowd, she is enormously crowded at lunchtime today. It's hard to believe how many people have made it, made it all the way here out on the floor. The boots are crowded. The, the demonstrations are what you would expect at a show like this. Lots of code, lots of, lots of block diagrams, lots of architecture. I think the audience is eating it up. You know, when they're, they're on their laptops, they're coding on their laptops. And this is very much symbolic of the crowd that comes to a cubic con. And it's, it's a, just a delight to see them outta here. I so much fun. >>So speaking of lots of gold, we have Bome Toro co-founder of pet trade, but, you know, just saw, didn't realize this Isto becoming part of CNCF was the latest on infield. >>Yeah. Is still is, you know, it was always one of those service mesh projects, which was very widely adopted. And it's great to see that going into the cloud native computing foundation. And I think what happened with Kubernetes, like just became the defacto container orchestrator. I think similar thing is happening with Isto and service mesh. >>What, >>So I'm sorry, Keith, what's the process like of becoming adopted by and incubated by the CNCF? >>Yeah, I mean, it's pretty simple. It's an application process into the foundation where you say, you know what the project is about, how diverse is your contributor base, how many people are using it. And it goes through a review of with TC. It goes through a review of like all the users and contributors. And if you see a good base of deployments in production, if you see a diverse of contributors, then you can basically be part of the CNCF. And as you know, CNCF is very flexible on governance. Basically it's like, bring your own governance. And then the projects can basically seamlessly go in and, you know, get into incubation and gradually graduate >>Another project close and dear to you Envoy. Yes. Now I've always considered Envoy just as what it is. It's a, I've always used it as, as a load balancer type thing. So I've always considered it somewhat of a gateway proxy, but Envoy gateway was announced last week. Yes. >>So Envoy is basically won the data plane war of in cloud native workloads. Right. And, but, and this was over the last five years, Envoy was announced even way before Rio and it is used in various deployment models. You can use it as a front load balancer. You can use it as an Ingres in Kubernetes. You can use it as a side car and a service mesh like steel, and it's lightweight dynamically, programmable, very open with a white community. But what we looked at when we looked at the Envoy base, was it still, wasn't very approachable for application developers. Like when you still see like the nouns that it uses in terms of clusters and so on is not what an application developer was used to. And so Envoy gateway is really an effort to make Envoy even more stronger out of the box for an application developer to use it as an API gateway. >>Right? Because if you think about it, ultimately, you know, people de developers start deploying workloads onto their Kubernetes clusters. They need some functionality like an API gateway to expose their services and you wanna make it really, really easy and simple. Right? I often say like what, what engine X was to like static websites like Envoy gateway will be to like, you know, APIs and it's really few the community coming together. We are a big part, but also VMware and as well as end users, like in this case, fidelity who is investing heavily into Envoy and API gateway use cases, joining forces saying, let's do this in upstream Envoy. >>I'd like to go back to IIO because this is a major step in IIOS development. Where do you see SIO coming into the picture? And Kubernetes is already broadly accepted. Is IIO generally adopted as an after an after step to, to Kubernetes or are they increasingly being adopted together? >>Yeah. So usually it's adopted as a follow on step and the reason is primarily the learning curve, right. It's just get used to all the Kubernetes and, you know, it takes a while for people to understand the concepts, get applications going, and then, you know, studio was made to basically solve, you know, three big problems there. Right. Which is around observability traffic management and security. Right. So as people deploy more services, they figure out, okay, how do I connect them? How do I secure all the connections and how do I do more fine grain routing? I'm doing more frequent deployments with Kubernetes, but I would like to do Canary releases to make safer rollouts. Right. And those are the problems that Isto solves. And I don't really want to know the metrics of like, yes, it'll be, I it's good to know all the node level and CPO level metrics. >>But really what I want to know is how are my services performing? Where is the latency, right? Where is the error rate? And those are the things thatto gives out of the box. So that's like a very natural next step for people using Kubernetes. And, you know, Tetra was really formed as a company to enable enterprises, to adopt STO Envoy and service mission, their environment. Right? So we do everything from run an academy for like courses and certifications on Envoy and STO to a distribution, which is, you know, compliant with various bills and tooling as well as a whole platform on top of STO to make it usable and deployment in a large enterprise. >>So paint the end to end for me, for STO in Envoy. I know they can be used in similar fashions is like side cars, but how they work together to deliver value. >>Yeah. So if you step back from technology a little bit, right, and you like, sort of look at what customers are doing and facing, right. Really it is about, they have applications. They have some applications that new workloads going into Kubernetes and cloud native. They have a lot of legacy workloads, a lot of workloads on VMs and with different teams in different clouds or due to acquisitions. They're very heterogeneous right now. Our mission Tetrad's mission is power. The world's application traffic, but really the business value that we are going after is consistency of application operations. Right? And I'll tell you how powerful that is because the more places you can deploy Envoy into the more places you can deploy studio into, the more consistency you can get for the value pillars of observability, traffic management, and security. Right. And really, if you think about what is the journey for an enterprise to migrate from workloads into Kubernetes or from data centers into cloud, the challenges are around security and connectivity, right? Because if it's Kubernetes fabric, the same Kubernetes app and data center can be deployed exactly as is it in cloud. Right. Right. So why is it hard to migrate to cloud, right. The challenges come in the security and networking layer. >>Right. So let's talk about that with some granularity and you can maybe gimme some concrete examples, right? Because it, as I think about the hybrid infrastructure where I have VMs on premises, cloud, native stuff, running in the public cloud, or even cloud native next to VMs, right. I do security differently when I'm in the VM world. I say, you know what, this IP address, can't talk to this Oracle database server. Right. That's not how cloud native works. Right. I, I can't say if I have a cloud, if I have a cloud native app talking to a Oracle database, there's no IP address. Yeah. But how do I, how, how do I secure the communication between the two? Exactly. >>So I think you hit it straight on the head. So which is with things like Kubernetes, IP is no longer a really a valid noun where you can say, because things will auto scale either from Kubernetes or, you know, the cloud autoscales. So really the noun that is becoming now is service. So, and I could have many instances of it. They could go scale up and down. But what I'm saying is this service, which, you know, some app server, some application can talk to the article service. Hmm. And what we have done with the te trade service bridge, which is why we call our platform service bridge, because it's all about bridging all the services is whatever you're running on, the VM can be onboarded onto the mesh, like as if it were a ity service. Right. And then my policy around this service can talk to this service is same in Kubernetes is same for Kubernetes talking to VM it's same for VM to VM, both in terms of access control in terms of encryption. What we do is because it's the Envoy, proxy goes everywhere and the traffic is going through them. We actually take care of distributing, certs, encrypting, everything, and it becomes, and that is what leads to consistent application operations. And that's where the value is. >>We're seeing a lot of activity around observ observability right now, a lot of different tools, both open source and proprietary STO certainly part of the open telemetry project, I believe. Are you part of that? Yes. But the customers are still piecing together a lot of tools on their own. Right. Do you see a, a more coherent framework forming around observability? >>I think very much so. And there are layers of observability, right? So the thing is like, if we tell you there is latency between these two services at L seven layer, the first question is, is it the service? Is it the Envoy? Or is it the network? It sounds like a very simple question. It's actually not that easy to answer. And that is one of the questions we answer in like platforms like ours. Right. But even that is not the end. It, if it's neither of these three, it could be the node. It could be the hardware underneath. Right. And those, you realize like those are different observability tools that work on each layer. So I think there's a lot of work to be done, to enable end users to go from app, like from top to bottom to make, reduce what is called MTTR or meantime to, you know, resolution of an issue, where is the problem. >>But I think with tools like what is being built now, it is becoming easier, right? It is because one of the things we have to realize is with things like Kubernetes, we made the development of microservices easier. Right. And that's great. But as a result, what is happening is that more things are getting broken down. So there is more network in between. So that's harder. It gets to troubleshoot harder. It gets to secure everything harder. It gets to get visibility from everywhere. Right. So I often say like, actually, if you're going embarking down microservices journey, you actually are, you better have a platform like this. Otherwise, you know, you're, you're taking on operational cost. >>Wow. J's paradox. The more accessible we make something, the more it gets used, the more complex it is. That's been a theme here at KU con cloud native con Europe, 2022 from Licia Spain. I'm Keith Townsend, along with my host, Paul Gillman. And you're watching the queue, the leader in high tech coverage.

>>The cube presents, Coon and cloud native con Europe 22, brought to you by the cloud native computing foundation. >>Welcome to Valencia Spain in co con cloud native con Europe, 2022. I'm Keith Townsend with my cohos on Rico senior. Etti senior it analyst at gig home. Exactly 7,500 people I'm told en Rico. What's the flavor of the show so far, >>It's a fantastic mood. I mean, I found a lot of people wanting to track talk about what they're doing with Kubernetes, sharing their, you know, stories, some word stories that meet tough. And you know, this is where you learn actually, because we had a lot of zoom calls, webinar and stuff, but it is when you talk a video, oh, I did it this way and it didn't work out very well. So, and, and you start a conversation like this that is really different from learning from zoom. When, you know, everybody talks about things that working well, they did it, right. No, it's here that you learn from other experiences. >>So we're talking to amazing people the whole week, talking about those experiences here on the queue, fresh on the queue for the first time, Chris Vos, senior software engineer at Microsoft Xbox, Chris, welcome to the queue. >>Thank you so much for having >>Me. So first off, give us a high level picture of the environment that you're running at Microsoft. >>Yeah. So, you know, we've got 20, well probably close to 30 clusters at this point around the globe, you know, 700 to a thousand pods per cluster, roughly. So about 22,000 pods total. So yeah, it's pretty pretty sizable footprint and yeah. So we've been running on Kubernetes since 2018 and well actually might be 2017, but anyways, so yeah, that, that's kind of our, our footprint. >>Yeah. So all of that, let's talk about the basics, which is security across multiple I'm assuming containers, work, microservices, et cetera. Why did you and the team settle on link or do >>Yeah, so previously we had our own kind of solution for managing TLS certs and things like that. And we found it to be pretty painful pretty quickly. And so we knew, you know, we wanted something that was a little bit more abstracted away from the developers and, and things like that that allowed us to move quickly. And so we began investigating, you know, solutions to that. And a few of our colleagues went to Cuban in San Diego in 2019 cloud native con as well. And basically they just, you know, sped it all up. And actually funny enough, my, my old manager was one of the people who was there and he went to the link D booth and they had a thing going that was like, Hey, get set up with MTLS in five minutes. And he was like, this is something we want to do, why not check this out? And he was able to do it. And so that, that put it on our radar. And so yeah, we investigated several others and Leer D just perfectly fit exactly what we needed. >>So, so in general, we are talking about, you know, security at scale. So how you manage security to scale and also flexibility, right. But you know, what is the you, this there, you told us about the five minutes to start using there, but you know, again, we are talking about word stories. We talk about, you know, all these. So what, what, what kind of challenges you found at the beginning when you start adopting this technology? >>So the biggest ones were around getting up and running with like a new service, especially in the beginning, right. We were, you know, adding a new service almost every day. It felt like. And so, you know, basically it took someone going through a whole bunch of different repos, getting approvals from everyone to get the SEARCHs minted, all that fun stuff, getting them put into the right environments and in the right clusters to make sure that, you know, everybody is talking appropriately. And just the amount of work that, that took alone was just a huge headache and a huge barrier to entry for us to, you know, quickly move up the number of services we have. So, >>So I'm, I'm trying to wrap my head around the scale of the challenge. When I think about certification or certificate management, I have to do it on a small scale and the, the, every now and again, when a certificate expires, it is just a troubleshooting pain. Yes. So as I think about that, it costs, it's not just certificates across 22,000 pods or it's certificates across 22,000 pods in multiple applications. How were you doing that before link D like, what was the, what and what were the pain points? Like? What happens when a certificate either fails or expired up not, not updated? >>So, I mean, to be completely honest, the biggest thing is we're just unable to make the calls, you know, out or, or in, based on yeah. What is failing basically. But, you know, we saw essentially an uptick in failures around a certain service and pretty quickly, I pretty quickly, we got used to the fact that it was like, oh, it's probably a cert expiration issue. And so we tried, you know, a few things in order to make that a little bit more automated and things like that, but we never came to a solution that like didn't require every engineer on the team to know essentially quite a bit about this, just to get into it, which was a huge issue. >>So talk about day two after you've deployed link D how did this alleviate software engineers and what was like the, the benefits of now having this automated way of managing >>Certs? So the biggest thing is like, there is no touch from developers, everyone on our team. Well, I mean, there are a lot of people who are familiar with security and certs and all of that stuff, but no one has to know it. Like it's not a requirement. Like for instance, I knew nothing about it when I joined the team. And even when I was setting up our newer clusters, I knew very little about it. And I was still able to really quickly set up blinker D, which was really nice. And, and it's been, you know, essentially we've been able to just kind of set it and not think about it too much. Obviously, you know, there are parts of it that you have to think about. We monitor it and all that fun stuff, but, but yeah, it's been pretty painless almost day one. It took a lot, a long time to trust it for developers. You know, anytime there was a failure, it's like, oh, could this be link or D you know, but after a while, like now we don't have that immediate assumption because people have built up that trust, but >>Also you have this massive infrastructure, I mean, 30 cluster. So I guess that it's quite different to manage a single cluster and 30. So what are the, you know, consideration that you have to do to install this software on, you know, 30 different cluster manage different, you know, versions probably etcetera, etcetera, et cetera. >>So, I mean, you know, the, the, as far as like, I guess, just to clarify, are you asking specifically with Linky or are you just asking in more in general? Well, >>I mean, you, you can take the, the question in the, in two ways, so, okay. Yeah. Yes. Link in particular, but the 30 cluster also quite interesting. >>Yeah. So, I mean, you know, more generally, you know, how we manage our clusters and things like that. We have, you know, a CLI tool that we use in order to like, change context very quickly and switch and communicate with whatever cluster we're trying to connect to and, you know, are we debugging or getting logs, whatever. And then, you know, with link D it's nice because again, you know, we, we, aren't having to worry about like, oh, how is this cert being inserted in the right node or, or not the right node, but in the right cluster or things like that. Whereas with link D we don't, we don't really have that concern when we spin up our, our clusters, essentially we get the root certificate and, and everything like that packaged up, passed along to link D on installation. And then essentially there's not much we have to do after that. >>So talk to me about your upcoming coming section here at Q con what's the, what's the high level talking points? Like what, what will attendees learn? >>Yeah. So it's, it's a journey. Those are the sorts of talks that I find useful. Having not been, you know, I, I'm not a deep Kubernetes expert from, you know, decades or whatever of experience, but I think >>Nobody is >>Also true. That's another story. That's a, that's, that's a job posting decades of requirements for >>Of course. Yeah. But so, you know, it, it's a journey it's really just like, Hey, what made us decide on a service mesh in the first place? What made us choose link D and then what are the ways in which, you know, we, we use link D so what are those, you know, we use some of the extra plugins and things like that. And then finally, a little bit about more, what we're gonna do in the future. >>Let's talk about not just necessarily the future as in two or three days from now, or two or three years from now. Well, the future after you immediately solve the, the low level problems with link D what were some of the, the surprises, because link D in service me in general has have side benefits. Do you experience any of those side benefits as well? >>Yeah, it's funny, you know, writing the, the blog post, you know, I hadn't really looked at a lot of the data in years on, you know, when we did our investigations and things like that. And we had seen that we like had very low latency and low CPU utilization and things like that. And looking at some of that, I found that we were actually saving time off of requests. And I couldn't really think of why that was, and I was talking with someone else and the biggest, unfortunately, all that data's gone now, like the source data. So I can't go back and verify this, but it, it makes sense, you know, there's the availability zone routing that linker D supports. And so I think that's actually doing it where, you know, essentially if a node is closer to another node, it's essentially, you know, routing to those ones. So when one service is talking to another service and maybe on they're on the same node, you know, it, it short circuits that, and allows us to gain some, some time there. It's not huge, but it adds up after, you know, 10, 20 calls down the line. Right. >>In general. So you are saying that it's smooth operations in, in ATS, very, you know, simplifying your life. >>And again, we didn't have to really do anything for that. It, it, it handled that for it was there. Yeah. Yep. Yeah, exactly. >>So we know one thing when I do it on my laptop, it works fine when I do it with across 22,000 pods, that's a different experience. What were some of the lessons learned coming out of KU con 2018 in San Diego was there? I wish I would've ran to the microphone folks, but what were some of the hard lessons learned scaling link D across the 22,000 nodes? >>So, you know, the, the first one, and this seems pretty obvious, but was just not something I knew about was the high availability mode of link D so obviously makes sense. You would want that in a, you know, a large scale environment. So like, that's one of the big lessons that like, we didn't ride away. No. Like one of the mistakes we made in, in one of our pre-production clusters was not turning that on. And we were kind of surprised. We were like, whoa, like all of these pods are spinning up, but they're having issues like actually getting injected and things like that. And we found, oh, okay. Yeah, you need to actually give it some, some more resources, but it's still very lightweight considering, you know, they have high availability mode, but it's just a few instances still. >>So from, even from a, you know, binary perspective and running link D how much overhead is it? >>That is a great question. So I don't remember off the top of my head, the numbers, but it's very lightweight. We, we evaluated a few different service missions and it was the lightest weight that we encountered at that point. >>And then from a resource perspective, is it a team of link D people? Is it a couple of people, like how >>To be completely honest for a long time, it was one person, Abraham who actually is the person who proposed this talk. He couldn't make it to Valencia, but he essentially did probably 95% of the work to get a into production. And then this was before we even had a team dedicated to our infrastructure. And so we have, now we have a team dedicated, we're all kind of Linky folks, if not Linky experts, we at least can troubleshoot basically. And things like that. So it's, I think a group of six people on our team, and then, you know, various people who've had experience with it >>On other teams, but I'm not dedicated just to that. >>I mean, >>No one is dedicated just to it. No, it's pretty like pretty light touch once it's, once it's up and running, it took a very long time for us to really understand it and, and to, you know, get like, not getting started, but like getting to where we really felt comfortable letting it go in production. But once it was there, like, it is very, very light touch. >>Well, I really appreciate you stopping by Chris. It's been an amazing conversation to hear how Microsoft is using a open source project. Exactly. At scale. It's just a few years ago, when you would've heard the concept of Microsoft and open source together and like, oh, that's just, you know, but >>They have changed a lot in the last few years now, there are huge contributors. And, you know, if you go to Azure, it's full of open source stuff, every >>So, yeah. Wow. The Cuban 2022, how the world has changed in so many ways from Licia Spain, I'm Keith Townsend, along with a Rico senior, you're watching the, the leader in high tech coverage.

>>The cube presents, Coon and cloud native con Europe 22 brought to you by the cloud native computing foundation. >>Welcome to Licia Spain in Coon cloud native con Europe, 2022. I'm your host, Keith Townson, along with Paul Gillon senior editor, enterprise architecture for Silicon angle. Paul, we're gonna talk to some amazing people this week. Coon, what the energy here, what, what, what would you say about >>It? I'd say it's reminiscent of, of early year, early stage conferences I've seen with other technologies. There is a lot of startup activity. Here's a lot of money in the market, despite the selloff in the stock market lately, a lot of anticipation that there are, there could be big exits. There could be big things ahead for these companies. You don't see that when you go to the big established conferences, you see just anticipation here that I don't think you see you you'll see maybe in a couple of years. So it's fun to be here right now. I'm sure it'll be a very different experience in two or three years. >>So welcome to our guest Q alum. BAAM Tobar the founder and CEO of Upbound. Welcome back. >>Thank you. Yeah, pleasure to be on, on the show again. >>So Paul, tell us the we're in this phase of migrations and, and moving to cloud native stacks. Are we another re-platforming generation? I mean, we've done, the enterprise has done this, you know, time and time again, and whether it's from Java to.net or net to Java or from bare metal to VMs, but are we in another age of replatforming? >>You know, it's interesting. Every company has now become a tech company and every tech company needs to build a very model, you know, modern digital platform for them to actually run their business. And if they don't do that, then they'll probably be out of business. And it is interesting to think about how companies are platforming and replatforming. Like, you know, as you said, just a, a few years back, you know, we were on people using cloud Foundry or using Heroku, you hear Heroku a lot, or, you know, now it's cloud native and Kubernetes and, and it, it begs the question, you know, is this the end that the tr point is this, you know, do we have a, you know, what, what makes us sure that this is the, you know, the last platform or the future proof platform that, that people are building, >>There's never a last platform, right? There's always something around the core. The question is, is Kubernetes Linux, or is it windows? >>That, that's a good question. It's more like more like Linux. I think, you know, the, you know, you've heard this before, but people talk about Kubernetes as a platform off platforms, you can use it to build other platforms. And if you know what you're doing, you can probably put, assemble a set of pieces around it and arrive at something that looks and can work for your business. But it requires a ton of talent. It requires a lot of people that actually can act, you know, know how to put the stick together to, to work for your business. It is, there's not a lot of guidance. I, we were, I think we were chatting earlier about the CSCF landscape and, and how there all these different projects and companies around it. But, but they don't come together in meaningful ways that you have, they act the enterprise itself has to figure out how to bring them together. Right. And that's the combination of what they do there organically or not is their platform. Right. And that changes. It can change over time. >>Do you think they really do. They really want to put these things together? I mean, there's, that's not what enterprise is like to do. They want to find someone who's gonna come in and turnkey do it all for >>Them. Yeah. And, and if there were, this is the, this is the things like EV every week now you hear about another platform that says, this is the new Heroku. This is the new cloud Foundry. This replaces every, you know, some vendor has, and you can see them all around here. You know, companies that are basically selling platform solutions that do put 'em together. And the problem with it is that you typically outgrow these, like you are, it might solve 80% of the use cases you care about, but the other 20% are not represented. And so you end up outgrowing the platform itself, right? And the, the choice has been mostly around, you know, do you buy something off the shelf that solves 80% of your use cases? Or do you build something on your own? And then you have to spend all your resources actually going through and building all of it. And that's been the dilemma, you know, people who talk about this as a platform dilemma, but it's been, it's been the way for a long time. Like you, every, we go through this cycle every few years and, you know, people end up essentially oscillating between buying something off the, you know, that's off the shelf or building it, building it themselves. >>So what's the payoff. If I'm a CIO and I'm looking at the landscape, I don't need to understand, you know, I don't know what a pod is to know that looking at 200 plus projects in co and at, in cloud native foundation and the bevy of, of co-located projects and, and conferences before the, even the start of this, what's the payoff >>Increasing the pace of innovation. I mean, that literally is when we talk to customers, they all say roughly the same thing. They want something that works for their business. They want something that helps them take their, you know, line of business applications to production in a much quicker way, lets them innovate, lets them create higher engineers that can, don't have to understand everything about every system, but can actually specialize and focus on the, the parts that they sh they care about. But it's all in the context of, you know, people want to be able to innovate at a very high pace. Otherwise they get disrupted. >>So I was at the, you know, my favorite part of coan in general is the hallway track and talking to people on the ground, doing cool things. I was talking to a engineer who was able to take their Java, stack their, their.net stack and start to create APIs between and break 'em into microservices. Now teams are working across from one another realizing that, that, that promise of innovation, but that was the end point. They they're there. Yeah. As companies are thinking about replatforming where like, where do we start? I mean, I'm looking at the, the C CNCF, the, the map and it's 200 plus projects. Where, where do I start? >>You typically today start with Kubernetes. And, and a lot of companies have now deployed Kubernetes to production as a container orchestrator, whether they're going through a vendor or not. But now you're seeing all the things around it, whether it's C I C D or GI ops that they're looking at, you know, or they're starting to build consoles around, you know, their, their platforms or looking at managing more than just containers. And that's a theme that, you know, we're seeing a lot now, people want, people want to actually bring this modern stack to manage, not just container workloads, but start looking at databases and cloud workloads and everything else that they're doing around it. Honestly, everybody's trying to do the same thing. They're trying to arrive at a single point of control, a single, you know, a platform that can do it all that they can centralize policies, centralized controls to compliance governance, cost controls, and then expose a self-service experience to the developers. Like they're all trying to build what we probably call an internal cloud platform. They don't know, they talk about it in different ways, but almost everyone is trying to build some internal platform that sits on top of, on premises. And on top of cloud, depending on their scenarios, >>You make an interesting point, which is that everyone here is to some extent trying to do the same thing. And there's fine points of granularity between now they're approaching it as you walk around this floor. Do you understand what all of these companies are doing? >>I'm not sure I understand all of them, but I, I do. I do recognize a lot of them. Yes. >>And in terms of your approach, you, you use the term control plane. What is distinctive about your approach? >>Very good question. So, you know, we, we end, Upbound take a, we we're trying to solve this problem as well. We're trying to help people build their own platforms, but let me, let me, you know, there's a lot to it. So let me actually step back and, and talk about the architecture of this. But if you were to look at any cloud platform, let's take the largest one. AWS, if you peek behind the scenes at AWS, you know, it's basically a set of independent services, EC two S three databases, et cetera, that are, you know, essentially working on different parts of, you know, like offer completely different pricing, different services, et cetera. They come together because they all integrate into a control plan. >>It's the thing that serves an API. It's the thing that gives it all a common feel. It's where you do access control. It's where you do billing metering, cost control policy, et cetera. Right? And so our realization was if the enterprises are platforming and replatforming, why shouldn't they build their platform in the same way that the cloud vendors build theirs? And so we started this project almost four years ago, now three and a half years called cross plain, which is a, essentially an open source control plane that can become the integration point for all services. And essentially gives you a universal control plane for cloud. >>So you mentioned the idea of if orchestrating or managing stuff other than containers, as I think about companies that built amazing platforms, enterprise companies, building amazing applications on AWS 10 years ago, and they're adopting the AWS control plane. And now I'm looking at Kubernetes is Kubernetes the way to multi-cloud to be able to control those discrete services in a AWS or Google cloud Azure or Oracle cloud, is that true? >>We kind have the tease it, the parts. So there are really two parts to Kubernetes and everybody thinks of Kubernetes as a container orchestration platform. Right? And you know, there is a sense that people say, if I was to run Kubernetes on everywhere and can build everything on top of containers, that I get some kind of portability across clouds, right. That I can put things in containers. And then they magically run, you know, in different environments. In reality, what we've seen is not everything fits in containers. It's not gonna be the world is not gonna look like containers on the bottom. Everything else is on top. Instead, what we're gonna see is essentially a set of services that people are using across the different vendors. So if you look at like, you could be at AWS shop primarily, but I bet you're using confluent or elastic or data breaks or snowflake or Mongo or other services. >>I bet you're using things that are on premises, right? And so when you look at that and you say to build my platform as an enterprise, I have to consume services from multiple vendors. Even if it's just one major cloud vendor, but I'm consuming services from others. How do I bring them together in meaningful ways so that I can, you know, build my platform on top of the collection of them and offer something that my developers can consume. And self-service on. That's not a, that's not just containers. What's interesting though, is if you look at Kubernetes and, you know, look inside it, Kubernetes built a control plane. That's actually quite useful and applicable outside of container scenarios. So this whole notion of CRDs and controllers, if you've heard that term, the ability, you know, like there are two parts to Kubernetes, there is a control plane, and then there's the container container workloads. >>And the control plane is generic. It could be used literally across, you know, you can use it to manage things that are completely outside of container workloads. And that's what we did with cross mind. We took the control plane of Kubernetes and then built bindings providers that connected to AWS, to Google, to Azure, to digital ocean, to all these different environments. So you can bring the way of managing, you know, the style of managing that Kubernetes invented to more than just containers. You can now manage cloud services, using the same approach that you are now using with Kubernetes and using the entire ecosystem of tooling around it. >>Enterprise has been under pressure to replatform for a long time. It was first go to Unix then to Linux and virtualize then to move to the cloud. Now, Kubernetes, do you think that this is the stack that enterprises can finally commit to? >>I think if you take the orientation of your deploying a control plane within your enterprise, that is extensible, that enables you to actually connect it to all the things that are under your domain, that that actually can be a Futureproof way of doing a platform. And, you know, if you look at the largest cloud platforms, AWS has been around for at least 15 years now, and they really haven't changed the architecture of AWS significantly. It's still a control plane, a set of control planes that are managing services. >>It's a legacy >>They've added a lot of services. They've have a ton of diversity. They've added so many different things, but the architecture is still a hub and spoke that they've built, right? And if the enterprise can take the same orientation, put a control plane, let it manage all the things that are, you know, about today, arrive at a single point of control, have a single point where you can enforce policy compliance, cost controls, et cetera, and then expose a self-service experience to your developers that actually can become future proof. >>So we've heard this promise before the cloud of clouds, basically, yes, the, the, to be able to manage everything, what we find is the devils in the details. The being able to say, you know, a load balancer issuing a, a command to, to deploy a load balancer in AWS is different than it is in Azure, which is different than it is in GCP. How do, how do enterprises know that we can talk to a single control plane to do that? I mean, that just seems extremely difficult to manage. >>Oh yeah. That the approach is not, you're not trying to create a lowest common denominator between clouds. That's a really, really hard problem. And in fact, you get relegated to just using this, you know, really shallow features of each, if you're, if you're gonna do that, like your, your example of load balancers, load balances look completely different between between cloud vendors, the approach that we kind of advocate for is that you shouldn't think of them as you shouldn't try to unify them in a way that makes them, you know, there's a, there's a global abstraction that says, oh, there's a load balancer. And it somehow magically works across the different cloud vendors. I think that's a really, really hard thing to say, to do as you pointed out. However, if you bring them all under a same control plane, as different as they are, you're able to now apply policies. You're able to set cost controls. You're able to expose a self-service experience on top of them, even, even if they are very different. And that's, that's something that I think is, you know, been hard to do in the past. >>So BAAM, we'll love to dig deeper into this in future segments. And I'm gonna take a look at the, the, the product and project and see where you folks land in this conversation from Valencia Spain, I'm Keith towns, along with Paul Gillon and you're watching the leader in high tech coverage.