 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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-in-Chief Joab Jackson hosted this conversation.
Port offers what it claims is the world’s first low-code platform for developers.
Port: Platform Engineering Can Be the First Step in System Automation
With Port, an organization can build a software catalog of approved tools, import its own data model, and set up workflows. Developers can consume all the resources they need through a self-service catalog, without needing the knowledge of 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 self-service catalogs, Einy points out in our convo. DevOps and system administration teams can also use the platform. A DevOps team can set up automation “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, then 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!
