Summary
Since 2010 we have DevOps. This brings increasing delivery speed and efficiency at scale. But next we got high ‘cognitive loads’ for developers and production congestion due to engineering lifecycle complexity. So we need on top of DevOps an instrumentation to ensure and enforce speed, quality, security in modern, cloud native software development. This instrumentation is called ‘golden paths’ in intenal develoepr platforms (IDP).
History of Platform Engineering
Let’s start with a look into the history of platform engineering. A good starting point is Humanitec, as they nowadays are one of the biggest players (’the market leader in IDPs.’) in platform engineering.
They create lots of beautiful articles and insights, their own platform products and basic concepts for the platform architecture (we’ll meet this later on!).
Further nice reference to the raise of platforms
- What we call a Platform
- Platforms and the cloud native connectionwhat-platform-engineering-and-why-do-we-need-it#why_we_need_platform_engineering
- Platforms and microservices
- Platforms in the product perspective
Benefit of Platform Engineering, Capabilities
In The Evolution of Platform Engineering the interconnection inbetween DevOps, Cloud Native, and the Rise of Platform Engineering is nicely presented and summarizes:
Platform engineering can be broadly defined as the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations
When looking at these ‘capabilities’, we have CNCF itself:
CNCF Working group / White paper defines layerwed capabilities
There is a CNCF working group which provides the definition of Capabilities of platforms and shows a first idea of the layered architecture of platforms as service layer for developers (“product and application teams”):
Important: As Platform engineer also notice the platform-eng-maturity-model
Platform Engineering Team
Or, in another illustration for the platform as a developer service interface, which also defines the ‘Platform Engineering Team’ inbetween:
How to set up Platforms
As we now have evidence about the nescessity of platforms, their capabilities and benefit as self service layer for developers, we want to thin about how to build them.
First of all some important wording to motivate the important term ‘internal developer platfoms’ (we will go into this deeper in the next section with the general architecture), which is clear today, but took years to evolve and is still some amount if effort to jump in:
- Platform: As defined above: A product which serves software engineering teams
- Platform Engineering: Creating such a product
- Internal Developer Platforms (IDP): A platform for developers :-)
- Internal Developer Portal: The entry point of a developer to such an IDP
CNCF mapping from capabilities to (CNCF) projects/tools
Ecosystems in InternalDeveloperPlatform
Build or buy - this is also in pltaform engineering a tweaked discussion, which one of the oldest player answers like this with some oppinioated internal capability structuring:
[internaldeveloperplatform.org[(https://internaldeveloperplatform.org/platform-tooling/)
What comes next?
Next we’ll see how these concepts got structured!
Addendum
Digital Platform defintion from What we call a Platform
Words are hard, it seems. ‘Platform’ is just about the most ambiguous term we could use for an approach that is super-important for increasing delivery speed and efficiency at scale. Hence the title of this article, here is what I’ve been talking about most recently.
Definitions for software and hardware platforms abound, generally describing an operating environment upon which applications can execute and which provides reusable capabilities such as file systems and security.
Zooming out, at an organisational level a ‘digital platform’ has similar characteristics - an operating environment which teams can build upon to deliver product features to customers more quickly, supported by reusable capabilities.
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.
Myths :-) - What are platforms not
common-myths-about-platform-engineering
Platform Teams
This is about you :-), the platform engineering team:
how-to-build-your-platform-engineering-team
in comparison: devops vs sre vs platform
https://www.qovery.com/blog/devops-vs-platform-engineering-is-there-a-difference/
