Kelsey Hightower stated already in 2017, that Kubernetes is not a Platform by itself, but rather a better way to start to build a platform. But what does that really mean? From my point of view, this means that Kubernetes is a platform that provides a core abstraction- and Service layer for cloud-native applications to interact with infrastructure and infrastructure services.
You might ask, why is this dude digging out a tweet from 2017, and why should I care? Well, in the end, you are reading this article, because you want to adopt Kubernetes and because you want to adopt Kubernetes, you are building a platform on top of Kubernetes.
Jim Nicol describes In this article, why Kubernetes is not the end game. Kubernetes is just a tool, but if you think of end-to-end automation and consideration, you will quickly understand that Kubernetes is only one piece in a larger jigsaw puzzle. So if you really want to build a platform you have to think about how do you want to improve the and expand the platform. Which Services and Systems do you want to integrate. How do you integrate those new Systems into your platform, and how do you have your platform interacting with those systems.
Product Centric vs. Customer Centric Mindset
You might ask yourself, why is that important? Because it is becoming increasingly important to think about End-to-End Customer Experience. The customer drives the roadmap and you try to make your customer as happy as possible. Let’s take this thought a bit further and apply it internally inside of a siloed Enterprise Organization. The IT department does no longer offer compute, networking, or storage to their internal customers, they deliver a platform for them to be successful. But what are internal customers to an Enterprise IT organization? It is the Business Leaders, the Application Owners, the Developers that innovate with new applications and maintain existing applications that generate Value for the Enterprise.
Once you begin to recognize you are a service provider to your internal customers, you can start to evaluate the Value Stream you are providing to them. Wikipedia defines it as such
A value stream is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages of development and on through delivery and support. A value stream always begins and ends with a customer.
https://en.wikipedia.org/wiki/Value_stream
In other words the faster your internal customers can realize value, the better your value stream is and the higher is the value the IT Department delivers.
Platform in a Multi-Cloud World
Application Architectures and Technology are becoming increasingly complex. Applications can span across multiple clouds, they use services from different cloud providers, they can span across multiple continents, they need to scale quickly, etc. Enterprise Organizations are jumping onto Public Cloud Providers, because they provide a Self-Service Portal (think of the value stream above) which includes rapid delivery of desired resources. This sounds like the right way to go, until you have to use a service from a different public cloud. Then things become cumbersome. In one of their recent reports, Gartner states that moving an application from one public cloud to another public cloud, can take as long as a year or longer. That is far from the agility promises, that you thought of, when adopting the public cloud. What is needed is the best of both worlds, you need a platform, that spans on-premise, across all public clouds, and is build on top of Kubernetes.
Building Blocks for a successful Kubernetes Platform
As I said above, it requires a shift in culture within your organization and within the heads of many IT Operations Leaders Heads to provide a platform that focusses on the Value Stream of their customers. What are these components?
- A Platform Journey
How do you continuously improve the platform customer experience? How do you integrate new services and chargeback models into the platform? How do you provide connection to legacy systems, how do you address the requirements of your customers? How do you address security, reliability, etc.? - A Developer Journey
How do your internal customer consume the platform in the best and most meaningful way? How do you market your platform within your organization? How do you accelerate and meet the needs of your customers that integrate well with your Kubernetes platform? - An Application Migration and Modernization Journey
Migrating applications on top of your kubernetes platform gives it all the benefits of the platform. But you need to think about which applications can I simply Rehost, which need Refactoring, which need to be Revised, Rearchitected, Rebuild, or which do I need to Replace, and all of the above to be prioritized based on Business Value - A Cultural Journey
The world changes constantly, are the classical hierarchical structures still the right way to go, or do we need a different approach to work as teams, being completely transparent? To build communities where people can contribute, if they would like to etc. All of this is captured there.
Platform Journey
So how does a Platform Journey look like? You should always try to answer your Why. Why do we want a platform? Start to capture your current state and compare it to your desired or future state. What are the Future Business Outcomes that you want to achieve.
- What is your overall Cloud Strategy? Are you planning to go All-In into the Public Cloud? Can you really move all applications into the Public Cloud? How do you manage access and securtiy between workloads running on the public cloud and on-premise.
- What is your Future SAP Strategy. SAP is present in many organizations and the people using and operating an SAP environment are often disconnected from the rest of the IT Organization. Can you join forces with them, and find allies in terms of Platform Adoption, because there is a lot of synergy in bringing those teams closer together.
- How do you want to address Continuous Integration and Continuous Deployment. How is your staging process going to change. How many foundations are you going to need. Do you want to integrate SAP workloads into the pipeline, etc.
- Do you have any preferred partners, that you would want the platform to operate? Can you incorporate them early into the process? Do you have outsourced application operations to System Integrator? How do you plan to integrate all of these things onto your platform?
- Do you have a Standard Operating Envionment? How does the platform change the way you hadle Security Patching, SCAP Analysis, etc.?
- How do you plan to give access to Metrics and Monitoring? How do you plan to meet your Service Level Objectives? How do you differentiate between Application and Platform Metrics? How will the Logging correlate between Platform and Application Outages? How do you plan to do your capacity planning?
- What about Business Continuity? What happens if the Cloud Provider has a fatal Service Outage? What is your Emergency Response going to be? Can you simply migrate from one region to another? Are you planning to migrate from one Public Cloud to another? Have you automated and tested for fatal failures?
- Automatic and Rolling Upgrades of the Platform. How do you plan for Day2 Operations? Did you consider all pitfalls? Are you continuously testing your upgrade procedure?
- Continuous Improvement of the Self-Service Portal. How do you plan for chargeback? Are you goint to immplement a Marketplace? Do you consider Multi-Cloud Management? How do you handle Multiple Clusters?
- etc.
Conclusion
As you can see there are a lot of questions when it comes down to only one journey of the four journeys I have mentioned. In the following articles I will dive deeper into the different journeys and other than just asking you questions, I will try to give you some reasoning about why they are important, and what the desired state could look like.