Developers today are responsible for a lot more than the developers of 10 years ago were. Not only do they write code, but they’re managing quality, security, incidents, observability, infrastructure, and more.
This has led to a lot of tool sprawl in development environments. Developers need an IDE to write the code, an incident management platform to fix issues, a platform for managing the infrastructure they are deploying to, an observability platform to track performance, and more. And sometimes, developers are reliant on people in other areas of the business to tackle some of those responsibilities, which can slow things down.
Out of this complexity, in the past few years a new type of tool has emerged to help developers get a better handle on all of these different things: the Internal Developer Portal (IDP).
“Additional responsibilities are getting pushed to developers, and so they have just more and more on their plates, in architectures that are more and more complex, and a tool chain that they have to use that is, again, just more and more complex, fragmented,” said John Laban, CEO of OpsLevel, a provider of IDP software.
According to Zohar Einy, CEO of the IDP company Port, an IDP is a layer on top of all other applications that gives developers easy access to all the different components and information they need to do their jobs.
And the technology is really taking off; Gartner predicts that by 2026, 80% of large software companies will have platform engineering teams, which are teams that create the IDPs.
To give a practical example of what an IDP looks like in practice, an IDP could be connected up to Datadog to display key metrics through a widget or dashboard. It doesn’t provide actual access to observability features, but if the developer needs to dive deeper, the IDP provides a clear path into Datadog to leverage the specialties of that platform.
“A developer portal is not a replacement for all the tools, but it’s a front door,” said Einy. “It gives you the most important things that you need to consume from all the other tooling, showing just the most important data with context, just the most important actions inside the portal. But from there, you can dive deeper into the different tools that specialize in the specific area.”
Essentially it provides a contextual place for all of those different tools, and then you can go from the portal to all these different paths.
The three pillars of an IDP
According to Laban, there are three pillars to IDPs: visibility, standards, and self-service. Visibility is all about getting a handle on the complexity of the software development toolchain, both in understanding what’s out there and in how those tools interoperate with each other. This includes knowing about their APIs, documentation, who owns them, their dependencies, and more, he explained.
“And of course, you need to know where to find the metrics, dashboards, the logs, all the different things that you might need to operate each of these services,” said Laban.
He explained that most organizations today don’t really have a strong handle on that, or if they do, the information is stored in places like a spreadsheet or wiki page.
The second pillar is standards. “Once you do have that understanding of what’s out there, the next question is – okay, we have all these different engineering teams, they are all building software somewhat differently, and it’s released independently and autonomously. In our current model of how we work, are we all building software the right way across the organization?”
According to Laban, IDPs provide a way of visualizing these standards and measuring them across all services.
And finally, the third IDP pillar is self-service, which is about making it easier for developers to get what they need in order to build their software.
“With that comes templating and scaffolding for new service creation, being able to generate new services, checking repos, using all the up-to-date libraries, as well as providing easy self-service actions for developers. So rather than having to create tickets and wait on other teams, they can ideally do things for themselves, whether it’s provisioning hardware or environments or even setting the service up in other tooling,” said Laban.
Advice for getting started
Kenneth Rose, co-founder and CTO at OpsLevel, believes that one way to ensure success is to start gradually by picking one problem and solving it rather than getting too excited and trying to connect everything up at the beginning. “The challenge there is that it’s kind of too much, and you end up spreading yourself really thin,” said Rose. “Where we’ve seen customers be most successful is to look first at the catalog setup, then we can talk about standards, and once we have this foundation of a catalog that we know is accurate and up-to-date, then we can also focus on developer self-service.”
Einy believes that successful IDP implementation can be achieved by viewing it as an Agile process versus a Waterfall one where once it’s set up you never adjust it.
“What you have to do is to treat the portal as a product, and to implement the portal in phases and make it an Agile process,” he said. “So you implement an MVP, you roll it out to the end users, you collect feedback, and then you reiterate, you create another version, get feedback, you make mistakes, you fix, you improve.”
It’s also not a one-size-fits-all thing, so what works for one company might not work for another. For instance, Netflix and Citibank may both have an IDP, but those are two very different companies with very different tech stacks and very different needs, so their IDPs will also look very different, Einy explained.
“Netflix might allow developers to do one click and to change the production for the entire customer base. At Citibank it’s more of a restrictive process because it’s highly regulated and there are approvals to be made, and there is a different DNA of what it means to be an engineer for such a company,” said Einy.
Different companies may also have different stakeholders utilizing the IDP so it’s important to ensure that the portal is dynamic enough to meet the needs of all stakeholders, he said.
He also believes being dynamic in the sense of scalability is important so that the IDP you have today can evolve into the IDP you need in the future.
“You need to make sure that you choose a solution that allows you to face the test of time, and meet your current needs, your current DNA, and can go with you and not hold back the innovation for the company, but rather to dictate the innovation and push everyone forward,” said Port.
And finally, Rose said that another key to success is to leverage automation when it comes to cataloging and mapping out the services, which can help speed up the implementation timeline.
You may also like…
Analyst View: What’s new, what’s now, and what’s next in platform engineering
The challenges with platform engineering don’t have to do with engineering
The post IDPs may be how we solve the development complexity problem appeared first on SD Times.
from SD Times https://ift.tt/3isNEyH
Comments
Post a Comment