Poltio is a market leader in survey-tools for enterprise clients. They help the world’s top brands to access, engage and learn from their users with interactive content and declared data.
Poltio is running a well trimmed setup on GCP, leveraging the managed Kubernetes engine (GKE). CI is run in Google Cloud Build and Github Actions , Google Cloud Container Registry, AWS ECR and Docker HUB are used as a container registry. Redis is running in cluster. Main database is Google Cloud SQL, DNS is managed by AWS Route 53.
The previous setup at Poltio was pretty good for their day to day developments but in a static way. Everytime a special development requirement was introduced, it broke the regular development, testing and deployment cycles.
“Setting up parallel and dynamic development, testing and QA pipelines by hand simply takes too long.”
By building their Internal Developer Platform with Humanitec, every developer at Poltio now has access to their own DevOps pipelines.
“Before Humanitec every developer kind of shared the generic devops pipeline and this became a bottleneck if multiple devs started working on the same code bases in parallel. Now it feels like every developer has their own personal devops engineer thanks to Humanitec.”
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.
Infrastructure orchestration before and with Humanitec
Before building their Internal Developer Platform (IDP) with Humanitec, Poltio setup was static. If a developer required a new infrastructure component, they usually asked a central DevOps team to procure this. Some fiddled around in the Google cloud console which led to several disasters.
After building their IDP with Humanitec, Poltio’s developers can now independently apply changes to configurations without having to fiddle 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.
“When we started looking at Humanitec we thought it’d be a dream setup, but probably super hard to achieve. It took some weeks and we had it. Insanely easy to set up.“
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.
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.