We had an interesting problem a few years ago. We’re a fully remote company with all our software in the cloud. And we had a suite of Spring Boot applications running on containers with Infrastructure as Code. But we needed business agility.

The global employment market moves fast, and there's always demand for new products. We had to find a way to keep our lead across the industry.

We’re a technology company with a bold strategy

In 2022, we created an ADR (Architecture Decision Record) that said, "serverless-first and containers-as-needed." And sparked debate across nearly 40 engineering teams.

Let's explain some terminology first

Serverless-first is not only functions-as-a-service. It’s also a group of managed services from cloud providers that: 

  • Lower operational overhead by not managing infrastructure

  • Scale as needed, including scaling to zero to make them fully elastic

  • Have elastic pricing (you only pay for what you use) 

At G-P, serverless-first refers to our use of AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB, and others.

Serverless-first means that when we select a solution for Compute, Storage, Messaging, or similar, we’d like teams to start with a serverless option. An important note: If the serverless service doesn’t meet the need, teams should fall back to a heavier service — one that requires more operational investment.

“Containers-as-needed” clarifies that serverless-first doesn’t mean serverless-only. There are times when we need containers (e.g., installing a COTS software product) — and that’s okay.

A technology strategy that prioritizes customers

We move at a nimble pace to meet the needs of our customers and users. Services like Lambda, S3, and DynamoBD are incredibly resilient and fast. By offloading the undifferentiated heavy lifting, we can spend more time building features for users, rather than working on generic infrastructure configuration.

A key principle at G-P is: "You build it, you run it." Our teams own their software. So, we don't just throw software over the wall to a DevOps team. 

Benefits of “serverless-first”

Serverless is inherently event-driven.

Our architecture is fully event-driven. By using EDA (Event-Driven Architecture), we can scale both our organization and our software. Serverless forces us to keep a small blast radius and communicate in a fully cloud-native manner via events.

Enabling constraints

As a global employment platform, we take compliance seriously. Our cloud infrastructure is Well-Architected, and we use a multi-account strategy that separates workloads and automates cloud compliance. Serverless helps us enforce high standards by controlling how we provision cloud resources.

Offload the work

Our cloud provider manages our serverless services. A single set of building blocks — integrated, secured, tuned, enabled, and maintained by AWS — frees us to focus higher up the value chain for customers.

Well-architected workloads

Every workload we create is reviewed with the AWS Well-Architected Framework. We focus on scale, security, reliability, and cost optimization to ensure that we not only meet but also exceed our SLA (Service Level Agreement). This empowers our engineering teams as we continue to evolve with cloud environments. 

About our teams

Our technology strategy is ambitious, and that makes it challenging. Many engineers have not worked in a serverless architecture (or a distributed architecture). The transition to serverless architecture isn’t easy, and we search for engineers that are comfortable with learning, thinking big, and moving at pace.

Some engineers aren’t sure about the term serverless (yes, we know there are servers) because the approach is more than writing code in functions. Our strategy requires a holistic approach to the classic cloud-native principles.

The outcome

We’ve made extraordinary progress in two years. There are many benefits to modernization (see our article on AWS / known business value of cloud modernization). Specifically, we’ve observed the following:

1. Speed: The way we’ve broken up our system allows teams and products to innovate and evolve independently. This has a massive impact on business agility.

2. Compliance: We use the AWS Well-Architected Framework to review all workloads. Because we use many AWS Managed Services, we can rely on their operational excellence and start from a place of high quality.

3. System thinking: We had to standardize many of our processes so we can reason about the system, reliability, and business value. We don’t spend time working on low-value components.

4. Innovation: Serverless means everything is an API. This forced constraint requires an API-first approach. When we think of ourselves as a platform, we can reach a new level of innovation by easily connecting systems via APIs, like plugging G-P Gia™ into a new knowledge base.

5. Ownership: AWS owns our infrastructure, but we own our business domain. Serverless-first with domain-driven design has forced us to focus on the business problem. This keeps ownership of capability clear.

Serverless-first is not always faster, but it’s more beneficial. We’d rather optimize for system velocity than individual developer velocity. Serverless-first is less about using functions and more about thinking, “Code is a liability. The system is the asset.” The less code we have to write, the more we can consider and mold the business system we’re building.

As we share our story, it'll become obvious the speed we’re working at, which is a direct outcome of serverless-first. Stay tuned.