Tag: platform engineering

  • AWS re:Invent 2023: Cloud Development Environments

    AWS re:Invent 2023: Cloud Development Environments

    Speaker 1: This is Techstrong tv.

    Shira Rubinoff: My name is Shira Rubinoff. I’m the chief cybersecurity officer with the Techstrong Group. I’m here with Rob Whiteley, CEO of Coder. Rob, it’s a pleasure to be with you here today.

    Rob Whiteley: Yes, thank you so much for hosting me. This is great.

    Shira Rubinoff: Rob, we’ve had some great conversations, and I’d love you to share with the audience who is Coder, what is your story? Please explain who you are, how you came about. Let’s go from there.

    Rob Whiteley: Yeah, I hope you have about two hours. No, I’m just kidding. I’ll give you the short version.

    Shira Rubinoff: Sure.

    Rob Whiteley: Coder is a cloud development environment solution or CDE is sort of the industry terminology. What that basically means is we’re trying to solve the problem of helping enterprises shift their development from local laptops to more of a cloud native where you’re asking developers to access the cloud and develop there.

    The idea is developing locally on laptops is expensive, it’s error-prone, and you often end up with the, “Well, it worked fine on my machine, but then when I ship the code, it doesn’t work.” So we try to solve that. We’ve been around for about seven years, and we actually started life as an open source project called Code Server, which is an IDE. We’ve since grown to have a more complete solution in this CDE space.

    Shira Rubinoff: Well, that’s wonderful and certainly very needed. Let’s dive into the security benefits of this because there are many and much are needed. I’d love to for your audience to understand that.

    Rob Whiteley: Yeah. Yeah. No, I’m super excited to be here because I think it’s an underappreciated element, right? So to me, if I step back, the reason why companies are investing in cloud development is for developer productivity, right? Only about a third of a developer’s time is actually spent coding. The remaining two-thirds is doing operational stuff, administrative. By going to the cloud, you get productivity gains. Great. That’s why I came.

    Why I stay is usually a security benefit. What I mean by that is so many of our customers have told us that, “Well, a developer left his laptop in a cab,” or, “She did not have access when she was on the road.” So by putting things in the cloud, it allows you to connect from any device, and it gets source code off of laptops. That’s now a major source of intellectual property for most companies. The applications run your business, and so to get source code off laptops is a huge benefit.

    That’s just the beginning. That’s usually what triggers. So for example, one of our large banks, it was actually the CISO that brought us in solely to solve that problem of getting source code off laptops.

    Shira Rubinoff: That’s a huge problem.

    Rob Whiteley: It is. I think that alone is worth it, but once you’re in the cloud, I have better access controls, I can do role-based access, I can be more thoughtful about encryption and how I secure it and whether I enforce certain forms of SSH. So there’s a lot of benefits, and I don’t think customers realize that until they’re underway. Part of what we’re hoping to do is front end that conversation a bit more. Security is actually a major driver on shifting to the cloud. It’s not just the productivity gains.

    Shira Rubinoff: Certainly. Let’s talk about the no extra steps that we were discussing earlier. The human factors piece of security is a massive piece that organizations and technology companies and all types of security, and certainly with coding there’s many different steps to do in order to get to what you want to do. Where there’s extra steps and people are in a rush, they don’t want to do that. They want to circumvent it, they want to break it, they want to leave it open so they don’t have to think about it, leave passwords around, all sorts of things. So please tell me what Coder does and why.

    Rob Whiteley: Yeah. No, it’s great. In fact, Coder’s co-founder Ammar, has a phrase that developers are inherently lazy. He doesn’t mean any disrespect by that. It’s just they’re-

    Shira Rubinoff: It’s everybody, right? It’s the multitasking. I wouldn’t just call it coders. Coders are fabulous.

    Rob Whiteley: But I think part of the coding ethos is do things as elegantly and simply as possible. That’s what makes good code. If you shift the security burden to the developer, like we in the industry love this concept of shift left, which basically means shift things earlier in the development lifecycle. What that really means is you’re asking the developer to do more, to take on more steps, to build security into his or her workflow. But that is against that ethos of being lazy and trying to do things efficiently.

    I think one of the things that we’ve noticed is, let’s flip that on its head a little bit. Let’s shift to the developer right. What if we could make the developer more productive and just make security seamless built into it? They’re not having to worry about it. How does that work? Well, if I’m logging into a cloud to do my development, I’m inheriting the entire security infrastructure I’ve already put in place for my cloud, my firewalling, my access controls, my encryption, my backups, everything that keeps that environment that I’ve probably already put in production. I now automatically shift those security controls to my development environment, which again, used to be laptops, and I was very dependent on making sure my antivirus or my mobile device management kept that device secure. My developer had to battle that. They had to toil, they had to update things, they had to make sure.

    We reduce that toil, but more importantly, we take the security off the plate, off the mind. If you access the cloud, it is more secure. Period. Full stop. So that’s what makes I think this work better as opposed to having to send developers through more security training. Yeah, you’ve got to write clean code and have fewer bugs, but that is what the developer should be focused on, not complying with your security policies, which is too much toil.

    Shira Rubinoff: Certainly. My background is heavy in security, and I will tell you the best technologies out there have the security built in and have the no extra steps. You want something that’s better, stronger, faster, without the onus being on the user, which is the developer or somebody who has to be responsible for it. You want to make sure they’re doing their job great and they’re doing their job well without having to burden them with thinking about those extra pieces.

    Just think about our daily lives. Moving a million miles an hour, and certainly the developers, that’s something they have to keep on top of mind, they have to be answering everything, running around and traveling, everything they’re doing. The last thing you want them to think about is, “Wait a second, did I do all these steps?” Because most of the time they haven’t. So that’s an excellent thing that you had certainly built in.

    In terms of the competitors out there that you see or you come face when you’re at the marketplace, what would you say your main differentiators are in the marketplace?

    Rob Whiteley: Yeah, sure. I think for us, there’s two primary ways these solutions get deployed. They’re self-hosted, which means you download the software, that’s Coder. So we start as open source, and you can upgrade to the commercial if you want, but you own the software, you deploy it. Or you can consume it as SaaS. The problem with this space in particular when deployed as SaaS, which is pretty much all of our competitors, is I now have a lot of very sensitive metadata about my developers. What environments are they using? What tools are they using? How often are they in those? What languages? What versions? That all could be used to exploit the application. So that metadata is now flowing out to some third party cloud, which by the way, I had to poke a hole in the firewall just to do, only for them to poke a hole right back into my environment in order to provision the developer workstation.

    For us, keeping it all hosted inside your cloud, whether it’s on-premise or public, we don’t care, is what has been the biggest inherent differentiation. I love SaaS. SaaS is the future, but in an early adopter market like this, there’s a clear leaning towards self-hosted. Most of these organizations can run software as well as a cloud provider anyway, and so they would rather just do it themselves. So that’s difference one.

    The second one I would just say is the majority of solutions in this market, and again I’ll call this the CDE or cloud development environment, is they’re designed with the operator in mind, the backend DevOps team that has to own the infrastructure. We’ve tried to approach it from the developer. What’s going to create the best developer experience? Because one of the things that you hinted at is if you make things difficult, it will not get adopted.

    Shira Rubinoff: Correct.

    Rob Whiteley: We don’t live in a world where we can force developers anymore. They pretty much have to opt in. So if it’s not a good experience, they just won’t adopt that structure.

    Shira Rubinoff: Well, that’s the mindset of developers, and it’s very good that you’re honed in on that. A lot of people are like, “Well, this is what we do for everybody else.” I like the fact that you’re really honed in to what do the developers do? How do they like to work? And work along the path of that. When they talk about security in general or how operating anything really works is think about your user base, work the way they work, and build the security around that.

    Rob Whiteley: Exactly.

    Shira Rubinoff: Don’t try to force them into something. So that’s key.

    Rob Whiteley: Yeah, exactly. So our mindset’s simple. If you make the developer experience clean and you take security friction out of it, they will adopt it. Then you finally benefit from all those advantages we talked about. The worst thing I think you could have is you deploy the solution and they just continue to work on their laptop as if nothing’s changed because they found the new thing too difficult.

    Shira Rubinoff: Right. True. I know you had some really interesting announcement that came out in September. I’d love you to reiterate that and tell our audience a little bit about that and also hint about some new things coming down the pike.

    Rob Whiteley: Yes. Yes. We’re very excited.

    Shira Rubinoff: If you could give us a little bit of a sneak peek here.

    Rob Whiteley: Yeah, back in September we announced something called the Coder Registry. Think of that as a marketplace for Coder plugins. The reason why that’s important is because we believe in developer choice. Developers should choose the tools that make them most productive. What we’ve done is we’ve created this registry so that anybody in the developer tooling ecosystem can write a plugin to Coder. If you want to be able to provision your tool to a developer … Because we sort of own that developer eyeball, if you will … We are the thing they log into to do their work so we can merchandise different tooling. If you want to use a code gen AI tool for assistance, we can make that. By doing these plugins, we’ll create a much more, I think, robust ecosystem where it is not on the developer to do that integration.

    We’re just a tile they can click on now to say, “I want that tool.” But we still give the platform team the chance to curate that. If they don’t want to introduce that tool, then they can just kind of exclude that from the developer’s pick list. That registry is what we announced. We’re building more and more third party support for that. That’s sort of the big thing. So that was big announcement.

    What I can say for next year that I think is going to be most exciting is we’re really trying to focus on how do we make these platform teams that are responsible for making developers productive, for helping secure source code, and really equip them with a much more advanced set of insights. One of the things that Coder does is we collect a lot of that metadata, and like I said, we don’t beacon it to the cloud. It stays local to your environment.

    Shira Rubinoff: That’s important.

    Rob Whiteley: Well, that’s a rich data set. There’s a lot we could do with that data set to help make operators’ lives easier. One of the things we’ll be looking at next year early is how do we expose that in a way where maybe you can figure out, “If I increased the amount of compute, what would that correlate to for an outcome?” By kind of front-ending that we can make it a lot easier for operators. Again, if we can remove friction from the developer experience, they will adopt it. So that’s part of what we’re looking at.

    Shira Rubinoff: Well, that’s very exciting. Everyone stay tuned for that announcement coming up. Anything else you want to add for our audience? Anything that they should take note of or any helpful hints around anything around the AWS Conference or your company itself that you’d like to share with us?

    Rob Whiteley: Yeah, I think the biggest thing would be … So the cloud development environment is new. It’s an emerging market. I think a lot of companies are not necessarily investigating it because they think it’s not right for them, or they don’t want to fit force developers to change behavior. I think what we’ve experienced is every customer that does it has quickly expanded. To me, my biggest call to action is just go look at it. I mean, it’s free. It’s open. You can get started. I’m not even asking you to purchase anything.

    But I think just shifting the behavior from local to cloud, getting those security benefits and demonstrating that win back to the business is the first step in I think what’ll be a sea change in arguably the last mile the cloud has not effectively touched yet, which is developers. Production environments have been in the cloud for a while now. Development environments are next. So I think now’s the time to get started.

    Shira Rubinoff: Well, that’s wonderful. Thank you so much for sharing your insight with our audience.

  • Survey Surfaces Significant Platform Engineering Gains

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

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

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

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

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

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

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

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

  • KubeCon 2023: 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.

  • Daytona Unfurls Developer Environment for On-Premises IT

    Daytona Unfurls Developer Environment for On-Premises IT

    Daytona has launched a development environment for on-premises IT environments that provides all the benefits of a cloud-based alternative.

    Ivan Burazin, CEO of Daytona, said the company’s namesake alternative to platforms such as GitHub Codespaces enables DevOps teams to retain control and better secure the intellectual property created by developers while simultaneously making them more productive.

    The Daytona platform enables developers to instantly start coding by accessing a development environment based on a set of preferred tools and frameworks, he added. Platform engineering teams looking to scale DevOps workflows can then take advantage of fine-grained access controls and advanced security features across developer environments spanning hybrid IT environments, said Burazin.

    He added that the ability to centrally manage development environments is designed to appeal to organizations attempting to improve developer productivity in highly regulated industries that are now allowed to use cloud-based alternatives. This is becoming a more pressing issue because as regulations become more stringent, organizations are trying to move source code off developers’ individual laptops that are more easily breached than a server environment, noted Burazin. The challenge is striking the right balance between enabling flexibility and centralizing the management of developer environments, he added.

    Of course, many of those organizations could opt to construct their own internal developer portal (IDP) to accomplish the same goal, but in most cases, that would prove expensive to both construct and maintain, noted Burazin.

    The same core team that created Codeanywhere, a cloud-based integrated development environment (IDE), is also behind the development of Daytona. The issue that organizations previously encountered when attempting to shift development to the cloud is that, in addition to regulations that forbid it, developers could not easily customize their environments. The Daytona platform is designed to enable more flexibility without sacrificing control, said Burazin.

    Arguably, organizations are more focused on developer productivity today than at any time in recent memory. Developers typically spend as much as 70% of their time maintaining environments versus writing code, so there is a clear need to reduce the level of toil. Reducing that toil doesn’t guarantee developers will spend more time writing code, but it does create the opportunity. DevOps teams are, as a consequence, being asked to eliminate as many of the bottlenecks that conspire to reduce developer productivity as possible in furtherance of that overall effort.

    Developer productivity issues are not going to be resolved overnight. Developers will not always be immediately inclined to give up control unless it’s conclusively proven that a platform engineering team will be responsive to their needs. The cultural challenge is finding that fine line between reducing friction while still giving the developer the sense that they can add a tool to a workflow that enables them to innovate.

    One way or another, change is coming to DevOps workflows. Each organization will need to determine how quickly that change will occur, but in the absence of any meaningful change, it’s clear they won’t be able to compete against rivals capable of producing higher-quality code faster.

  • Internal Developer Platform (IDP) Reference Architectures

    Internal Developer Platform (IDP) Reference Architectures

    If you’ve been following the DevOps space recently, you’ve probably noticed the excitement brewing around platform engineering. Despite uncertainty in other areas of tech, it seems like platform engineering is poised for growth—Gartner even expects that by 2026, 80% of software engineering organizations will have established platform teams.

    The platform engineering idea hinges on an internal tooling system known as an internal developer platform (IDP), which platform teams own and operate and is exposed to developers to improve their efficiency, satisfaction and release fluidity. IDPs have been the talk of the town. But what does an IDP actually look like? What sort of components are they usually composed of?

    Well, at PlatformCon 2023, McKinsey representatives shared a reference architecture for building out IDPs. This framework was modeled after hundreds of internal platforms and could be a helpful benchmark for other organizations as they begin developing and standardizing their internal developer platforms.

    Below, we’ll examine the sample IDP reference architecture and its components. We’ll also have a refresher on the platform engineering concept and offer some expert tips on overcoming potential obstacles while implementing platform engineering and IDPs.

    Why Engineer Internal Platforms, Why Now?

    First, for those new to the idea, let’s explain what platform engineering is. I’ve previously defined platform engineering as “maintaining an internal self-service platform that serves the needs of developer consumers.” The practice doesn’t necessarily supplant DevOps, rather, the experts I’ve spoken to view it as the next evolution.

    This trend is essentially a response to developers overseeing more and more aspects of software life cycle management. Complexity in enterprise-level software delivery workflows has escalated in the last decade, leading to what The State of Platform Engineering Report describes as “increased cognitive load on engineers.” This is negative, as it could lead to shadow operations and burnout.

    The fact is, most developers require the same sort of technologies, which could be standardized across the board. For instance, take the consolidation around containers and Kubernetes, infrastructure-as-code and the need to implement similar build configurations and security policies across applications.

    By outsourcing the maintenance of tools for shipping and running cloud-native applications to a common platform, you take the burden off developers and free them up to code. Also, by centralizing DevOps tooling, you can enforce more governance and build out internal standards. Which should help reusability and overall deployment agility … at least, that’s the promise of it all. 😉

    Sample IDP Reference Architectures

    So, let’s turn to some real-world examples to see how this is being implemented. Mike Gatto, senior DevOps engineer, McKinsey, shared an internal platform reference architecture for AWS-specific environments:

    McKinsey’s Internal Developer Platform reference architecture

    As you can see, the architecture is divided into these subgroups. At a high level, they perform the following functions:

    • Developer control plane: This is the version control, where developers publish their code. They provide a workload specification (in McKinsey’s case, a Score file) that codifies specific configurations.
    • Integration and delivery: This includes the CI pipeline to build application code into a container and publish it to a registry. This notifies the platform orchestrator to initiate a build. Then, resources are provisioned. This area also includes a CD pipeline and infrastructure control plane.
    • Monitoring and logging: This plane includes tools for observability, analytics, and application performance monitoring.
    • Security plane: This area includes tools for secrets management, policies, and security vetting.
    • Resource plane: This plane encompasses cluster management, database tools, networking, and messaging architectures.

    “By separating developer and platform team concerns and allowing them to control the respective areas they’re experienced in separately, without requiring too much overlap,” said Gatto, “we’re making deployments more compliant and better aligned with client initiatives.”

    Humanitec has also created internal developer platform reference architectures for GCP and Azure, displayed below.

    IDP Reference Architecture for GCP
    IDP Reference Architecture for Azure

    PlatformEngineering.org has also expanded McKinsey’s original IDP reference architecture with a tooling landscape that adopts the same umbrella subgroupings but includes other pluggable tools.

    The Internal Developer Platform tooling landscape

    Roadblocks to Developer Platforms

    Starting from a blueprint could be a big help to rapidly construct IDPs. Yet, there will still be some potential roadblocks associated with adopting an internal developer experience platform. One of them is creating common platforms that actually cater well to all environments.

    “You can not and should not try to please everybody,” said Kaspar von Grünberg, CEO and co-founder of Humanitech. “Platform engineering is an 80/20 game.”

    “Platform organizations often face a lot of pressure when it comes to meeting demands for building more services that are both agile and agnostic to cloud and data center environments,” said Venkat Ramakrishnan, VP, product management and engineering, Portworx by Pure Storage. “At the same time, almost all platform engineering teams are understaffed while facing the need to support large application development initiatives and developer teams twice their size.”

    Tips to Get Platform Engineering On Track

    Reference architectures for various clouds could help cater IDPs to different scenarios. But outside of that, it will take a product mindset approach to strategically accept feedback and iterate the platform. This will involve doubling down on developer experience and adopting cloud-native foundations that can scale.

    “Platform engineering teams must consider adopting Kubernetes as it enables them to manage and deploy applications in production at scale, without having to manage applications at the individual level,” added Ramakrishnan. “Additionally, it may not be realistic to expand platform engineering teams alongside growing platforms, so teams should also consider leveraging automation and self-service capabilities to help them better manage projects at scale.”

    Is ‘You Build It, You Run It’ Dead?

    The idea of ‘you build it, you run it’ is starting to look a little antiquated next to the new and shiny platform model. It’s tough to say, but I’ll be keeping an eye on this area to see if all the effort to standardize the internal engineering approach pays off!