This week I have been enjoying deconstructing the “State of DevOps Report 2020” presented by Puppet & CircleCI.
This year’s report shares lots of findings, not just analysed data but also proposed fixes and paths forward. It focuses on 3 topics:
- Security
- Change Management
- Internal Platforms
Security
OK, the security side comes across a bit like an afterthought (2 pages compared to 15+ pages for each of the other sections). But hey, it’s like the boring part of parenting: “BRUSH YOUR TEETH!”, “EAT YOUR VEG!”, “SHIFT LEFT ON SECURITY!”. Better a nod to security than no mention at all.
Changes-as-code
There is a lot on change management and automation—suffice to say change management and the associated bureaucracy is an ongoing challenge. My big takeaway here was the “change-management hack” of automated changes-as-code because you can side-step the bureaucracy, lol.
Internal Platforms
So onto the best bit: scaling DevOps practices with internal platforms. The report cites 63% of respondents saying their company has at least one self-service internal platform and correlates ‘high DevOps evolution’ with high use of internal platforms.
Nevertheless, this seems to be a point of contention for some:
Corey Quinn goes on to hypothesize that the focus on internal platforms is because the sponsors have platform offerings. Also, the perception that internal platforms are merely wrappers around AWS services so a waste of invested energy.
I think the cynicism is misplaced, likely due to a misunderstanding there about this concept of an ‘internal platform’ as just cloud services++. The report itself defines an ‘internal platform’ as one that is built by and for the organizations and used to build and delivery applications or services.
With our experience with end-user organizations at the Continuous Delivery Foundation, internal platforms are certainly a thing! There is a whole heck of a lot of stuff you need to build and delivery software above and beyond what your cloud provider offers today. Here are some examples to give a better idea of what internal platforms involve.
Fidelity Investment’s Internal Platform
At this year’s cdCon, Aoife Fitzmaurice and Jimmy McNamara gave an excellent talk about Fidelity’s internal platform for its 12,000 developers.
eBay’s Internal Platform
As another example, eBay also has an internal platform for ‘Enterprise Continuous Delivery’ (ECD), very much treated as an internal product, complete with its own name: tess.io. At a CDF Interoperability SIG meeting, eBay shared how they are reworking the platform to decompose into microservices and leveraging the Tekton Pipelines and Tekton Triggers to do so.
Internal Platforms as Products
At CDF we do see the rise of self-service internal platforms. There is a lot of technology that goes into building and releasing software, and the reality is that most of it is very fragmented and hard to integrate. This is often an under-appreciated fact, but enough of a reality to really warrant a whole open-source foundation dedicated to the topic :-). We are a long, long way from teams being able to pass on all that responsibility to third parties or managed services entirely. Internal platforms are on the rise and the best teams treat them as products, which in this case refers to:
- gathering user stories and requirements
- having product road maps
- establishing metrics for adoption and publicizing them
Kudos to all involved with the report. The State of DevOps Report is well written and well worth digging into for more insights on the platform model, the ‘product-mindset’ that is key as well as the challenges faced. We also hear a great deal about these challenges, as outlined in the report, particularly lack of time and lack of standardization. CDF aims to help address these challenges with our communities working together in the End-user Council and Interoperability SIG respectively. Stay tuned for our CDF Newsletter as the December edition is all about Continuous Delivery in action at organizations such as Fidelity Investments, eBay and more.
