Cloud Computing (Akamai)Cloud Native ComputingDevelopersDevOpsFeaturedPlatform EngineersT3M: TFiR Topic Of The MonthVideo

Platform Engineering Is The Next Logical Step From DevOps | Pavel Despot, Akamai

0

Guest: Pavel Despot (LinkedIn)
Company: Akamai Technologies (Twitter)

In this episode of TFiR: T3M, Swapnil Bhartiya sits down with Pavel Despot, Senior Product Marketing Manager at Akamai Technologies, to share his insights on where the market is headed, particularly in the DevOps and platform engineering space.

Key highlights of this video interview:

  • Platform engineering is not different from DevOps — it’s a natural evolution from the DevOps maturity model which, broadly speaking, has 5 stages: 1) no DevOps, 2) you’re just starting off, 3) you’ve got the basics and you’ve got everything going, 4) you start measuring things, and 5) you start optimizing what you’re measuring. Platform engineering is the next step insofar as reusing everything for different groups, projects, and workloads.
  • What’s driving people to move to either DevOps or platform engineering is the constant pressure to deliver software efficiently, whether it’s releasing a new product, a new feature, downloading updates, or rolling out a patch.
  • The goal of platform engineering is to improve velocity, address bugs more quickly, get your patches in places, decrease failure rate, and because you catch things earlier in deployment, you can roll back more quickly.
  • To be a successful platform engineering team, you need to: 1) define the platform capabilities, 2) define the interactions, 3) understand upfront what you’re going to provide and agree on the use case, 4) make sure the expectations and what you’re providing are aligned, and 5) once you deploy it, you have to keep it running.
  • Is DevOps dead? No, not at all. Switching over to platform engineering or staying with DevOps depends on two things: 1) how far along are you in your maturity model. If you’re halfway up the DevOps ladder and just starting to implement some observability, you probably shouldn’t just jump up and grab two rungs up until you’ve got optimization; and 2) how much reuse are you going to get out of it. If you have a heterogeneous set of technologies in your stacks and your clouds, trying to kind of unify it all in one platform that does everything for everybody will likely be a lot harder. Instead of improved velocity and time to restore, it becomes almost a product management problem.
  • Advice for organizations: Be very thoughtful about technology choices. Technology isn’t always about the most popular thing. Always ask why you want to do something, e.g., build a platform or deploy code quicker or rip something out. It doesn’t mean you shouldn’t do it, but you should be able to answer why. If it serves a purpose and that purpose is valid, then do it.

This summary was written by Camille Gregory.