7 Reasons Internal Developer Platforms Fail (So Yours Won’t) – InApps Technology is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn 7 Reasons Internal Developer Platforms Fail (So Yours Won’t) – InApps Technology in today’s post !
Read more about 7 Reasons Internal Developer Platforms Fail (So Yours Won’t) – InApps Technology at Wikipedia
You can find content about 7 Reasons Internal Developer Platforms Fail (So Yours Won’t) – InApps Technology from the Wikipedia website
Bruno is the CEO of Shipa, a Kubernetes developer platform. Bruno previously held software engineering roles at Juniper Networks, HTBASE, Oracle and IBM.
Internal developer platforms offer organizations a path for improving developer productivity while leveraging Kubernetes architectures. Productivity is an increasing challenge: In a recent survey from Stripe, developers self-reported that just 68.4% of their time is productive. Organizations implement microservices architectures in an effort to unlock that tremendous potential for greater productivity while also pursuing more rapid development, increased scalability, independent small team deployments and other benefits.
But here’s the catch: The complexity of these architectures adds new difficulties that can hamper the productivity of developers. By building a developer platform internally, organizations hope to streamline developer activities to foster more focus on product development and innovation. Unfortunately, respondents in the Stripe survey identified building custom technology as one of the top hindrances to productivity within their organizations. And many companies that do pursue a custom internal developer platform abandon that initiative within two years.
Here is why internal developer platforms can fail:
1. Building a Developer Platform Is Complex
Teams that expect a custom developer platform to be the silver bullet for their productivity challenges are often in for a rude awakening when the complexity of the task comes into focus. Once teams begin onboarding the many developers, applications, services and clusters at work across their organization, custom scripts and automation can fail to meet those intense scalability demands. Soon, developers complain about poor experiences and the impact on productivity. Deployments slow down. Post-deployment visibility and management may even become more complex than without the platform. Crucial governance and controls across applications and teams also become harder to manage and maintain. In time, these factors pressure organizations to abandon the developer platform altogether.
2. No Workflow for Handling Governance Needs
The same governance and controls are not appropriate for all teams and applications. Often, DevOps or platform engineers must now introduce controls for governing and maintaining security, role-based access controls, resource consumption, network policies and more. The complexity of those tasks increases exponentially with scale, increased by each service and team involved. When teams find that complexity overwhelming, developer platform projects will struggle.
3. No Observability or Post-Deployment Management
Developers aren’t finished when code is deployed. For developers to truly achieve fast and flexible development, continuous delivery instrumentation must enable deep observability, control and governance over applications and their dependencies post-deployment. A lack of strong capabilities in this area is a fatal blow to many internal developer platforms.
4. No Integration with Existing Technology Stacks
Developers tend to be extremely adaptive and proficient at onboarding new technologies and tooling. DevOps and platform engineers similarly adopt infrastructural changes as needed, to meet evolving business and application requirements. An internal development platform must also be prepared to integrate with new development tools and leverage new infrastructure. Development platforms built without adaptive capabilities may serve developers well today, but will see their utility decrease over time and eventually become obsolete.
5. Unclear Roles and Responsibilities
An increasingly common case I see: There’s excitement to build an internal development platform, but no one is excited to support it. Microservices architectures and Kubernetes push infrastructural tasks into application delivery and management processes, requiring developers to take on challenging ingress rules, charts and other complexities in which they aren’t experts. The purpose of a development platform is to abstract these tasks and insulate developers from that complexity. However, the lines of responsibility between developers and DevOps or platform engineering teams often become blurred. When this happens, developer productivity suffers, defeating the purpose of the platform. For this reason, distinct roles and responsibilities, designed to allow developers to focus on development, are essential to the success of a developer platform.
6. Failure to Treat It as a True Product
Organizations make a mistake by treating the internal developer platform as a one-time DevOps or platform engineering team initiative made of assembled custom scripts. (And too often tying an internal developer platform to just a few people with requisite knowledge, meaning the project will suffer if those team members move on). To be successful, the platform needs to be treated as a living, ongoing product. The approach here should be to conduct regular interviews with developers and other users to address their requirements, establish a support team, deliver improvements on a set roadmap and evangelize for the platform to win developer support. Advocating for developers and meeting their needs is the cornerstone of success for any developer platform initiative.
7. Cost Becomes a Concern
Many teams begin pursuing an internal development platform with the idea that money is no object when it comes to investing in new business capabilities to meet their “unique” needs. But, after these projects have matured for a year or more, reality sets in. The platform absorbs 25% of DevOps or platform engineer bandwidth. It’s not core to the business and doesn’t add business value. Most importantly, it becomes clear that developer productivity needs aren’t actually all that unique and could be met with external solutions for far less cost and effort. Once that truth is clear, organizations make the tough but honest choice to scrap their expensive years-long investments and move on to solutions and tools that more efficiently enable their developers to, well, develop. (It’s why we built Shipa.)
Avoid These Pitfalls
Building and maintaining a successful developer platform internally requires particularly careful foresight, planning and execution. By steering clear of the issues detailed above, it is plenty feasible and advantageous to implement a cost-effective strategy that enables developers to realize newfound productivity and continually drive results for your business.
Lead image via Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.