A 100% unfiltered blog straight outta
NewsroomProduct StudioInside CurveCompiled
Compiled

Self-Service Infrastructure

By Adam Strawson23 Nov 2021
3 min read

Unexpected item in bagging area ⚠️

Within the Core Platform team at Curve we spend a lot of our time building the tools that allow our engineers to be more efficient.

One of the most common requests to our team was for the provisioning of infrastructure for a service; that might be a database, or setting up of credentials to something like RabbitMQ. The Engineer would have to submit a ticket, a Platform Engineer would then have to update Terraform with the requested change, wait for the Merge Request to be approved, and then apply the change, and repeat for each environment. This process could be anything from an hour to a couple of days depending on what we're working on at the time.

It was clear that this wouldn't scale as Curve continued to grow. 📈

Bring on Self Service! 🚀

Giving the ability for Engineers to manage their service components without the need of a Platform Engineer was where we wanted to be. It would mean Engineers would no longer be blocked waiting for us to create a database, and free up time for the Core Platform team to focus on other tasks, rather than creating databases.

All services at Curve are deployed to our Kubernetes clusters via a Helm Release (Using the FluxCD Helm Operator), using our own internal Helm Chart. We felt it was sensible to keep all service infrastructure components within their helm release, this would allow anyone to easily see what components a service has (Postgres, RabbitMQ, etc), and also create a clear lifecycle for the service (Delete the helm release, and it's components are removed too 🚮).

We first setup Terraform Operator, a Kubernetes CRD and Controller to handle Terraform operations. This would allow us run Terraform within our Kubernetes cluster as part of the Helm install/upgrade process.

We then modified our Helm Chart with a handful of templates for specific infrastructure components which created the Terraform resources, these templates used conditional blocks, so that when the new infrastructure value was used, it would use the appropriate template.

Lets use RabbitMQ as an example;

We have a Terraform module that is used to create credentials within a defined RabbitMQ cluster, and then store those credentials within Vault for a given service.

Within our Helm Chart, we create a template terraform-rabbitmq-credentials.yaml

What the above will do is if the conditional is met, the Terraform Operator will pull the module, and then run a terraform apply with the variable service. In this example, RabbitMQ will create a user as the service name. 

The Engineer can then create the RabbitMQ credentials at the point of deploying their service by updating their Helm Release with this new Chart:

The combination of these means, when a service is deployed for the first time the following will happen:

  1. Helm install will run

  2. Terraform Operator will run a job with the RabbitMQ resource (terraform apply), the created credentials will be written to Vault as part of the module.

  3. When the pods come online, the credentials will be pulled from Vault (via an init container), and made available to the service.

Currently we have self-service support for Postgres 💾, MongoDB 💿 , RabbitMQ 🐰, Kafka 📬, and PagerDuty📟(for service alert routing).

 

About the Core Platform Team 🦜

The Platform team maintain Curve’s services, both for customers and for our engineering team. Our goal is to build highly reliable and highly scalable infrastructure, running across AWS and GCP, on Kubernetes (EKS), and technologies such as Istio, Ambassador, Terraform, Atlantis, Kafka, and Vault to name a few.

We're hiring within the Core Platform Team too! - Careers | Curve

engineeringSREPlatformcompiled

Recommended


Studio

Add your Visa credit card to Curve to keep shopping at Amazon

Newsroom

The US consumer is going to lose its mind over Curve

Compiled

Developer Experience@Curve

Compiled

The history of tech at Curve


Curve OS Ltd, registered in England and Wales, #09523903

Copyright - 2021 © Curve OS Limited. 

The Curve Card, the Samsung Pay+ and the E-money related to these cards is issued in the UK by Curve OS Limited, authorised and regulated by the Financial Conduct Authority to issue electronic money (firm reference number 900926). Curve OS Limited is registered in England and Wales, United Kingdom (company reference number: 09523903) and located at 15-19 Bloomsbury Way, Holborn, London, United Kingdom, WC1A 2TH. 

Curve Flex is provided in the UK by Curve Credit Limited. Curve OS Limited is an introducer appointed representative of Curve Credit Limited, which is authorised and regulated by the Financial Conduct Authority (firm reference number 925447). Curve Credit Limited is registered in England and Wales, United Kingdom (company reference number: 12464458) and located at 15-19 Bloomsbury Way, Holborn, London, United Kingdom, WC1A 2TH.

The Curve Card and the e-money related to cards issued in the EEA is issued by Curve Europe UAB, authorised in Lithuania by the Bank of Lithuania (electronic money institution license No. 73 issued on 22 of October, 2020). The Curve Card and Samsung Pay+ are issued pursuant to license by Mastercard International Inc. Mastercard® is a registered trademark of Mastercard International Incorporated. Curve Europe UAB is registered in Lithuania (company reference number: 305626541) and located at Jogailos g. 9, LT-01116 Vilnius.