Chapter 16. Platform Abstractions
Many times we have seen organizations adopt a build it and they will come approach to designing and building a Kubernetes platform. However, this philosophy is usually fraught with risk as it often fails to deliver on the key requirements of the many teams (e.g., development, information security, networking, etc.) that will be interacting with the platform, resulting in rework and additional effort. It’s important to bring the other groups along on the journey and ensure that the platform constructed is fit for purpose.
In this chapter we’ll cover some of the angles you should consider when designing the onboarding and usage experience for other teams (specifically developers) to your Kubernetes platform. First we’ll look at some of the more philosophical aspects and ask the question, How much should developers know about Kubernetes? Then we’ll move on to discuss how we can build a smooth onramp for developers to get started deploying to Kubernetes and deploying clusters themselves. Finally, we’ll revisit the complexity spectrum we mentioned in Chapter 1 and look at some of the levels of abstractions we can put in place. Our objective is to strike a good balance between complexity and flexibility when offering a Kubernetes platform to development teams that have varying degrees of knowledge and desired engagement with the underlying implementation.
Many of the areas in this chapter are covered elsewhere in the book, which we’ll call out where ...
Get Production Kubernetes now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
