Kubernetes Learning Center

Hands-On Course:

Kubernetes full service ownership

Get hands-on! Add service metadata with Kubernetes annotations


Hands-On Course:Full Service Ownership for Developers

K8s full service ownership

Full service ownership is becoming the best practice for cloud-native organizations. In this model, development teams own the entire life cycle of a service, and developers, as part of this ownership, become central to the full code, ship, run equation.

Why full service ownership for developers?

"Full-service ownership means that people take responsibility for supporting the software they deliver, at every stage of the software/service lifecycle. That level of ownership brings development teams much closer to their customers, the business, and the value being delivered. In turn, that unlocks key competitive advantages that make all the difference in today's digital world." -PagerDuty

Why is full service ownership the ideal? In brief, cloud-native development has promised rapid development loops and the ability to ship softer faster -- safely.

Beyond coding for developers

Full service ownership can increase development agility and scale, but the mindset behind how and why changes with this transfer of responsibility. Developers who still believe their team's job is just to write code fail to see that the real job, or mission, is to deliver and run software that represents business value.

Despite the difficulties of introducing developer-centric full service ownership, some organizations have real-world experience in introducing and making this model successful by:

  • Investing in developer education
    • Developer education is an ongoing investment for new and experienced developers, regardless of whether or not they are new to Kubernetes and cloud-native development.
    • Education will consist of developers becoming immersed in the best practices of the specific organization in order to be able to, as the goal above states, deliver and run software that is of business value.
    • Education of this type is both targeted and specific training as well as less formal but more hands-on, such as in the form of game days and failure simulations. There is no better way to learn than to do.
  • Focusing on creating a developer experience
    While creating the developer experience (DevEx) usually falls to the platform engineering team, it is still something the developer should keep in mind in gauging the maturity of their organization and what they can expect in terms of support from their DevEx or platform team. The DevEx team is "productizing" the developer experience, making it replicable and easy to adopt for developers joining a team.
  • Adopting a developer control plane (DCP)
    The entire cloud development loop is complex, and having a single control plane to enable developers to control and configure from development to release to production simplifies the process. Without this "one-stop-shop" of sorts, developers are overrun by an unmanageable number of different development, release and production tools that would all require a level of mastery that is impossible. Developers need their own control plane that integrates the various tools used for all aspects of the development lifecycle, enabling them to become full service owners. An example of an all-in-one dashboard to centralize development tools and manage Kubernetes services is the Ambassador DCP, which is built on popular CNCF tools and integrates into existing GitOps workflows.

Human Service Discovery

Troubleshooting always begins with information gathering. While much attention has been paid to centralizing machine data (e.g., logs, metrics), much less attention has been given to the human aspect of service discovery. Who owns a particular service? What Slack channel does the team work on? Where is the source for the service? What issues are currently known and being tracked?

Kubernetes annotations are designed to solve exactly this problem. Oft-overlooked, Kubernetes annotations are designed to add metadata to Kubernetes objects. The Kubernetes documentation says annotations can “attach arbitrary non-identifying metadata to objects.” This means that annotations should be used for attaching metadata that is external to Kubernetes (i.e., metadata that Kubernetes won’t use to identify objects. As such, annotations can contain any type of data. This is a contrast to labels, which are designed for uses internal to Kubernetes. Label structure and values are constrained so they can be efficiently used by Kubernetes.

As the number of microservices and annotations proliferate, running kubectl describe can get tedious. Moreover, using kubectl describe requires every developer to have some direct access to the Kubernetes cluster. Over the past few years, service catalogs have gained greater visibility in the Kubernetes ecosystem. Popularized by tools such as Shopify's ServicesDB and Spotify's System Z, service catalogs are internally-facing developer portals that present critical information about microservices.

Note that these service catalogs should not be confused with the Kubernetes Service Catalog project. Built on the Open Service Broker API, the Kubernetes Service Catalog enables Kubernetes operators to plug in different services (e.g., databases) to their cluster.

Annotate your services now and thank yourself later

Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Don't wait until something is on fire in production to start wishing you had implemented better metrics and also documented how to get in touch with the part of your organization that looks after it.

There are enormous benefits to building an effective “version 0” service: a dancing skeleton application with a thin slice of complete functionality that can be deployed to production with a minimal yet effective continuous delivery pipeline.

Adding service annotations should be an essential part of your “version 0” for all of your services. Add them now, and you’ll thank yourself later.

Hands-on: Adding service metadata with K8s annotations

Read the following introductions to full service ownership and full lifecycle developers.

  1. Introduction​
  2. Service Ownership Functions
  3. Full Cycle Developers at Netflix - Operate What You Build

Adding Service Metadata in K8s

  1. Read the following: Annotating Kubernetes Services for Humans​
  2. Watch this video: Using a Service Catalog
  3. Follow the tutorial here: Quick Start

Congratulations! You've completed your final Kubernetes lesson. Now you should now have the understanding and tools to comfortably code, ship and run your apps rapidly and safely.

View all Kubernetes Courses


Kubernetes: Faster & Easier Than Ever Before

View and manage your services across the software development lifecycle in real-time with a common interface that integrates with your existing Kubernetes workflow.


We’re here to help if you have questions.

Get a free demo cluster through Ambassador Labs