CNP: Cloud-Native Platform

In most companies, an application team that needs a new database files a request and waits for a platform team to set it up by hand, or learns enough cloud configuration to do it themselves. Either way it's slow, and the result is hard to keep track of once it exists.

CNP is an internal platform, built by a team of six in the SIGL major at EPITA, that removes that step. A team creates a project, describes the pieces of infrastructure it needs, and the platform provisions them on the cloud. Access is scoped per project, so a team only ever sees and changes its own resources.

My part

I owned the layer that turns what a team asks for into real infrastructure, from the data model through to the API and the interface teams use. The goal was keeping the request simple enough that nobody needs to understand the underlying cloud resources to get it right.

Finding what nobody uses

Once a project grows past a handful of resources, a plain list stops telling you much. It can't show which resources depend on which, or which ones nobody uses anymore but are still costing money every month.

I proposed and built a different model: teams describe their project as a graph, where each resource says what it depends on. The platform can then walk that graph and flag anything nothing leads to, which is either a mistake or money being spent for nothing. The interface for this shipped, and the part that lets the platform act on it automatically is still in progress.

Safe, reviewable changes

Every resource gets its own history of changes, applied to the cluster automatically. A change to one resource never forces a redeploy of everything else, and any single change can be reviewed or rolled back on its own. I worked on this part of the architecture with the rest of the team.

The graph model and the way changes reach the cluster are written up in detail below.