How FreeWheel Transformed a Monolith into a Cloud‑Native Microservices Architecture

FreeWheel, a high‑end video‑ad technology provider under Comcast, serves over 90% of major U.S. TV media and operators. The article describes how its core business system team refactored a monolithic application into a cloud‑native microservices architecture.

What Is a Cloud‑Native Application

In 2010 Paul Fremantle coined the term “cloud native.” The CNCF now defines it as applications that run on dynamic cloud environments (public, private, hybrid) and leverage core cloud‑native technologies such as containers, service mesh, microservices, immutable infrastructure, and declarative APIs. An app that runs on the cloud and uses one or more of these technologies is considered cloud native.

Beyond the definition, cloud‑native apps are characterized by continuous change and evolution. The cloud platform’s core capability is replication, enabling elastic scaling by automatically creating or destroying workloads.

Microservices, a key cloud‑native technology, allow each service to be developed, deployed, and run independently, supporting iterative, cell‑like evolution. Immutable infrastructure (containers, Pods) further simplifies this process.

Business‑Centric Design of Cloud‑Native Apps

Distributed systems consist of three parts: business logic, control logic, and technical framework. Business logic delivers commercial value and is the primary development focus. Control logic handles non‑functional requirements (e.g., data sharding, retries) and often consumes more effort than the business code itself. Technical frameworks provide reusable models and tools but are optional.

Cloud platforms have evolved from simple compute resources (e.g., AWS EC2 in 2006) to comprehensive services covering compute, storage, networking, and security, offloading many non‑functional concerns to the infrastructure.

Cloud‑Based Innovation Stages

Amazon’s Modern Application Development (MAD) model divides cloud‑native adoption into three stages: lift‑and‑shift (containerize and migrate), cloud‑native refactor (leverage cloud capabilities for cost‑effective redesign), and building new applications (shared services platforms for faster delivery).

Lift‑and‑Shift

FreeWheel first split its Ruby monolith (over 1 million lines of code) into microservices using the “Strangler” pattern and migrated to Go. The Strangler pattern rewrites the system gradually, allowing old and new services to coexist and reducing risk.

The migration involved three phases: conversion (create new services), coexistence (gradually route traffic to new services via reverse proxies), and deletion (retire legacy components). Front‑end Rails UI was rebuilt with React, calling the new microservice APIs.

Containerization

Microservices were packaged into containers, enabling smaller compute units, cost reduction, and a unified deployment model across teams. Containers also simplify CI/CD pipelines. Over 90% of organizations now use containers for building and deploying applications (CNCF 2020 survey).

Cloud‑Native Refactor

FreeWheel adopted Amazon EKS (managed Kubernetes) for orchestration, operating 16 clusters with more than 5 000 Pods. Workloads were mapped to appropriate Kubernetes resources (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs) and exposed via services.

External traffic is managed with an API Gateway providing routing, authentication, and rate‑limiting. Internal traffic uses ExternalName + Route53 for legacy system access and direct service‑name resolution for microservice‑to‑microservice calls.

To handle increasing service‑to‑service complexity, Istio Service Mesh was introduced, enabling declarative traffic splitting, retries, timeouts, and circuit breaking without custom code.

Data storage was refactored: metadata such as ad inventory moved to a NoSQL key‑value store for faster queries. Observability was enhanced by shipping business and request logs to ELK, metrics to Prometheus, dashboards in Grafana, and distributed tracing with Jaeger.

Building New Applications

FreeWheel explored serverless solutions with AWS Lambda for asynchronous, compute‑intensive tasks, achieving lower resource costs and higher operational efficiency.

The team also built internal platforms: a low‑code development platform (Bingo) that generates serverless or microservice scaffolding and CI/CD pipelines, and the FreeWheel Operation Center (FOC) for deep Kubernetes integration, automated deployments, and monitoring.

The resulting architecture is a hybrid cloud‑native system combining microservices and serverless components, orchestrated by Kubernetes and Istio.

Future Outlook

The next phase moves from merely using cloud‑native technologies to designing applications natively for the cloud—leveraging declarative Kubernetes controllers, service‑mesh‑based governance, and observability‑driven development to keep the focus on business value.

Adopting this mindset requires developers to abandon traditional habits and embrace cloud‑native principles throughout the software lifecycle.