**Parent Topic**: [[Software/README]] ## The Pattern Picnik's render farm was the natural first thing to move to EC2 because render servers require **no access to internal services** — no databases, no storage servers. A web server packages a chunk of edit-describing XML into a render queue; a render server pulls the job, reconstructs the image, and returns it. That decoupling is what makes the component portable to the cloud. ## The "Grown-Up" Prerequisite Huff: "Effective use of cloud computing resources requires a fairly 'grown-up' attitude toward application architecture and configuration management/automation." Because the render VMs already ran on Xen and a homegrown config system (ServerManager) already existed, moving to EC2 was quick — modify the render VM image into an AMI; on boot it contacts ServerManager for its components and connects to the queue. ## Connection Decoupling plus existing automation is what made [[Queue-Depth Auto-Scaling Control Loop]] "easy and very reliable." Contrast the components you *can't* decouple — the DB-coupled web tier shouldn't move; see [[Cloud Connectivity as Total Outage Risk]]. --- *Source: [[Web Operations]] (Allspaw & Robbins, O'Reilly 2010) — Ch 2 — How Picnik Uses Cloud Computing: Lessons Learned*