Making sure services, applications and infrastructure are up and running has always been a role in technical organizations. But, as application architectures have changed and become simpler, yet simultaneously more complex, application demands are greater and customers more picky than ever before. Companies live and die based on their ability to make sure their application is available and working. But, what we deliver today is services, not sites. And service reliability may be a more appropriate term for those heroes making sure everything is working.
The S in SRE usually refers to “site.” But, to better align with what developers are delivering today I’d argue that it should be Service. The reason being that the way we deploy applications has directly impacted how they’re consumed. And, all other aspects of our pricing and development have changed to accommodate that. These options include:
- Subscription-based business models
- Application architectures
- Modern delivery chain
- Cross-platform
- Customer-centric
Subscription-based business models
More and more businesses are turning to monthly recurring revenue models. The goal of the subscription model is to attract users into subscribing to a useful service where they can charge customers monthly or annually – ideally leading to more consistent financial forecasts and revenue streams. For the user, this evolution has been frustrating at times yet also offers the convenience of being able to come and go as you please. And, the ability to only pay for what you use is nice. This business model is service-based and customer-focused, not asset-based. When you’re done paying the subscription, you can’t use the service anymore.
Application architectures
Application architectures have become more service-oriented, as well. Starting with the obvious microservices setup where each service in a microservices-based application has an independent lifecycle and can act as an ongoing resource from which the broader application can consume logic and features from. But, microservices aren’t where it stops. As applications move into even newer architectures like serverless, which is based on a model of robust APIs where each each API function is essentially a service.
The application architectures alone don’t complete the service unless they’re delivered as one. Modern delivery chains allow code to be pushed into production as a stream of functionality versus bite-sized chunks in the case of sprints (AKA fast waterfall), or huge chunks with waterfall development in monolithic applications. In addition to continuous releases, there’s tooling such as feature flags that allow developers to create a logical structure around their features as they relate to their individual components. In this new model, application versioning, the process by which development teams operated, is less about chunks of components than it has become a reference point to track points in time across various application services. It’s still valid but it’s not the trigger that drives adoption.
Cross-platform
The applications we develop and thus, need supported, aren’t always sites, even if you take site to mean infrastructure or site to mean website. Applications and infrastructure are compilations of features and services for other development teams – APIs, mobile applications, IoT applications etc. Application services, when architected correctly, can be consumed over a variety of application formats.
Customer-centric development
And, finally, development is more and more customer-centric, what a novel idea. It may seem silly to say that waterfall development wasn’t customer-centric, but it wasn’t, it was application-centric. In waterfall development, you didn’t consider the user during the development process. You considered customers at the very beginning, at requirements gathering and at the very end, user acceptance testing. You didn’t really mind the nuanc involved with their understanding of functionality and yours. Now, that’s not true.
Now, development teams want to know as quickly as possible if a feature is being used, how it’s being used, and if the outcome is what’s expected. It’s not just faster feedback loops, the user adoption is what guides the development process and backlog. Or, at least, it should. When you look at it like this, your products and features sound very much like a service, a form of functional concierge. You’re continually trying to improve the experience of your user.
SREs are tasked with keeping all aspects of the above paradigm true in production. Thus, the title should reflect the service-oriented nature of modern application development.
