 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Platform engineering is the newest sociotechnical discipline to arise in response to the cloud native world. As the process of designing, building, and maintaining workflows and tools for software engineering organizations, platform engineering helps drive consistency and speed up common tasks.
While developer relations typically focus on external developer customers, platform engineers are building services to better serve the needs of internal application and operations developers. An evolution of business agility and DevOps, platform engineering looks to break down more cross-organizational silos, while reducing the cognitive load of application teams and duplicate work. This is usually achieved via the creation of the internal developer platform or IDP.
Read on to learn what platform engineering is, when it’s needed, and how to leverage it to increase team velocity without increasing developer burnout.
DevOps looks to create application teams that are able to build, test, release, maintain and operate a single domain. But, the further down the stack you go, you’ll find a lot of cross-company duplicate effort. Because application teams were built to more rapidly deliver value to end users — not to learn how to orchestrate Kubernetes, to spin up multicloud environments or to worry about security and compliance. As a maintainer of platform-as-a-product framework Kratix Abigail Bangser put it, these are non-differentiating activities, but not unimportant ones. And, as the tech industry moves more cloud native, they are extra burdens for release teams.
In comes the internal developer platform team to the rescue! Platform engineering is the discipline of building workflows, toolchains, platforms and documentation to support application teams in their delivery of business value. The platform engineering team sits on the horizontal, serving cross-company needs so the vertical application teams’ can serve their end users. It focuses on enabling an application team to get up and running without the cognitive overload and overlap of each team learning to be cloud native. Ideally, it enables them to do it without a human in the loop always having to approve things either.
“One of the goals of platform engineering is to promote self-service to enhance developer velocity and free them from being dependent on people and processes to do their job,” David Melamed, Chief Technology Officer of the Jit DevSecOps orchestration platform, told The New Stack.
A la Netflix’s guardrails not gates, platform engineering teams look to create “golden pathways” where teams are able to choose from a pre-approved selection of tools, resources and compute, to help them get what they need to run their applications. The platform team takes care of the cloud, so app teams don’t have to. But that doesn’t mean they’re off the hook for essentials like security — it’s just these teams now have the pathway to automate and run security tooling.
Platform engineering isn’t for every company. In fledgling startups, usually everyone does a bit of everything and that’s OK. But it doesn’t scale. Once you have two or more app teams, you may start to discover duplication of efforts. As you scale up more, so does this repetition. That’s when you might start thinking about hiring a platform engineer to tackle that toil.
There’s no secret recipe to “the platform.” It will vary by organization. The best way to get started on your platform engineering journey is to have a conversation with your engineers. This could kick off with a survey on bottlenecks or developer frustrations or by platform engineering embedding and pair programming within application teams. Some teams, like at CyberArk, borrow application developers to help build aspects of the platform.
You can also kick off your platform planning by looking at the tools you already have, Bangser recommends, like Slack, Trello and Jira. Where do you see the most complaints or requests? Where are your developers finding the most uninteresting repetitive, manual work? Where’s your toil? Start looking to solve those shared concerns first.
Just remember, at every step of your platform process, it’s essential to get internal developer feedback early and often, iterating as you go. Look to over-communicate. Offer your internal customers product demos over free lunch. Incentivize early adopters. And never forget to document your platform to encourage self-service and independence.
These are all tactics to make sure you are building a platform that your colleague developer audience will actually want to use.
And don’t forget to factor in other stakeholders, like making sure you are tying the platform to the overall business value delivered. Namely, make sure your C-suite understands what you are building and why as well, or your platform might not be adopted at all.
Platform engineering looks to, hopefully, deliver on more of the promise of DevOps. After all, developers are creative knowledge workers and are best put to use solving interesting problems and delivering value to your customers — not fixing problems outside of their domain.
Benefits delivered by platform engineering include:
Again, an internal developer platform isn’t necessary for all organizations. But as your infrastructure gets more complex, platform engineering can help abstract out what’s unnecessary for your developers to get their jobs done.
While platform engineering is still an emerging discipline, there’s already a lot of different options to get started. Part of it depends on how much flexibility your application developers need and where you want the platform to sit.
You can certainly build your own platform, but that costs a lot of overhead. You could also use an out-of-the-box IDP tool but that might not include the flexibility needed to best serve your internal customers. It may be that the complexity is abstracted out by a developer portal that facilitates self-service. You can also use a plethora of open source options as well as CI/CD pipeline tools. Here’s an overview of the currently available platform engineering tool suite:
Also under this umbrella of platform engineering tooling, you will find a wider array of tooling dedicated to abstracting out Kubernetes complexity.
DevOps — the bringing together of development and operations — is the practice of breaking up monolithic architecture and teams, in order to create smaller, autonomous teams that can build, deliver and run whole applications. Platform engineering is the discipline of abstracting out any infrastructure or toil that distracts from DevOps teams delivering their domain. Site reliability engineering or SRE teams are dedicated to helping both the DevOps and internal platform teams by increasing reliability, scalability and, often, security. DevOps focuses on the development side, SRE focuses on the operations side, and platform engineering focuses on internal development enablement.
All three disciplines understand that it’s not all about technology — everything stands on the sociotechnical pillars of people, processes, and tech.
Both site reliability engineering and platform engineering benefit from the three ways of DevOps:
And any successful SRE or IDP strategy hinges on cross-organizational collaboration and understanding, which DevOps’ silo-breaking enables.
As the open source Internal Developer Platform guide puts it, “An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service.” It can act as the source of truth or one-stop shop for everything your developers need to get up and running. It also acts as a contract between your platform and application teams. The IDP is the engineers’ self-service layer on top of your infrastructure. It aims for the highest level of developer self-service, and it should speak to both technical and business teams. Ideally, it’s where engineering teams have everything they need to build and operate.
That depends. How self-efficient are your engineers? How much of their work is dedicated to toil versus delivering business value to your end users? How complex is your infrastructure? If you have more than a few application teams and are running at least partly in the cloud, you may benefit from the perspective of a platform engineer. Many organizations start with a platform engineer embedded within application teams, learning what they need to do their work faster and more securely. From there, you may want to scale to a whole internal developer platform team, which then may build its own platform or leverage an array of IDP tools.
Some say DevOps is dead, and it is time to embrace platform engineering. We would argue that platform engineering helps deliver the promise of DevOps. Some would argue that DevOps has become a rote and overused term, but that its foundation of observation, experimentation, and feedback toward continuous improvement is needed now more than ever.
“Platform Engineering: What You Need to Know Now” explores how DevOps culture has led to the adoption of internal developer platforms. Pave a golden path for developers that delivers value faster while creating a better DevEx. Get your free copy!
