At Humanitec, we're committed to enhancing the productivity of development teams by continuously evolving our Platform Orchestrator to meet your complex and unique needs. With that in mind, we’re thrilled to announce our latest feature addition: Custom Workload Profiles.
What are Workloads and Profiles?
A Workload in Humanitec is a representation of the code that runs in a Kubernetes cluster, typically as a pod.
In most cases, a Workload is a back-end service or a front-end of an Application. For example, in a microservice architecture, each service would be represented by a Workload in Humanitec. This allows developers to manage and deploy their code in a more organized and efficient manner.
Each Workload uses a Workload Profile to define the infrastructure and runtime requirements for applications and services.
Profiles allow specifying details like:
- Compute resources - CPU, memory, GPUs
- Storage - disks, volumes
- Networking - subnets, ingress
- Runtimes - languages, frameworks, containers
- Dependencies - databases, caches, queues
Beyond generic
Up until now, Humanitec provided three unmutable default Profiles which contain a set of features useful for most standard Workloads. With Customizable Workload Profiles, it’s now possible to precisely control the inputs required by your Workloads and how they should be rendered in the Humanitec Portal.
Perhaps some of your Workloads manipulate user data and, therefore, need different verbosity of logs for audit purposes?
Or maybe you have an advanced observability setup that requires some configuration from the developers to work as designed?
Now, you can expand or create entirely new Workload Profiles with these specialized functionalities, ensuring your applications integrate seamlessly with all parts of your existing ecosystem.
Tailored abstraction
Custom Workload Profiles empower platform teams with the flexibility to curate the right level of abstraction for their developers. You can now fine-tune the Workload Profiles by incorporating additional logic or stripping them down to essentials, depending on your team’s needs.
For example, to reduce the cognitive load of your developers, you want to make the container image version the only thing they have to set before they can run their Workload in the cluster.
To do so, you can remove everything other than the container collection and image feature from your Profile, like this:
Such Workload Profile produces a much simpler UX for the developers and reduces the number of decisions they need to make. As a result, this improves their productivity every time they deploy a new workload or make changes to the existing ones.
For more information check out our detailed documentation on leveraging the CustomWorkload Profiles in your setup.