February 2nd, 2022
What Internal Developer Platform Teams Can Do For DevOps
by Robert Boyd, CTO of Guide-Rails®, overseeing technology and engineering for our Software Delivery Platform.
Mature DevOps practices have shown potential to help organizations improve their interactions with customers and outpace competition, but many organizations are still struggling to see results. One option to enable these practices is using an internal developer platform to streamline your entire software delivery lifecycle.
In this article, let’s look at who manages these platforms internally, what these platforms are, the “build vs. buy” question and how to get started.
What are internal platform teams?
In the early 2000s, SysAdmins were the ultimate guardians of any system. Developers sent any program or piece of software to the SysAdmins, who would then determine the action and how they could deploy it. By the end of that decade, the SysAdmin role became less necessary as cloud-native came into play, allowing developers to get resources at any moment.
While cloud-native brought a slew of benefits in terms of availability, scalability and ease of use, it also brought complexity. The more organizations became digitized, the more complex they became.
Now development teams must interface with a slew of new technologies, distributed across suppliers and runtime environments. The sheer number of technologies can completely overwhelm developers. When developers need to understand both their product and a detailed process with complex tooling, the cognitive burden of juggling both is detrimental.
Firms began exploring alternative options after realizing DevOps was still not progressing the way they wanted. Prominent tech companies created internal platform teams to help them grow quickly while ensuring that their systems were dependable and manageable. They also ensured that the developers’ end-user expertise was seamless.
If a platform team treats the platform as a product with developers as their client, developers can off-load complexity. These developers can now exclusively focus on their product and clients. Success of these internal platform teams has been documented in Puppet’s annual study.
What’s in a platform?
There are many different options and pathways for an organization to follow in search of their “platform product.” Terms used today are broad-reaching, including (but not limited to) a value stream delivery platform, DevOps platform, continuous integration platform, internal developer platform, software delivery platform and more. The design can run the gamut from being 100% developed in-house, a platform framework to build upon or the “consolidated vendor” approach.
Regardless of the chosen path, the platform should give developers access to self-serve settings, deployments, databases, logging and whatever they need to operate their apps. It also needs to meet organizational needs for tool standardization, policy compliance and process transparency. In order to scale, it must balance flexibility with standardization so developers can get what they need.
When it comes to the capabilities of the platform, start from the viewpoint of the end-to-end process. This list may seem overkill to some, but all areas are essential for long-term success and scale.
• Plan and create: agile planning, backlog management, project management.
• Integrate and verify: continuous integration, automating all types of testing (unit, API, acceptance, etc.).
• Deploy and operate: infrastructure automation, immutable environments, cloud options, feature flags, rollbacks, etc.
• Monitoring: logging deployments, alerts, tracking production, etc.
• Security and compliance: SAST & DAST scans, container scanning, audit trails, traceable pipelines.
• Team collaboration: information collected, then presented as actionable information to the different individuals involved.
• Value stream metrics: information collected and distilled into metrics to manage and improve the process.
• Platform governance: capabilities around securing the software supply chain such as RBAC, data management, etc.
Then the challenge presents itself to the platform team. They need to bring these capabilities together as a system across the process. They need to make it easy for developers, Ops and all other stakeholders to use with a self-service UI. In addition, the capabilities need to be tailored to the organization, for example being able to work with both cloud-native and legacy applications.
Should you build or buy a platform?
Building a platform is not easy. Over the past 10 years, I’ve spoken with many firms who have invested hundreds of millions to build their own platform only to miss the mark and start over. Also, if the platform is built for today but does not have flexibility to change and meet future needs you may be starting over in two years.
If building most or all of the platform in-house, a significant factor to consider is who builds it. Only a handful of firms (most big-tech) have successfully built their own platform, and the number of individuals with this experience is limited. Without this expertise and big picture vision, the risk, time required and investment are massive.
Unless you are Google, the build vs. buy question should be fairly obvious. Why recreate the wheel when an off-the-shelf solution can be used right away?
How do you make the change to use an internal development platform?
A key first step to set the organization up for success is executive sponsorship. The funding must be present, but the leadership and commitment to make the change are critical. An initial pilot may be possible without executive sponsorship, but scaling to the organization will require this support.
The platform team needs to be well designed, not just a few former “DevOps Team” members but a blend of individuals that have different yet complementary skills relating to the process. Understanding the technical capabilities for different tools is the starting point, yet product management and the soft skills for working with the different dev teams are equally important. A well-rounded team can successfully face challenges as the rollout expands.
Finally, the recommended approach is to start small and expand. As the first few teams see success, the door to increased collaboration opens and can be capitalized upon to create cultural changes as new teams are added. As the platform provides important information, day-to-day management, plus overall improvement efforts, can be leveraged further for making the change towards a trust-based development organization that innovates.
Original posting on Forbes Site