blog.devops.center

At devops.center we often talk about standardizing – standardized tooling, standardized ways to do anything to an app, standardized db backups, standardized forms of communication, and more. After all, much of the complexity in modern devops has to do with similar tasks being done in different ways, with different tooling, often for no particulary great reason.

Just because.

Because different people solved the problem for different apps, or even just because the same person made use of a new tool. Maybe it was better, maybe it wasn’t … but it sure was different.

Different enough that whoever ends up with devops for that app has to learn all of the ideosyncracies and quirks, and keep those in mind for as many apps as they can. Of course these “house rules” make it tough for that same person to handle a large number of different apps, or to easily swap in other folks should the need arise.

Perhaps the most aggravating consequence is that these differences add to the cost for ensuring that this app does what it ought. Since that is the whole point of devops anyway, these variegated solutions to similar problems mostly just add to the cost for the devops of each app.

Honestly, who wants that?

Legitmate Diversity

However this is not the whole story. Each app has plenty of unique aspects – languages, frameworks, support libraries, datastores, and more. For each app there may be local directories for temporary files, unique configurations for web servers, even unique combinations of different types of instances or containers.

So the key is for a developer to be able to express this legitimate diversity in a standardized way, and even more importantly present standardized control points – the knobs and dials for tuning and observing each app – to the world around the app.

A Logical, Precise, and Helpful Solution

In order to be able to express legitimate diversity in a standardized way we developed dcStack, an open-source app stack. By utilizing dcStack to encapsulate (“wrap”) an app, you are able to easily express what is unique about your app, yet do so such that our teams are able to provide all devops support in a simple, standardized, efficient and most importantly cost-effective manner.

With the formalism of dcStack it becomes simple to deploy the application across multiple environments, on instances or containers with Docker, on various infrastructures, or even for local development. The app itself remains the same in all these cases, which definitely simplifies debugging across multiple deployments.

In the next post we’ll take a closer look at dcStack, and begin to consider the simple process for wrapping any app … perhaps your app! … in order to gain all the benefits from this new approach to standardized devops.

At any given point in time our apps are the sum of a whole series of choices that we’ve made – design choices, implementation choices, even choices about implementing good build tests to ensure quality, about implementing sound operational practices to ensure that the app can be relied upon … or not.

Since every development team is finite, and the needs for new features and functionality essentially unlimited, something has to give.

Very often the finite resources are spent mostly on the most pressing needs … that next new feature, that new capbility that will help sales close the next deal, that bug which absolutely has to be fixed or <fill in the blank> is dropping us, the feature needed to gain support within the organization.

So what gives are the unglamorous parts, the type of tooling and hidden work that ensures that your app will be resilient, that it will survive the unexpected hardware failure, that it will scale gracefully as usage increases. Nobody ever really sets out to skip this hidden stuff, but most of us end up there at one time or another.

However, do you really want to wait until the databases are lost to make sure that backups are solid? Do you really want to wait until a customer drops before ensuring that regularly scheduled parts of the app run accoording to schedule? Do you want to wait until you’re overrun with folks using the app before knowing precisely how to add capacity effectively?

We gently propose that there’s no need set aside many of the hidden tasks, even unintentionally. That’s precisely where our standardized tooling, patterns, and procedures can be very handy … the dev team is now able to focus on the high priority, visible parts of the app, and the devops.center team can efficiently focus on the hidden stuff.

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.

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.

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.