The Lifecycle of a Service
Services are the backbone of our systems. Whether they’re functional microservices or logical components of a traditional application, they are the pieces that make up our businesses. We can’t do the computer thing without services.
But who’s responsible for owning a service in your company or organization? The cast of characters involved in the lifecycle of a service is more than just software engineers. It can include program managers, product owners, sustainability teams (SREs/operations engineers), and business stakeholders, just to name a few.
The people in these roles make different types of contributions as we move through the lifecycle of our services. When we think about how those contributions evolve over a service’s “lifecycle,” there are three main phases we should be considering: design, runtime, and sunsetting.
Design
This is the beginning of a service, when it’s in its infancy. During this phase, we need to consider a few key factors, including customer needs, pre-production requirements, and production readiness.
Customer Needs
Every service, even one buried deep in your company’s internal stack, has someone or something that consumes it and expects a given output. Those someones or somethings are its customers. Full-service ownership teams must work toward an understanding of their customers. Are their needs being met? Could the service be more useful to them? Sometimes these consumers of your service don’t even know what to ask for in order to make your service more valuable to them.
Understanding customer needs requires adopting a product mindset. Regardless of whether the consumers of your service are signing up on your website and paying you money or if your service is consumed by other internal applications, adhering to the principles of product management will help ensure a great experience for all consumers of the service.
Pre-production
Before your service is ready to be unveiled, you need a place to test and understand it. It’s critical that your pre-production environments are as similar to the “real world” as possible—they don’t have to be set for the same scale, but major differences between pre-production and production will result in headaches down the road. The precepts of Continuous Delivery mandate that all pre-production environments should match production, except for scale. Remember: In lower environments we aren’t just testing our code, but the deployment process as well.
Production Readiness
When it’s time to release a new service, a key element is to have discipline around preparation, also known as “production readiness.” A few key elements we recommend including:
- Engaging with necessary production teams (SRE, Operations, Sustainability Teams)
- Defining (and testing) alert notifications
- Drafting an initial runbook
- Completing internal reviews (security audits, etc)
Runtime
Once a service is deployed to production, the design phase doesn’t actually end. Remember, services are never “done”; we are constantly improving them. However, deploying them into production also introduces many day-to-day operations of your service, such as maintenance, iteration, and deploying updates. The design phase continues throughout the runtime phase, both to develop new features and to resolve issues with existing functionality discovered after the service is put into production.
In addition to ongoing design, some additional contributions are necessary once your service is operating in production. Most importantly, now that your service is being used by real customers, how you communicate with them is key.
Versioning
One key way to communicate with consumers of your service is with a robust and clear versioning strategy. This helps your customers understand what they can expect out of your service and not be surprised by changes. For example, if your service presents an API, consider using Semantic API Versioning to help consumers understand what features and capabilities they have available to them, and allow them to gracefully migrate to newer versions.
Communication
While versioning is an implicit method of communicating to consumers of an API, you can’t simply version your endpoints and call it a day. You also have to communicate with your customers to set expectations. How exactly you do that will vary according to the needs of its consumers. But typically, you’ll want to have at least two different ways (beyond versioning) to make announcements to your customers about features being deployed or any changes being introduced—especially if those are “breaking” changes.
Two low-effort and high-touch methods for establishing that type of communication are providing both mailing lists and changelogs. Giving customers the option to subscribe to change announcements via email might seem redundant due to the other mechanisms we have available. But the reality is that not everything you might need to announce to users of your service is necessarily directly related to a released change. Mailing lists give you a way to gracefully manage unusual situations. In contrast, maintaining a detailed changelog gives customers an option to subscribe to and reference specific changes introduced over time. Your customers can decide which level of communication is right for their needs.
Learning From Incidents
No service is perfect. Incidents will occur, but they are great opportunities to learn more about the service and its consumers—provided that the opportunities are capitalized on.
For example, when service incidents occur, an essential practice is regularly performing postmortems to understand what happened. When action items are discovered as part of a postmortem, they need to be prioritized into the service team’s workstream. Service team Product Owners should participate in postmortem meetings in order to fully contextualize and help prioritize these action items.
Sunsetting
While it’s usually never fun to say goodbye, the time may come when your team or organization decides to retire a service. It’s important to have a plan in place and a consistent process for service retirement that’s beyond just “turn it off.”
Deprecation vs. Retirement
Are you going to keep the service running, but no longer make improvements to it? In this case you may consider deprecating it. This is a method of setting different expectations for the consumers of the service, but still allowing it to provide some value to them.
If you plan to shut the service down completely, you will be retiring it on a specific date. It is usually common to deprecate a service for some time prior to full retirement so consumers have time to off-board to another solution.
Identifying Customers and Determining Business Impact
Be sure you can identify who is currently still consuming your service prior to sunsetting it. You may be able to determine this via methods such as activity logs or other programmatic approaches.
In addition to identifying customers to contact with a deprecation/retirement communication, doing this will help you understand the business impact of shutting down this service. Work with senior leadership in your organization to help communicate and quantify the business impact of retiring the service. Senior leadership should help facilitate discussions with other parts of the organization (e.g., Sales, Support, Customer Success) to create a more complete understanding of the business impact for sunsetting a service.
Offboarding Customers
It is critical for customer satisfaction and your organization’s perception and reputation to communicate the deprecation/retirement of a service professionally and compassionately. Provide ample lead time before retirement to allow customers to move to another solution—preferably one you are able to provide instructions for, or recommendations on migration. Clear and helpful communications in this part of the process can make or break customer satisfaction.
Want to read more about all the components and teams involved in service lifecycle? Check out PagerDuty’s guide to Full Service Ownership for a comprehensive look at everything that goes into owning, building, and running a service in production.