White Papers

White Paper: Platform Engineering Challenges and Solutions

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

Contents of this Issue

Navigation

Page 1 of 5

© 2020 Mirantis Inc. All Rights Reserved. Information is subject to change. | www.mirantis.com OpenSearch — you thought I was going to say Elastic, right?), building APIs that let application developers consume and use services in fully-abstracted ways. They can help SREs create operational APIs and automation to martial and/or deploy and monitor around these services on (or behind/underneath) K8S. And they can then let actual Cassandra experts tweak and tune the Kubernetes operators that maintain, monitor, and scale the specific components (and/or services) themselves. • Deep standardization of tooling and best-practices — In this Kubernetes-centric environment, clean separation of concerns is more about actual (business-meaningful, explicable to laypeople) concerns, and way less about tooling silos. Everyone can use pretty much the same tools, and there can be lots of sharing, standardization, policy, etc., that: » Makes the work of one group findable and (in general terms) comprehensible to other groups. Read: easier collaboration, faster personnel onboarding, less confusion- in-crises, faster times-to-resolution. » Limits the blast radius of weirdness. Sure, the Cassandra experts can break a Cassandra (hopefully only on staging). But if they're coloring within lines established by the platform engineers, nothing else should fail. And new application pods that need Cassandra should find a healthy one. • Abstraction and outward simplification — In this model, APIs and automation hide complexity and efface minor differences between functionally/semantically equivalent services within and around the platform, and further APIs determine how these services are exposed to developers and work. Life is simpler because of this: portability at the application layer, in application-lifecycle management tooling, etc., is increased. Potential lock-in factors are reduced. • Kubernetes-ification of services — Kubernetes provides a model for declarative configuration, strong contracts about how basic things will work, growing standards for integrating third-party solutions (e.g., LB, DNS, ingress, CNI, CSI, etc.) plus plenty of ways to customize around this model. Platform engineers and service engineers should, in many cases, be able to collaborate (efficiently) so that all platform components and provided services work "just like Kubernetes." But There's a Problem The model described above is full of promise. But it's only straightforward and efficient when an organization can make hard choices and place heavy bets on a particular spin and configuration of Kubernetes, and on a particular environment in which Kubernetes can run. If you make those choices, platform engineers can then work in a finite domain and solve each problem once: anything after that is about optimization and new features (i.e., building value).

Articles in this issue

Links on this page

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