REA Group’s End‑to‑End DevOps Practice for Microservices on AWS

Author "Hammer" (real name Man Chengyuan) joined REA Group in Melbourne in 2015 and shares his experience transitioning from a monolithic background to a micro‑service, DevOps‑driven environment.

Initially unfamiliar with Continuous Delivery, he learned that achieving it requires extensive automation, testing, environment management, data migration, and rollback capabilities.

REA’s micro‑service architecture follows the 12‑Factor App methodology, emphasizing codebase, explicit dependencies, environment‑based configuration, treating backing services as attached resources, strict separation of build and run, stateless processes, port binding, concurrency, disposability, parity between development and production, logging as event streams, and one‑off process management.

Microservices and DevOps

Microservices, while sometimes criticized for violating DRY, provide independent, API‑defined services that can be deployed and scaled separately, offering flexibility that monoliths lack.

REA enforces the 12‑Factor principles to maintain consistency across services.

With a small team managing over ten micro‑services, full automation of build and deployment becomes essential, and Continuous Delivery is the solution, supported by DevOps practices.

DevOps optimizes development, testing, and operations through highly automated tools and processes, enabling faster, more reliable software delivery.

REA DevOps Toolchain

The toolchain includes:

Code repository: GitHub Enterprise.

Build and deployment: Buildkite, Jenkins, and legacy Bamboo.

Container platform: Docker for packaging micro‑services.

Environment: Majority of services run on AWS; separate IAM accounts for dev/test and production, isolated via VPCs; deployments use AWS CloudFormation.

Log management: Splunk, with Docker agents forwarding logs.

Monitoring: New Relic, AWS CloudWatch, Nagios (integrated via rea‑health‑check), alerts routed to PagerDuty.

Alerting: PagerDuty (email, Slack, phone, SMS) and Zendesk tickets for customer‑reported issues.

Collaboration: LeanKit.

Despite the comprehensive toolchain, challenges remain in automating processes, managing AWS accounts across >40 teams, configuring VPCs, deploying services, and coordinating monitoring.

REA DevOps Layered Collaboration

Different squads (following Spotify’s model) own distinct layers of the toolchain, with Delivery Engineering responsible for building and maintaining the toolchain (e.g., Docker registry, base images, Buildkite agents) and Global Infrastructure handling underlying infrastructure.

Developers use the toolchain to deliver value.

Developer DevOps Daily Routine

1. Coding

Code resides in GitHub Enterprise using GitHub Flow; deployment scripts, CloudFormation templates, and Docker definitions are treated as code.

2. Build and Deploy

Buildkite pipelines run automated checks, unit tests, and contract tests using the Pact framework. Successful builds produce Docker images uploaded to a private registry, typically within three minutes.

Deployment scripts invoke rea-shipper, which performs zero‑downtime, immutable Auto Scaling Group deployments via CloudFormation, and automatically bundles monitoring and logging modules.

Deployments to test and production environments complete in under ten minutes, with manual approval required before production release.

3. Operations

Operational duties include handling customer‑reported issues via Zendesk tickets and production alerts via PagerDuty. A rotating on‑call structure (Dingo for business hours, Owl for off‑hours) routes incidents to squads.

Conclusion

The article summarizes REA’s DevOps practice, aligning it with Gene Kim’s three pillars—flow, feedback, and continuous learning—showing how every developer participates in process optimization, rapid feedback, and a culture of ongoing improvement.

Further reading is recommended, such as the "Scaling On‑Call" article, which illustrates the cultural shift behind the technical changes.