devopsy.kinsta.cloud

Category: Platform Engineering

  • Massdriver Adds Cloud Cost Controls to Internal Developer Platform

    Massdriver Adds Cloud Cost Controls to Internal Developer Platform

    Massdriver has made available tools for tracking cloud costs and generating a cloud infrastructure bill of materials (Cloud IBOM) to internal developer platforms (IDPs) as part of an ongoing effort to streamline platform engineering workflows.

    The Cloud IBOM makes it possible, with a few clicks, to map hybrid cloud resources such as databases, machine learning pipelines and serverless computing frameworks.

    Massdriver CEO Cory O’Daniel said collectively, these tools reduce expenses by preventing misconfigurations that result in unexpected costs. Rather than solely providing a summary of costs incurred, the tools provided by Massdriver surface how much cloud services are going to cost at the time the developer is invoking them, he noted.

    In the absence of that context, developers will nearly always overprovision cloud resources to ensure maximum availability regardless of cost, says O’Daniel. The overall goal is to help organizations reduce the total cost of IT by providing developers with insights into costs in real-time, he added.

    Earlier this year, the company launched an IDP that comes with platform engineering tools that, for example, make it possible for DevOps teams to build a catalog of infrastructure components that developers can access within the context of guardrails they define. The platform also includes observability and visualization tools that make it simpler to track metrics and monitor the usage of cloud resources.

    Massdriver is making a case for an IDP that provides built-in tools and workflows that enable organizations to embrace platform engineering as a methodology for managing DevOps workflows at scale. The goal is to reduce the level of expertise required to build and deploy applications in cloud computing environments, said O’Daniel. One of the primary reasons there are not more applications running in the cloud today is that these environments are still too complex to successfully manage, he added. An IDP abstracts away that complexity within a set of workflows that have been vetted by a DevOps team, he added.

    There are, of course, multiple approaches to building an IDP, but rival approaches require too much effort to set up and maintain, said O’Daniel. A proprietary platform provides a more turnkey approach that doesn’t require DevOps teams to either build their own or customize an open source platform, he added.

    It’s not clear at what pace organizations are embracing platform engineering, but there is a clear need to strike a balance between delivering IT services managed by a centralized team and the desire a developer might have to embrace new tooling whenever they see fit. Today, too much responsibility for provisioning IT environments has been pushed left toward developers who now have less time than ever to write code.

    There is, naturally, no guarantee that reducing the cognitive load for developers will increase productivity. Building applications requires streaks of inspiration, but, in theory, an IDP should provide more time for inspiration to strike. DevOps teams, as part of that effort, should be continuously working toward eliminating any bottlenecks that have emerged in their DevOps workflows.

  • Platform Engineering is a ‘Golden Path’ to FinOps

    Platform Engineering is a ‘Golden Path’ to FinOps

    Cloud costs. This simple reality has given rise to all manner of toolsets now being focused on modern IT stacks to shore up resources, reduce waste, optimize identified efficiencies and to monitor system wellbeing at the highest, widest and broadest level.

    Across cloud computing landscapes now being reinvented for generative AI functions, the rise of machine learning operations (MLOps) practices is aiming to bring software engineering in line with operations engineering and—perhaps above all—cost engineering.

    Before MLOps, There Was FinOps

    But before we tread too deep into MLOps territory, perhaps we should remind ourselves that FinOps (operations aligned to consider the financial impact of all systems architecture and software engineering decisions) is really the foundational practice that should oversee all matters in this field.

    CloudBolt is one organization that’s been very vocal in its desire to help businesses optimize, automate and control hybrid cloud and multi-cloud environments by providing cloud financial management, automation, orchestration and governance solutions for global enterprises. The firm runs several industry reports around various aspects of multi-cloud complexity. 

    Institutionalized Platform Engineering

    CloudBolt’s Kyle Campos, chief product & technology officer (CPTO), suggests that as businesses continue to sharpen their focus on efficiency–scrutinizing every expenditure and tool–by December 2024, most forward-thinking CIOs will ‘institutionalize’ platform engineering and establish corresponding teams. These teams will not only manage technology assets but also prioritize them to accelerate business value. This strategic shift aligns with the broader industry trend of optimizing technology stacks for agility and efficiency, offering a multi-dimensional approach to business.

    “FinOps silos that drive friction and [the presence of] unrealized optimization promises will reach a breakthrough as the conversation and solutions shift from ‘motivation’ to ‘facilitation’ in the coming year,” said Campos. “With platform engineering fully adopted as a technology approach by the majority of forward-thinking IT organizations by the end of next year, FinOps practices will become a native part of the journey to ‘golden paths,’ on par with security and observability, as the trifecta of defaults in the delivery process.”

    The Ultimate Performance Metric

    After decades of profligate spending on hardware, software and services, Campos said he thinks that 2024 will become the year that the cost to run an application becomes the ultimate performance metric. Why does he make this assertion? Because the traditional metrics that are focused on commodities (CPU, memory, disk, network) will actually become less important, he said. 

    As digitally transformed organizations continue their advance to the cloud, the cost-of-goods-sold will get linked intrinsically with operational and services measured at a finer-grained level; looking at specific tools, services and algorithms for cost savings.

    “As organizations grapple with intricate financial challenges in 2024, consumers will increasingly demand flexibility, compelling cloud providers to offer more consumer-centric pricing and services,” said Campos. “The FinOps FOCUS initiative instituted this year is just the beginning. The collective voice of the user community will continue to be a game-changer in leveling the playing field between cloud providers and consumers.”

    AI/ML Disrupts Linear FinOps

    Campos concluded by saying that currently, there is a direct correlation between user complexity/friction and capabilities/cost granularity in the FinOps solution ecosystem. 

    “Increases in the latter make the former that much more complex,” he argued. “But advances in AI/ML will continue to disrupt the status quo, lowering the barrier and time to value for users. What used to take hours of custom configuration, trial and error, will be a low-friction conversation. Additionally, AI/ML will facilitate unit cost solution inversion such that unit cost is provided to the user, not from the user.”

  • Survey Surfaces Significant Platform Engineering Gains

    A survey of 100 software engineers working at organizations in the U.S. and Western Europe published today found nearly all (99%) have embraced platform engineering to some degree as a methodology to manage DevOps workflows at scale, with more than half (53%) having done so in the last year.

    Conducted by Port, a provider of a proprietary internal developer portal (IDP) platform, the survey also found 83% of respondents have also incorporated GitOps workflows into their platform engineering practices.

    The survey also found 85% are working for organizations that have either started deploying IDPs or plan to do so in the coming year. However, what constitutes an IDP is not exactly clear, with more than a third (35%) that have implemented one reporting they are relying on spreadsheets to manage their IDP. A little over half (53%) of respondents, in contrast, are using an IDP to provide developers with self-service capabilities for setting up environments to write code that either was custom built, is based on open source Backstage software originally developed by Spotify or a commercial IDP platform.

    Among the 85% of respondents using or planning to use an IDP, the main measure of success is to improve developer productivity (56%), followed by reduced time to deployment (25%). Despite those initiatives, only slightly more than a third (34%) said IDPs are helping DevOps teams enforce software engineering standards.

    Roni Floman, chief marketing officer for Port, said overall, the survey suggests developers are wasting a lot of time on tasks that have little to do with writing code. For example, the survey finds that prior to embracing platform engineering, developers spent three to four hours a day on non-core activities, resulting in weeks being required to eventually deploy software in a production environment.

    The biggest challenge organizations face when embracing platform engineering is convincing developers that a centralized team has their best interests at heart. Many application development teams embraced DevOps as a best practice in the first place to escape the tyranny of a centralized IT team. The issue is that, as a result, many of them now find themselves managing tasks that have little to do with writing code. Platform engineering seeks to strike a balance between giving developers the ability to adopt new tools when they see fit and the benefits of having a dedicated platform engineering team that automates processes on their behalf.

    Unless platform engineering teams find a way to get developers to buy into the effort, however, it’s unlikely they will succeed, noted Floman.

    Each organization will need to determine for itself what level of platform engineering makes sense for them to implement, given their unique culture. In most cases, a platform engineering initiative will start small before increasing in size and scope as momentum is gained. In the meantime, the most important thing any platform engineering team clearly needs to do in the short term is engage developers. After all, the best way to get support for any change to a DevOps workflow is, as always, to convince developers it was their idea in the first place.

  • KubeCon 2023: CTO.ai’s Developer Control Plane

    KubeCon 2023: CTO.ai’s Developer Control Plane

    Speaker 1: This is Techstrong TV.

    Alan Shimel: Hey, everyone, we’re back. We’re here in Chicago at KubeKon. We’re wrapping up our day two coverage, our last guest for day two. We’ll be back tomorrow, though. But let me introduce you to Kyle Campbell, right?

    Kyle Campbell: That’s right.

    Alan Shimel: Kyle is the founder of cto.ai and we’re going to find out about cto.ai and a little bit about what they’re doing here at KubeKon. But before we do that, Kyle, first of all, welcome.

    Kyle Campbell: Thank you.

    Alan Shimel: Second of all, let’s hear a little bit about Kyle.

    Kyle Campbell: Yeah, thanks.

    Alan Shimel: Tell us your kind of journey.

    Kyle Campbell: Yeah, well, first of all, great to meet you in person. I’ve talked in the past. Yeah, so my journey, I’ve told this story before, a little unconventional. I grew up in Nova Scotia in Canada, a small town. Been on the internet since the age of eight and just had no interest in the formal past. So I’ve been building software from the early days of the .com boom. I may not look at it, but I got some of the scar tissue. But I was self-taught software engineer, so open source was the key to my success and good developer tools.

    Alan Shimel: Sure.

    Kyle Campbell: And I came up through the cloud and open source era and then started founding developer platforms in 2014. The first company I built was a developer platform, the real estate space. Zillow acquired it in about eight months, which was interesting.

    Alan Shimel: Very.

    Kyle Campbell: And then I bootstrapped a DevOps agency quite successfully and started to find that there was a lot of opportunity for next generation developer platforms, which led me to cto.ai.

    Alan Shimel: Excellent, man. What a great story too. You still up in Nova Scotia?

    Kyle Campbell: I’m not. I moved to the other side of the country. I live in British Columbia now.

    Alan Shimel: Good for you.

    Kyle Campbell: Love the outdoors. Spend a lot of time with my son camping, fishing, and trying to get outdoors and just enjoy the beautiful-

    Alan Shimel: Loving it. Yeah, no, it’s beautiful. I mean, not that Nova Scotia’s not beautiful. It’s brutal in the winter, but it’s a beautiful country, part of the country.

    Let’s talk cto.ai now. So look, I’ve founded multiple companies myself. Every founder I’ve ever interviewed or spoken with in 30 years, they don’t just say wake up and say, “Oh, I feel like founding a company today.” There’s kind of like Richard Dreyfuss in Close Encounters of the Third Kind, right? There’s something driving you like, “I got to do this. This needs to get done.” What was driving you that needed to get done here with cto.ai?

    Kyle Campbell: Yeah. I mean, as I described my past, a lot of my journey was self-taught and stand on the shoulders of giants. And really important thing for me was developer experience and ease of use and tooling early on in my career because that enabled me to really drive my competencies as a developer and keep up with these people that had computer science degrees and master’s and all these things, right?

    Alan Shimel: Certainly.

    Kyle Campbell: So when I thought about that and I also thought about where the future’s going and my passion for platform engineering, it became pretty obvious to me that what was missing in the market was a set of tools that were designed to embrace the future of developer experience and how AI can impact that from code to cloud.

    So in 2016 or so, I started experimenting with the idea, and through 2020, I decided to formally launch cto.ai as a developer control plane is what we call it. The way to think about it is it’s a modern CI/CD platform where teams can compose their workflow across build, deployment, test, and preview. And as they work with these tools, they can interact with them in the CLI Slack, GitHub, talk to these workflows through sort of a prompt based model. And we collect telemetry data that allows them to then measure that against DORA metrics, which is-

    Alan Shimel: It’s standard.

    Kyle Campbell: … yeah, it’s a standard and I think, frankly, an empirical way to measure the developer experience. We don’t try to measure developer productivity. We think that’s the wrong question to ask. The question is how do I measure the experience the developer has in the same way that I would measure the experience my users have with my product? And if what we’re doing is building platforms to enable developer experience, we need a natively integrated way to measure that. And we also think that that measurement is a way to pave a future between how the developers experience those tools and how AI can support the developer experience and enhance developers with, frankly, superpowers over time.

    Alan Shimel: So I was recently at a couple of user conferences, big DevOps companies, and it was interesting. Three conferences all use the same metric, which is that developers only spend about 30% of their time developing.

    Kyle Campbell: State of DevOps Report 2018, I think?

    Alan Shimel: But it was in there and it’s been kind of verified in several others. What do you think about that? Is it good thing, bad thing, something to be proud of, something we should be working on? What’s the deal?

    Kyle Campbell: Yeah. Well, I think a pretty practical point of view in that as a software engineer, my goal is to release features that customers love and drive business value. And if I can do that at a higher velocity while maintaining quality, I mean, I think that that is a way that I, as an individual, can contribute to the success of the business and the team.

    But I think what often happens is we get really obsessed about the individual developer. And I think any developer who looks at the idea that they only spend 30% of their time adding value isn’t going to like that very much. And I think we need to reframe the conversation away from developer productivity towards developer enablement and look at the tooling and the process that the developer experience promotes and how developers go from code to cloud and ask ourselves as a business leader, as a CTO who we work with a lot, is the tooling and the workflow that we’re supporting our team with and that developer experience, what they’re experiencing, is that driving results?

    And I think DORA metrics is an empirical way to measure that, obviously, through anecdotes and surveys, but what we’ve really innovated on is creating a vertical integration with the tool chain that allows you to measure that in real time and then iterate on the tools quickly. And some of the teams can really own that themselves. And what the businesses should be doing is zooming out and asking themselves, “Yeah, how do we maximize the amount of time developers spend without individualizing that consideration?” There’s an innerloop and there’s an outerloop. And what DORA is really good for is measuring the outerloop of how we work in aggregate of teams. We need next generation platforms that make this data and this context more accessible to business leaders.

    Alan Shimel: I don’t disagree with anything you said there, so we’re there with that. What about have you guys released any news or anything? What do you got going on around the show?

    Kyle Campbell: Yeah, so for the last while, we’ve been focused on really building a rock solid workflow and tooling to basically set the premise of that next generation composable CI/CD vision. We’ve fed that data into DORA Metrics. You can now report on DORA metrics in real time, save those reports, share them with whoever one-on-ones, retros, so kind of up to you. And we’re starting to experiment with some data science, but something that’s really exciting that we just kind of put into production last week. We haven’t really officially announced, so I guess this is a first is we’ve released our first kind of AI-

    Alan Shimel: Heard it here first.

    Kyle Campbell: … yeah, heard it here first. Our first AI feature set, which is AI code review. And what we’re doing is we’re letting teams start with these sort of base models for how they can leverage AI in the code review process to get developers’ feedback earlier. But then, we want them to be able to do is enhance that model to really customize it to their preferences on their own kind of hardware, to customize those models to take into consideration their own specialized requirements and obviously protect proprietary information that’s so core to their beliefs. So we launched that into production, announcing it here first.

    Alan Shimel: Really?

    Kyle Campbell: And we’re looking for early adopters who can kind of test it out and help us stress test it and figure out how do we further enhance the context of that model with some of the information that is derived in these DORA metrics as well.

    Alan Shimel: So here, we’re talking to this camera. Developers out there. You’re looking for them to kick this around a little bit. Kick the tires.

    Kyle Campbell: That’s right. Yeah.

    Alan Shimel: How do they do it?

    Kyle Campbell: You’re a developer and you’re interested in how AI can support your CICD workflow, specifically code review, come over to cto.ai, sign up, send a message. I’d love to talk to you personally, software development yourself, and love to hear what you think, what you think are the limitations and hesitations, and more importantly, how do you think we can enhance this with other use cases? Because I think there’s a whole exciting set of use cases for AI and software delivery that is going to help software developers.

    Alan Shimel: Absolutely.

    Kyle Campbell: We embrace-

    Alan Shimel: I had this conversation in an earlier interview today. Look, for people who aren’t tech, you show them an AI interface and some of the kind of parlor tricks it could do and they think it’s magical.

    Kyle Campbell: Yes. Arthur C. Clark.

    Alan Shimel: Right.

    Kyle Campbell: Yeah.

    Alan Shimel: Now, we know it’s not magic. It’s just putting one word in front of the other or one… but there are some uses that AI really shine certain. So it’s not meant to replace Google Search nor is it meant to replace software developers.

    Kyle Campbell: No.

    Alan Shimel: But it can empower software developers to be 10x more effective. And one of the ways it could teach you to code, right? You could put code in there and say, “Explain it to me.” It could review code, right? So either it’s writing code or it’s reviewing code. You shouldn’t have it doing both probably, but…

    Kyle Campbell: It’s true.

    Alan Shimel: Right. But if it’s using it for review, what a great use of the technology.

    Kyle Campbell: Yeah. We’ve seen that the number one thing that slows down time to market in feature sets for developers is waiting for code review. And while I’m not sure that it’ll be the same thing as you and I pair programming and getting into the nitty-gritty details, if we can make sure that every developer can get a code review instantly just by adding a label and then that we can tailor the quality of that code review with more context that is supported by how the team thinks about quality. I think this is an important example of how we can accelerate the needs of developers and the developer experience with AI that still leaves all the control in the hands of the developer to decide, “Is this rational? Is this a hallucination? Is this the appropriate time?” But the feedback loop that we can get from this is, I think, a really great beachhead and why we chose to start there.

    Alan Shimel: Absolutely. And we’ll see. I don’t think we scratched the surface yet on how we’re going to use AI, but this is certainly a real definitive first step that I see us going with, right?

    Kyle Campbell: I think so. And I think the call to action for other software vendors out there is to think about reinstrumenting what they’re offering to prepare for this because I think there’s a necessary hesitance around AI. I think rightly so. But if we can think about how we can take control of it, how softwares can take control of it. Software engineers are perfectly suited to be some of the first stewards of these problems. Just like we see AI and code generation, I think the next natural step is to support it within code review. And then we’ll start looking at how smarter deployments, smarter rollbacks, and obviously, operations can be enhanced with AI. And this place is a perfect example of people trying to solve that problem.

    Alan Shimel: Absolutely. Absolutely. And here’s the other thing. I’ve been in technology a long time. You don’t put these genies back in their bottles.

    Kyle Campbell: Right.

    Alan Shimel: Once they’re out, they’re out. And so like it or not, they’re here. And I think you could… if you can’t beat them, join them.

    Kyle Campbell: You can’t stop Moore’s Law. I mean, this the pathway that the world is on.

    Alan Shimel: No, you’re not. You’re just not going to stop it. That’s the way it is. It’s great stuff, man. I love the attitude. I love having you on here. Cto.ai. Again, if you’re looking to help Kyle out, kick the tires on this AI code review product they got coming on, it’s fantastic. So let’s check it out.

    Kyle Campbell: All right. Thank you so much.

    Alan Shimel: All right. Hey, Kyle, enjoy the rest of your KubeKon. cto.ai wrapping up day two in Chicago at KubeKon. We’re going to be here tomorrow morning. I think we’re on at 10. We’re only here till two tomorrow because it wraps early tomorrow. But we’ll be back with a full load. We hope you’ve enjoyed today. On Demand is available at Techstrong TV. And so if you missed anything, do check it out. This is Alan Shimel. We’re out.

  • KubeCon 2023: Developer Productivity and Platform Engineering

    KubeCon 2023: Developer Productivity and Platform Engineering

    Mitch Ashley: Hey everybody. Welcome back to KubeCon here in Chi-Town, Chicago, 2023. I am joined by Venkat Ramakrishnan. Welcome. With Pure Storage, right?

    Venkat Ramakrishnan: Yes.

    Mitch Ashley: Great. And you are in charge of product and engineering?

    Venkat Ramakrishnan: Yes. Yeah.

    Mitch Ashley: Cool. So you want to talk about something I want to talk about, and that’s platform engineering.

    Venkat Ramakrishnan: Yeah.

    Mitch Ashley: We’ve done some work in this area. And in my mind I think the timing for platform engineering is perfect because the focus on developer productivity and reorienting… DevOps is just about everybody else helping developers do their job. It seems like platform engineering has really been good at adapting in ways that organizations need that function in their company.

    Venkat Ramakrishnan: Yeah, absolutely. If you look at most of the modern enterprises, one of the most precious resources they have as a developer, they want to make sure the developer community is thriving, is able to move their products and the experiences forward, and are able to get the most out of the infrastructure without being slowed down by the infrastructure.

    And I always joke around, if data is the new oil, then developers or the new engines of the economy. So you really want… every enterprise out there is a modern software enterprise, a digital enterprise. And without the developers moving the business forward, they’re going to get left behind. So you have to look at it from that perspective as to why platform engineering is so critical in even the post-pandemic age. It has really accelerated it. We were all part of the Kubernetes container community.

    You could see some of the early adopters, innovators trying to drive a platform story, consolidate the services. But as more and more folks were remote, as more of the tasks had to be consolidated, and the more teams had to be consolidated across, we saw over the last couple of years, in the post-COVID era, the platform discipline. The platform engineering discipline has really taken a strong hold and we see a lot of customers run platform engineering orgs that centralizes all of the DevOps capabilities they had distributed before but also brings a lot of control over cost, security, governance, regulatory stuff, and all of that.

    So it gives them a one stop shop for everything that the developers need to build and run their applications. And that’s where Kubernetes really shines. If you really go back and look, the vision for Kubernetes and containers is that you enable developers to build, ship, and run anywhere. But now all the tooling has matured and all the organizations, many of the world’s largest organizations have embraced it. So we see a ton of adoption, a ton of growth there from the perspective of folks running their applications and building these internal developer platforms and everything. Yeah.

    Mitch Ashley: We abstract things, and containers simplify things to make parts of the pipelines more efficient and easier. That complexity goes somewhere else. Maybe it gets replaced by technology, but we still have to engineer the test, development, production environments we’re going to be in. We want those to be the same or as similar as possible. That’s one domain of platform engineering. There’s also developer portals and that kind of thing too.

    Venkat Ramakrishnan: Yeah, yeah.

    Mitch Ashley: Are you focused more on the platform in platform engineering, or do you expand into other parts?

    Venkat Ramakrishnan: No, that’s great. Our mission is to make the platform engineers’ life easy, but definitely our consumers are developers. See, the platform engineering team exists to serve their application teams and to help them build, ship, and run faster. But there are essentially two major personas that we build our products for. One, the top persona for us is a platform engineer, and they’re our superheroes, I call them. I just came off a customer meeting and they just told me they have about 6,500 to 8,000 developers on a platform which is building out about 100,000 builds a day, and their team size is only eight people.

    Mitch Ashley: Wow. That’s impressive.

    Venkat Ramakrishnan: That’s how lopsided the developer-to-platform engineer ratio is. There’s the large development teams, really small platform teams. So what they need is a lot of automation. They need a lot of observability. They need to be able to control or manage the platform through policies, through rules and rule-based automation and all of that. So our job is to provide that to the platform engineering orgs, the platform engineers so they can have a quality of life.

    But at the same time our customer’s customer is also very important to us, and most of the time or almost all the time it’s the developers who are the customers of the platform. They’re application users or the clients of the platform. So we build it so that these application teams have visibility into what happens to the infrastructure. They know how to manage the infrastructure without having to file tickets so they can even make the underlying infrastructure behave the way they want, for example, with respect to performance or how the data is placed, how it is all backed up, how you can do a DR across, or how you even migrate between versions.

    So there are a lot of these things we let our developer community be able to control and manage so they can get the most out of their platform. And we don’t just stop there. We have also let our developers, our platform teams protect the platform like at the data level, at an application level, but we have also surfaced those capabilities to the developers as well. So if you’re a developer using a namespace. You have your applications running in a Kubernetes namespace, you can back it up. Or as a platform admin you can back up the entire Kubernetes cluster and you can also restore just the namespace if you want.

    So we give different fine grain controls for both the users. And not just that. We didn’t stop there. One of the toughest workloads to run, any environment, is a database. And there was a lot of fear, uncertainty, and doubt about, can a database really run in Kubernetes? If you go back to the early days of Kubernetes. Portworx is one of the companies that emphatically said, “You can absolutely run databases on Kubernetes.” And they are actually best suited, especially the modern cloud-native databases, they’re best suited for running in Kubernetes because they need scale, they need agility, they need elasticity. And what better than a Kubernetes infrastructure to give you that?

    Mitch Ashley: Distribution. All kinds of things.

    Venkat Ramakrishnan: Exactly. So we have been shipping Portworx data services, which makes it so easy to automate about to 14 important databases, and we’re continuing to add more and to run these databases anywhere from day zero to day two ops. Install, upgrade patching, all the way to doing DR for databases. You can literally deploy a clustered Postgres in a matter of minutes and you can set a DR policy so if your entire AWS region goes down, you can spin up in another region again in a matter of minutes. In a few minutes RPO.

    Mitch Ashley: Let me ask you, and it may not be a fine line, but where does a platform engineer’s job start and end and a developer’s begin? What is that middle point where they intersect with each other? Because platform engineering isn’t just taking a bunch of stuff from developers and doing it for them. Developers still have to have their own way of… I might want to spin up an environment. “Create this for me. I don’t want to open a ticket.” Like the old days. So what does that middle part look like?

    Venkat Ramakrishnan: Yeah. I think this goes with the principle that if you build it, you own it. That means a platform engineer is not going to do the developer’s job for them, and neither is the developer is going to do the platform engineer’s job for them. Where the line draws is like a platform engineer looks… If you look at the platform engineer’s view of their day-to-day work, they are making sure their environment is up and stable, it’s able to serve up apps, people are able to deploy applications and get them running within the SLA they promised, and they are looking at it, the environment as a whole.

    But a developer’s view is they have a namespace or a few namespaces and a provision for them. They have authentication into that. Their view is very narrow. They’re focusing on their application. They’re focusing on how performing their application is. They’re focusing on the uptime of their application. They’re focusing on how they can do code patch updates and security updates to their application. They are making sure their application runs in compliance with the platform’s requirements. It is secure, it has all the latest CVEs patched, it’s able to get the performance it needs. It’s backed up at their level and all of that.

    So developer’s scope is very narrow to their set of applications, but a platform engineer… a developer doesn’t go tell the platform engineer, “You know what? You need to add more nodes in your Kubernetes platform.”

    Mitch Ashley: They don’t want to have to.

    Venkat Ramakrishnan: That’s the platform engineer’s job. Yeah. They don’t want to have to. They shouldn’t be because it’s invisible to them. So what Kubernetes essentially delivers is an invisible infrastructure to the developers. And for the platform engineer, the platform engineer is not going to go to developer to say, “You know what? You should rewrite your code because this is how this platform works-”

    Mitch Ashley: Won’t go over well if they do.

    Venkat Ramakrishnan: Exactly. And we all know the biggest inertia in enterprise, especially in software enterprises, that no developer wants to rewrite their application because it has to work for a different infrastructure. That’s what a lot of infrastructure companies think. Oh, I have a new API. All the application-writers are going to rewrite this applications to use by new API.

    Mitch Ashley: Good luck.

    Venkat Ramakrishnan: That’s why Posit still survives. We were having a raging debate yesterday in one of our community dinners we had. People were asking, “Why is Posit still around? Why is Block still around?” Because you have billions of apps out there that use these interfaces, and they work. And I guess object is a new interface, and we support it, but hey, I have seen-

    Mitch Ashley: And nobody’s going to pay to move it. Why? What’s the value?

    Venkat Ramakrishnan: So you’re going to see that the platform engineer cannot dictate the application developer to say, “Go change your app.” That’s whole reason I talk about databases. You could offer a bunch of data services, but a developer is going to come in, especially you’re building a new age app, you’re trying to bring in a new digital experience. They’re going to say, “Look, I’m going to use this high-speed database that can really do this many transactions or a few hundred nodes, or a few hundred or billions of users.” And the data service you offer may not be scalable to deliver that.

    That’s why we’ve built these Portworx data services, because we want to offer the most favorite databases for developers and make it easy for them to run so they don’t have to wrangle with platform and the team and all of that on which data services they need to run for them. Because again, platform engineers are not database experts. And DBAs are not platform experts. So we wanted to marry that together and offer this to database teams, application teams, how you can run these modern databases and how you can simplify it. Again, that is the clear separation of responsibility. I hope that answered your question.

    Mitch Ashley: Yeah. No, very good. Tell us a little bit about, what does your product do? What’s your approach to market? How do you help platform engineers do their part of this ecosystem?

    Venkat Ramakrishnan: Yeah. Our product, as I mentioned, we have a complete data platform. It has storage, backup, and data services. We continue to add and expand it so we can engage with our customers in pretty much any stage of the journey. For example, if your customer is starting out early, you have an enterprise customer, you’re running a bunch of workloads, but hey, you’re not ready to run data services. You’re not ready to run mission-critical applications, but you are running a ton of apps in your… so we can start you with data protection, or your Kubernetes data protection, like where you can back up and restore your Kubernetes clusters. You’re always compliant with your security policies. You’re protecting your Kubernetes or the platform operations against ransomware attacks, and all of the great stuff. But we can go from there and then say, “You know what? You could run all of your mission-critical apps, including your complete application stack, your databases, get back-up in DR with our Portworx enterprise data management software.”

    And the third thing is you can add to the platform and run any database of your choice from our catalog, that you can immediately spin it up and get your application teams to use it. Our primary mission is to serve the platform teams, as I mentioned. So we sell primarily to platform teams. If you look at all of our large customers that run thousands of nodes of Portworx installs, they’re all mostly platform teams. But almost always the developers are consuming that platform, the application. So we look at developers as a community of users that actually leverage the service that’s available to them or provided to them. We are the platform team.

    It’s kind of like if you’re in a company, the IT offers you a service and we as the employees of the company use that IT. For example, it could be email, it could be something like Slack. Same thing. A platform team offers a whole bunch of services to a community of developers who are building apps, and that’s what’s driving the business. Yeah. So we sell to the platform teams, but consumed primarily by the application developers.

    Mitch Ashley: Great. And Portworx, is that a SaaS cloud offering, or you on-prem as well?

    Venkat Ramakrishnan: We have on-prem as well as SaaS. Honestly we have seen explosive growth in both the deployments.

    Mitch Ashley: And you really have to be in both to serve the center parts, right?

    Venkat Ramakrishnan: Exactly.

    Mitch Ashley: Very good. Can folks kick the tires like with the cloud service? Or how do folks learn about what you can do with Portworx?

    Venkat Ramakrishnan: Yeah, they can go… for example, we have an Essentials version of Portworx. They can go to central.Portworx.com and download our Essentials version. We have backup as a service. There’s a free tier version of the backup that they can go play with. You can just sign up, self sign up. You don’t need to contact us. You can just come onto a portal, self sign up. Point it to your Kubernetes cluster, your namespace. You can back it up as much as… we have some upper limits, but it’s pretty liberal. Then we have a trial version.

    If they want to play with the enterprise, the entire suite of the platform, then they can download a trial. It’s unlimited from a features standpoint but limited by a certain number of days for you to play with and run. And then feel free to ping us, and we’re happy to always chat. We want to be partnering with our customers’ journey. Our mission is to make the platform engineer’s life easy. To give them the time back. To let them manage complexity at scale, and to be able to deliver these services and keep their SLAs but serve a large developer community. So again, we are on their side. They are our superheroes and we’re there to serve them.

    Mitch Ashley: I’m sure they appreciate the help. Tell us the URL again to go check this out. The web address. Where do they go?

    Venkat Ramakrishnan: Yeah. It’s ww.Portworx.com, ww.Portworx.com. They can go to central.Portworx.com as well to check us out. There’s a ton of help on docs.Portworx.com as well. So there’s a ton of resources. And we have our YouTube channel, which is Portworx. You can subscribe to it. There’s a ton of learning videos. If you go to Portworx.com, there’s also sandbox labs that they can play with as well so they can deploy immediately and run. So there’s a ton of resources to get up to speed. And you can always fight us on slack.Portworx.com as well, and come and ask questions also.

    Mitch Ashley: That’s always great, to get in there, try it, and see what it does. How it works. There’s nothing like hands-on. Well, thank you, Venkat. It’s a very pleasure talking with you. Hope you have a good rest of the show.

    Venkat Ramakrishnan: Yeah.

    Mitch Ashley: And if you’re talking Kubernetes, you’re at the right place.

    Venkat Ramakrishnan: Absolutely. I’m always happy and excited to be here. Thanks for having me.

    Mitch Ashley: You bet.

    Venkat Ramakrishnan: It’s always a pleasure to talk to Techstrong.

    Mitch Ashley: Have you come back again. Always.

    Venkat Ramakrishnan: Absolutely.

    Mitch Ashley: Yeah. It’s an evolving area, right?

    Venkat Ramakrishnan: It is. It is.

    Mitch Ashley: And fast moving, too. So it’s always good to keep up with what’s happening.

    Venkat Ramakrishnan: And this show has gotten so much bigger and so much busier, right? It’s an amazing show.

    Mitch Ashley: It’s pretty amazing. It really is. Well, thanks again.

    Venkat Ramakrishnan: Thank you.

    Mitch Ashley: We’ll be back with other great interviews, just like with Venkat, and talking about who knows what next. We’ll see, but I’ll bet it’s something to do with Kubernetes or cloud or both. So we’ll be talking with you soon. Don’t go away. We’ll be back in a few minutes.

  • KubeCon 2023: Internal Developer Platforms and Developer Productivity

     

    Mitch Ashley: Hey there, everybody. Welcome back to Chicago to KubeCon 2023. We are on day two of our live-streaming on Techstrong TV across all of our sites, devopsy.kinsta.cloud, Security Boulevard, Techstrong.TV, and Cloud Native Now. So, we’ve got more great interviews. Alan’s just finished a couple and I’m teed up now with Amit Gorvin. Nice to meet you.

    Amit Eyal: Very nice to meet you.

    Mitch Ashley: And you are with, say the name.

    Amit Eyal: Kubiya AI.

    Mitch Ashley: Kubiya AI, okay. That’s a lot of syllables there, but okay. I’m just kidding you.

    Amit Eyal: We do this on purpose to confuse.

    Mitch Ashley: You know what? Once you hear it, it’s unique, right? You remember those [inaudible 00:00:45].

    Amit Eyal: Hundred percent.

    Mitch Ashley: Exactly. Okay, so I know you’ve talked with this before and you’ve talked about IDPs. It’s a really fast-growing area, right? Everybody’s focused on-

    Amit Eyal: Absolutely.

    Mitch Ashley: How do we help developers, platform engineers, the people all working together to make lives easier, self-service, that kind of thing, portals and all of that. I know you had some announcements recently. Talk about that, but maybe set it up of what you all do and why that’s a little different.

    Amit Eyal: Sure. I think maybe to take one step back, one of the things that I think a lot of companies in the industry, including ourselves are doing is, how do you create a better exchange between the developers and the DevOps, the operators on one side, developers on another hand where you have the golden path towards productivity. IDPs, internal developer platforms, have been known backstage being the primary leader in this space to unlock lab productivity.

    One of the things that we, at Kubiya, have discovered, and this is what we’ve tried to essentially address, is the self-service is only as good as the interaction between the users and the tools. And where often it does break down is on the fact that it’s a one directional exchange between the user and the tool. If you fail on authentication, fail on permission, don’t know the variables you need to pass or anything just doesn’t work as expected, you have a question, you have to go back and do a Jira ticket queue in order to go and to essentially get assistance from a human being.

    So, what has come to fruition in the last year, obviously ChatGPT doing the market education for this, is conversational AI, having a two directional exchange between machines and humans. We’ve married these two worlds together. We’ve created that exchange between your users, developers, and operators with the tools in a way where you can have a full-on conversation with it.

    You can go and spin up a Kubernetes deployment, it will ask you how many you replicated. You can scale it up, scale it down. You can have for your Jira ticket queue, for example, and ask it questions about who owns what, where they’re assigned creation, notating, anything that you would be able to do as a human, only in this case, you’re just having a conversation. Because imagine having on the other side, someone like Fred, John, Bob on the on-call channel having a conversation with you. We’re replacing that with the virtual assistant.

    Mitch Ashley: Interesting. So, replacing the virtual assistant model. It sounds like also you were maybe describing, if I got this right, that the developer technical staff can interface through ChatGPT to say… I mean the nice thing about ChatGPT is you can talk to it like a programming language just in conversational logic, right? I want you to create this for me with blah, blah, blah. Is that part of what you’re saying? You can give it instructions or requests?

    Amit Eyal: One minor information, we’re not using ChatGPT. It’s a ChatGPT-like experience.

    Mitch Ashley: I see.

    Amit Eyal: It’s probably the best way to anchor people to-

    Mitch Ashley: I jumped that.

    Amit Eyal: Which is fine. We’re using about eight different language models, both large and small. We’re actually using conversational AI piece with GPT-4 for Azure, just a FYI, but that’s separate. The experience is ChatGPT-like. Only here, it’s your tools, your programs, your scripts, essentially a personalized IDP, if you may, for each and every persona in organization, each and every individual in the organization.

    Mitch Ashley: Okay. So, are you using generative AI large language models underneath, or that’s just the experience that you’re delivering with whatever technology?

    Amit Eyal: Certainly. So, large language models are giving that natural exchange, essentially the benefits of large language models and the generative piece we’re using. But we’re also harnessing and scaffolding it with rule-based systems, with sound engineering practices. So, that’s how you get the benefit of an expected outcome on one hand. Our users would expect an expected outcome. Essentially, it has to be deterministic what they’d get on the other end.

    Mitch Ashley: I’m glad you said that because I was thinking down the ChatGPT line. It’s nice, but you don’t get the same response, same outcome. It’s not necessarily guaranteed to be consistent, to be accurate. So, it makes sense on the backend scaffolding part.

    Amit Eyal: And there’s permissioning and rule-based systems in place to harness the LLM to function the way you would expect it to.

    Mitch Ashley: Very nice. So, you talked about the developer experience, and I totally get the cognitive dissonance between I’m working in my IDE and doing my developer thing, and then I got to go to this ticketing system or go to some weird operating portal that wasn’t built for developers, but I still got to use it in a huge sense.

    Amit Eyal: Maybe it is, but it’s only as good as how it’s been upkept, maintained or what you’ve actually input into there. So, you still have to go in to program it to act the way you expect it to.

    Mitch Ashley: And it’s part of the flow too, right?

    Amit Eyal: Yeah.

    Mitch Ashley: I might not know answers to all 10 questions at the start of the interaction, but I need to get it started, and then finish it at some point in the process. But it’s about in the flow of the developer work, not I’m a form, fill me out. Right?

    Amit Eyal: A hundred percent.

    Mitch Ashley: Great. So, the announcement then, summarize again for us because I stepped on it with the GPT stuff.

    Amit Eyal: Sure, yeah. No, it’s fine. So, we came out last year actually with our initial platform, which was more resembling next generation of workflow automation because it was more so to get people connected to the world of conversational AI into the world of IDPs. Where we took it from there, and especially with the evolution of large language models, is an agent-based approach where we’re using different models and different agents trained on different models in order to map out effectively different functions within a transaction, almost like the human brain and the lobes interacting with each other.

    So, when you go and interact with the system, depending on how you approach it, it could be, show me how I do something. Say, set up a VPN. That may be in your docs. So, we’re using RAG techniques obviously to go into a train on your knowledge base. But if you’re going to go and run a query against a data source or a database, or maybe show me all my Jira tickets for current sprint for certain… That’s a different language model that’s interacting with you.

    And then if you’re going to go and create a Terraform, create a Kubernetes deployment, destroy Terraform, that’s an action base that’s also needing to go into verify permissions. We’re using open policy agent. We’re also using all the techniques to or data masking, and then we obviously have the orchestration there, a state machine that will go in to orchestrate all of those with the business logic of the organization. So, there’s a lot going on behind the scenes.

    Mitch Ashley: There is. Well, a lot of different kinds of users’ requests.

    Amit Eyal: To the user, it’s seamless. You have a brain emoji thinking and then reading back to you what it’s doing. So, it’s actually very fun interaction, human-like interaction, but then behind the scenes, there’s a lot that’s going on.

    Mitch Ashley: Very cool. Do you integrate at all with IDEs and go that far with it or is it a separate portal?

    Amit Eyal: Users can integrate with their IDEs. They can go and plug in. We have a SDK and it’s all open API based. So, essentially, you can connect to any tool.

    Mitch Ashley: I think it’s really nice and important because for one, it’s right there handy. And also, if you’re delivering any information that you can deliver in the way the code looks like or structured or auto-fill, you can mimic the behaviors of what you do in an IDE that… Very natural. So, I don’t have to go look up an API or what that call is; it’s right there. Or I don’t have to go look up what that thing’s called on my request; it’s right there.

    Amit Eyal: Agreed. So, I think maybe the one call-out I would love to make is people are thinking about the co-pilot approach or ChatGPT approach as a code completion tool. What we’re doing is, we’re doing an operations’ completion tool. Essentially, all of the next step, what would you do, how would you deploy the code, run your CI/CDs and maintain it for day two operations, so that’s where you can think about us filling that gap.

    Mitch Ashley: Okay, interesting. So, congratulations on the announcement.

    Amit Eyal: Thank you.

    Mitch Ashley: That’s fantastic. And every time you come, you’ve got new, in progress and things happening. I’m curious, maybe you’ve talked to Alan about this or Mike, your backstory, you’re CEO, founder of the company. How did you get going down this path? Was that, I was doing this at a big company and this is like a huge need, I’m going to go forward or?

    Amit Eyal: It’s a great question. So, the first time we came on it was myself and my co-founder, who he himself is an operator who built a self-service platform for his platform team in his previous company at Bluevine, and I came from AWS where I was managing partnerships for all the DevOps and DevSecOps-

    Mitch Ashley: Nice couple.

    Amit Eyal: Tier one players. So, I saw where they were possibly struggling with some of this self-service, and where I was in the middle of trying to assist them. And that’s where the thesis on the business side, which is this is a much larger problem and how we’ve actually solved this ourselves came together.

    Mitch Ashley: Interesting. Talk a little bit about your experience in the partnership side of it. Has that come to fruition as an important part of the business? I would imagine when you’re integrating with lots of things, just to look up the API, you can do it. You want to build relationships, partnerships with other companies.

    Amit Eyal: So, we have a very strong ecosystem of partners really looking to have the conversation. I experienced essentially that assistant experience on top of their platform. And right now, we’re letting into queue a few of the strategic ones that we feel that we can both have a strong alignment with, but also maintain. As we grow our team, we’re going to have a much larger ecosystem. We’re already at probably 10, 15 very strong players in the industry who want to have a partnership in place. So, I feel it’s only going to grow from that point.

    Mitch Ashley: Good, good. Amit, you already know this. I learned that lesson on one of the products I worked on where you didn’t design it with you were going to have a partner ecosystem in mind. You get to a point like, okay, we can’t do what we want to do. We got to go back and add that in. So, having that perspective upfront, if that’s a place you’re going to want to go at some point in the life cycle, it’s-

    Amit Eyal: That’s exactly it. Our ecosystem is built to be two-way conversation with all tools. So, if our customers are asking for it, there’s no reason why the vendor on the other side wouldn’t have a stronger alignment so we can have a better user experience for both sides.

    Mitch Ashley: I’m curious, do you sell to the engineering development community? Do you sell more to the platform engineering, operational DevOps tool folks? Where do you tend to focus?

    Amit Eyal: I would say usually that decision is made jointly. The platform teams typically have to have a handshake with the engineering managers. So, whether it’s an engineering manager taking us to the platform team, platform team taking us to the engineering manager, typically, we see both sides involved at least in validating this. But the easiest way to get started is really with the platform teams because they’re the power users typically of the system. They’re the ones creating and scaffolding the configurations of these systems, so it’s easiest for them to get started, test it internally on themselves. And very easily, we usually see that they roll it out to the rest of the engineering team.

    Mitch Ashley: They already have a good idea of what kind of requests come their way.

    Amit Eyal: Precisely.

    Mitch Ashley: And it would make that easier for people.

    Amit Eyal: Otherwise, the other way around would be, let me go and bring in a platform team. So, it’s a more direct approach [inaudible 00:13:09].

    Mitch Ashley: That makes sense and it’s nice. I could totally see. It’s starting, “Well, hey, something might make it easier to take a load off-

    Amit Eyal: Precisely.

    Mitch Ashley: The platform engineering team” or them saying, “Hey-

    Amit Eyal: We’re here to augment them.

    Mitch Ashley: … that’s an easier way to work with this.” Right?

    Amit Eyal: We’re here to augment them. Not everybody has a luxury of hiring three to five more headcounts for next year, but if you could do so with one or two headcounts and then Kubiya, now you can scale.

    Mitch Ashley: Great. If you look forward a little bit, maybe this next six months or maybe 12 months, six months or so, what things are happening in the industry, maybe where you’re heading, what are you thinking about next?

    Amit Eyal: The most recent announcements by OpenAI have been very interesting, because from our perspective, it’s giving us even more tools in order to get to our end goal, which is, in my opinion, a self-driving operator. A self-driving operator that will be able to take end-to-end tasks away from human beings and really free them up to do the highest and best use of their time. It’s still going to require human-in-the-loop interaction and we don’t expect it to be overnight. But I think a lot of the things that was announced recently is already in line with what we’ve been doing, but it’s only making it easier and again unlock more and more use cases.

    Mitch Ashley: Seems like OpenAI have done a pretty decent job of, don’t throw it all out there, incrementally add capability when you’re ready to handle it.

    Amit Eyal: Yes. Because we’ve been in this space a couple of years, we’ve been thinking about, we’ve already been architecting our platform to be conversational native. That’s allowing us to move very fast in this space.

    Mitch Ashley: Great. Well, tell folks where can they go check it out?

    Amit Eyal: Absolutely.

    Mitch Ashley: Can they get a demo online or what can we do to help?

    Amit Eyal: That’s a beautiful part. We open our platform up for self-service. So, you could actually sign up at Kubiya.ai, www.kubiya.ai. Sign up for a free trial. We also have a sandbox where you could, without needing to put in organizations credentials, anything. It’s a gated experience. Obviously, it’s a bit more limited, but you could go and have that nice exchange with Kubi, our DevOps assistant, and really enjoy the experience before committing to going into a trial.

    Mitch Ashley: Appreciate the sandbox. You don’t want to quite turn it loose on your infrastructure quite yet. Let’s kick the tires and then get there.

    Amit Eyal: Mostly read only. We have a few write actions in there, but typically, we want to make sure it’s rated PG for what people can do.

    Mitch Ashley: Exactly. Exactly. Great. And it’s spelled K-U-B-I-Y-A.ai.

    Amit Eyal: Y-A.ai.

    Mitch Ashley: Great.

    Amit Eyal: Thank you very much.

    Mitch Ashley: It was on the… I’m sure on your title but-

    Amit Eyal: Yes, it would be there.

    Mitch Ashley: Amit, pleasure talking with you and congrats on the new progress, new release and capabilities, where you’re headed next. Great market to be in.

    Amit Eyal: I appreciate it and I appreciate your time here today.

    Mitch Ashley: Of course. Great to have you on. For our folks, for the people in the audience, Amit’s representative of some of the great things that are happening not just at KubeCon but in our industry, and progress that’s happening overall. So, stay tuned. We’ve got more great interviews coming back up. Don’t go away. We’ll be right here in a few minutes. So, we’ll be back.