View profile

Fudge Sunday - Cloud in Public: DevCommsOps

Fudge Sunday
This week we continue to take a look at public things for a public cloud.
☁️✅⚠️🛑
This issue is part 3 of a 5 part series
  1. Fudge Sunday - Cloud in Public: Status Dashboards
  2. Fudge Sunday - Cloud in Public: Engineering SLO
  3. Fudge Sunday - Cloud in Public: DevCommsOps
  4. Fudge Sunday - Cloud in Public: Mean Time To RCA
  5. Fudge Sunday - Cloud in Public: Impact Mapping

When I wrote about The Perfect Team, I summarized it as one to do it, write it down, and think ahead. We now have a historical perspective and definitions for the status dashboards and the Engineering SLO. Next, let’s talk about how “write it down” can be expressed as various forms of communication in DevOps cultures.
DevCommsOps is best described as a purposeful insertion of change management communications within a DevOps culture and conspicuously expressing change management communications. To unpack that neologism a bit, imagine things we want (need?) to know relating to change that is planned, achieved, deferred, failed, and resulting in an outcome.
Recall that Error Budgets, Uptime, and SLO are simply a way to describe the operational objectives to stay up and running balanced with the innovation demands for developing new features, functionality, and availability for services. As such, DevCommsOps provides a consistent and conspicuous account for the changes planned, taking place, and completed that draw against Error Budgets.
Is DevCommsOps a word soup for Changelog, Release Notes, and Error Budget tracking? Perhaps! In practice, much like the growing depth of status dashboards, a single Changelog is more symbolic than practical as a single page to follow all change.
Is DevCommsOps a word soup for a post-ChatOps world within the context of Error Budgets economic policy? Perhaps! However, ChatOps definitions are likely going to vary from vendor to vendor to practitioner pioneers.
Luckily, there’s always a cat meme ready to help us better understand.
Vive La ChatOps!
DevCommsOps in practice
  1. Who do cloud companies send “write it down”? Public? Personalized?
  2. What do cloud companies “write it down”?
  3. Where do cloud companies “write it down”?
  4. When do cloud companies “write it down”?
  5. Why do cloud companies “write it down”?
Let’s take 1-3 in this issue and leave 4-5 for our following issues in the series.
To provide examples, let’s examine where DevCommsOps is found within the hyperscale cloud service providers today using a basic search for “Release Notes,” “Changelog,” “Notices / Maintenance / Announcements,” and “Root Cause Analyses (RCAs) / Incidents.” The list is in no particular order or weighting other than shorter names to longer names.
IBM Cloud
Alibaba Cloud
Microsoft Azure
Amazon Web Services
Google Cloud Platform
Oracle Cloud Infrastructure
Notes:
  • As of this brief exercise, the only hyperscale cloud service provider that appears to have a “single page” approach to Release Notes and Changelog is Oracle Cloud Infrastructure.
  • Compared to AWS’s use of the term major, Google Cloud Platform “incidents,” Oracle Cloud Infrastructure “incidents,” and Microsoft Azure RCAs are more granular and historically accessible IMHO.
  • OCI Status appears to be using Atlassian Statuspage.
  • IBM Cloud publishes incident reports as PDFs.
While there are variations amongst the hyperscalers in expressing DevCommsOps, it is essential to consider personalization less transparent to public perspectives. Personalization is outside of the examples above because these are not public representations.
At the same time, personalized views are unique to the customer experience, which is a topic for our next issue related to time to published communications and dependency mapping.
At this point, we have established definitions for status dashboards and the Engineering SLO set against the backdrop of communications of DevOps culture in the form of DevCommsOps. Now we have a baseline to look at for comparison against timing and dependencies.
In the remaining two issues of the series, we will examine the time involved in publishing “Root Cause Analyses (RCAs) / Incidents” and dependency mapping value. We will also look at the increasing importance of dependency mapping for the future. The answers to “When and Why” from questions 4-5 above are coming soon.
Stay tuned!
Work Plug!
We’ve also been busy publishing content too! Here is a quick sample:
  1. Intelligent CIO’s Myths of Multi-Cloud by Matt Wallace
  2. Dataversity’s The Hidden Costs of Cyber Attacks by Mike Phelan
We’ve also been working with CTOAdvisor as well!
  1. Multi-Cloud at VMWorld 
  2. Multi-cloud data fabric use cases 
  3. Faction multi-cloud technical overview 
  4. Multi-cloud data security: Dell Technologies & Faction
  5. Using Dell PowerScale for multi-cloud data access
If you read this far, when you think about a multicloud journey, keep Factionin mind as a means to maximize access to hyperscale public cloud service provider innovations. Also… We’re hiring at Faction!🎉 See a fit for you or someone in your network? Please don’t hesitate to reach out to me.
  1. Cloud Data Services Leader 
  2. Product Manager, Alliances & OEM (Cloud Technology) 
  3. Enterprise Sales Executive (Cloud Technology) 
  4. Product Development Engineer 
  5. Senior Back-End Engineer
  6. Senior DevOps Engineer 
  7. Senior Infrastructure Engineer (Cloud) 
  8. Senior Software Engineer - Front End
Disclosure
I am linking to my disclosure.
Did you enjoy this issue? Yes No
Jay Cuthrell
Jay Cuthrell @JayCuthrell

Start the week more informed than the week before

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
2814 Brooks St, Suite 512, Missoula, MT, 59801