About AlexisHR
AlexisHR is a fast growing startup in the HR space. They offer automation, onboarding to offboarding and everything in between the HR management cycle. AlexisHR goes the extra mile in engineering to craft a product that nails the balance between design, functionality and security.
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.
Alexis’ 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 DevOps/operations teams would not have to scale linearly. Developers should be able to go fast while keeping chances of breaking things to a minimum. The word of hour: standardization. It became
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.
- Complex deployment setup: at Alexis’ scale, the GitOps-Helm combination was hard to debug, maintain and operate for developers. Kubernetes was hard to use and slowed teams down.
- Ops bottleneck: key person dependencies slowed down overall delivery and led to ticket ops. Waiting times for databases, environments and other resources blocked development.
- Prod outage: deployment failure rate increased due to faulty dependencies on the test-infrastructure.
- Slow onboarding: getting new developers up to speed used to be extremely time consuming and inefficient. At their growth rate this blocked a lot of resources.
“We knew that the scale at which we had to onboard team members wouldn’t work with our setup.”
Emil Kilhage - Co-founder & CTO
Platform architecture
AlexisHR designed their platform following Humanitec’s GCP reference architecture. AlexisHR opted against an additional UI portal layer and focussed down on primarily code-based interaction. As an interface they opted for Score, complemented by the Orchestrator CLI. AlexisHR is strongly engrained into the Pulumi ecosystem. Humanitec’s flexible driver system allowed them to extend their platform to be compatible with their Pulumi setup. The platform team configured the baseline-configurations for applications and built reusable infrastructure templates. For AlexisHR it was vital not to take any flexibility away from the developers. Because of this RBAC rules for the Platform Orchestrator were set in a way that allow individual contributors to configure resources down to the Pulumi level should that be necessary.
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 Orchestrator 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 & CTO
Timeline and evaluation
- POC: 7 working days
- Total Migration: 6 weeks
- Onboarding per new developer: 30 minutes
