Krateo PlatformOps: Streamlining Platform Engineering through Standardization
The current context
It was back in early 2021 the exact moment when we realized we were living at a pivotal moment in the digital transformation journey for enterprise companies: the overwhelming speed of nascent cloud-native technologies was slowing down the process of innovation and this may appear at first glance a contradiction.
The problem
Every enterprise company — medium or large, regardless of the market segment — with an internal IT department is experiencing this friction in building a platform that allows them to accelerate application development to improve their time to market. Wait a moment — what do we mean by platform? Based on Gartner’s definition:
a platform is a product that serves or enables other products or services. Platforms (in the context of digital business) exist at many levels. They range from high-level platforms that enable a platform business model to low-level platforms that provide a collection of business and/or technology capabilities that other products or services consume to deliver their own business capabilities.
The Cloud Native Computing Foundation Landscape is an example of this technology capabilities wealth of choice — or should we call it fragmentation? How is it possible to understand if any of these solutions are complementary to each other, how well maintained they are etc?
Having multiple choices doesn’t mean that is easier to build up your platform based on these technologies.
The first and second waves of DevOps
We did a lot of interviews with customers to understand why they are struggling with the digital transition.
Before showing you the feedback from the interviews, we need to circle back again to another definition of DevOps — this is from AWS:
DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
DevOps is not a new approach —Patrick Debois used this term in 2009.
DevOps methodology found particularly fertile ground in the Continuous Integration methodology — the Jenkins project was created in 2011 — and the containerization technology — Docker was becoming a disruptive tool in 2015.
We call the period between 2016 and 2020 the first wave of DevOps, which lead to tons of PoCs, PoVs, and MVPs that convinced enterprise companies that that approach — the DevOps methodology — was the golden path for the digital transformation: release software Harder, Better, Faster, Stronger — sorry for the Daft Punk citation, but you got the point.
We are currently experiencing the second wave of DevOps — which will end in 2025 based on Gartner’s reports — where DevOps methodology has to embrace broader teams within the enterprise company, but that’s not happening.
Why?
Because companies are not realizing that to deliver applications and services at a high velocity they need a digital platform that is made by different technologies maintained by different engineering teams that belong to the same IT department. The reason is linked to the fact that a platform makes it possible to integrate self-service provisioning processes of application and infrastructural components that follow precise compliance regulations present within the company without the user of the platform having any friction in achieving his goal — developing quality software, quickly and as independently as possible.
Why is it so complicated to build a fully functional platform?
The solution
Companies are realizing the key turning point: a platform needs to be treated as a product. A product needs to be always running 24/7 and needs to be resilient, self-explanatory, and self-service, with the smoothest user experience available and resilient.
Let’s make a practical example — the iPhone. We don’t think that you take a 2-weeks onboarding classroom to get the most out of the phone. We don’t think also that to install an app you need to open a ticket and wait for some days to get it processed. So why your platform shouldn’t be the same?
Your platform must be treated as a product — your internal or external platform consumers want to love it, and they’ll use it if the enjoy the experience on it.
If your customers — which are internal or external developers, business analysts, data scientists, IT managers, Product managers, etc — are not using the company platform, the IT department is the one to blame because it didn’t find a collaborative, standard and scalable way to collaborate, consolidate and contribute to the platform — which was the initial objective of the DevOps methodology.
Krateo PlatformOps
We decided to write Krateo PlatformOps — a self-service platform to provision, manage and monitor multi-cloud native resources based on Kubernetes — which provides three main functionalities:
- Platform Engineering implementation with PlatformOps approach
- Self-service Developer Portal
- FinOps for the entire platform and managed resources
PlatformOps approach
PlatformOps is the natural evolution of DevOps, which forces a cultural change through the entire IT department via the creation of a new cross-functional team (the Platform Team) whose purpose is to make the internal toolchain a self-service platform-as-a-product.
We started to evaluate if there was already an industrial, well-adopted, de facto standard available to implement a PlatformOps approach in the market and it was really easy to spot: Kubernetes!
This evolution of the DevOps methodology is nowadays called Platform Engineering — which implements PlatformOps. So now the practical question is: which actions should we take to properly build a platform?
We always answer in the same way: with a cultural shift. Technology is never the answer but it’s the enabler for the shift. We must find a way to let different, vertical IT engineering teams which have the competence in a concrete domain collaborate on automating services — any kind of IT service, from infrastructure to code collaboration to cloud resource procurement.
The technical approach to be adopted must be inherited by developers writing microservices: small, well-defined, atomic pieces of software that interact with standard interfaces with each other and can be composed with other microservices to build application logic. Why automation shouldn’t be done in the same way?
Self-Service Developer Portal
Then we found out that even the best automation is missing the platform objective if it’s not consumable in a self-service approach.
The platform must be consumable by customers via a self-service portal which has the user experience as the foundation for its design. That’s just the beginning: this portal helps the company with the governance of services, implements compliance guardrails, abstracts the complexity of the underlying platform, and exposes the relevant data to the customer.
FinOps
Last but not the least, we genuinely believe that self-service doesn’t mean self-throw away money out of the windows. Cost budgeting is already complex - there’s a great article from dataconomy with the following title:
Cloud costs have started to become a heavy burden for the IT sector.
It’s complex to define a cost model, simply because companies' procurement processes don’t fit with cloud providers' billing: an enterprise reality needs to put on top maintenance costs, design costs, public tenders costs, etc.
The FinOps Foundation is a program of the The Linux Foundation (alongside organizations like Cloud Native Computing Foundation) dedicated to advancing people who practice the discipline of cloud financial management through best practices, education and standards. The FinOps Foundation is a 8700+ strong community, representing more than 3500+ companies.
We love this approaching methodology because — and we want to stress this concept — FinOps is NOT cost allocation. It is a mixture of different skills, from financial budgeting to procurements processed to cloud architects to data scientists. These different, complementary worlds need to develop a common understanding of spending, collect financial data, extract business values, and develop prediction and optimization models to act immediately on reviewing contracts with cloud providers — may be moving from a pay-per-use model to reserved instances — or review cloud-native architecture or optimized overprovisioned resources.
We really don’t need to get a dashboard where CPU cost metrics are allocated to a Product Team. We need to understand if the business value that is powered by that CPU is following the prevision of the company.
We don’t need cost allocation — we need cost optimization based on business values.
In Krateo PlatformOps we are collecting requirements from customers, mapping existing procurement processes with state-of-the-art approaches, and designing technical solutions to showcase the right information to the right people. This is FinOps for us.
Get in touch with us
If you want to try Krateo, it’s completely open source and available on our organization on GitHub: https://github.com/krateoplatformops/krateo.
There’s also our online documentation that can help to clarify the onboarding on the platform: docs.krateo.io.
If you want to get in touch with us, follow us on Medium, Twitter, Linkedin, and GitHub. Any feedback is deeply appreciated.
