Implementing an IDP: Lessons Learned

‍

Kubiya.ai hosted a panel of experts to discuss their lessons learned from implementing Internal Developer Platforms. This blog post shares key insights from our discussion. 

‍

Panelists:

‍

Jon Skarpeteig: Jon is the Tribe Lead Global Platform at Signicat, based in Trondheim, Norway. He has been part of the team designing and operating an IDP over the past 3 years in Signicat. The IDP is designed to scale DevOps way of working in our organization, serving regulated industries which also includes Platform level services (auth/authz with OPA, SMS/Email gw, CRM integrations)

‍

Pavan Kumar: Pavan is based out of the SF Bay Area. In recent roles, he’s led engineering teams focused on modernizing infrastructure and evangelizing platform engineering principles. His most recent group spearheaded efforts to thoroughly evaluate IDP solutions, and they ended up choosing one that was open-source, customizable, and cloud-native.

‍

Samir Cury: Samir Cury has worked in many different aspects when it comes to infrastructure. His experience started at the time when DevOps managers were still called Systems Administrators. He also managed High Performance Computing setups for Particle Physics Experiments but quickly got into Config Management, Big Data, Microservices and Kubernetes.

Rob Fletcher:  Co-Founder at DevZero. He previously worked at Uber when the development of devpods started. Prior to that he was at Facebook and has experience from the manager and developer perspective and first hand experience how platform engineering can improve workflows 

Overview of IDPs 

IDPs are a way to fuel the concept of platform engineering at scale. It is a system to launch systems as a service -  SaaS operating system if you will. It has many different infrastructure components. Here is a nice example from Adobe. It can be useful for driving standardization through voluntary adoption. It has many elements including:  pipelines, container platform, developer portal, observability and more.

Why did your teams decide to adopt an IDP?  

As tech stacks become more complex and DevOps has evolved, and teams move to multi-cloud, more microservers, increased importance of security infrastructure as code etc - DevOps managers are experience bottlenecks - the back up of tickets and toil - repetitive tasks are slowing down productivity and impacting teams in all sorts of ways. 

Specific include:

• Want to run an lean organization 
• Time spent on answering questions, meetings, troubleshooting - that was taking away from progress on the roadmap. Looking for ways to cut down on time spent here. 
•  As our architecture scaled in complexity with microservices, multi-cloud, and infrastructure as code, our developers were bogged down in repetitive infrastructure tasks. 
• Environment provisioning, access controls, configuration and secrets management and deployments became huge bottlenecks that stunted productivity. 
• An IDP provided guardrails through standardized workflows and boilerplate scaffolding while enabling self-service access. 

What factors did you evaluate when you are looking at IDPs?

Focusing on understanding what will most enable developers to do their job faster and have fun while doing it is important. Oftentimes, this materializes in an IDP that is easy to use but also allows developers to customize the look and feel of their workflow to fit their needs. At the end of the day, developers are artists and all have their favorite paint and paintbrush. 

Key points:

• Flexibility 
• Improve developer happiness
• Ability to mature and adapt over time
• How will it mesh with internal culture
• Defaults are important - if it there is no starting point, developers will be overwhelmed

What about Backstage?

Backstage is a great option if you prioritize fl, integrations, and open source community. The setup was smooth in Pavan’s experience and the ecosystem of more mature than we realized

We underestimated the work to migrate legacy systems into Backstage's architecture.  There is a learning curve around customizing Backstage beyond just installing plugins.

What worked in driving adoption of your IDP?

Learning from product management. Make sure you solve a real problem, so that your IDP will be loved by some. Don't make something mediocre that tries to anticipate every need. Focus on the few first customers, and make sure to delight them!

What about AI and LLMs in IDPs?

LLMs can augment how we get the job done in a positive way – for example configuring environments and understanding build steps are perfectly suited for AI to assist with and to help maintain as the environment changes over time. With a vast knowledge base, an AI based configuration system can help tame the heterogeneity of development workflows.

Virtual persona bots tailored to different engineering roles and workflows is an interesting area with much potential. For example, a team could easily spin up a personalized SRE bot to provide ops assistance, or a QA bot for testing advice. By capturing tribal knowledge from senior engineers and encoding it into conversational personas, organizations can massively scale expertise. Junior developers could get high-quality mentorship on-demand through natural chat. As workflows evolve, the bots are quickly updated with the latest best practices.

Biggest takeaways from implement an IDP

Pavan

• In summary, prove value simply first, make it a community-driven culture shift, engage developers continuously, and architect for flexibility.

Rob

• An important takeaway is understanding that development and the workflow around development changes over time as a company evolves – this means any meaningful IDP solution needs to be able to adapt with the changes in an easy way. An IDP that drifts significantly from the workflow in the future becomes more of a headache than a painkiller for developers.

Jon

• Make sure you get good backing from management. One way to help with this is measurable success. This could be with DORA metrics. Collecting these from before and after introducing your IDP will help show value also outside your Tech department. Setting up an IDP can mean a big investment! And you will be fighting the laws of gravity pulling towards your existing revenue centers. 

Samir

• Flexibility is key. The initial design and use cases but you may not have thought of something initially so make sure to have an avenue for feedback. Be able to grow as your tech stack changes. Keeping an open mind for expansion will take your ruther in your journey. 

‍