Skip to content

Commit

Permalink
Merge pull request #198 from InternalDeveloperPlatform/fix-rbac-typos
Browse files Browse the repository at this point in the history
Fixed RBAC typos
  • Loading branch information
christophcrichter authored Nov 18, 2024
2 parents 2ab9ce1 + fc5162f commit 6a897e0
Show file tree
Hide file tree
Showing 3 changed files with 40 additions and 41 deletions.
4 changes: 2 additions & 2 deletions content/ecosystem/platform-tooling/image-registries/harbor.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@ url="/registries/harbor"

# Harbor

Harbor is an open source registry that secures artifacts with policies and Role Based Access Control. It ensures images are scanned and free from vulnerabilities, and signs images as trusted. Harbor is a graduate of the Cloud Native Computing Foundation. It delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud-native compute platforms like Kubernetes and Docker. Harbor is what we are seeing used most in the Internal Developer Platform ecosystem.
Harbor is an open source registry that secures artifacts with policies and Role-Based Access Control. It ensures images are scanned and free from vulnerabilities, and signs images as trusted. Harbor is a graduate of the Cloud Native Computing Foundation. It delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud-native compute platforms like Kubernetes and Docker. Harbor is what we are seeing used most in the Internal Developer Platform ecosystem.

{{< button href="https://goharbor.io/" target="_blank" >}}
-> Harbor
{{< /button >}}
{{< /button >}}
Original file line number Diff line number Diff line change
Expand Up @@ -8,79 +8,79 @@ url="/platform-orchestrators/humanitec"

**Claim:** Powers your Internal Developer Platform (IDP)

**Focus:** Enables teams to build their own Internal Developer Platforms. Developed by former Google platform engineers, Humanitec focuses on providing a high-level developer experience and self-service for scale-ups to Fortune 100. Humanitec is widely considered the number one Platform Orchestrator and best option for IDP building in terms of total users and community. The system claims that it can save a seven-person developing team about 50 hours a week by streamlining the development process.
**Focus:** Enables teams to build their own Internal Developer Platforms. Developed by former Google platform engineers, Humanitec focuses on providing a high-level developer experience and self-service for scale-ups to Fortune 100. Humanitec is widely considered the number one Platform Orchestrator and best option for IDP building in terms of total users and community. The system claims that it can save a seven-person developing team about 50 hours a week by streamlining the development process.

