I was laid off by Atlassian

**TL;DR:** A former Atlassian engineer reflects on eight years of work before being laid off, walking through the technical systems he built — including an Open Service Broker, an Envoy control plane called Sovereign, and large-scale proxy infrastructure across AWS regions. ## Interview Process at Atlassian The interview process eight years ago differed significantly from today's. It included a HackerRank coding test (passed with a perfect score), followed by two technical rounds: - **Round 1:** Two interviewers handed over a Cloudflare whitepaper on custom domains, left the room for ~10 minutes, then returned to ask questions about its contents. Additional questions covered microservices, architecture, and containers. - **Round 2:** A troubleshooting exercise based on a real Atlassian outage that caused a denial of service, plus a question about latency-based DNS routing. The answer given — that Route 53 triangulates based on actual client latency — was not entirely accurate; in practice it uses geolocation databases to route DNS responses based on estimated latency. - **Values interview:** The candidate asked interviewers to describe what success would look like after 12 months. They described an internal application for self-service load balancer provisioning — similar to AWS ALB, but for internal Atlassian developers. A confident "I can build it in Python" was enough to get the offer. --- ## First Weeks: Building the Open Service Broker Joining Atlassian is often described as "drinking from a fire hose" — enormous amounts of information to absorb in the first weeks. The first self-assigned task was to build exactly what was promised in the interview. ### What Is an Open Service Broker? An **Open Service Broker (OSB)** is a web application with a standardized API that acts as a middleware layer for resource provisioning on a platform. The OSB spec is published on GitHub and defines endpoints such as: - `/catalog` — lists all available services and plans with metadata - Provisioning endpoints — `PUT`, `PATCH`, `DELETE` for creating, updating, and removing resources In Atlassian's context, developers submitted configuration files to version control, which were then picked up by build servers to deploy services. The OSB abstracted the underlying infrastructure (e.g., MySQL-compatible databases) away from internal developers. ### Implementation The broker was initially built with **Connexion** — a Python library that ingests an OpenAPI document and auto-generates route handlers. It was later migrated to plain **Flask**, then to **FastAPI** (where it remains today). **Final architecture:** 1. Client sends a provisioning request to FastAPI 2. Web server writes a task to an **SQS queue** (asynchronous processing) 3. A **Worker** picks up the task and executes it — creating DNS records, CloudFront distributions, calling external APIs, etc. 4. Worker writes results to **DynamoDB** 5. Client polls the web server: "Done yet?" The server checks the database and responds accordingly --- ## Second Major Build: Envoy Control Plane ("Sovereign") An architect proposed replacing Atlassian's licensed enterprise load balancers with an open-source, cloud-native alternative: **Envoy Proxy**. Envoy is similar to Nginx but more modern, and it supports dynamic configuration via an API — meaning configuration can be reloaded at runtime without restarting the proxy. The goal: deploy many always-running proxies that reconfigure themselves dynamically as services change, eliminating the need for developers to request manual load balancer configuration. ### What Sovereign Does Sovereign is the **Envoy management server** (control plane). It was open-sourced and published on Bitbucket. Sovereign runs a **FastAPI application** that accepts two types of input: - **Templates** — corresponding to Envoy resource types: clusters, routes, listeners, etc. - **Context** — dynamic data that gets injected into templates At startup, the management server reads templates and context, then exposes them via API. Envoy proxies poll this API. As context changes, Sovereign re-renders templates and pushes updated configurations to the proxies. **Context sources include:** - The provisioning database (written to by the OSB worker) - S3 buckets containing data that changes over time ### End-to-End Provisioning Flow 1. Client submits a provisioning request to the Broker 2. Worker executes the task, writes new data to the database 3. Sovereign polls for updated data and re-renders Envoy configuration 4. New configuration is pushed to the proxies 5. Proxies begin behaving differently — routing traffic according to the new config --- ## Infrastructure: Provisioning the Proxies at Scale With the broker and control plane in place, the next question was: how are the proxies themselves provisioned? What are they, and where do they run? ### CloudFormation-Based Provisioning Proxies were provisioned using **AWS CloudFormation** templates — infrastructure-as-code that creates AWS resources without manual console interaction. Resources created per deployment: - VPC and subnets - Internet gateway - Security groups - Key pairs - IAM roles - **Auto Scaling Group (ASG)** - EC2 instances Additional components included: - **NLB** (Network Load Balancer — Layer 4 proxy) - **ACM** (certificate management) - **Route 53** DNS records ### Scale The infrastructure spanned approximately **13 AWS regions** with around **2,000 proxies** deployed in total. ### AMI Generation CloudFormation templates reference an AMI rather than create one. A separate process generates a standardized machine image containing all critical components for the proxy fleet — setting up the build pipeline for these images was the next major infrastructure challenge discussed. --- ## Reflections The video is structured as a technical retrospective for others facing layoffs or similar career transitions. The goal is both to document real engineering work and to offer a reference for engineers thinking through similar architecture challenges — or avoiding mistakes made along the way. Most content is intentionally technical, though non-technical aspects of the Atlassian experience are also touched on. --- Source: [https://youtu.be/55pTFVoclvE](https://youtu.be/55pTFVoclvE)