Your App Matters … the Better Way

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 devops.center 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.


Your App Matters … Now What?

When an app becomes integral to the well being of the biz, when how you serve your customer is, in fact, dependent on one or more apps behaving, then you have a need for devops, welcome or not. In other words, you need to take some actions to ensure that the apps will behave.

As a practical matter these actions, this “devops problem” tends to be addressed one of a few ways.

For many smaller teams the natural choice is to have the developers take care of the devops themselves. Some real advantages to this, not the least of which is that the developers will actually tend to … well, they’ll tend to add the dev into devops. Build apps that are a bit more resilient, that can deploy themselves, perhaps even handle scale more gracefully. Routine, repetitive tasks tend to be automated, tooling tends to be more robust.

This approach can work quite well for some teams, even some larger teams, provided that the culture and conditions are right.

On the other hand, the devops features often tend to migrate lower on the priority stack. When the development team is pressed for features, the devops support tasks are often not done. Perhaps not intentionally, but over time the gaps tend to increase. Risks become riskier, backups are not tested, updates not made, patches not applied … and who really wants to be on-call at 2 am?

Besides, the super-integrated set of tooling will tend, by definition, to be unique to each app, becoming a sort of app unto itself. Too long to explore at the moment, but just know that uniqueness can also be a burden.

So another common approach, perhaps more traditional, is to have dedicated devops teams. On the positive side these are folks with no higher priority than simply making sure that the app is up and serving the customer – protected against risks, backed up, safe and sound.

This approach can also work well, provided that the culture and conditions are right. Yet …

These teams are often rooted in the history of operations, so the focus will naturally tend be more heavily operational. Tooling tends to be less integrated with the app itself, perhaps sometimes a bit less sophisticated, perhaps less resilient. Much of the time dedicated teams can seem to be lightly loaded, an extravagance indeed. At the same time these same teams can instantly flip from lightly loaded extravagance to woefully understaffed, when a problem arises.

While it is true that for a larger organization, one with several “apps that matter” this conundrum may be addressed by pooling the support for all of the apps into one group, that has many obstacles that must first be overcome to be practical. Yet, it does point in the direction of a third option, a new approach that may make the most sense.

In the next post we’ll outline what this new approach to devops, this third option, might look like.


A New Way

For the past couple of years there have been a few of us bootstrapping a new approach to devops – one that thinks of the “devops problems” the same way that the owner of “apps that matter” often thinks. Not so much as devops problems, but as obstacles standing in the way of building, financing, or growing a business that counts on cloud-deployed applications to serve your customers.

Whether you’re an overworked dev team having to choose between new features for the customers or sound operations, a financial exec who wonders why the admirable reductions in infrastructure and other application costs have not helped with chronic, expensive, and often unpredictable operations costs, or a CEO who wonders why with so much new in applications, your teams remain mired, even fixated on everything but what your company is actually good at … no matter which of these sound familiar, we think you’ll be intrigued.

We have developed some fresh tooling, fresh operational approaches, rethought many other aspects of “the devops problems”, then rolled it together into a coherent, efficient, and best of all cloud-native approach to making sure that the (cloud-based) apps on which you depend will actually behave as you intend, so you can serve your customers as they expect, an in doing so grow your business as you hope.

Together we’re confident that this fresh, new way of approaching an old problem will open some eyes, challenge some stale assumptions, but most of all be really helpful in solving the problems you really care about – growing your company.