AlexisHR

Infrastructure and tooling setup

AlexisHR is one of those companies that has their sh*t together. They are running a well trimmed setup on GCP leveraging the managed Kubernetes engine (GKE). CI is run in GitHub Actions, builds are done using Google Cloud Build. Google Container Registry is used for container registries. Redis and RabbitMQ are running in cluster, Pulumi is used for IaC. Main database is MongoDB Atlas.

‍

Key challenges

AlexisHR was already running a fairly mature yet static setup. All the infrastructure was “scripted” using Pulumi which made the setup agile but hard to navigate and use by developers. As they prepared to scale their team, they wanted to make sure developers would be able to self-serve and focus on coding and business logic. The inability to spin up environments on demand was a key challenge. Neither the current approach to application configuration management nor to infrastructure orchestration would have been enough to pull this off.

• Static setup: spinning up a fully provisioned new environment including fresh database instances or namespaces took too long.
• Developer Experience: the current setup added too much cognitive load to teams that were already overwhelmed.
• Ops under pressure: as the company prepared for scale, management wanted to make sure Ops wouldn’t need to scale linearly with the number of developers.

“We knew that the scale at which we had to onboard team members wouldn’t work with our setup.”

Emil Kilhage, Co-founder & Lead Architect

Key improvements

By building their Internal Developer Platform with Humanitec, AlexisHR was able to reach the “dynamic environment” setup they were aiming for. Humanitec helped them to streamline application configuration management. They went from having to fiddle with scripts to a situation where the Platform API creates environment specific manifests, following the rules set by the Ops team. It also helped them streamline their infrastructure orchestration, integrating with their existing Pulumi setup and leveraging Humanitec’s open source drivers.

• Spin up fully provisioned environments dynamically to test, debug and prevent developers from being blocked.
• Ops can scale: frustrating, repetitive ticket ops workflows are automated
• Developer experience is optimized and cognitive load reduced through a streamlined delivery setup.

“The fact alone that Humanitec enables us to spin up fully provisioned environments with a single command is tremendously helpful. No more waiting times due to blocked environments!”

Emil Kilhage, Co-Founder and Chief Architect

Humanitec erased bottlenecks and dependencies, reduced pressure on operations, simplified maintenance and reduced waiting times. Deployment frequency skyrocketed and the change failure rate dropped.

Technical deep dive

Infrastructure orchestration before and with Humanitec.

Before building their Internal Developer Platform (IDP) with Humanitec, AlexisHR’s setup was static. If a developer required a new infrastructure component, they did that through Pulumi. This approach was hard to scale, tedious to operate and non-compliant. After building their IDP with Humanitec, Alexis’s developers can now indipendently apply changes to configurations without fiddling with unstructured scripts. They are able to self-serve any tech they require, such as fully provisioned environments, databases, or simply debug by pulling logs and error messages.

“What struck me most is how simple it was to get going. “

Emil Kilhage, Co-founder & Lead Architect

App config management

Before Humanitec, the team used Helm to manage application configurations. This approach made it complex to spin up environments dynamically without being trapped in dependencies between systems. Onboarding developers to Helm is neither easy nor scalable.

Humanitec allowed them to simplify their setup, without further overwhelming teams with Helm charts. Ops can now set baseline templates that contain any default they want to enforce. Developers can apply changes to these templates through the CLI or UI. At deployment time, the platform API creates a fresh set of manifests including the environment specific elements (DBs, DNS, etc.), saves them to the repo in Github and executes them against the GKE API. Manifests are versioned, increasing visibility and allowing for easy rollbacks or diffs.

Ops still left the option for developers to script everything themselves using Helm, if they so wish.

Final setup

Github Actions is used for CI and is wired up to the Platform API to notify it once the image is built. The image registry is wired up to the Platform API as well. The API deals with RBAC, creates application configurations per deployment and calls the correct open source driver at the correct request. Developers self-serve deployments, resources, logs and more through the developer self-service UI or CLI.

Timeline and evaluation

• POC: 3 weeks
• Migration: 5 weeks
• Onboarding per new developer: 30 minutes