**Website:**[humanitec.com](https://humanitec.com/)

**Docs:** [docs.humanitec.com](https://docs.humanitec.com/)


### Details

| Details | |
| --- | ----------- |
| Does it require developers to have DevOps knowledge? | No |
| Self-hosted: | No, but Enterprise yes |
| Orchestrator | Kubernetes |
| Integration Concept | API based, external drivers |
| Setup time first app | 4 hours |
| Source | Closed |
| Use Case | Scale up to Enterprise Setups |
| Total Cost of Ownership | The vendor doesn’t publish prices on the website but people report a cost of around 20-30% of a self-built setup. |
| Adoption | Market-leader for IDPs, production-grade, widely adopted |
| Details | |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Does it require developers to have DevOps knowledge? | No |
| Self-hosted: | No, but Enterprise yes |
| Orchestrator | Kubernetes |
| Integration Concept | API based, external drivers |
| Setup time first app | 4 hours |
| Source | Closed |
| Use Case | Scale up to Enterprise Setups |
| Total Cost of Ownership | The vendor doesn’t publish prices on the website but people report a cost of around 20-30% of a self-built setup. |
| Adoption | Market-leader for IDPs, production-grade, widely adopted |

{{< button href="https://humanitec.com" target="_blank" >}}
-> Humanitec
{{< /button >}}
{{< /button >}}

### What is Humanitec?

Humanitec describes itself as “the Platform Orchestrator at the core of your Internal Developer Platform.”

Humanitec enables organizations to build their own dynamic Internal Developer Platform, bringing the learnings from the platforms at Google and other leading tech companies to the general public. It is a flexible, highly-customizable product that orchestrates tools and infrastructure components to enable end-to-end self-service.

Engineering teams can describe the application architecture and its infrastructure dependencies in a declarative way. Humanitec’s Platform Orchestrator applies changes and dynamically generates app and infra configurations for every deployment. This dynamic approach allows platform teams to drive standardization by design, by letting them define reusable templates. Developers self-serve the tech and tools they need to operate their applications, driving productivity and velocity across the organization.

Humanitec offers the broadest coverage of integrations compared to other tools on the market through its open-source drivers and the capability to use any Infrastructure as Code (IaC) script. Many adopt Humanitec because of its overall extensibility, and developers can use the API, UI or CLI to self-serve all the tech they need.

With Humanitec, platform/DevOps/operation teams can define golden paths for developer self-service and overcome ticket ops. This allows developers to self-serve the tech they need while ops stays in control (consistency and standardization by design.

An IDP built with Humanitec serves to increase deployment frequency and reduce lead time + lower change failure rate, reduced time spent on maintenance, increasing developer satisfaction.

The most significant setback with the current version of Humanitec is that the documentation needs improvement. Given the fast growing functionalities, some parts seem to be missing in the docs.

## What is the mission and vision of Humanitec?

Humanitec has five fundamental product principles: integrate & embrace, openness, zero lock-ins, following industry conventions, and platform as product.

Through the integrate and embrace strategy, Humanitec is designed to effortlessly work with any CI, any cloud (also multi-cloud), any IaC and other tools such as Backstage, Argo, meeting the variability of an enterprise-level infrastructure setup.

Openness pledges that developers of any skill level can effectively use the platform to “fight the scripting hell.”

With the promise of zero lock-ins, Humanitec releases users from dependency on a vendor for products or services.

And since Humanitec doesn’t believe in reinventing the wheel, they adhere to industry standards to streamline IDP development.

Finally, Humanitec believes in a platform as product approach, where platform teams behave as product teams, iterating on the platform based on the feedback from their customers, the rest of the development teams.

## A brief history of Humanitec

Humanitec is a VC-financed company created to make IDP building easier. It was crafted by a team of developers who worked on Google’s IDP and wanted to share what they learned with the general public.

## Core features of Humanitec

Humanitec is a Platform Orchestrator, which enables dynamic configuration management and does the heavy lifting for RBAC, infrastructure orchestration, app config management, and deployment automation. As the core of the IDP, the orchestrator enables developers to request fresh environments, resources like databases, DNS, storage and more without writing scripts or filing operations tickets.
Humanitec integrates with any CI pipeline. It also promises that operation teams can incorporate just about any tool or workflow (incl. GitOps & IaC) they want to use for their IDP through the system’s open source driver library. Alternatively, engineers can build a custom driver.

Humanitec integrates with any CI pipeline. It also promises that operation teams can incorporate just about any tool or workflow (incl. GitOps & IaC) they want to use for their IDP through the system’s open source driver library. Alternatively, engineers can build a custom driver.

Definition and configuration capabilities for operations teams include

- Definition of baseline configurations
- Role Based Access Control (RBAC)
- Role-Based Access Control (RBAC)
- Infrastructure orchestration
- Definition of resource dependencies (e.g., which kind of environments should be equipped with which kind of infrastructure)


Self-service capabilities for engineering teams include

- Creation of fully provisioned environments with a single command
- Service creation (workloads, default configs and depending resources)
- Resource provisioning (databases, file-storage, DNS and clusters)
Expand Down
11 changes: 5 additions & 6 deletions content/learn/what-is-an-internal-developer-platform.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,25 +31,24 @@ Internal Developer platforms have five core components, reflecting the features

#### Separation of concerns

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" >}}).
Two features are exclusively owned by the platform, Ops, or DevOps or team: [_Infrastructure Orchestration_]({{< relref "infrastructure-orchestration" >}}) and [_Role-Based Access 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 and core components are enabled by the configuration engine at the heart of an IDP, the Platform Orchestrator.
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)
_***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)

### Integrating with all existing tech and tools

Expand All @@ -66,7 +65,7 @@ Monitoring, logging, and security tools can be plugged on top of the orchestrato
Before we dive into the specifics, let’s briefly look at the reason this category is evolving along with those naming conventions.

- **Internal** – clearly separated from externally facing platforms such as [Twilio's developer platforms](https://www.twilio.com/platform). IDPs are meant for internal use only.
- **Developer** – indicates the internal customer and the primary user, the application developer.
- **Developer** – indicates the internal customer and the primary user, the application developer.
- **Platform** – characterizes the product type.

Slight variations exist, but we’ve actively decided against those as the descriptions are less accurate and the risk of misunderstanding is too high. Those include:
Expand Down

0 comments on commit 6a897e0

Please sign in to comment.