At atama plus, application engineers provision and operate their own infrastructure using an internal platform made from AWS CDK libraries, documentation, and guardrails. There is no glossy portal and no giant “Deploy” button. The platform is still a platform because it removes specialist decisions from routine work.
Internally it is called DeKITA, a Japanese wordplay that also carries the satisfying sense of “I did it.” The name is cute. The staffing problem that produced it was not.
The bottleneck was structural #
The SRE team nominally had five people: one manager, three employees, and one contractor. In practice, management work, an upcoming departure, parental leave, and existing operations left a little over two people available. One person’s worth of capacity was already consumed by current products.
Then three new products requiring infrastructure were scheduled in parallel, with more expected behind them. Centralizing infrastructure knowledge in SRE had made the team the gate for every new service. Heroics might clear one queue; they do not scale the organization.
Three ways out #
The team considered three approaches.
- Adopt a public PaaS. Fast to start, but limiting when architecture, scaling, or security requirements need customization. It also weakens the desired Infrastructure-as-Code workflow.
- Build an internal PaaS. Flexible eventually, expensive immediately. A useful version would take substantial time, and new products were not politely waiting.
- Enable application teams directly. Provide safe CDK constructs, operating guidance, and guardrails while leaving product teams in control of composition.
They chose the third option. The deciding principles were to start small and build something people would actually use. A highly abstract internal PaaS can freeze the technology stack before the organization understands its future products. It can also become a beautifully engineered service with no customers, which is a very expensive way to decorate a roadmap.
The three parts of DeKITA #
CDK constructs package SRE defaults for security and cost. Common resources such as S3 buckets and Lambda functions can be created safely without every application engineer becoming a part-time cloud specialist.
Operating guides cover monitoring, security, maintenance, and cost management. Provisioning is only the first afternoon of a service’s life; ownership also needs incident response, capacity planning, upgrades, and cleanup.
Guardrails catch unsafe configurations that escape the first two layers. AWS Service Control Policies, Config, and Security Hub CSPM provide constraints and detection. Documentation says what good looks like; guardrails stop the most dangerous interpretations of “creative freedom.”
SRE still advises, reviews, and enables teams when needed. Its primary work shifts toward evolving the platform and operating existing products, rather than constructing every new stack by hand.
Roll it out through one real product #
One product became the pilot. SRE prepared the CDK project and templates, then ran hands-on training so application engineers could implement the infrastructure their service needed. Complex and non-functional settings lived in an SRE-owned directory behind configured constructs.
Once the pilot succeeded, those constructs moved into a reusable library. The team prioritized frequently used resources and encoded practices it had already learned in production. Documentation grew alongside the library: CDK onboarding, monitoring, security, maintenance, and cost management.
The result was five new products progressing in parallel without SRE remaining the infrastructure bottleneck. Product teams used the CDK library and guidance—with some help from LLMs—and required relatively little direct SRE support.
The honest trade-off #
This model transfers real work to product teams. Engineers learn valuable skills, but the work is not free and the approach is not universal. If you can staff cloud specialists, do that. If product infrastructure is uniform, a conventional internal PaaS may be better.
DeKITA fits a particular constraint: too few infrastructure specialists, varied new products, and a need to retain architectural flexibility. Over time the library gained higher-level constructs such as maintenance mode, while the guides expanded into load testing and capacity planning. The documentation eventually became large enough to need a chatbot—which is perhaps the most 2026 possible ending.
Platform engineering is a product discipline, not a prescribed interface. Sometimes the right platform is a portal. Sometimes it is a carefully designed library, good defaults, and enough documentation that another team can operate safely without waiting in your queue.