devopsy.kinsta.cloud

Tag: KubeCon

  • KubeCon 2023: Dell, DevOps and DevRel

    KubeCon 2023: Dell, DevOps and DevRel

     

    Speaker 1: This is Techstrong TV.

    Alan Shimel: Hi everyone. Hey, we’re back here live in Chicago, KubeCon + CloudNativeCon, day two, continuing our coverage, we’ve got some great people lined up to bring you today. We started just now with Dan Garfield from Argo and Codefresh, and my next guest is my friend Brad Meltzer…

    Brad Maltz: Maltz.

    Alan Shimel: I screwed this up… He’s my friend, and why do I think Meltzer?

    Brad Maltz: I don’t know, it’s a good New York name.

    Alan Shimel: No, I knew a Richard Meltzer.

    Brad Maltz: There you go.

    Alan Shimel: I’ll tell you a great story about him off camera, he was a tech entrepreneur, a miserable failure of a tech entrepreneur.

    Brad Maltz: Okay.

    Alan Shimel: His wife though, invented the things, you know how you’ve got holes in Crocs?

    Brad Maltz: Yes.

    Alan Shimel: His wife invented the things that go into those holes. He closed down his venture backed startup, his wife sold those to Crocs, and they’ve lived happily ever after.

    Brad Maltz: And I hope he’s watching this.

    Alan Shimel: Richard Meltzer. He’s from Boulder, Colorado. Hey man, how are you, Meltzer?

    Anyway, that took me down a rabbits nest. Brad is with us… Actually shout out, right? Dell Technologies is sponsoring our broadcast this year from KubeCon again, as they did in Amsterdam last year, and a large part of it is due to Brad, Brad is a director…

    Brad Maltz: Senior director of-

    Alan Shimel: Senior director.

    Brad Maltz: Of the DevOps portfolio and DevRel.

    Alan Shimel: There you said it. Now a lot of you may be asking at home, wow, I didn’t know Dell was involved in DevOps and DevRel, or in CNCF.

    Brad Maltz: Yep.

    Alan Shimel: I got a Dell, right? I got a Dell box-

    Brad Maltz: You’ve got your laptop.

    Alan Shimel: I got the Dell server and stuff like that, but there’s more to today’s Dell than the boxes. So Brad, I don’t want to embarrass you, but I’m going to put you on the spot here.

    Brad Maltz: Go for it.

    Alan Shimel: Talk to us about, I want everyone at home to understand what your group does and how involved you are, not just in CNCF, but in the DevOps community, the DevRel community.

    Brad Maltz: Yeah, so basically over the past year and a half, we’ve been making sure to kind of expand our community outreach, specifically around the DevOps stuff. When I took over the role in product management to help kind of build out further our container strategy, our infrastructure as code strategy, we didn’t realize that we needed a DevRel-like function to help kind of expand our community outreach, our advocacy back into Dell.

    And the reason for that is, what a lot of people don’t know is, I mean, we play across the entire ecosystem of CNCF, right?

    Alan Shimel: Absolutely.

    Brad Maltz: We bring Containers and Kubernetes solutions to market, we play in the AIML space, the security spaces. We’re enabling ecosystems around us with our technology.

    So because of that, having DevRel was extremely important. We spun up podcasts, we have what we call our DevOps Dispatch, which we’re actually recording here at CNCF, and you can get that on YouTube and Spreaker. We have developer.dell.com which we relaunched last year, and now it’s kind of taken off, hands-on labs and blogs and a whole bunch of stuff on there. So for us, the evangelism’s important, but the advocacy for our end users is more important back into Dell.

    Alan Shimel: Got it. So we talked about the… I don’t want to use the word infrastructure, but the infrastructure of how you’re reaching out.

    Brad Maltz: Infrastructure matters.

    Alan Shimel: Absolutely. But I want people at home to understand that behind that infrastructure though is real solutions.

    Brad Maltz: Exactly.

    Alan Shimel: Right? Because part of the whole Dell Technologies thing, it’s solutions. It’s not just a PR marketing kind of… Though we see it here on the show floor, and the podcast and all these things. Let’s talk about the solutions you guys bring.

    Brad Maltz: Yeah, so I mean, a great example is, and this show is actually a big one for us, we just recently have launched our APEX Cloud platforms, and we did one with Azure Stack, we just did one with Red Hat with OpenShift, and that’s actually one of the big things here.

    And what you’re going to see more and more of from us is the ability to take our compute, with our storage, our networking, integration with our ecosystem partners, but give you more of that easy button experience, give you more of the turnkey experience, or even the DIY. We’re always been good at the DIY.

    Alan Shimel: Yeah, that was DNA…

    Brad Maltz: But right now, can we get you more of those easy buttons, right? And that’s exactly where something like ACP for Red Hat here, is if you just want to be able to get OpenShift up and running from the factory as quickly as possible with the least amount of hands as possible, you’re looking at things like our solutions like ACP. And the trick is when you look at solutions, are they just white papers, [inaudible 00:04:57], which are really invaluable to certain people?

    Or is it a factory delivered end-to-end platform experience that delivers that Cloud-like experience and developer experience, on top of the infrastructure, plus plus.

    Alan Shimel: Guys, let’s not minimize that, that makes life a lot easier. I mean, I think back to the first DockerCon… It wasn’t the first, but it was the first one in Austin, because before that DockerCon was in Seattle, this is going back a while. And I saw Kubernetes there, I think it was maybe 0.8 was the release, it wasn’t-

    Brad Maltz: It was early.

    Alan Shimel: It was early. I came home, because at the time, we hadn’t launched Cloud Native Now, and before that it was Container Journal, we hadn’t launched it yet, we were still coming up with the names, and we were toying around with names with Docker in it, which would’ve been a mistake… Well on multiple levels.

    But I came home and told the team, I said, “Look, everybody at DockerCon is talking about this thing called Kubernetes, but it’s never going to catch on. It’s so God damn hard, I don’t know how anyone would use it.”

    Brad Maltz: Why do you think you didn’t bet on that?

    Alan Shimel: Well, this is why I still work and I’m not retired, Brad.

    Brad Maltz: Okay.

    Alan Shimel: Yeah… Another brilliant insight from Alan Shimel… So now with that being said, I’ll stand by my original point, Kubernetes is still hard.

    Brad Maltz: Yes,

    Alan Shimel: It is. I don’t care, I’ll work till I die, I guess, but it’s hard.

    Brad Maltz: Kubernetes is hard, and I think… So Kubernetes hit a maturity point, right? So definitely it won.

    Alan Shimel: No doubt.

    Brad Maltz: And everybody needs it. It’s leading the Cloud Native application kind of abstraction battle, so it’s there, but that doesn’t mean you don’t need to be a jack of all trades to be able to understand all the nuances in the abstraction. And you basically have to be able to operate everything under the covers of Kubernetes to make Kubernetes work properly.

    Alan Shimel: Absolutely.

    Brad Maltz: So what is the real long-term easy button? That’s I think an open question right now for Kubernetes. Opportunity.

    Alan Shimel: Absolutely, I don’t want to get [inaudible 00:07:10], maybe the easy button is something other than Kubernetes?

    Brad Maltz: That is always a potential.

    Alan Shimel: Yeah. But let’s get back to our point here though, so now you get Red Hat OpenShift, right?

    Red Hat OpenShift is probably, I guess the most, certainly in the top two Kubernetes platforms, if you will, if you’re using Kubernetes. And it’s still a little hard, right? I mean, you could go download it from Red Hat-

    Brad Maltz: You can get it running, but you’ve still got to have some knowledge behind it to do the basics.

    Alan Shimel: But this is where the easy button comes in.

    Brad Maltz: Yes.

    Alan Shimel: And also, I want to make clear, when we talk about this easy button, a lot of people say, look, why do I get it from Dell? I don’t want hardware, I’m hosting it in the cloud.

    Brad Maltz: But are you? That’s the question. So when people talk about-

    Alan Shimel: I wouldn’t have asked you if it was the… Okay…

    Brad Maltz: With cloud, it’s always, yeah, you have the super easy button in the public cloud, they’ve done an amazing job there. But you get to deal with things like egress fees, you got to deal with things like costs for ongoing costs for a lot of services behind that. And at some point people start to become cost conscious, so that’s one angle that you deal with.

    The second angle, in this new AI world that we’re now officially in as of 2023, you do start to wonder where’s your data living? Where do you want your data to live? And you’ve got the governance compliance side of it. Not security as much, but it’s more the ownership governance. And we’re seeing a lot of people say, you know what, with all those GPUs, there’s a cost and a governance angle to hosting it in my data center, in a Colo, Cloud adjacent and Cloud aware.

    Alan Shimel: Yep.

    Brad Maltz: So that’s where I see things like ACP for Red Hat 100% making sense.

    Alan Shimel: I agree with you 100%. I think there’s another angle here though, and that is this: Unless you’re really in it, and you may not realize this, but Kubernetes on bare metal, Kubernetes in a data center, not in the public cloud, has always been a big component of the Kubernetes footprint.

    Brad Maltz: Yes.

    Alan Shimel: Everybody just assumed, puts the words Cloud Native and Kubernetes Cloud Native, that it’s all in the big three clouds, right?

    Brad Maltz: Yep.

    Alan Shimel: Well, even beyond Oracle, IBM and the rest, but there’s always been a Kubernetes on-prem.

    Brad Maltz: There always has been, and there always will be.

    Alan Shimel: It’ll continue, it will be-

    Brad Maltz: I think it’s going to grow.

    Alan Shimel: Right, well, I think for the reasons you’ve outlined, right? People are worried about control, they are worried about compliance, they are worried about how’s AI play in all this and cost containment and FinOps and everything else.

    So I think that again is an insight that if you’re not really wired into the Kubernetes community, you don’t-

    Brad Maltz: You don’t think about it.

    Alan Shimel: Recognize… Yeah, excellent. Let’s talk about the show a little bit, so you guys are podcasting here live as you said, but what about conversations? I don’t know, I heard today there’s maybe eight, maybe up to eight to 10,000 people or something like that.

    Brad Maltz: Feels like that, yep.

    Alan Shimel: Conversations with people; what are you hearing? What are you seeing?

    Brad Maltz: A lot of the conversations right now are actually… So I’ve had a lot of AI discussions, which-

    Alan Shimel: So do we.

    Brad Maltz: I mean I expected it, but they’re kind of interesting because they’re not just about how do I build AI things, it’s how do I use AI operationally?

    And I think that’s the nuance that I’m seeing CNCF, maybe in the forward-looking view of the world, is how do we apply AI in the operational side of things like Kubernetes and security and all of that. That’s been a handful of, not a large percentage of conversations. There’s always… Actually the easy button thing, honestly, that’s probably been one of the biggest things.

    People are just, they don’t have enough skills out there, and actually one of the other things is Platform engineering. So one of the things you can see on my shirt, right? We have this-

    Alan Shimel: I saw it, I saw it when you came in.

    Brad Maltz: This is our logo that we have here, at Amsterdam, we kind of have this DevOps operating model yin yang where Dev and Ops have to play well together, cats and dogs have to come and be nice.

    Well enter Platform engineering, and these folks building the platforms that are like products inside of the end user environment, they need to adopt and embrace the DevOps operating model in their world. Platform engineering has been one of the buzzwords, I think it has been a big conversation for us here as well.

    Alan Shimel: Absolutely. Hey, just a quick plug for Techstrong, if you don’t mind, on the topic of operationalizing AI.

    We actually, I mentioned to you off camera, we did this hackathon about two months ago at our office with some of the founders of the DevOps movement, around operationalizing AI. And we recorded it-

    Brad Maltz: Oh, that’s awesome.

    Alan Shimel: We recorded all the sessions and we’ve just about got done editing now to make it manageable, and it’ll be out on Techstrong TV, I think in the next week or so. So if operationalizing AI is something you are into, go check that out. Edited, created totally by our Techstrong video team and starring some really cool people, so-

    Brad Maltz: That’s awesome.

    Alan Shimel: Looking to hear that about it. All right, enough of my own plugs. Brad, what else have you got for us?

    Brad Maltz: I mean, right now I think it’s just an exciting time to be in CNCF, in the community, in the industry, right?

    I mean, what’s interesting, I had seen, funnily enough a meme, that popped up in one of my social media threads, it talked about over 2000 years, the acceleration was like: The horse and buggy to the horse and buggy and everything was very flat, and all of a sudden the last 100, 150 years… Right now it feels like this year, and the past of one or two years, technology is accelerating at such a fast rate that we as an industry, can we keep up with it skills wise and people wise and career-wise?

    I feel like going into the next few years, we’re definitely going to have this skills challenge, and I think that’s one thing that I’m going to be focusing on a lot is how do we enable the industry, as technology just keeps evolving around us? I think that’s a big thing personally for me.

    Alan Shimel: So I will tell you, I’m a little older than you, a little… I don’t disagree with you except I think it’s even bigger than… It’s not just about this industry.

    Brad Maltz: Yep.

    Alan Shimel: I think the kinds of changes we’re seeing now is almost akin to when the internet first went public, right? So this is how I divide things, there are technology innovations that have a profound impact on the technology industry. I’ll give you a perfect example, the cloud. The cloud changed a lot of how we do tech, right?

    I mean, your grandma may say, “Where’s your pictures, grandma?”

    And she says, “They’re in the cloud…”

    Whether they were in the cloud or in the server [inaudible 00:14:33] or whatever, it didn’t make a difference to grandma, but it made a difference to us in this industry, we had to know about cloud security and deployments and everything that goes along with cloud and it kind of rocked our world.

    Then there are technology innovations that rock civilization: the internet rocked civilization, think about life before the internet. It’s a very different-

    Brad Maltz: Cell phones.

    Alan Shimel: Cell phones rocked civilization. So there are things that transcend technology markets, and I think we’re in one of those layers right now where things like AI and quite frankly, look, quantum is going to be real-

    Brad Maltz: At some point, it’s just going to magically happen to everybody.

    Alan Shimel: Boom. I read an article last week the very first time they broke RSA 256.

    Brad Maltz: Yeah, I saw that.

    Alan Shimel: With quantum. That’s crazy stuff, if you’re not up on it out there. But I feel like all of these things are converging to create another civilization changing and it couldn’t come at a better time because God knows we need it.

    Brad Maltz: We do. I’m with you, AI is going to be the next… It’s not even going to be, it is the next thing. And one last note on that for me, when we talk about in product management and Dell Technologies land, like our end users are people? Not anymore… The end users of our technology might actually be the AI, so we have to figure out what is the personality of an AI in the future? There’s a lot of things to think about.

    Alan Shimel: What is the AI wanting and looking for?

    Brad Maltz: That’s it.

    Alan Shimel: Nuts. All right. Hey Brad, you know what we didn’t mention? Hey, people who want to go visit the website, what’s the url?

    Brad Maltz: Obviously at dell.com, we have developer.dell.com now, so please focus on developer.dell.com. Go there, you can get all the latest events, newsletters sign up, hands-on labs, you name it. And you can reach out to me on LinkedIn, and if you have any questions, we’ll help you out.

    Alan Shimel: Fantastic. All right, we are live here in Chicago. We’re going to be back with our next guest in a second in KubeCon. Go check out developer.dell.com, and many thanks to Dell Technologies for sponsoring us here at KubeCon. We’ll be back in a minute.

  • 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: What’s Next for Managed Deployment

    KubeCon 2023: What’s Next for Managed Deployment

    Mitch Ashley: Hi everybody, welcome back to KubeCon here in Chicago, 2023. Lots of great conversations, and here comes another one with Adam Frank Armory, welcome, Adam.

    Adam Frank: Thanks for having me, pleasure to be here.

    Mitch Ashley: Always, we love having you on. So what’s happening in continuous delivery in this, I mean, it’s evolved so much just in the last even year or so, about how many environmists we’re deploying to and the mix of all that. Most of us don’t live in a greenfield, so we’ve got to deal with lots of variety of things.

    Adam Frank: That’s right, that’s right. And I think one of the biggest things that people are really starting to come across now is the fact that they are looking at multi deployments, multi cluster, multi environments, really trying to orchestrate all of that and coming around to manage delivery. Understanding that everybody from a seed stage to large, large enterprises, they all have at least three dev stage prod, right? So how are you going to orchestrate across that when that just grows to more and more environments, talking about global companies and things of that nature.

    So, I think that’s one of the big conversations that’s been happening around here is about the orchestration of that deployment. So it’s been exciting. It’s been exciting for us. That’s one of the things that we went into from the very beginning was understanding that the deployments have to be orchestrated. There’s a lot of things that have to happen, security scanning, integration, tests, you name it, throughout that deployment. So it’s been quite nice.

    Mitch Ashley: When you mentioned managed deployment, right, it’s not just press the button, everything happens. There’s a lot of variables, things have to be sequenced. Some environments require different things than other environments, some you can do is declarative, you can really build it from the ground up through automation and others. Maybe you can’t do that, you’ve got to work with infrastructure or apps or code that’s already there.

    Adam Frank: Yeah, whether it’s infrastructure, apps, or code, or whether it’s just policies that you have in place that you need manual approval before you go out to production. Or something has to happen in staging, like data. Data needs to be transferred from production into staging to do actual validated tests.

    We had a talk on Monday with Portworx actually, really fantastic use case that we’ve come up with them. There’s a use case with their largest customer where they are actually transferring live production data into staging environments to do real tests, because I know a lot of people today, the code’s the same, the configuration’s the same, the infrastructure’s all the same. Is the actual data the same? Well, not really. Okay, well, how do you know that what you’re actually about to change is going to inflict what you want to change? So the fact that we’ve worked a lot with Portworx to do the actual data transfer, to have real live production data in the staging environment to run those tests and things against, has been pretty cool for our customers.

    Mitch Ashley: That was always one of my biggest challenges, how do you get data, especially earlier in the development of an app or a product, is you don’t have a lot of access to a lot of production data unless you’re in a SaaS, and maybe you can then, but you have to worry about things of anonymizing. But you have data, but not necessarily the right data to test what you’re going to deploy so you’ve got to kind of match that all up. Is there anything in that demo that talked about that, sort of that part of the problem, how do you get the right data in the right environment?

    Adam Frank: Yeah, exactly. One of the big things that the security of data, the management of data, moving data around, and and Portworx has a great solution for it. So it’s nice to partner with them, given that we can do the orchestration of those deployments and have that as a check that’s within that deployment. It’s not going out to production before that data is moved into staging, and tests are run against that and validation has happened.

    So like I said, you can have the manual approval at that point if you want, if that’s a policy within your organization, or you can have that continue on automatically and go straight out to production, which is great. That’s the dream right there, is to have that end-to-end automation and have that deployment fully automated, which a lot of people work towards, which is great.

    Mitch Ashley: Well, let’s talk about that. Is there kind of a life cycle that people go through from, we’re not doing it at all now everything’s manual, and maybe it’s scripted, but it’s not automated in the same way they do through Armory. Is there sort of a step by step phases people usually go to get to a point where they might do some really automated through this?

    Adam Frank: There absolutely is. I mean, we talked to a couple of people yesterday from, I can’t remember what company now, but one of the first questions that we start to ask them is, what do you do for your organization? Okay, great. You’re a DevOps engineer, you’re a platform engineer, you’re an SRE, there’s loads them around. These two particular gentlemen said that they were just automation ninjas they didn’t really have specific titles or roles, and they just helped the organization automate everywhere they could. So the next question is then, “okay, well what are you doing to deploy your software? What are you you doing for deployment?” And they said, “Well, it’s manual right now.” Okay, that’s where most people are starting, it’s going to be manual.

    So, I think that one of the biggest things that we see is people start with CI. They’re going to automate the build and the test of that, and they’re going to have an artifact that they want to be deployed. The next thing they’ll start to do is exactly what you said. They’ll start writing some scripts and they’ll start extending some of that CI until that starts to become a little bit fragile and it doesn’t necessarily provide the developer experience that they’re looking for and enabling blue-green and your canary and things like that to protect your customer experience. So at that point, then they go out and they look for a continuous deployment solution that is going to actually meet that, and that’s where the evolution comes from.

    From that point, they’ll start to have some of the manual checks in place. They might not have integration tests all automated, that’s okay. You can have the deployment go out to dev, you can have deployment, go to staging, you can go run some manual integration tests if you need to, and then you can carry that deployment on. That would be the next piece of it, and making sure that all those pieces are automated that are being orchestrated. And then the final piece is, are you comfortable with all of this to remove that gate, to remove that manual approval to go after production and once people are, then you start to see that end-to-end automated deployment. And it’s really, really fantastic to see.

    Mitch Ashley: Really Cool. So, I’ll make a premise supposition you can tell me if it’s true or not, it seems to me that last step of getting into the, okay, yeah, we’re going to pull the pin and let it go and see and let it automatically deploy. A couple things I would want to have experience with one is, how often do we say no when we’re doing a manual decision about, okay, it’s time to release, and when we do, what are the issues? The other is, well, if something does happen, I want to be able to quickly redeploy a fix to whatever it is, and we might’ve put in production, so in minutes, an hour, hour, whatever, very quickly. If I can’t deliver code that fast then maybe I’m not ready to quite go to the automation fully onto production. Is that a good characterization?

    Adam Frank: That is, yeah. I mean, the fact that we’re talking about that as well, the rollback of that as well, are you comfortable rolling that back? Do you have the mechanisms in place that are going to allow you to roll that back? And that’s again, where a great CD solution is going to enable that both automatically or by a single click. You actually see that the baseline is off and this isn’t behaving the way that it’s supposed to be or the way that it’s expected to be, you can one click and roll that back to the last known working state, or you can have that automatically rolled back based on looking at some of that observability data that might be outside of the expected threshold.

    Mitch Ashley: Interesting. So we’re at KubeCon, let’s talk about Kubernetes, that holds another layer of complexity and technology and challenges. How does that roll into it? What are the things you need to consider about automated delivery deployment with Kubernetes?

    Adam Frank: Yeah, I think one of the big things is people have their repos structured in a way that makes sense for their business. People also have a couple of different choices in the way that they’re architecting Kubernetes, so they’re going single big clusters, are they going multi clusters, depending on what they’re doing there. And one of the mantras that we have at Armory is we’ll meet the customer where they are. So we don’t tell people to structure their repos in a certain way, we don’t tell people to architect Kubernetes in a certain way, we don’t tell people that you have to have a CRD written in a certain format. However you have your Kubernetes manifest today, we’ll deploy that.

    And I think that’s one of the beautiful things that alleviates a lot of that complexity of Kubernetes is giving people that flexibility that allows them to meet their organizational needs. We’ll deploy that, that manifest, we’ll deploy those containers any way that you need.

    Mitch Ashley: Yeah, it could be multi-cloud, could be out to the Edge and whatever regional center. I mean, it’s-

    Adam Frank: The Edge stuff is getting really interesting.

    Mitch Ashley: And multiple Applications. It is, it’s picking up. I hear a lot more about the Edge.

    Adam Frank: Yeah, absolutely. I mean, the fact that people are running pretty small clusters, but still Kubernetes clusters out in cars is a great example. That’s one of the big ones.

    Mitch Ashley: One of the people of the big manufacturers in Germany speak about that.

    Adam Frank: There you go. There you go. I know there’s a big American one that does that as well. And again, that’s one of those use cases, having that data on board, shifting that data back to a staging environment, testing with that, and then deploying back out.

    Mitch Ashley: Maybe that’ll be a light on our dashboard. You’ll see the little captain’s wheel. Kubernetes, come on you’re cluster running somewhere in your automobile.

    Adam Frank: That’s it, that’s it.

    Mitch Ashley: It needs a [inaudible 00:09:33].

    Adam Frank: Yeah, yeah. I was actually really surprised when I first started hearing about that, thinking like well that’s got to be pretty resource intensive in a car, we’ve got to figure out a way to do that without having clusters in every single one of these cars and Edge and things like that. But it seems to be working so far, and we’re talking thermostats and things of that nature as well with some of our customers. So, it’s pretty cool.

    Mitch Ashley: I heard someone describe automobiles now are becoming software platforms with wheels.

    Adam Frank: Oh, yeah.

    Mitch Ashley: I mean, essentially-

    Adam Frank: That’s exactly what they are.

    Mitch Ashley: How much of it is, it’s all software, right? With some electric motors or whatever kind of things. So what’s coming up next, the next six months where we’re going to be at re:Invent?

    Adam Frank: We are, we are.

    Mitch Ashley: Hopefully we’ll see you there. What’s on your mind about the next set of things you want to work on?

    Adam Frank: Yeah, so we’re at KubeCon, we’re talking a lot about Kubernetes, but every single person that we talk to also has something else. And whether they’ve found that Kubernetes is a little bit too complex for them and they don’t want to invest the resources in it, and they move to another container service like ECS or they’ve got some serverless. Everybody seems to have some level of serverless, whether it be Lambda or whatnot.

    So one of the things that we’ve really been working on that we’re going to be revealing pretty big at re:Invent is not only deploying to Kubernetes, but also being able to deploy to Lambda in a declarative way. Kubernetes brought us the world of declarative and gave us that abstraction layer above, the imperative nature of things. So we’re now bringing that to Lambda and full blue green, full canary, and being able to just share that declarative config between your Kubernetes or Lambda deployment, so you can actually deploy to both within the exact same deployment, which absolutely nobody’s doing right now. So we are very-

    Mitch Ashley: To both, but also in parallel, right?

    Adam Frank: Exactly.

    Mitch Ashley: Because apps maybe running in both environments, different parts of it.

    Adam Frank: Precisely. Precisely.

    Mitch Ashley: Well, sounds like you get a pretty good peek into what’s coming.

    Adam Frank: Yeah, we’ll have to get back together at re:Invent and sit down and showcase and discuss that a little bit.

    Mitch Ashley: Yeah, we’d love to hear a lot more about that. That sounds exciting. Well, good.

    Adam Frank: Yeah.

    Mitch Ashley: Well, congratulations. I said you and I have talked before the show seems really great. I mean, the buzz and the traffic and conversations-

    Adam Frank: Yeah, its always good.

    Mitch Ashley: And I’ve been to a session, I never get to go to sessions anymore we’re always talking-

    Adam Frank: Likewise.

    Mitch Ashley: Which is good, I’m good. But I’ve heard that they’re really good as well.

    Adam Frank: Yeah, most definitely.

    Mitch Ashley: Great. Have a good rest of the show and we’ll see you-

    Adam Frank: Appreciate it, thank you much.

    Mitch Ashley: In Las Vegas.

    Adam Frank: See you there.

    Mitch Ashley: Okay, re:Invent.

    Adam Frank: All right.

    Mitch Ashley: All right, man.

    Adam Frank: Cheers.

    Mitch Ashley: Say hi to Adam, stop by the booth, go visit Armory. Check him out online Armory dot… Is it io or .com?

    Adam Frank: .io, Armory.io.

    Mitch Ashley: I thought io.

    Adam Frank: You got it.

    Mitch Ashley: Okay, good. Definitely check them out and lots of good things coming too, as well as where we are today with Armory. Okay, talk to you again.

    We’ll be right back with our next great guest.

  • The Ultimate Measure of Software Development Effectiveness

    The Ultimate Measure of Software Development Effectiveness

    There is a famous quote by Peter Drucker that states, “You can’t manage what you can’t measure.” In our industry, measuring how quickly we can get working software into the hands of our customers has become a mantra for agile development teams, and it’s even being talked about in the boardrooms.

    Customers measure the value of software by how quickly it can solve their problems. Customer needs change constantly. Just like us, they are responding to the needs of their own customers. Reacting quickly to customer feedback and turning that feedback into working features is key to customer satisfaction and retention.

    Having these directives in mind, it’s no wonder our teams are being asked to deliver working software sooner. Often, the main roadblock in achieving this goal lies not in developing the features but in getting them deployed.

    Let’s focus on three areas that determine your team’s deployment performance, which, in turn, directly impacts your software development effectiveness.

    1. Frequency of Deployments

    When I meet developers, I ask them a simple question: How often do you typically commit your code? A typical answer is a few times a day or even a few times per hour. However, if you ask the same person a question about how often their application is deployed to production, the answer varies widely.

    Some will say weekly or daily or still – very rarely – even a few times a day, which is software development nirvana. However, a more common answer is monthly or quarterly. I’m also not surprised if someone says that they release annually. They say it with an honest level of pride and accomplishment.

    Let’s put these two things – code commit and deployment frequency – into a broader perspective. If the goal of measuring software development effectiveness is getting working software into the hands of the users, it doesn’t matter how often you commit your code but how often you can give your users new value.

    Delivering small improvements to your customers has more impact on client satisfaction than giving them a big gift (new release) once a year.

    2. The Control of the ‘Launch’ Button

    Triggering a deployment includes someone instructing a deployment, pushing a “deploy” button, or committing triggered deployments. How many people in your organization can promote the application to a production environment? If this privilege is limited to a single person or just a handful of people – we have a problem.

    There are many reasons you might want to limit access to production. It could be because you don’t have safety measures built into your deployment process, such as role-based access control. You may believe in the delusion that you can protect your organization just by having fewer people with access to the production environment.

    The reality is that artificially limiting user access to production significantly reduces your chances of deploying frequently. Imagine if the “person in charge” must take a sick day or is traveling. Remember that access to the production environment is also required for bug fixes when your organization applies a fix-forward versus rollback strategy.

    3. The Level of Deployment Automation

    Measuring software development performance is directly correlated to the level of process automation. You can’t manually deploy to hundreds or thousands of customers in a reasonable amount of time. The manual process does not scale, as time is the one thing we can stretch.

    Ask yourself: Is your deployment process manual, partly automated (where parts of the process are automated, such as scripts that can be triggered to perform application deployment tasks), or can you claim that you fully automated your deployment process where there is no manual intervention, apart from push-button approvals.

    The more you automate your deployment process, the more productive your development team can be. For complex deployments, you may need to target many customers, sets of infrastructure or even physical locations. You might need to apply different configurations or hit agreed maintenance windows for customers or regions. One way to accelerate software delivery for these scenarios is tenanted deployments.

    Tenanted deployments capture these differences and apply them to a shared deployment process, allowing the complexity to be automated. You can manage tenanted deployments with tags, variables and customizations while reducing the cognitive load for team members.

    There are many ways deployment frequency impacts software development effectiveness. When you deploy more often, you reduce deployment risk, increase quality and get feedback sooner. One action you can take to reduce batch sizes is to increase deployment frequency. Smaller batch sizes will also allow you to recover faster when a problem arises.

    Remember that the longer the time between deployments, the more changes and points of failure build up.

    As you think about ways to increase software development effectiveness, think about the deployment process as a way to get close to the ultimate measure of developer success–getting the working software into the hands of customers sooner!

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.

  • The Best (and Worst) Reasons to Adopt OpenTelemetry

    The Best (and Worst) Reasons to Adopt OpenTelemetry

    It was a rainy day in Seattle at KubeCon + CloudNativeCon North America in December 2018 when I first encountered the term ‘OpenTelemetry.’ At that time, I was an active member of a working group focused on developing W3C Trace Context, a standard now extensively employed for context propagation in distributed systems. It is likely no coincidence that some key individuals in this working group also played a pivotal role in orchestrating the merger between two prominent open source telemetry products: OpenCensus and OpenTracing. I never would’ve guessed that, in 2023, OpenTelemetry would become the second-largest project in the CNCF, sitting just behind Kubernetes.

    As is the case with any popular new technology like OpenTelemetry, the hype can make it difficult to discern signal from noise. During my years working in observability, I’ve had the chance to chat with many organizations that were thinking about using OpenTelemetry or already actively use it. Through those conversations, I’ve heard many reasons for adopting OpenTelemetry, some good and some bad. In this post, I will share examples of the best and worst reasons to adopt OpenTelemetry to help you cut through the noise.

    Poor Reason One: Following the Crowd

    It’s never a good idea to adopt something solely because others are doing it. Just because you saw a conference talk praising a new technology as the greatest innovation since sliced bread doesn’t necessarily mean that technology is suitable for your specific use case.

    Speaking of which, have you clearly defined your use case? To start, ask yourself the following three questions:

    1. Are you able to determine at any given moment whether your systems are performing as expected, such as meeting their service level objectives (SLOs)?
    2. When something goes wrong, can you easily pinpoint the root cause?
    3. Are you able to drill into previously unidentified problems, also known as “unknown unknowns”?
    If you answered these questions with “no,” you certainly have observability gaps worth tackling, and OpenTelemetry may help close some of them.

    Poor Reason Two: Building Your Own Observability Product

    Gathering telemetry data can be a challenge, and with OpenTelemetry now handling essential signals like metrics, traces and logs, you might feel the urge to save your company some cash by building your own system. As a developer myself, I totally get that feeling, but I also know how easy it is to underestimate the effort involved by just focusing on the fun parts when kicking off the project. No joke, I’ve actually seen organizations assign teams of 50 engineers to work on their observability stack, even though the company’s core business is something else entirely.

    Keep in mind that data collection is just a small part of what observability tools do these days. The real challenge lies in data ingestion, retention, storage and, ultimately, delivering valuable insights from your data at scale. Chances are, a homegrown solution won’t give you a return on investment that your company would appreciate.

    However, whether you build your own system or use an existing product, OpenTelemetry may be a good fit for your observability stack.

    Poor Reason Three: ‘Vendor Neutrality’

    People I chat with often cite vendor neutrality as a major reason for their interest in OpenTelemetry. While there’s some truth to this, which I’ll touch on shortly, it’s important to take this argument with a grain of salt to avoid over-promising your management.

    If you’re a developer, you’ve likely worked with database abstraction libraries and have probably mentioned to someone that they allow you to swap out the database at any time–using MySQL today and Oracle tomorrow, for instance. While that’s the promise, I’ve never seen this happen in my career. There’s more to consider other than the SQL dialect when switching a database backend.

    In the same vein, the idea of vendor neutrality suggests that you can easily switch your observability backend. While this might be true in theory, in practice, vendor lock-in often occurs on the backend, where people and processes become closely tied to the tool currently in use.

    So, if you believe you’ve achieved vendor neutrality by going all-in with OpenTelemetry, I’d encourage you to think twice and consider building a stronger case. Vendor neutrality should not be your only reason.

    With all that said, it’s time to focus on the good reasons to use OpenTelemetry today. Trust me, there are plenty, and they’re definitely worth considering.

    Good Reason One: Bridging Gaps With Manual Instrumentation

    Nearly every observability tool out there today relies on some degree of auto-instrumentation. This means once you’ve added their respective language SDK to your code, the library will utilize a technique called “monkey patching” to insert observability code that runs automatically.

    At the very least, auto-instrumentation will search for recognized libraries and APIs and then add some code to indicate the start and end of well-known function calls. Additionally, auto-instrumentation takes care of capturing the current context from incoming requests and forwarding it to downstream requests.

    However, auto-instrumentation falls short when it comes to pure userland code, particularly for dynamic languages like JavaScript. It won’t catch your blocking Fibonacci function that’s slowing down all your requests by 50%. In some cases, you might also have to add your own context-propagation logic to RPC calls not captured by the auto-instrumentation.

    That’s where manual instrumentation comes in. In the past, vendors provided an API for their SDK, allowing developers to manually add instrumentation code to segments that weren’t auto-instrumented. This often resulted in code being littered with vendor-specific instructions. This brings us back to the topic of vendor neutrality. While adding a dependency to your project is usually no big deal, it becomes cumbersome when 20% of your codebase is made up of vendor-specific observability instrumentation.

    OpenTelemetry addresses this issue by offering both auto-instrumentation and a vendor-neutral API for manual instrumentation. This allows observability vendors to access the data while maintaining vendor neutrality within your codebase.

    Good Reason Two: Sending Data to Multiple Vendors

    I’ve yet to come across a large organization that relies on just one observability tool. Different parts of the organization have unique needs and perspectives when it comes to data, and it’s rare that a tool designed for SREs satisfies all use cases developers have and vice versa.

    At the same time, it’s not practical to instrument code specifically for each vendor. Doing so would lead to performance issues and other problems, such as double-tracing. For example, if multiple vendors modify an outbound HTTP request to add context, which one takes precedence?

    OpenTelemetry addresses this by offering a unified way to instrument code and multiple integration points where vendors can capture the collected data and send it to their respective backends. As a result, a single application can send data to multiple observability backends with a minimal added performance impact.

    Good Reason Three: Gaining Insight Into Third-Party Libraries and Services

    In an era where many applications depend on third-party libraries and services, gaining insight into all your application dependencies has become increasingly difficult. It’s also challenging for observability vendors to keep up with every new library and service that’s released.

    Traditionally, vendors would try to reverse-engineer these services and apply the aforementioned monkey patching to add in their code. However, since every vendor must do this for each service, it ends up being a lot of redundant work. A key goal of the OpenTelemetry project is to make it easy for infrastructure and library vendors to add instrumentation hooks to their code. This way, their offerings can be monitored without the need for reverse engineering. The observability community is gradually making progress on this goal. One successful example is Istio, which emits OpenTelemetry data that can be easily consumed by observability backends to understand what’s happening inside the service mesh.

    Unsurprisingly, cloud vendors like AWS, Microsoft and Google are among the founding members of the OpenTelemetry project. They share a strong interest in defining a format that allows observability vendors to seamlessly consume data from cloud services. OpenTelemetry Protocol, or OTLP, is set to become the standard for emitting observability data from these services that would otherwise be black boxes.

    Wrapping it Up

    “If all you have is a hammer, every problem looks like a nail.” This statement holds especially true when selecting tools in the tech industry. While there are many good reasons to adopt OpenTelemetry, it’s crucial to approach technology choices pragmatically.

    Avoid jumping on the bandwagon for its own sake; instead, carefully evaluate your use case and assess the available tools. OpenTelemetry is undoubtedly here to stay, and if you’re new to the topic, taking a closer look at the project and adding it to your toolbelt makes perfect sense.

    And don’t forget: OpenTelemetry is open source. Your contribution is always appreciated.

  • The Now and Next of Automation

    The Now and Next of Automation

    Today’s never-ending flood of data has many of us drowning in noise. And while humans are still essential for thoughtful analysis and driving action, it’s no longer possible for a human to parse gigabytes of data alone.

    How do you begin to filter out the noise and then understand what to do with it? How can you get to the root cause of an issue so you can act on and resolve it? Most of all, how can you do all of this while being more productive and driving more innovation instead of constantly putting out fires?

    Automation is the obvious answer. For many organizations, automation isn’t just about efficiency – it’s about survival. Automation can make organizations more agile, resilient, and capable.

    Where you sit within an organization or team, however, often dictates how automation can help with your specific goals or alleviate your immediate pain points. Mandi Walls, a DevOps advocate with PagerDuty, offers some advice on how even less experienced teams can use automation to perform simple tasks, solve problems and improve the work environment.

    We hear a lot these days about A.I. and machine learning, or tools like Chat GPT which to some is a harbinger of robots finally replacing humans. Putting the hyperbole aside, where do you see automation today? Is it still a “nice to have” for engineering teams or a “must-have” to do their jobs effectively?

    Automation is definitely a “must-have.” Manual processes are risky; they can inadvertently introduce too many errors, especially in complex environments. The scope and complexity of modern technical ecosystems is just too vast for teams to effectively cope with using only manual methods.

    This is especially true for teams that develop and manage customer-facing services. Having a successful product leads to more customers, which requires more capacity and creates more complexity. To deliver the kind of performance customers expect, teams need to be fast and efficient. That’s where automation comes in.

    What are some specific types of automation that engineers and IT pros should be aware of?

    Some automation has become more or less ubiquitous, such as tools that enable configuring and building large numbers of systems with little human intervention. Other processes might feel less like “big-A” automation–for example, continuous integration/continuous delivery (CI/CD) pipelines are automation.

    Humans also aren’t manually building many software packages anymore. The use of automation in the software testing process has greatly expanded in the last several years, changing the jobs of QA engineers significantly.

    Is self-service automation – aka true autonomy that doesn’t require human intervention – the ideal end state for a digitally mature organization? When is the best time to jump in?

    Organizations that wait for a perfect opportunity to automate their processes risk wasting a lot of time and resources in the interim. Teams can look at any of the tasks that they regularly perform and assess them as candidates for automation.

    Tasks can be assessed in a number of different ways, but for teams just starting out with automation, seeking tasks that are low complexity and low impact is a strong starting point. Even if we look just within the realm of tasks that might be utilized during incident response, teams might have any number of tasks related to information gathering, log preservation, system diagnostics, and other telemetry that responders run for every incident. There’s no reason to require humans to run those well-understood tasks!

    As teams get more comfortable with creating and using automation, they can seek out more complex tasks to automate. And it’s entirely possible that there will be tasks that teams aren’t able to automate fully! Those tasks might be too complex, require a lot of human input or interaction or have too many edge cases for the team to create automation for.

    Are the principles of automation the same in simple versus more complex environments like Kubernetes?

    The principles are essentially the same, but the constraints and tools may be different. In some environments, a simple shell script might be enough to accomplish our goals. In other environments, we might need to make use of APIs or vendor SDKs to do what we want.

    On that topic, is self-service automation in cloud environments the preferred path?

    Actually, self-service is sort of how the cloud really got going! Development teams armed with nothing more than a credit card got the environments they needed without going through lengthy procurement processes.

    Now that cloud is a critical part of many workloads, organizations are putting more rigorous guidelines in place. The cloud platforms are also much more complex, with more service offerings than in the early days, which makes automation more important than ever. Automation helps organizations ensure that their cloud environments meet their security and compliance requirements, helps manage spend and still provides enough flexibility for all teams to get work done. And with self-service automation, developers can request an environment in the cloud to develop their service and have that service meet all the organization’s standards without having to keep up with all the details themselves.

    What about toil? Can that be fully eliminated through automation, or is some toil still necessary?

    I’m not sure I’d say toil is necessary, as much as it tends to be inevitable. There will likely always be some boring, repetitive tasks that are too unpredictable or unstable to automate well.

    That said, teams certainly don’t need more toil; having too much repetitive work tends to lead to less job satisfaction and higher attrition rates, so teams should be looking to minimize as much toil as possible where they can.

    Is there one myth or misconception, either about automation overall or self-service automation in particular, that you’d like to clear up? What’s the reality?

    First of all, don’t worry. You won’t be able to replace your team with a set of shell scripts! Seriously though, automation isn’t about “doing more with less.” It’s about doing more with the same. Automation is an approach to help teams cope with the day-to-day running of complex environments and will need to be managed as part of those environments. Managers need to make sure they are allotting time for the creation and maintenance of automation in the same way they would for other tools and applications.

    Interested in learning more about PagerDuty? Stop by Booth S49 at KubeCon to speak with an expert or see a demo!

  • Are you Being ‘Nice’ to Your Developers? Think Again

    Are you Being ‘Nice’ to Your Developers? Think Again

    As a developer, you’ve learned your craft. From your fingers comes the magic that builds the applications that run the world. You can literally create something from nothing! And not just software programs. You can create value that means revenue for your company. You’re a revenue machine — no, you’re a god, creating anything that’s needed! That is, you could be if you could spend all of your time writing that magical code. But this dream is not so simple. If you’re like most developers, you’re spending way too much time on other things, such as:
    ● Meetings
    ● Dealing with interruptions
    ● Security hassles
    ● Operations
    ● Debugging
    ● Fighting with infrastructure
    ● Burnout

    Every minute you’re dealing with any of those, you’re not making magic. Because you’re human, that is going to make you unhappy.

    If you really are a developer and not just imagining you are, you already know all of this. Now let’s turn our attention to those of you who are responsible for developers. Because it’s your job to make them happy.

    Yes, it is, if you want them to keep working productively for you and add value. Luckily, it’s within your reach to do so. It will benefit you, add value to the organization and, most importantly of all, the employees themselves.

    Simply put: If you want to get value from your developers, you have to be nice to them. If you expect them to pour themselves into you and into the company, you must first prioritize them and invest in them. Success can only be realized and achieved by a happy balance of developers who are motivated to create.

    Do you know who feels more motivated than anyone else? Who will always go above and beyond?

    Those who are appreciated.

    So let’s get started.

    Increased Productivity and Value

    The most obvious issue is productivity. The reality is that software development can be an arduous mental task, and when developers are unhappy, it will inevitably affect their productivity—especially when they spend mental cycles on things that are not directly related to the task at hand.

    Even if they’re not spending work time searching for another job (or quiet quitting), they’re probably thinking about what could be different and mentally grumbling about it every time something comes up that irritates them.

    By treating developers well and eliminating those annoyances as much as possible, you prevent that problem and get 100% of their attention.

    And there are other productivity benefits, as well. When developers trust their company and their co-workers, it fosters greater collaboration between those developers and business stakeholders. It also engenders greater creativity, which can lead to innovation and value above and beyond what you are expecting them to deliver.

    Retention

    The most obvious issue when it comes to developer happiness is, of course, retention. After all, if you’re not nice to your developers, you should expect them to leave for other jobs. If the Great Resignation taught us anything, it’s that it is human nature to move along if dissatisfied.

    That may not seem like a big deal to you, but think about the implications if your developers are leaving in droves. Never mind the turnover costs, what about the inevitable delays as you bring new developers up to speed? Hiring and training are arduous, time-consuming endeavors. And if turnover is bad enough, you may never be able to actually complete anything because nobody ever gets a chance to build up a good head of steam.

    Compare this to a company with a dedicated team of happy developers who are motivated to grow and innovate for themselves, their team and your organization.

    Which organization do you think is going to come out on top? Yes—the organization with the happier team of developers is probably going to have a competitive advantage—and a big one!

    When developers are happy, they are likely to be loyal to your company. That loyalty means they stay long enough to become experts in what you do, making them more likely to create the kinds of innovations that move the company forward for added value.

    But most of all, can you really afford to have your best employees leave and take all of the knowledge they’ve gained with them, potentially to a competitor? Probably not.

    Maintaining a Good Reputation

    All of this adds up to reputation; get a bad reputation in the developer world and it is going to be hard for you to attract top talent. In a world where technology changes so fast, it’s already difficult to find developers who have stayed with one technology long enough to become experts. You need to take advantage of every tool you can to make it easier. Your reputation can be one of them—if you treat your developers right.

    But there’s another reason to protect your reputation among developers: It could easily bleed over to your reputation among your customers. If you’re a big company, word of your treatment of developers may spread. If you’re not so big, and you have enough developer turnover, some of your former employees may work for prospective customers or know someone who does.

    Today, customers are trying to be socially responsible by buying from companies that ‘do the right thing.’

    Without much effort, you can be one of those companies by trying to foster developer happiness. Ultimately, it’s not that difficult.

    How to be Nice to Your Developers

    Fostering developer happiness doesn’t have to be a hugely expensive proposition. It’s not always about huge paychecks (though they do help smooth out some rough edges). Some things you can do to be nice to your developers include the following.

    1. Provide what they need: Developers should be able to spend as much of their time as possible actually coding; make sure they have the tools that they need so that they’re not having to improvise or struggle with creating infrastructure. For example, engaging a ZeroOps partner can take some of this off their plates.

    2. Eliminate distractions: Even in ideal situations, it can take as long as 20 minutes for a developer to get back into their train of thought every time they’re interrupted. Try to provide an environment with as few distractions as possible.

    3. Foster a training-centric culture: Developers need to feel as though you have their best interests at heart, and one way to do that is to help them learn new skills. And there are multiple benefits for you: For one, it’s much easier to train your existing people in an in-demand technology (such as Kubernetes) than it is to hire someone who already has those skills. For another, training your entire team in these new technologies can unlock creative ways of solving problems.

    4. Help developers understand how their work relates to the customer: While it can be tempting to expect developers to simply do what you ask them to, when they understand why they’re doing it, they’re much more likely to feel invested in the work.

    5. Listen to ideas: Your developers are at the heart of what you’re trying to do. It’s very possible that they have a new way of doing something or an idea for something that could help your company. Even if you don’t end up going forward with the idea, your developers need to know that you respect them enough to listen.

    6. Respect work-life balance: Developers have a reputation for working long hours and many even take pride in it. But it’s not always the most efficient way to get things done. A tired developer works more slowly and makes more mistakes. Be flexible and make sure that you’re not overloading your people with more than they can reasonably accomplish. If your developers have to work 70, 80 or 100 hours a week to meet deadlines, you either need to hire more people (if you can find them) or find a way to partner with other organizations to take things off their plate. (See number one).

    All of these things make for a positive work environment that enables your developers to work their magic for you, day in and day out, making something from nothing and moving you forward the way nobody else can.

  • Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic today at the KubeCon + CloudNativeCon North America conference unveiled a platform-as-a-service (PaaS) environment for building cloud-native applications using Web Assembly.

    Based on the open source wasmCloud distributed computing environment now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), the Cosmonic PaaS gives developers access to a lightweight environment that makes it simpler to quickly build applications that can run anywhere.

    Cosmonic CEO Liam Randall said a PaaS enables developers to achieve that goal by making databases and other non-functional services available via an abstraction layer that eliminates the need for developers to provision these resources themselves.

    Designed to be deployed on any cloud service or on-premises IT environment, the Cosmonic PaaS also enables developers to define their own laptops, cloud resources or entire data center by combing resources to create Constellations. Cosmonic also enables developers to build a Super Constellation by adding customer-hosted components to the services provided by Cosmonic.

    Originally developed under the auspices of the World Wide Web Consortium (W3C) for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The wasmCloud project was created by Cosmonic to provide an open source application runtime that hosts components, written as Wasm modules, that can then be loosely connected to build applications. Cosmonic reports there are now more than 100 members of the wasmCloud community.

    The Cosmonic PaaS extends the capabilities provided by wasmCloud so developers can now more easily build Wasm applications via an abstraction layer defined by Cosmonic. Those applications are also more secure than applications built using previous software artifacts because all Wasm code is executed in a stateless and reactive sandbox that prevents malware from moving from one software component to another.

    It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Every earlier format for building applications locked developers into a specific platform. Wasm is the first software artifact that enables applications to run on any platform, including Linux and Windows, without any modification required.

    Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

    Obviously, Wasm has major implications for DevOps teams, and Randall said Cosmonic is working toward integrating its PaaS with multiple continuous integration/continuous delivery (CI/CD) platforms.

    It’s not clear how quickly Wasm will drive a transition to another era of computing, but the ramifications for how IT is managed in the next era of cloud-native computing could be profound. It remains to be seen how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that there are an increasing number of platforms that will make it possible to more easily embrace Wasm.