Notes on Go, Deno and Devops.

What is Devops ?

   

There are thousands of entries out there on What is Devops ? Here’s my understanding on the subject.

Devops is a set of technical and non-technical practices tuned to quickly deliver product experiences which meets the customer’s expectations at a reasonable cost.

Let’s break it down

Assuming that the below concepts are already understood, here is a list of considerations for the above claim.

Technical Practices

  1. Continuous Integration, Delivery, Deployment.

  2. Infrastructure Provisioning and Configuration e.g. via infra as code.

  3. Monitoring: Probes to indicate performance and usage experience for end user.

  4. Ensuring Infrastructure Security.

  5. Budgeting Infrastructure costs.

Non-technical Practices

  1. Collaborating with product engineers and owners to refine technical practices.

  2. Defining perfomance indicators in coordiation with the business needs.

  3. A culture to keep operational concerns in view during product design and development.

  4. A culture of self-service to enable product engineers to provision, monitor and debug independently.

  5. A culture to keep security in mind while adopting a technical practice.

Quick Delivery

  1. Automation to deliver product features quickly while balancing quality.

  2. Introspection tools to allow product engineers to provision, debug and monitor independently.

Product Experiences and Customer Expectations

  1. Priortize Customer Expectations to choose goals. e.g. Monty expects a popular airline ticketing website to show the cheapest tickets but can live with a slower website. Goal: Tooling to ensure available and fresh data integration with partners.

  2. A culture of linking performance optimization activities to improved product experiences.

Reasonable Cost

  1. A 25% budget to logging is unreasonable, if development environments needs to be constrained.

  2. A culture to discuss Build vs Buy before development of bespoke tools.

  3. A culture to discuss Impact vs Effort before adopting new technical practices.

Well, LA-DI-DA. You just defined SRE

Maybe I did. IMO what is Devops and what is SRE is largely dependant on the context. For some organisations, a particular set of practices closely relate to Devops or SRE depending on business needs. Google SRE has the following programming analogy to make a distinction:

Class SRE implements Devops

In this analogy, Devops is the interface to which SRE conforms to. Depending on the scale and needs of a business, a set of practices that can enforce the Devops interface can be organised as a separate function called SRE.

Source: Class SRE implements Devops

The above lists are ofcourse highly opioniated emanating from my own experiences as a systems engineer.

Feedback welcome on twitter: @adnaanx