By now, almost everyone agreed platform engineering is probably a good idea, in which an organizations builds an internal development platform to empower coders and speed application releases. So, for this latest edition of The New Stack podcast, we spoke with one of the pioneers in this space, Zohar Einy, CEO of Port, to see how platform engineering would work in your organization. TNS Editor Joab Jackson hosted this conversation. Port offers what it claims is the world's first low code platform for developers. With Port, an organization can build a software catalogue of approved tools, import its own data model, and set up workflows. Developers can consume all the resources they need through a self-service catalogue, without needing the knowledge how to set up a complex application, like Kubernetes. The DevOps and platform teams themselves maintain the platform. Zohar Einy - @ZoharEiny Joab Jackson - @Joab_Jackson The New Stack - @thenewstack
By now, almost everyone agreed platform engineering is probably a good idea, in which an organizations builds an internal development platform to empower coders and speed application releases. So, for this latest edition of The New Stack podcast, we spoke with one of the pioneers in this space, Zohar Einy, CEO of Port, to see how platform engineering would work in your organization. TNS Editor Joab Jackson hosted this conversation.
Port offers what it claims is the world's first low code platform for developers.
Rethinking Web Application Firewalls
With Port, an organization can build a software catalogue of approved tools, import its own data model, and set up workflows. Developers can consume all the resources they need through a self-service catalogue, without needing the knowledge how to set up a complex application, like Kubernetes. The DevOps and platform teams themselves maintain the platform.
Application owners aren't the only potential users of a self-service catalogues, Einy points out in our convo. DevOps and system administration teams can also use the platform. A DevOps teams can set up automations "to make sure that [developers are] using the platform with the right mindset that fits with their organizational standards in terms of compliance, security, and performance aspects."
Even machines themselves could benefit from a self-service platform, for those who are looking to automate deployments as much as possible.
Einy offered an example: A CI/CD process could create a build process on its own. If it needs to check the maturity level of some tool, it can do so through an API call. If it's not adequately certified, the developer is notified, but if all the tools are sufficiently mature than the automated process can finish the build without further developer intervention.
Another possible process that could be automated would be the termination of permissions when their deadline has passed. Think about an early-warning system for expired digital certificates. "So it's a big driver for both for cost reduction and security best practices," Einy said.
But what about developer choice? Won't developers feel frustrated when barred from using the tools they are most fond of?
But this freedom to use any tool available was what led us to the current state of overcomplexity in full-stack development, Einy responded. This is why the role of "full-stack developer" seems like an impossible, given all the possible permutations at each layer of the stack.
Like the artist who finds inspiration in a limited palette, the developer should be able to find everything they need in a well-curated platform.
"In the past, when we talked about 'you-build-it-you-own-it', we thought that the developer needs to know everything about anything, and they have the full ownership to choose anything that they want. And they got sick of it, right, because they needed to know too much," Einy said. "So I think we are getting into a transition where developers are OK with getting what they need with a click of a button because they have so much work on their own."
In this conversation, we also discussed measuring success, the role of access control in DevOps, and open source Backstage platform, and its recent inclusion of paid plug-ins. Give it a listen!
Alex Williams 0:08
You're listening to the new stack makers, a podcast made for people who develop, deploy and manage at scale software. For more conversations that articles go to the new stack dot I O. All right now on with the show.
Colleen Coll 0:32
For its founding team has over 10 years of hands on dev x expertise, Port believes every developer deserves a best in class experience while coding and bringing code to production.
Joab Jackson 0:49
Hello, and welcome to the latest edition of the new stack makers podcast. This is Joe Jackson, your host for this interview. And today we're going to be talking about platform engineering. There's a lot of buzz around platform engineering, and the suppose the benefits it can bring both to developers and to the company as well. We just started hearing about this late last year, and we're still getting up to speed on what it is. So we decided to talk to our friends over at port to get a little bit more of a introduction. Today on the episode we have so heart Annie, he is the CEO of port. And we're gonna find out why port is important for platform engineering, and how to implement it and other great things around this emerging concept. So Ari, thank you for joining us.
Zohar Einy 1:45
Thank you for having me.
Joab Jackson 1:46
All right, terrific. Well, first of all, let's get up to speed. You got us? I haven't heard of Port before last year. What is port? How did it come about? And what are your specialties?
Zohar Einy 1:56
Yeah, so basically, port is the first no code, internal developer portal. So basically, by using port, you can build an holistic IDP. Meaning that you can build like a software catalog, bring your own data model to it using the no code, the building blocks, as well as ensuring software maturity, allowing developers with cell service actions, workflow dimensions, and so on. Basically, developers use for it in order to consume everything, DevOps and infra in a self service manner, while the platform engineering are the ones that are responsible to build this kind of internal portal for them.
Joab Jackson 2:34
All right, well, let's, let's all keep that in mind. And we're going to circle back around what the no cu angle in a bit. But first of all, what is your definition of platform engineering?
Zohar Einy 2:45
Yeah. So I really think that, you know, there is a lot of going on about DevOps and platform engineering and the relationship between the two, right? So many people are talking about the fact that DevOps is dead. Right. So I think this brought a lot of into the conversation. But I really think that if we talk about it, like, seriously, for a sec, I don't think that DevOps is dead. But I think it's evolving, right? So I think like DevOps is more of a culture of ownership, right? Like, ideally, it's about being the full owner, that you have the full control over the development lifecycle of an application or a service, either if you are a team, or a developer, right. So but to gain this full ownership, you do you need a Deep Ops knowledge, right? So platform engineering, is about creating this developer independence by providing developers with off the shelf services or tasks that are easy to consume, right. So they can use it in order to build the life cycle they want as an independent unit. So one of the main tools used by platform engineering is the developer portal. So I don't think like DevOps is dead. But I do think that it will become far more efficient. And interesting as platform engineering evolves.
Joab Jackson 4:01
So familiar. So DevOps, is the onus is on the developer to own the whole life cycle. And platform engineering is the operation side of a company, giving developers a standardized, I guess, tool set platform to which they build their apps
Zohar Einy 4:20
Exactly. Like you'll have platform engineering, which provides like all the different services that developers need in order to be owners of their application. And as part of the development team, they might have someone with a DevOps knowledge DevOps engineer or either another engineer that manage the upside of application, and they will be the ones that will use the the services provided by the platform engineering, and this is being done by an IDP, essentially.
Joab Jackson 4:49
Nice, nice. IDB is an internal developer platform. Now we've had internal developer portals for years now. What is the difference between the two?
Zohar Einy 4:59
Yeah, so it's So, you know, there is a lot of going on, you know, some people say, Portal platform, you know, what's the differences between the two? I think there is a big difference. And the short answer is that both portal and platform coexist, right? But there are two very different things. So imagine the platform, like as all of your existing implementations of DevOps, right, let's see ICD Kubernetes, pipelines, getups, and so on, and so forth. So this is all the, like, the platform side, some kind of reusable components that are your all your DevOps implementation. And the developer portal is about making all these reusable components and automations, accessible and consumable for your organization, right? allowing people to interact with it and to consume it without the cognitive load of understanding every bit and byte behind the scenes. Right. So so by accessible, I mean, providing this layer of visibility into the software components like microservices, environments, deployments, different DevOps processes with this visibility layer, and by consumable, which is the second part of the IDP is allowing them to interact with with a portal by using self service actions, right. So they can perform all kinds of actions directly from the portal, and get everything that they need from provisioning a micro service, and environment permissions to a cloud resource. And it arise by using the self service part of their portal
Joab Jackson 6:30
traffic. So this sounds a bit like a software catalog just collection of micro services. Is this a software catalog? Or how do I describe it?
Zohar Einy 6:39
Yeah, so there's a couple of definitions. So there is the software catalog and the micro service catalog. But I really think that both of them are not comparable, right. So a micro service catalog is just like one instance of a software catalog. So a micro service catalog covers only a subset of what's inside a broader software catalog. So as a result, micro service catalog is usually very opinionated, showing just a list of microservices and their respective metadata about their lifecycle. But a software catalog, yeah, is much more than that. Because we live in a little bit more complex world, right? You want to bring more things into the software catalog and bring your own data model into it. So you know, you would like to also reflect development, environment and cloud resources and permissions, and many more things that are related to your organization, and things that speaks your language and like custom entities into the catalog. So it's really important to think about the software catalog is something that you can bring your data model into it, and to reflect the catalog that you need for your organization. So a software catalog is a more generic, more broad way to a broader way to see us catalog. And the Microsoft stock catalog is just like one shape or form of one specific use case. All right,
Joab Jackson 8:03
terrific. Terrific. So how does this developer self service work? I'm a developer, I show up in the morning, I maybe, you know, turn on Visual Studio or, or whatever development environment I have. How does the Self Service How do I build an app through cell services? Put it out like Right? And use, please feel free to use ports own platform as an example? Right?
Zohar Einy 8:28
Okay. So first of all, self service actions is not like just like creating an application or anything like that there are many different user flows or developers flows, that leads them into using cell service, right. So it can be really anything. So I saw customers that are using cell service to provision development environment, or allowing developers to get permissions to cloud resources, or to make the deployment directly from from port, and so on, and so forth. So they're using port 80 as their portal in order to consume all these services, while they're using ports solution, and integrate it with their existing platform, right. So they want to be the owners, like the platform team wants to be the owners of how things is going on behind the scenes, right. So they use sport in order to create the experience for their users, either like provisioning microservice, or anything of the examples that I just gave. And they tell birth, what automation behind the scenes, they would like us to leverage because they already have it, they already implemented a lot of things. So we want them to we want to empower them, these automations with the portal to make it accessible for developers. And thus, it allows the organization to democratize all the existing automations as part of their platform and giving developers a way to use it. Yeah, that's
Joab Jackson 9:46
the other part of it. You mentioned automation. What is workflow automation? Yeah,
Zohar Einy 9:51
so this is actually a very interesting part. I think that is we see more discussed nowadays. So you know, many people think about IDP Something that is being used by the developers, right. But we saw that an IDP is not only used by the developers it also used by DevOps, because they also need a software catalog. But the third persona, which is very interesting is the machines themselves, right? They're also users of the platform. So imagine like, like MASH, let's take a machine, for example, right? It can be a CI CD job that wants to make a CD process, right? Or a build process. So they also want to know, like, what is the maturity level of a service before they make the deployment, right? So they went, they want to query port with one API call, and say, Hey, is this maturity level sufficient enough, right? If not fail the build, and let the developer knows if got failed, giving them like a very clear reason why, and if not make it successful. So this is just like one example of one automation, you can build on top of your software catalog. But you can also like automatically revoke resources, like permissions, right. So if you have a TTL, for a resource in the catalog, it can be automatically revoked by get notified by port that the TTL go to zero and run an automation behind the scenes that auto terminates it for you, right. So you don't have to have like sketchy databases or glue code around to make it clean up for your resources. So it's a big driver for both for cost reduction and security best practices.
Joab Jackson 11:26
So an additional charge of building out these machine workflows, you said that might be DevOps, specifically, not so much the developer or the administrator.
Zohar Einy 11:38
Yeah, so the ones that will define the workflow automation, can be either the application owner in the team, so they wanted to be responsible for creating the lifecycle of the application. So they can use it in order to make queries against the software catalog, to build automation that they want. And it can also be the platform engineering team themselves, setting up the right automations to make sure that their organization is using the platform with the right mindset that fits with their organizational standards in terms of compliance, security, and performance aspects.
Joab Jackson 12:12
Traditionally, developers have been very individualistic and choosing their tools. They showed a strong preference for the tools they want. How does the platform accommodate that or address this kind of developer preference?
Zohar Einy 12:26
So this is, first of all, was the developer this is absolutely true. Like, like, naturally, you want to gain like the control of everything, I want to choose the technologies, I want to be responsible. I want to know everything about anything, right. So I think platform engineering came to help the developers choose how much they want to get in depth of stuff, right. So essentially, developers are being provided with a good platform. So they can be provided with very, really good services off the shelf that they would like to use. And this will help them gaining trust of the things that they get out of the box, right. But if they want to know more about like, what is happening behind the scenes, how this automation took place, how this data got into the software catalog. So a well designed portal can reflect them with the information that they want, as a curious persona, right. And it's all about trust, essentially, you want to gain trust from your developers. So you need to give them the visibility into what happens behind the scenes, but not you know, but not overload with too much information, making them overloaded again.
Joab Jackson 13:31
So it's almost by refining the palette to just the needed tools, it actually gets gives developers a certain amount of freedom, because they don't have to worry about bringing in the kitchen sink and everything else. Here's the tools they work with. And then they can concentrate on doing their job.
Zohar Einy 13:47
Exactly. And they also see think that it's perfectly okay, if a developer wants to contribute to the platform that is being managed within the organization, right. So I think the platform team needs to be open to suggestion from the developers of what needs to be inside the platform. But they do need to stay in control and not giving too much freedom, because essentially, they need to think like product managers, and sometime product managers knows a little bit better what is right or wrong for their users.
Joab Jackson 14:15
So that sounds like some good benefits for the developer. But there's also the operations team who are in charge of running the external facing platform. And now imagine platform engineering. This approach offers them benefits as well,
Zohar Einy 14:29
right? Essentially, what we saw is that the IDP is also being used by by the operations team, the DevOps team, because, you know, the developers gets a software catalog with a simplified visibility layer that gets them into the good understanding of what's going on. But the DevOps team also manage a lot of different assets. So the software catalog of the DevOps is much more complex and more granular than a developer portal catalog, but they also need to make sense and to bring order into their into their software. components. And sometimes we see it results into CSV files, and things like that. And another part of an another use case for the DevOps. So imagine, like a DevOps, get a lot of tickets today for creating all kinds of resources and all kinds of automations to be executed on behalf of the of the developer. And they need to document these kinds of automation results into a software catalog. So the self service part needs to play with the software catalog so that DevOps can be in charge and be in control of what's going on and what provision and then what is the state so they can get comfortable with allowing developers to be autonomous as an individual.
Joab Jackson 15:42
Nice, nice. All right, fantastic. Now, we've been covering backstage the open source backstage project for a while this is developer platform. And recently, they announced a paid plugin program. And I'm very curious to see what ports take is on that program and on backstage in general.
Zohar Einy 16:01
Yeah, so I think it makes a lot of sense, the paid plugins they offer around software maturity, role based access control, and the rest of the rest are really important building blocks of an IDP. So indeed, some of the paid plugins are the core to developer portals, right. So role based access control is a big deal for both for the software catalog side and from the developer self service action side. So on the data access side, you don't want to reflect everything to anyone, right? You want to encapsulate the access and to make sure that everyone gets what they need. And the maturity part is even more interesting, right. So measuring the Production Readiness or health, within the context of a service, or a resource, will become a primary method of prioritizing work and creating a culture with good standards engineering quality inside. But I think it's really interesting, because backstage is an open source project. But it indicates that backstage is not a classic open source project. It is a commercial, it has commercial interest. And thus, it needs to be evaluated accordingly as a commercial product.
Joab Jackson 17:06
Terrific. So yeah, let's let's dive into that for a second. Now, I'm a CEO of my company. And I like what you're saying, I like what board is saying, How does port interact with the customers? Is this? Is this a cloud based offering? Is this software? How much of it is just off the shelf? And how much is it? Do I have to consult with you guys? or explain to me what's going to happen? If I'm interested as a customer?
Zohar Einy 17:31
Yeah, that's a great question. So basically, port is a SaaS solution. So you can get started right away, we have a self service option to try it out yourself as a no code platform. So again, port is not opinionated, we are not telling you how your software catalog should look like or your cell service actions look like. We provide very good like templates and building blocks from best practices we saw in the industry industry, so you can use them off the shelf. So you can get into port and you're still you can start assemble very quickly, your software catalog and your service sections. And basically, we do help you if you need any help, we are available on Slack and by email. But once you get the gist of it, you can get up and running really quick. And the average time to set up into something that is valuable is around 30 minutes.
Joab Jackson 18:20
All right. And I believe we're also going to be posting on the new stack, a demonstration video of how this works. And we'll link to that from the write up from this particular podcast. And so you can take a look in depth how this works. Finally, I'm very curious, this is a really merging field for us. And it's still I guess, still kind of a lot of changes happening. Where do you see internal developer platforms? Two years from now? Or what's the future here?
Zohar Einy 18:54
So first of all, I have to say that we are facing a huge revolution. And we are entering the platform era, right? Like this is a new era, we were had moved from it to DevOps. And now we are moving from DevOps with platform engineering, right. So I think in two years from now, IDPs will become standard with every organization. So imagine like, you'll have the good provider, see ICD infrastructures, code, cloud and internal developer portals, which is going to be a very important platform within your stack. So it will be used not and this is like in terms of the like, where it goes. And I really think that the IDP is not just for the developers, but will be used by almost every persona in their organization, including security analysts that needs to understand vulnerable packages and where they're currently running. Also salespeople that needs to provision a demo environment, product managers, QA is developers, SRE is platform engineers, DevOps, and the sky's the limit.
Joab Jackson 19:59
Thanks All right, fantastic. Fantastic. I think we're about running out of time. But this is so much good information here. And yeah, take a look at we have a number of articles being sponsored by board that will be coming out in the next few weeks that will explore platform engineering in depth. So this is the first step, go to the new stack and check out the additional material that board has provided for more information. And so thank you so much for taking time to get us up to speed.
Zohar Einy 20:32
Thank you so much. Thank you very, very,
Joab Jackson 20:34
thank you, listeners for tuning in our viewers as you're watching, and we'll see you again soon at the new stock
Colleen Coll 20:43
ports founding team has over 10 years of hands on dev x expertise. Portfolio, every developer deserves a best in class experience while coding and bringing code to production.
Alex Williams 20:57
Thanks for listening. If you like the show, please rate and review us on Apple podcast Spotify, or wherever you get your podcasts. That's one of the best ways you can help us grow this community and we really appreciate your feedback. You can find the full video version of this episode on YouTube. Search for the new stack and don't forget to subscribe so you never miss any new videos. Thanks for joining us and see you soon.
Transcribed by https://otter.ai