Merge pull request #196 from FL303/main

Updated articles

content/community/articles.md

@@ -9,6 +9,7 @@ weight=30
 _Here we provide a repository of the latest and greatest blog posts and articles all about Internal Developer Platforms (IDP). Wrote an amazing piece and like to have it included? [Submit a pull request!]({{< relref "/#how-to-contribute-to-internal-developer-platform" >}})_
 
 ## 2024
+- [Platform engineering is the industrialization of software development](https://platformengineering.org/blog/platform-engineering-is-the-industrialization-of-software-development) _Luca Galante, Product at Humanitec_
 - [Building an Internal Developer Platform: 4 Essential Pillars](https://thenewstack.io/building-an-internal-developer-platform-4-essential-pillars/ ) _Ritesh Patel, Co-Founder & VP of Products at Nirmata_
 - [How to Define Engineering Standards](https://roadie.io/blog/how-to-define-engineering-standards/) _Sam Nixon, Head of Product at Roadie_
 - [Platform engineering: Best practices in “Vendor engineering”](https://platformengineering.org/blog/platform-engineering-vendor-engineering-best-practices) _Jordan Chernev, Senior Technology Executive_

content/learn/what-is-an-internal-developer-platform.md

@@ -6,53 +6,56 @@ weight=10
 
 # What is an Internal Developer Platform (IDP)?
 
-_An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service. An IDP consists of many different techs and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies. Following best practices, platform teams treat their platform as a product and build it based on user research, maintain and continuously improve it._
+_An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service. An IDP consists of many different techs and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies. Following best practices, platform teams treat their platform as a product and build it based on user research, maintaining and continuously improving it._
 
 {{< hint info >}}
-TLDR; Internal Developer Platforms (IDPs) are configured by platform engineering or Ops teams and used by developers. Ops teams specify what resources start up with what environment or at what request. They also set base-line templates for application configurations and govern permissions. This helps them to automate recurring tasks such as spinning up environments and resources and makes their setup easier to maintain by enforcing standards. Developer teams gain autonomy by changing configurations, deploying, spinning up fully provisioned environments, and rollback.
+TLDR; An Internal Developer Platform (IDP) is built and provided as a product by the platform team to application developers and the rest of the engineering organization. An IDP glues together the tech and tools of an enterprise into golden paths that lower cognitive load and enable developer self-service. The platform team ships the IDP following product management best practices, iterating on it based on user research and tight feedback loops with users and other key stakeholders. Stakeholders include application developers, infrastructure and operations teams, security teams, architects and CCOEs, and executives, among others. This means that successful platform engineering teams develop dedicated functions within themselves to ensure the perspectives of different stakeholder groups are represented. For example, infrastructure platform engineering aims to ensure that the IDP provides tangible benefits to infrastructure and operations teams.
 {{< /hint >}}
 
-### How Internal Developer Platforms are used by Platform, Ops or DevOps teams
+### How Internal Developer Platforms are built by Platform teams
 
-The platform team primarily builds, runs, configures and maintains the IDP. Teams building and running IDPs concentrate on standardization by design, infrastructure, service level agreements, workflow-optimization and configure the IDP to automate recurring or repetitive tasks, such as spinning up resources or environments for developers. The platform team also sets the baseline for dynamic configuration management  to avoid unstructured scripting which would lead to excessive maintenance time. See below for all building blocks that the platform team usually operates.
+Internal Developer Platforms are built by platform engineering teams with their end user in mind, the application developers. Developers are therefore the internal customers of platform teams. However, many other stakeholders within the engineering organization need to be involved in the development and rollout of an IDP to ensure adoption. These include infrastructure and operations (I&O) teams, architects, security teams, and executives.
 
-### How Internal Developer Platforms are used by application developers
+The IDP is designed and shipped in sync with the overall business goals and the objectives of the different stakeholder groups. Platform teams combine a set of open-source and commercial tools following best-practice architectural blueprints and [reference architectures](https://platformengineering.org/platform-tooling). Successful platform engineering initiatives start small, following a Minimum Viable Platform (MVP) approach, and iterate quickly to continuously prove value to all key stakeholders.
+
+Enterprise-grade Internal Developer Platforms have a set of baseline configurations that get enforced across all workflows and development teams, driving standardization and automation by design. This allows engineering organizations to decrease time to market while ensuring security and compliance best practices are followed everywhere, i.e. they can move faster without breaking things.
 
-IDPs integrate into existing workflows which usually remain a git-push deploy workflow but add further automation. The entire deployment process is now at the disposal of the developer. They can request resources, spin up fully provisioned environments, rollback, deploy and set deployment automation ruling autonomously.
+### How Internal Developer Platforms are used by application developers
 
-{{< figure caption="A modern developer needs three panes of glass: the IDE to code, git to merge and an IDP to ship." link="/_assets/images/3_panes_of_glass.png" src="/_assets/images/3_panes_of_glass.png" alt="3_panes_of_glass.png" >}}
+Internal Developer Platforms meet application developers where they are at. This is crucial to ensure adoption. Successful platform engineering initiatives provide developers with interface choice (code-based e.g. OSS workload specification [Score](https://score.dev/), UI based e.g. a portal, CLI, API, etc.), striking the right balance between shielding them from complexity while still providing them with the context they need to do their job.
+Through these interfaces, developers can request resources, spin up fully provisioned environments, roll back, deploy, and trigger deployment automations, all without the need for support from their operations colleagues.
 
 ### Five core components
 
-Although variations exist, a fully-fledged IDP is made out of five core components. 
+Internal Developer platforms have five core components, reflecting the features and main usage patterns of their different users. Note, that these are different from the five planes of [IDP reference architectures](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures).
 
 #### Separation of concerns
 
-Two features are exclusively used by the Ops, DevOps or Platform team: [_Infrastructure Orchestration_]({{< relref "infrastructure-orchestration" >}}) and [_Role Based Action Control (RBAC)_]({{< relref "role-based-access-control" >}}). [_Application Configuration Management_]({{< relref "application-configuration-management" >}}) is used by the platform team to set baseline-templates but also used in day-to-day activity by the application development team. Developers use the functionalities [_Deployment Management_]({{< relref "deployment-management" >}}) and [_Environment Management_]({{< relref "environment-management" >}}).  
+Two features are exclusively owned by the platform, Ops, or DevOps or team: [_Infrastructure Orchestration_]({{< relref "infrastructure-orchestration" >}}) and [_Role Based Action Control (RBAC)_]({{< relref "role-based-access-control" >}}). [_Application Configuration Management_]({{< relref "application-configuration-management" >}}) is used by the platform team to set baseline templates but is also used in day-to-day activity by the application development team. Developers use the functionalities [_Deployment Management_]({{< relref "deployment-management" >}}) and [_Environment Management_]({{< relref "environment-management" >}}).  
 
 {{< button relref="core-components" >}}
 -> Core Components
 {{< /button >}}
 
 ### Developer portal, service catalog, UI, API, or CLI?
 
-All of the above-mentioned building blocks are centered around a platform API or a Platform Orchestrator. 
-Depending on the maturity of the IDP, it provides several interfaces and access points.
-That can be a CLI, different kind of User Interfaces (UIs) or a developer portal with a service catalog to unify the developer experience.
+All of the above-mentioned building blocks and core components are enabled by the configuration engine at the heart of an IDP, the Platform Orchestrator. 
+Different interfaces can be plugged on top of the Platform Orchestrator to access the underlying platform capabilities.
+These can be a CLI, different types of User Interfaces (UIs) or developer portals (e.g. Backstage), or code-based workload specifications (e.g. Score)
+It’s important not to get confused by the linguistic similarities between Internal Developer Portals and Internal Developer Platforms. Portals are simply one of the possible interfaces (UI-based specifically) of the underlying platform. IDP should always be used to refer to an Internal Developer Platform, which is the entire platform layer of an enterprise, not a single tool or interface.
 
 Or how Gartner puts it:
 
 _“***Internal developer portals*** serve as the interface through which developers can discover and access ***internal developer platform*** capabilities.”_ 
 
-Source: A Software Engineering Leader’s Guide to Improving Developer Experience by Manjunath Bhat, Research VP, Software Engineering Practice at Gartner. ([Full report behind paywall](https://www.gartner.com/document/4017457))
+Source: A Software Engineering Leader’s Guide to Improving Developer Experience by Manjunath Bhat, Research VP, Software Engineering Practice at Gartner.  - [Full report behind paywall](https://www.gartner.com/document/4017457)
 
 
 ### Integrating with all existing tech and tools
 
-IDPs consist of all the existing tech and tooling a team has in place already. They integrate mainly through APIs to prevent introducing yet more scripts running in clusters which would increase the security risk and increase maintenance overhead.
-On the cluster side, modern IDPs are (in 95% of all cases) built on Kubernetes with containers as workloads. Platform teams usually assign fixed clusters to the platform and assign them to environment types. If a developer requests a new environment, the platform can now set up a namespace in the assigned cluster and take care of updating configurations.
-As being part of the IDP, CI setups fetch built images needed to update environments or create new ones. External resources such as databases, DNS, and others are connected through resource drivers that signal the success or failure of updating/creating a resource back to the IDP’s API. Those drivers can be Infrastructure as Code (IaC) scripts or simple little services.
-Ops tools such as monitoring, chaos engineering, GitOps tools can be plugged into the different workflows of an IDP at the team’s convenience. We’ve compiled a long list of all tools we see commonly used within IDPs.
+Internal Developer Platforms are designed to enable developer self-service on top of complex, brownfield enterprise setups. This means an enterprise-grade IDP needs well-established integration patterns with both existing and future tooling.
+Top performing platform teams rely on Platform Orchestrators as the glue bringing together the different components of the underlying toolchain. Orchestrators typically sit post-CI pipeline and ingest built images directly from image repositories. They match developers’ requests to the rules and templates defined by the platform team, generating the respective configuration files and handing them over to a CD solution (some orchestrators like Humanitec can also take care of the deployment).
+Monitoring, logging, and security tools can be plugged on top of the orchestrator and across the different workflows of an IDP at the team’s convenience. We’ve compiled a long list of all tools we see commonly used within IDPs.
 
 {{< button relref="platform-tooling" >}}
 -> Platform tooling