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.
One thought on “Your App Matters … Now What?”