White Papers

White Paper: Platform Engineering Challenges and Solutions

Issue link: https://read.uberflip.com/i/1387898

Contents of this Issue

Navigation

Page 2 of 5

© 2020 Mirantis Inc. All Rights Reserved. Information is subject to change. | www.mirantis.com Sadly, however, the result of making these choices is often some form of lock-in. "Kubernetes and what it runs on" is the biggest part of "the platform." And changing the platform itself can be complex, time-consuming, and expensive. Think about running a fully platform-engineered Brand A Kubernetes setup on an in-house IaaS datacenter — say, VMware. And now you want to switch to hybrid cloud and build the same thing on AKS: providing all the same platform services, and using those to support the same service-level APIs for devs. It's doable, sure. But before the job is done — before your applications are trivially portable f rom the VMware environment to the AWS environment — you'll end up a) learning more about AWS than you ever wanted to learn, and b) touching every part of your platform and service engineering stack. Add another public cloud, bare metal cloud, edge server model, and your platform and service engineers are learning new ways to do what should be commodity things (or hiring more and more folks with inf rastructure-specific skills), and solving the same problems again and again. And each time they solve them, that's another codebase, toolkit, procedural model, maybe monitoring f ramework everyone needs to learn to work within, and maintain. As your multi-cloud builds out, this all eats time, increases risk (more, and more divergent, platform-specific automation tooling and code always means more risk), potentially increases attack surface (more "unknown unknowns"), and locks down the agenda of platform engineering to fundamental enablement, rather than adding strategic value and helping everyone above them in the stack ship code faster. Plenty of Mediocre Solutions Of course, DIY-oriented end users, cloud service providers, vendors, etc., have stepped up to offer solutions to parts of this growing snarl of problems. Some examples: "We have the technology!" — Given the wide availability (and elegance) of multi-cloud capable declarative and hybrid declarative/procedural deployment tooling (waves to Pulumi!) out there, plenty of people feel capable of building out a container multi-cloud without external or product support. There are 99 problems latent here: the biggest is that it focuses effort and demands exhaustive learning (or hiring expertise) not just about Kubernetes, but about underlying inf rastructure specifics. DIY multi-cloud tends to drag platform engineers down into the underlying inf rastructure instead of focusing on making life easier for service engineers. It works best (arguably: it only works) when the platform engineering stack is shallow and simple. In fact, DIY approaches reinforce a misunderstanding about the role of platform engineering: i.e., that it's really just inf rastructure-engineering-for-K8s. "Who needs platform engineering? Here's your platform!" — Covering up Kubernetes with a heavy PaaS layer seems to obviate the need for platform engineers entirely. But unless PaaS is run as an application on K8S (at which point, it creates a higher-order

Articles in this issue

Links on this page

view archives of White Papers - White Paper: Platform Engineering Challenges and Solutions