IDPs: A Piece of the Developer Experience Puzzle
Cloud native software development, thanks to its decentralized nature, can almost appear to be a virtuoso solo act from a single developer. But to orchestrate the symphony, and take advantage of the promise of the cloud’s speed, agility and flexibility, many organizations invest in internal developer platforms (IDPs) as a piece of the cloud native development puzzle.
Not only are IDPs a way to pave the path, speed up onboarding and reduce complexity, friction and cognitive toil, but these platforms are a piece of a bigger and more fundamental concern: the developer experience.
The Evolution of the Cloud Native Developer Experience
In 2021, Gartner predicted that by 2025, more than 95% of new digital workloads will be cloud native (up from 30% at the time of this prediction). Whether that prediction materializes, cloud native is clearly becoming mainstream. The ability to take advantage of distributed services for rapid scale and flexibility convinced early adopters to evolve from a monolithic, and often slow, approach to software development to a decentralized microservices paradigm.
The cloud native evolution split applications into smaller, more manageable, interconnected pieces, which fundamentally changed the developer experience. This supports the developer’s ability to move faster with less risk but also introduces new complexities and different threats to the mix.
Has the move to cloud native and Kubernetes been a net positive for the developer experience? The answer depends on the organization, its needs and how teams decided to introduce cloud native into their day-to-day work. Some organizations started as cloud native and gave developers control of the full software life cycle, and some developers welcomed that level of control.
However, developers working for other organizations prefer a much clearer delineation of responsibilities and relief from outside-of-scope tasks, such as infrastructure management. Either way, the complexities of Kubernetes and building cloud native apps have led to active discussions about platform engineering and the need for internal platforms to shape and codify the necessary abstractions developers need to build applications.
Assemble Puzzle Edges: Internal Development Platforms
For the 1% developer (early adopters, cloud native natives, for example), an IDP might not seem as needed as in an organization where the 99% developer (the majority) works, but centralizing aspects of what is otherwise quite decentralized can provide benefits, particularly for the nebulous, varied developer experience. An IDP can be a framework, or the edges of the puzzle, helping to create guardrails for developer self-service capabilities. That can both empower developers and contribute to the ultimate goal of speed – of both development and releasing new applications and features to end users.
Let’s assume that an organization is well into its cloud native journey and has evaluated the return on investment, identified the addressable obstacles and understands the expertise needed to build an IDP that suits its developers. Oft-cited obstacles to getting started and being successful with Kubernetes can include everything from operational tasks being shifted to developers, which demands an extended developer skill set, to architectural and infrastructural complexity. Each obstacle diverts developer focus from their core functions and can slow down development productivity which affects the ultimate end goal: shipping software.
At its core, the platform must first give application developers exactly what they need to jump in and remove bottlenecks so they can code and ship their software.
Second, the platform must serve its stated purpose: addressing the needs of the developers and the organization. Will the platform support your organization’s business objective? Organizations at the vanguard of cloud native development can benefit tremendously from creating a self-service IDP.
This approach empowers developers to own the full software life cycle because this is the role they are accustomed to from Day 1. This approach is particularly beneficial for cloud native organizations that don’t have as much, if any, legacy code and application infrastructure to manage.
The reality today, however, is that the vast majority of developers (the 99%), work with multiple kinds of legacy — infrastructure, tools and processes — that make up the creation and operation of applications for stalwart institutions, such as banking, retail, insurance, healthcare and more. Stringent security measures are put in place to safeguard against sophisticated threat vectors as these organizations cannot afford the financial impact and reputational damage associated with a potential breach.
However, cloud native development has made strong inroads. This has largely been possible because development organizations have begun to figure out how to put complex pieces to work effectively for them within the confines of their organizations in the broader cloud native world. In deciding how to adopt cloud native, organizations have identified the keys to developer success and productivity. There are, arguably, two basic keys: one is developer tools, which can potentially be part of an IDP; the second is understanding the need to support the developer experience on a cultural level.
With an IDP, development teams can gain access to the same tools and insights, which contributes to speedier onboarding to shorter time to first commit, from better developer collaboration for faster feedback using productivity and collaboration tools to overall velocity of development and frequency of deployment.
Numerous cloud native tools exist to accomplish all of these things — from both commercial and open source platform solutions and service catalogs to more specific tools that do everything from aid in collaboration to bridging the gap between remote clusters and local machine (another cloud native development challenge).
Selecting the right tools and bundling them in an IDP can make a developer’s job significantly easier, a key part of improving the developer experience. An IDP can also deliver multiple positive effects for organizations. Developer productivity and happiness produce faster product and feature releases. IDPs foster standardization, leading to reduced maintenance costs and more scalable setups.
Ultimately an IDP developed to serve the needs of a given organization can deliver relief to developers who do not necessarily want to become part-time platform engineers, can establish consistency in processes and workflows, and can enable safer, faster software deliveries. But before we get ahead of ourselves, we can’t overlook one bigger-picture consideration when introducing an IDP: culture.
Don’t Forget the Cultural Aspects: Beyond the IDP
Creating and asking developers to use an IDP makes a lot of sense, but only if the cultural piece of the puzzle is considered as well. Bring developers into the IDP planning and development process. Ask what they need to not only make their jobs easier but what will aid in their ability to develop software that meets the expectations of their organizations’ customers. Two-way communication is critical not just to the usability of the IDP, but to the overall developer experience.
The positive developer experience is forged in acknowledging the complexity developers routinely face and actively creating ways to navigate that complexity. This starts with communication and continues with internal developer advocacy – or formal support within an organization for improving the developer experience.
With collaboration, the cloud native community converges around best practices, tools and processes, develops learning and sharing opportunities and eventually elevates its network(s) of experts and practitioners.
Making IDPs Part of Your DX Strategy
Cloud native developers and the organizations in which they work are turning to internal developer platforms to ensure that development teams have what they need to ship software faster and safely. There is no one-size-fits-all IDP, and organizations have a lot of flexibility in designing the right IDP. As with cloud native development itself, creating the right IDP to balance business goals and developer experience will rely on understanding how the pieces will fit together to complete the puzzle.
