# Platform Engineering [Platform Engineering](https://iits-consulting.de/en/services/cloud-devops/platform-engineering) ## Platform Engineering Most internal platforms are built once and then quietly abandoned, because they were scoped as an infrastructure project instead of a product with users. We built ours as a product. KumoOps serves customers across multiple clouds and they pay for it every month, which is a harder test than an internal rollout ever is. We build yours the same way. [Book a 30-min call](https://iits-consulting.de/en/contact/index.md) [Free Cloud Architecture Workshop](https://iits-consulting.de/en/cloud-architecture-workshop/index.md) Our Technology Partners ## TRUSTED BY TEAMS AT: Deutsche Telekom Uniper GOLDBECK PwC Vattenfall Schwarz Gruppe Cornelsen Meridiam ## What exactly is Platform Engineering? A platform is the set of defaults your developers get without asking: how a service is created, where it runs, how it reaches production, who can see it and what happens when it breaks. Platform engineering is the discipline of designing those defaults deliberately, treating them as a product, and being accountable for whether anyone chooses to use them. The measure is not how much the platform can do. It is how much a developer no longer has to know. Every capability you add either removes decisions from their day or adds to the pile they already carry. ### Self-service, or it is just a ticket queue with better branding A team asks for a database and gets one in minutes, already encrypted, backed up and tagged to their cost centre, without learning what any of that required. Nobody chose those defaults under delivery pressure. We chose them once, carefully. The test: if using the platform requires understanding the platform, the abstraction is in the wrong place. ### Platforms grow. They do not get leaner Every exception becomes a permanent capability, every migration leaves the old path running next to the new one. After three years the platform that was meant to reduce choices offers more of them than the cloud underneath. The cognitive load moved, it did not shrink. Deciding what not to build, and what gets deprecated on a date rather than on goodwill, is most of the job. ### Your platform has new users, and they do not read the wiki Coding agents open pull requests, provision infrastructure and trigger deployments. No tenure, no memory of the outage that led to the rule, no sense of which of your three deployment paths is sanctioned. They use whatever interface is reachable, at a speed no review process was built for. That makes guardrails the interface. A policy people mostly followed becomes the only control left when the caller is an agent, and the golden path has to be the easiest thing to call rather than the best documented. ### We do this in public Our engineers publish on platformengineering.org, teach our own platform engineering course, give guest lectures and attend PlatformCon. We are a certified service provider with more than twelve certified platform engineers. And we run KumoOps, our own platform product, across several clouds for long-term customers. We have made the expensive abstraction mistakes on our own bill. ## Why this platform gets used ### Less to know, not more to use We measure how long a new service takes from repository to production and how many defaults a developer sets themselves, at the start and at handover. ### A minimum viable platform, not a two-year programme One golden path, one real team, in production early, while the design is still cheap to change. ### Ownership drawn on purpose Who fixes what is decided in the design, not during the first failed upgrade. ### Guardrails that hold when the caller is not a person Policy as code and enforced defaults, so an agent gets the same answer as your most experienced engineer. ### You can stop and take ours instead If building your own is not worth it, we say so. KumoOps is the alternative and we would rather sell you the right one. [Send Inquiry](https://iits-consulting.de/en/contact/index.md) ## Process Steps ### Talk to the developers, not the infrastructure. We count the decisions between an idea and production, including the ones made wrong and fixed later. Step 01 ### Scope the minimum viable platform The smallest thing that improves one real workflow, plus a baseline so the value is measurable rather than arguable. Step 02 ### Ship it to one team Production, real traffic, real support. First users find in weeks what a design review misses for a year. Step 03 ### Run it as a product Roadmap, intake, versioning, deprecation. Your team takes it, or KumoOps takes the operational side. Step 04 ## Areas we support in ### Telecommunications Hundreds of internal teams, where a single bad default propagates faster than anyone can correct it. ### Energy & Utility Separation of duties as a platform capability, so the audited path and the fast path are the same path. ### IT & Digital Services Developer experience as a competitive factor, because your engineers are the product ### Public Sector One platform across many organisational units, on sovereign infrastructure, with evidence built in. iits-consulting helped us build a robust and flexible cloud on the OpenTelekomCloud. They possess strong cloud-native expertise and utilize modern technologies. The workshop was clear and practical, and the subsequent consulting guided us step by step. They provided highly experienced consultants who were genuinely committed to helping us and sought the best solutions for our challenges. We highly recommend iits-consulting for training, consulting, and a robust cloud solution. Karsten Brusch Senior Cloud Architect Cornelsen ## What we work with. Nothing here is exotic, and that is the point. Your teams have to run this after we leave, and hiring for it should be easy. PLATFORM CORE - Kubernetes - Terraform - OpenTofu - Helm - Argo CD - Crossplane - Operators DEVELOPER CONTROL PLANE - Service Catalog - Gold Paths - Self-Service Provisioning - Scaffolding Templates - Portal - Agent-facing APIs GOVERNANCE & OPERATIONS - Kyverno - Keycloak - Vault - OpenTelemetry - Grafana - Cost allocation per Team ## Are you building a platform, or operating everyone's infrastructure? Two weeks, your teams interviewed, a scoped MVP and an honest answer on whether you should build one at all. No obligation. [Get in touch](https://iits-consulting.de/en/contact/index.md) [See our work](https://iits-consulting.de/en/our-work/index.md)