Amazon: de monólito a SOA

01 · CONTEXTO

Um site, uma aplicação, bancos compartilhados

Este caso é lido a partir de um resumo publicado no High Scalability, montado com base numa entrevista com o CTO da Amazon. É um resumo de terceiros, não o texto primário da entrevista.

A mudança de arquitetura que o texto descreve é a passagem de um monólito de duas camadas para uma plataforma de serviços distribuída e descentralizada, que atende várias aplicações. No começo havia uma aplicação conversando com um back end.

1. No começo havia uma aplicação conversando com um back end; o diagrama mostra o navegador, a aplicação de front end e os bancos.

2. Por anos o esforço de escala foi fazer os bancos do back end crescerem para guardar mais itens, clientes e pedidos e atender vários sites internacionais.

3. Os bancos viraram um recurso compartilhado, o que dificultava escalar o negócio como um todo.

4. Front end e back end evoluíam com restrições porque eram compartilhados por muitas equipes e processos.

5. Em 2001 ficou claro que a aplicação de front end não escalava mais.

O texto aponta duas dores: os bancos como recurso compartilhado e a evolução presa por front end e back end compartilhados por muitas equipes e processos.

02 · A VIRADA PARA SERVIÇOS

Dados atrás de interfaces de serviço

A resposta foi dividir os bancos em partes pequenas e criar, em volta de cada parte, uma interface de serviço que passou a ser o único caminho de acesso aos dados.

Em termos de hoje, é a ideia por trás de microsserviços com limites de domínio bem definidos, embora o texto fale em arquitetura orientada a serviços.

1. Os bancos foram divididos em partes pequenas, e cada parte ganhou uma interface de serviço que é o único caminho de acesso aos dados.

2. A arquitetura cresceu para centenas de serviços e servidores de aplicação que agregam a informação deles; o diagrama mostra só alguns.

3. A aplicação que renderiza as páginas do Amazon.com é um desses servidores de aplicação, e a interface de web services é outro.

4. Para montar uma página, são acessados entre 100 e 150 serviços; aqui aparecem apenas três.

5. Clientes não acessam o banco direto: assim o serviço pode escalar e ficar mais confiável sem envolver quem o consome.

6. Para fora são oferecidos serviços web em SOAP e REST, com 30% usando SOAP e 70% usando REST; o diagrama mostra a interface de web services.

Um detalhe de desenho: um mecanismo único de acesso a serviços facilita a agregação, o roteamento descentralizado de requisições e o rastreamento distribuído.

03 · EQUIPES E OPERAÇÃO

Serviço também é unidade de equipe

Serviços são as unidades independentes que entregam funcionalidade e também a forma como a empresa organiza as equipes. Uma equipe é limitada a 8-10 pessoas, as chamadas equipes de duas pizzas, e recebe autoridade para resolver o problema como um serviço da forma que achar melhor.

Outra lição do texto é que quem constrói também opera (you build it, you run it), o que traz contato diário com o cliente. Internamente, usam-se SLAs para gerenciar serviços.

Pergunta de entrevista que decorre disso: o limite de um serviço deveria coincidir com o limite do que uma equipe pequena consegue ser dona de ponta a ponta, dados incluídos.

04 · ESTADO E CAP

Disponibilidade no carrinho, consistência no pedido

O resumo trata o gerenciamento de estado como problema central em sistemas de grande escala, mas observa que poucas operações são stateful; os passos de checkout são.

Pelo teorema CAP, um sistema de dados compartilhados tem no máximo duas de três propriedades. Para escalar é preciso particionar, e sobra escolher entre alta consistência ou alta disponibilidade para um sistema específico.

1. No carrinho sempre se aceita o pedido de adicionar item, porque isso gera receita; os erros ficam escondidos do cliente e são resolvidos depois.

2. Ao enviar o pedido, favorece-se a consistência, porque cartão de crédito, envio e manuseio e relatórios acessam os dados ao mesmo tempo.

3. A escolha da abordagem depende das necessidades de cada serviço.

05 · LIÇÕES E CUIDADOS

O que levar e o que não generalizar

Entre as lições do texto: manter as coisas o mais simples possível, sem requisitos e dependências escondidos, e notar que muitas tecnologias de terceiros são difíceis de escalar ao tamanho da Amazon.