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 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.
â
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.
âWe knew that the scale at which we had to onboard team members wouldnât work with our setup.â
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.
â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!â
Humanitec erased bottlenecks and dependencies, reduced pressure on operations, simplified maintenance and reduced waiting times. Deployment frequency skyrocketed and the change failure rate dropped.
by changing the setup from static to dynamic.
by providing what developers need in real-time.
Developer driven deployments drove deployment frequency.
by allowing developers to go fast without breaking things.
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. â
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.
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.