O CTO da Amazon, Werner Vogels, gasta mais da metade de seu tempo na estrada, ajudando departamentos de TI com a transição para cloud computing. Vogels chegou à Amazon em 2004, da Cornell University, onde trabalhou por dez anos em pesquisa de TI, focando em sistemas empresariais distribuídos em larga escala. Na Amazon, ele usou sua experiência de prática ajudando a escala de e-retailers na infraestrutura de TI e a abriu para outras empresas na forma de Web services da Amazon.

Em uma entrevista na sede da Amazon, Vogels discutiu, com a InformationWeek EUA, o design arquitetônico e a filosofia da AWS, seu papel como tecnólogo que visa ao cliente e sua visão do que há por vir em cloud computing.

Nesta primeira parte você acompanha a discussão sobre a questão do código aberto e também da arquitetura de TI que está por trás dos web services da Amazon.

InformationWeek - Vamos começar do começo. O que vale a arquitetura de TI atrás dos Web Services da Amazon?

Werner Vogels - Quando eu entrei, já tínhamos estabelecido uma arquitetura orientada por serviço de larga escala.

Na fase anterior, a Amazon era principalmente bancos de dados e servidores. O que era um tipo de fim de vida de uma arquitetura por volta dos anos 2000, 2001. Mudamos para esta arquitetura orientada por serviços com partes individuais de lógica de negócio que estavam nos servidores, buscávamos os dados que eles operavam, juntava-os e colocava um API neles, o que chamamos de serviço. Permitindo-nos um caminho de evolução para uma arquitetura orientada por serviços. Cada uma daquelas partes que formavam a plataforma de e-commerce funciona separadamente. Se você entra na página da Amazon, há entre 250 e 300 serviços para construir aquela página. 

Não se trata somente de um modelo de arquitetura, mas de organização. Cada serviço tem uma equipe associada que leva confiabilidade neste serviço e fica responsável pela inovação dele. Então, se você é do time responsável pelo Listmania, o trabalho é inovar e torná-lo melhor. Enquanto eu estive na equipe, nós também mergulhamos na pesquisa de onde estávamos gastando nosso tempo, percebemos que estávamos perdendo tempo com as mesmas coisas. Na realidade, todos estavam investindo tempo no gerenciamento de infra-estrutura, que era uma parte da organização que tínhamos escolhido, de forma bem descentralizada.

Então em uma etapa tradicional de arquitetura corporativa, decidimos utilizar uma plataforma de serviços compartilhados, se tornando a plataforma de serviços de infraestrutura que agora conhecemos mundo afora como AWS. Primeiro tivemos de desenvolvê-la de maneira que estas equipes pudessem focar no lado da inovação e não se tornar administradores de super aplicativos e super operadores, porque não há glória nisso, embora na escala da Amazon, todos os engenheiros precisam estar cientes da escala, confiabilidade e serem capazes de transferir os serviços de um data center para outro.

Temos, então, uma plataforma de comércio eletrônico que consiste em todos estes serviços. E mais, rodamos muitas operações grandes de e-commerce - Amazon.com, nossos sites internacionais e sites como Marks & Spencer e Target. É uma arquitetura grande orientada por serviço e multifacetada. Descemos um degrau e encontramos os serviços de infraestrutura que potencializam a plataforma de comercio eletrônico; a maioria que alcança o mundo que conhecemos como AWS, foi focado inicialmente em clientes internacionais. Abaixo disso temos nossos serviços de hardware, as equipes que constroem os data centers e fazem o networking.

InformationWeek - A Amazon é conhecida como uma loja de código aberto. Ainda é verdade? 

