Moving from infrastructure silos to a platform model
A large education technology company
We worked with a large EdTech company with more than 100 engineers. The infrastructure team had a stream of requests from developer teams, and developer requests were coming in faster than the team could properly step back and improve the way that work was done.
We worked with the team on both sides of that problem. We looked at how requests were handled day to day, and how much of the infrastructure developers could get without needing someone to provision it manually.
100%
IaC adoption for new cloud infrastructure
<1 hour
to get infrastructure
25 → 3
exposed microservice endpoints
What was getting in the infrastructure team’s way?
The team had a lot of work in progress at any given time. Ad hoc requests from developers kept getting added and WIP kept growing. There wasn’t enough time for them to work on automation or improve how infrastructure was provisioned.
We introduced Kanban to keep WIP under control and brought more structure to how those service requests were coming in. The team also started going through those requests every week. If the same kind of request kept coming up, the team could use that to decide what they needed to focus on over the next month or quarter.
How did we make infrastructure easier to provision?
We moved new cloud infrastructure to Infrastructure as Code.
That covered Kubernetes clusters, EC2 workloads, S3, RDS, ALBs and ElastiCache. New cloud infrastructure reached 100% IaC adoption, with a reported reduction of around 95% in provisioning.
That was a significant shift from developers depending on someone in the infrastructure team every time they needed something new.
What else changed in the platform?
We used API Gateway to reduce the number of exposed microservice endpoints from 25 to 3. That gave the team a much smaller API surface to manage.
We added monitoring and alerting for infrastructure such as Kubernetes, API Gateway and Certificate Manager as well.
Cost tagging was added as well, so teams and leadership could see cloud spend by service, team and infrastructure resource.
How did we get a clearer view of software delivery?
We ran a survey across the engineering teams to understand how software delivery was working and where teams were getting stuck.
We used DORA metrics to compare delivery performance across teams. The findings were shared with the engineering organisation and helped us agree on what needed attention next.
The team later started tracking DORA metrics at service and team levels.
What changed for the infrastructure team?
The team had a much more repeatable and consistent way to provide infrastructure to the rest of the engineering team.
New cloud resources were created through code instead of depending on someone to provision them manually, and developers could get infrastructure in under an hour.
The team also had a better handle on incoming requests and more time to work on the platform itself.
Want to make your infrastructure work harder for your team?
Tell us what your engineers are wrestling with.