Microstructures and other Velocity Drivers — Part 1
Over the next six weeks I’ll be releasing a chapter at a time of the Manifesto I’ve written on my approach to DevOps and why I believe it should be the de-facto approach to development, delivery, maintenance and support for Cloud Native organisations.
So here is Chapter 1:
Introduction
I came into DevOps almost by accident. I’ve worked in Software design and delivery for most of my professional life, which started too long ago that I wish to detail. In will say, however, that I started as a COBOL programmer building a Sales Order Entry system before going on to write Assembler for the Operating system, all of which was on an IBM System 360 Mainframe. Then I worked with Minicomputers, PC’s, Client-Servers, CORBA, Web Services, SOA, API’s and Microservices using languages like C, C++, Java, Python, JavaScript and Node.js, and Golang; all governed by Waterfall, and Agile. Is that the summarized history of modern computing? Possibly, but it is a summary of my pre-DevOps career.
However, in 2015 I was offered and opportunity, by my then employer, to move to the UK as part of a plan to sell the company to a huge international services organization that had, one year before, bought the sister company of ours. The sister company had built a cloud design product that was agnostic and also supported bare metal. Back in 2015 this was of great interest. Our company had built a very flexible and powerful API Management provider. Back in 2015 this was also of great interest, and the two had synergies that made them attractive.
The plan failed, for reasons I won’t detail, so it left me in a position of being in the UK and needing to find a place in this huge international services organization, that I had joined as part of the sales plan. The obvious path was to become the EMEA expert in the cloud design/delivery product. So, I moved from Software Product build to Infrastructure and Cloud Professional Services.
Just Prior to this I had had some exposure to Cloud via AWS, where I migrated the API management Demo installation from CD’s distributed by post across the world, to an AWS AMI that could be used to create a temporary EC2 VM whenever a demo was necessary.
As luck would have it, while working for a client in South Africa in 2013, consulting on my company’s SOA and API Management solution for a very large Pay TV operation down there, the client asked me to brief them on this new approach to delivering Software called “DevOps”. So, my introduction to “The Phoenix Project” was made.
So, moving into working with the Cloud Management Product wasn’t entirely a green field for me.
Such is the way I do things; I began to re-read “The Phoenix Project” and began to see subtleties and lessons lost on me on the first read. I also consumed document after document and attended presentations on DevOps from various sources.
I became convinced that DevOps was the next, obvious, step from Agile in the evolution of computing. The problem is, apparently, I was the only one!
Even while at ThoughtWorks their focus was on Software Development and not Delivery. There was great work coming from Jez Humble, John Allspaw, and Kief Morris, but those at the top of the ThoughtWorks tree thought this was orthogonal to software improvement and velocity. It was still just about the infrastructure that software run on. Over time I have learnt to dislike the word “infrastructure” a great deal as it was a convenient way of justifying that DevOps had no impact on software development and delivery.
My most recent years my work has been one of delivering into public clouds, as these bundled services have become more mature and accepted by most businesses. The fundamental differentiator between a public cloud and any other cloud variant is that all services can be utilized and managed via an API. This knowledge has led to an epiphany for me:
Public Clouds have no infrastructure (at least none that the user sees). They are all a bundle of Software Services that you access via API’s and utilize to run your software.
So, if public clouds don’t have infrastructure, only software interfaces, what is the difference between using them and using SQL to utilize a RDBMS? Similarly, what is the difference between using them and a Ping Identity API, developers interact with to provide Authentication and Authorization for their services?
I pose these questions as a mechanism to reset your thinking in readiness for the ideas I’m about to put forward. Collectively I call them Velocity Enablement and Gain, or just Velocity Enablement.
Velocity Enablement is a loose collection of practices that I term Velocity Drivers. As the title of this book suggests, Microstructures are one of these Velocity Drivers, and probably the most important. Others are:
- Structuring a DevOps team to be responsible for:
- Shared Cloud Services
- Velocity Enablement
- DevOps Advisory Services - Having Dev teams take responsibility for their own Microstructures
- Shared Production Support
We’ll take a detailed look at these Velocity Drivers in the remainder of this book.
Before we do that, Let’s explore why this book is concentrating on Velocity and Velocity Enablement and Gain.
Velocity is a metric for work done, which is often used in agile software development. [1] It is fair to say that it has had a chequered history and that there may be better metrics [2], however using the term, if not the metric, is still useful in conveying a sense of the ability to deliver required business ability. So, with this in mind, why is this book emphasizing it? To be honest, as a practicing engineer, I’m always more concerned with Security, Resilience, Performance, Scalability, and Maintainability.
The reality is, in today’s world, it is very expensive to create business value from computing. It may be necessary in some cases, but if the cost of delivering that value can be minimised a business to use those methods (hence the dream of No-Code[3] systems becoming fashionable again). Therefore, regardless of the measure, if Velocity is increased more is done in the same amount of time, or, as I like to look at it, waste is eliminated.
Improving daily work is even more important than doing daily work [4]
Therefore, improving ways of working, changing ways of working, or eliminating ways of working, can return back to the Dev team time and resources they can use to say:
- Improve the scope and detail of Performance Testing, or for some organizations, start conducting Performance testing
- Start, or do more Code Reviews and/or Walkthroughs
- Introduce, or improve, Vulnerability Testing
- Review the design for completeness and correctness
- Introduce Threat Modelling sessions
All these activities are seen as de-rigor for a modern, high performing, development team. However, the reality is that there are not that many modern, high performing, development teams in existence, even in “Poster Child” organizations like Google, Apple, Meta (Facebook), Spotify, etc. They also have a common goal, to reduce the Unplanned Work of Downtime, bugs, Performance issues and Security Breaches.
Unplanned Work is what prevents you from doing planned, or productive work. Like matter and antimatter, in the presence of unplanned work, all planned work ignites with incandescent fury, incinerating everything around it. Like Phoenix. [5]
This is why I use the term Velocity Improvement and Gain. It’s a metaphor, a pointer, to an organization’s ability to create High Performing Teams [6].
It is also important for me to state that Velocity Enablement and Gain is only practical in a Public Cloud. It’s Cloud Native, if you like. The reason I say this is that Velocity Enablement relies on the ability to break up Cloud Services into bundles that support a Microservice – the Microstructure. It is often not possible to do this with Data Centre Infrastructure, and Private Clouds are more often than not a renaming of and outsourced and shared Data Centre, making them as unsuitable as a physical Data Centre. For this reason, I will not be talking about anything other than Public Cloud Services in this book, not Infrastructure.
I have only one ask of you, the reader, going forward, and that is to keep an open mind, if you have issues with anything I propose then please ask yourself why? and keep on being enquiring and looking for “better ways”.
[1] https://en.wikipedia.org/wiki/Velocity_(software_development)
[2] https://www.agilealliance.org/glossary/velocity/
[3] https://en.wikipedia.org/wiki/No-code_development_platform
[4] The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Authors: Gene Kim, Kevin Behr, George Spafford
Publisher: IT Revolution Press
ISBN:978-0-9882625-9-1
Published:10 January 2013
[5] The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Authors: Gene Kim, Kevin Behr, George Spafford
Publisher: IT Revolution Press
ISBN:978-0-9882625-9-1
Published:10 January 2013
[6] https://en.wikipedia.org/wiki/High-performance_teams