Vogels - Onde no passado poderíamos dizer que se tratava de uma loja puramente Linux, agora, em termos de grandes partes da plataforma de e-commerce, somos uma loja puramente Linux EC2. Há uma escolha mais fácil de diferentes sistemas operacionais. O Linux ainda é muito popular, mas, por exemplo, o Windows Server é geralmente requerido, ainda mais no caso de transcodificar um vídeo e coisas que têm de ser entregues através do Windows DRM (digital rights management), existe uma variedade de sistemas operacionais disponíveis para desenvolvedores internos. Temos um longo histórico de tentar não restringir nossos desenvolvedores, permitindo que eles escolham as ferramentas que pareçam funcionar melhor. Se eles quiserem trabalhar com prototipia, provavelmente neste momento os engenheiros vão optar pelo Ruby, há alguns experimentos em andamento com serviços altamente competitivos, eles podem utilizar o Erlang, outros grupos podem usar o Java e C++ e assim por diante.

Essa questão nos direcionou a um princípio muito importante da forma como construímos os serviços de infraestrutura, quero dizer que se você estivesse utilizando o Amazon EC2, você não necessariamente precisaria utilizar o S3 ou SimpleDB ou Elastic Block Store. É claro, você espera que todos estes serviços sejam sedutores o bastante para que nossos engenheiros os utilizem, mas se eles sentirem que existem ferramentas melhores disponíveis para uma tarefa em particular, eles podem se sentir a vontade para fazê-lo.

Eles são requeridos da maneira que construímos estes serviços que não havia lock-in interno. É a mesma vantagem que oferecemos aos clientes no mundo de fora; nenhuma das coisas é travada (locked-in).

A maioria dos nossos softwares é mais bem caracterizada como sendo feita em casa. Sobram poucos terceiros de software e isso não tem nada a ver com pensar que software terceirizado não seja interessante. Se eu pudesse comprar coisas, eu compraria, mas vimos no passado que para conseguir a confiabilidade que requer a Amazon e, para se ter o controle tanto em custo quanto em desempenho, precisamos de melhor controle do software que roda nossos serviços e para isso os fabricantes ainda não atingiram o ponto onde eles podem entregar software com segurança de forma a operar em escala Amazon. Construímos nosso software e, se realmente compramos um software de terceiro, utilizamos da mesma forma que qualquer outro cliente está utilizando.

InformationWeek - Na Cornell University, sua pesquisa é centrada nos sistemas distribuídos em larga escala. Como isso funciona no mundo real da Amazon?

Vogels - Ao meu ver, a Amazon é provavelmente o maior sistema distribuído do mundo. Pode parecer estranho se compararmos aos números de outros sites da internet que estão por ai, mas o Amazon é único na questão de vários softwares ativos; não é só request/reply, ou indexar ou caching massivo. Há um grande fluxo, disseminação e entrega de conteúdo. Estas diferentes tarefas fazem da arquitetura da Amazon muito grande. Não vou dizer complexa, mas uma plataforma muito diversa. Para nós, existem dois princípios que são importantes, especialmente no contexto da confiabilidade. Cada segundo de downtime tem impacto financeiro. Alcançando a disponibilidade que - Jeff Bezos utilizou um termo recentemente que cabe -  "não distinguível da perfeição" - o mais próximo dos 100% quanto possível para nós.

Existem então dois termos que utilizamos internamente. Um é isolamento, direcionado pela arquitetura orientada por serviço. Não há acesso direto ao banco de dados a não ser pelos softwares que rodam em serviço e quando o serviço tem um API difícil. Esta é a única maneira que os softwares podem interagir entre si.

O segundo termo e o mais fundamental é o de componentes independentes, onde a interação entre eles não depende de conexões entre as partes, no caso de alguma falha ou overload ocorrer, ficando fácil mudar para outro componente que não tenha defeitos ou para oferecer melhor disponibilidade. Fazemos isso em um nível micro e em um nível de maior abstração, ao ponto em que nossos sistemas sejam desenhados para cobrir quaisquer falhas do banco de dados. Temos uma regra interna no espaço de e-commerce que deveríamos ser capazes de perder um data center completo sem que o SLA com o cliente seja violado. Então o isolamento e independência dos sistemas são os dois princípios da construção que utilizamos na arquitetura geral.

Veja a segunda parte da entrevista.