A Practical Guide to Building a Serverless Platform

This article is based on a piece originally published on Forbes Tech Council (2018). The technical guidance below has been expanded and clarified for a DevOps engineering audience.

Why Go Serverless?

The pressure on engineering teams to move faster has never been greater. Legacy infrastructure — racks of physical servers, monolithic applications, sprawling IT organisations — creates institutional inertia that slows every release cycle. Serverless architecture addresses this directly by eliminating the undifferentiated heavy lifting of provisioning, patching, and capacity planning, so engineers can focus on writing business logic.

Building a 100% serverless platform is an ambitious goal, but it is achievable incrementally. The four pillars below — mindset, static frontends, Function-as-a-Service (FaaS), and cloud-native data — give you a concrete path to get there.

1. Adopt a Serverless Mindset

Technology transformation fails far more often because of culture and process than because of tooling. Before touching a single line of infrastructure-as-code, your team needs to commit to a fundamentally different way of thinking about software: shifting from “build to last” to “build to change.”

Many organisations still run systems originally built decades ago on hundreds of physical servers or virtual machines. The engineers who built those systems are often the first to acknowledge that the technology has become a bottleneck rather than an enabler. The mindset shift required before moving to a serverless platform includes:

1. Commit to continuous learning, testing, and improving. Serverless patterns evolve rapidly; your team needs to treat learning as a first-class engineering activity.
2. Commit to discarding old code. Technical debt compounds. Willingness to deprecate rather than extend is a competitive advantage.
3. Commit to retiring physical infrastructure. Every server you decommission is operational overhead eliminated.
4. Commit to architectural simplification. Break large, tightly coupled systems into smaller, independently deployable components.
5. Commit to automating everything. Manual processes are error-prone and slow. If a human is doing it repeatedly, a pipeline should be doing it instead.

2. Build Static Websites and Application UIs

The simplest place to start eliminating servers is at the presentation layer. Replace server-rendered application stacks with static HTML, CSS, and JavaScript. Static sites can be served directly from cloud object storage, which scales transparently and costs a fraction of running web servers.

This approach decouples your frontend from your backend entirely. Frontend engineers can iterate on user experience without waiting on server deployments, and your backend teams can version and release APIs independently.

Getting Started

1. Choose a cloud object storage provider that supports static website hosting and scales automatically with traffic — for example, AWS S3 or Google Cloud Storage. Pair it with a CDN (such as AWS CloudFront or Google Cloud CDN) to minimise latency globally.
2. Select a JavaScript framework that supports client-side routing and can consume REST or GraphQL endpoints from your backend services. Common choices include React.js and Angular, though the right choice depends on your team’s existing expertise.
3. Invest in frontend skills. Ensure your team has strong HTML, CSS, and JavaScript fundamentals. Gaps here will slow delivery more than any tooling choice.

3. Replace Application Servers with Function-as-a-Service (FaaS)

Once your frontend is static and calling backend APIs, you can eliminate your application servers by moving business logic into functions. Function-as-a-Service (FaaS) is an execution model where individual functions are deployed, scaled, and billed independently — without the operator managing or provisioning the underlying compute infrastructure.

Key advantages of FaaS for DevOps teams include:

• Single-purpose functions are easier to reason about, test, and maintain than monolithic service codebases.
• Independent deployability means a change to one function cannot break an unrelated function, reducing blast radius.
• Pay-per-execution pricing means you are not paying for idle compute time between requests.
• Automatic scaling is handled by the cloud provider, removing capacity planning from the operational burden.

Getting Started

1. Choose a cloud provider with mature FaaS offerings. AWS Lambda (exposed via AWS API Gateway or AWS AppSync for GraphQL) and Google Cloud Functions are established options. Evaluate based on your existing cloud footprint and language runtime requirements.
2. Use a vendor-agnostic deployment framework such as the Serverless Framework or AWS SAM to define and deploy functions consistently, and to reduce lock-in risk.
3. Implement CI/CD from day one. Your production environment should be deployed exclusively through your pipeline — no manual deployments. Tools such as Jenkins, AWS CodePipeline, or GitHub Actions can enforce this. A zero-touch production policy catches configuration drift early and makes rollbacks reliable.

4. Move Your Data to Cloud-Native Storage

Data is often the last and hardest piece of infrastructure to migrate, but it is also one of the highest-value targets. Pre-provisioned database servers sitting idle between peak loads are a significant, unnecessary cost. More importantly, a monolithic relational database shared across all services creates tight coupling and becomes a bottleneck as teams scale.

The key principle here is polyglot persistence: choose the storage medium based on how the data will actually be accessed and used, not on organisational habit or the preference of a single DBA. Examples:

• Key-value or document stores (e.g., AWS DynamoDB, Google Firestore) for low-latency, high-throughput access patterns.
• Managed relational databases (e.g., AWS Aurora Serverless) for transactional workloads that still require SQL semantics, with the option to scale to zero when idle.
• Object storage (e.g., AWS S3) for large binary assets, logs, and data lake ingestion.
• Search engines (e.g., Amazon OpenSearch Service) for full-text search use cases.

Getting Started

1. Audit your data profiles and access patterns. Understand what your data looks like, how frequently it is read versus written, and what latency requirements each workload has. This analysis will guide your storage selection.
2. Make the case for high availability. Cloud-managed databases provide built-in replication, automated backups, and failover that would require significant engineering effort to replicate on-premises. Factor this operational reduction into your migration business case.
3. Treat data security as a first-class concern. Understand your data classification requirements, apply encryption at rest and in transit, and design your IAM policies using least-privilege principles before migrating sensitive data to the public cloud.

Key Takeaways

The unifying theme across all four pillars is simplification:

• Thick, server-rendered applications become thin static websites.
• Large monolithic services become small, single-purpose functions.
• One-size-fits-all databases become purpose-built, managed data stores.
• Large ops teams focused on keeping servers running become small DevOps teams focused on automation and delivery.

A serverless platform does not eliminate complexity — it relocates it to managed services and shifts engineering effort from infrastructure management to product development. The result is a system that can absorb change rather than resist it, which is the defining characteristic of a durable digital platform.

The journey to fully serverless is rarely a single lift-and-shift. Start with the layer that delivers the most immediate relief — typically the static frontend or a high-traffic API — prove the model, and expand from there.