In the last post we described the two most common approaches to devops – the fully integrated team (with dev and devops handled by the same team) and the traditional, separate devops / ops team. The first is lighter, newer and often more responsive, but can struggle with devops left undone, and is tough to scale efficiently; the second tends to be stronger operationally, but tends to be heavier, less responsive, and less integrated with the app itself … leaving the walls between devs and ops stronger than ever.

Is there a better way?

Naturally, we say yes! At our focus is on creating a new model, one that is organically related to the cloud-native apps that we are all building today. Fresh and new, yet deeply rooted in the best of the existing approaches.

One of the traditional sources of cost and complexity in devops is that similar tasks are done in a thousand different ways; when you multiply across an entire application, the devops tooling, methods, and procedures are completely unique app to app, and company to company.

To get a handle on this we standardize. Like cloud-native apps, we take a scalable, standardized, building block approach … and apply it to devops. Standard ways to represent an application (including dcStack), standard ways to operate on an application (including dcUtils),

Together these allow us to express what is unique about an application, then do our job in standardized ways. Monitoring, provisioning, backups and all those other devops tasks … all standardized. Communication with our customers and within our teams … standardized.

Applications, process and procedures, and team interactions all wrapped together into a cohesive, effective, and efficient … standardized building block.

This is what enables us to take the risk out of devops … operating more effectively and efficiently than any other approach, then scaling as your applications scale … all at a stable, predictable monthly cost.