Explorando Microserviços

Transcrição

1

2 Explorando Microserviços Princípios, Padrões e Práticas Aldrin Leal and Alexandre Saudate This book is for sale at This version was published on This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do Aldrin Leal, Alexandre Saudate

3 Contents Introdução: Uma breve história das Arquiteturas Antes do Computador Pessoal Aplicações Desktop Cliente-Servidor e os Bancos de Dados Relacionais Três Camadas (Desktop 2.0) Application Server Web Mobile Web Mobile Retorno à Sanidade E o que temos hoje? Monolitos, Application Servers Problemas de Escalabilidade Confusão entre Ops e Devs E quais são os desafios? lead time curtos terceirização de serviços cloud computing times pequenos O que nos ajuda? Agile Integração Contínua NoSQL / Big Data Cloud Devops / NoOps Conceituando Microserviços Princípios Práticas Padrões

4 Introdução: Uma breve história das Arquiteturas (ou: A que ponto chegamos, hein?) É importante contextualizar a história da tecnologia da informação à partir de suas gerações, e as tendências de arquitetura para aquela época. Esta definição de geração é arbitrária, baseada em nossa percepção de características comuns. Antes do Computador Pessoal Providos de um certo receio em denunciar a idade, os autores optaram por poupá-los desta velharia¹. Aplicações Desktop Na década de 80, ficou famosa a figura do Clipeiro : Um único analista, que dividia-se entre Analista de Requisitos, Desenvolvedor, e Administrador de Sistema. Era Controle de Estoque pra lá, Folha de Pagamento pra cá. Nós vivenciamos muito pouco daquela época, mas confessamos que tínhamos uma inveja imensa do sucesso que os mesmos possuíam. Na verdade, em muitos lugares, esta figura ainda existe. O Clipeiro da época utilizava de plataformas como o dbase II (nos micros de 8 bits) e o III (já no IBM PC), FoxPro, além do célebre Clipper. Estas plataformas integravam um motor de base de dados baseado em disco (o famigerado DBF), um motor de formulários e relatórios, e produziam binários compactos, que cabiam em um disquete de 5.25 polegadas (para sua informação: Capacidade de Armazenamento entre 360 KiB e 1.2 MiB) - Junto com a base de dados. Devido a flexibilidade desde modelo, era relativamente prático atualizar o sistema: Copiava-se o banco para nova versão, e distribuía com o novo binário. Backups eram simples também. Não havia, porém, controle de versão, tornando mais problemáticas a manutenção do histórico, além de frequentes problemas de perda do código fonte. Com o surgimento das placas NE-2000 e das Redes Locais (especialmente a Novell), o Clipeiro já não escalonava. Era necessário, então, trazer a figura do Técnico do Computador, responsável por manter a rede, os PCs, e publicar novas versões. Este dura até hoje. ¹ - Vamos falar dos tempos do Getúlio pra cá, por favor!

5 Introdução: Uma breve história das Arquiteturas 2 Persistência Um grande problema na época das redes locais para aplicações que utilizavam dbf era que, para sua arquitetura ser viável, era necessário que a rede local implantasse excelentes protocolos de concorrência. Para aquela época, excelente significa concorrência pessimista e a utilização dos mecanismos de Lock. Obviamente, estes locks causavam dois problemas, que era a perda de performance natural, bem como problemas de corrupção de dados. Um terceiro problema, que envolvia a disponibilidade, especialmente para manutenções e backups, não era tão periclitante porque, à época, as empresas não precisavam ser 24 horas. Mas não deixou de ser uma implantação natural do modelo de cliente-servidor. Cliente-Servidor e os Bancos de Dados Relacionais Já à partir de 1993, entra a figura do Banco de Dados relacional. As plataformas baseadas no dbase não migraram para o Windows, à exceção do Visual FoxPro, e houve a ascenção inicialmente do Visual Basic e então (1995 em diante) do Delphi². Porém, com redes cada vez maiores, surgiram novos requisitos não funcionais³: Em particular, com cada vez mais nós nas redes, tornava-se inviável controlar o acesso não autorizado à informações, e era importante implantar os controles necessários para auditoria e compliance. À partir deste momento, era importante distribuir DOIS executáveis: O para o usuário final, e o backend propriamente dito. Aí finalmente entramos no modelo cliente-servidor com os dois pés. Três Camadas (Desktop 2.0) Neste ponto, já estávamos com o modelo de três camadas. Porém, a Internet estava no começo, e as redes locais ainda não rodavam exclusivamente sobre o protocolo TCP/IP. A Novell oferecia um Sistema Operacional para seus servidores (com clientes para DOS e Windows, entre outros), e a Microsoft surgia com o Windows NT. Alguns ratos de computador mais destemidos defendiam o Unix, mas diante do processo entre a Unix System Labs e a BSDi, sua situação legal encontrava-se no limbo⁴, criando uma visão entre o BSD Unix (que trazia a evolução da comunidade, como a pilha TCP/IP) e o System V, Release 4, que tinha a grife Unix Com o surgimento do Processador Intel em 1989 e features específicas de multitarefa e gerenciamento de memória (MMU), finalmente o PC torna-se interessante para a execução do Unix. Com os BSDs feito reféns, em um primeiro momento um autor de livros acadêmicos ganhou a fama, ao distribuir como material didático um sistema operacional (Minix) com um Kernel totalmente inspirado no Unix, porém utilizando o suite de ferramentas criado pelo projeto GNU, de O mesmo era distribuído pela editora como um jogo extra de disquetes complementares ²O codinome (tornado nome) Delphi é por si só um índicio: O mesmo tinha este nome em função do Oráculo mais Famoso estar na ilha de Delfos. Logo o humor interno do time explicando o codinome: -Se você deseja falar com o Oráculo, vá para a Ilha de Delphos (Delphi, on Singular) ³i.e., tudo aquilo que é pobrema do arquiteto pra resolver. ⁴

6 Introdução: Uma breve história das Arquiteturas 3 ao livro, e é muito provável que a editora tenha vendido muito mais disquetes do que livros. Porém, os livros venceram, e é provável que você encontre uma cópia de Sistemas Operacionais do Andrew Tanembaum na biblioteca de Ciências da Computação mais próxima de você. Um aluno da universidade de Helsinki decidiu ler o livro e, após experimentar o Minix, decidiu ler o livro todo e implementar outro Kernel, também inspirado nas idéias do Minix - ma non troppo -. Óbvio que falamos do Linus Torvalds e do Linux. Porém, ao invés de buscar reinventar a história e produzir outro material didático, Linus abraçou o movimento e permitiu-se aceitar e publicar novas versões agregando novas features, fato que permitiu que o Linux crescesse como um novo sistema operacional, adotando um modelo novo. Com a Internet, era o começo do modelo do Bazaar, aonde programar passou a ser uma atividade social, mesmo que restrita à listas de discussões e ocasionalmente em servidores de IRC. Application Server À partir de 1995, ainda havia muita incerteza sobre qual plataforma usar. O Windows ainda era forte, o Linux estava surgindo e o modelo de open source começava a estabelecer-se nas empresas. Ainda assim, houve oportunidade para o surgimento de novas plataformas, como o Java, o JavaScript e o Flash. Para o Java, em particular, o apelo do Write Once, Run Anywhere motivava empresas, que poderiam experimentar, com relativa segurança, a hipótese de rodar em outro sistema operacional. Porém, era importante que esta opção fosse interessante ao modelo de negócio dos fornecedores. Por isto, criou-se a visão do Application Server, que consistia em um Container comum para publicações. Na visão da época, uma grande aplicação exigia um fluxo bem definido, onde: Um desenvolvedor codificava um pacote implementando uma funcionalidade Um DBA criava as tabelas necessárias para botar em produtor Um administrador de sistemas fazia o seu empacotamento, publicação, e configuração de vínculos, como Data Sources e parâmetros de configuração Para o primeiro, embora seduzido pela facilidade em criar componentes, surgiam-se problemas na hora de colocar em produção, como a Escalabilidade e eventuais diferenças de comportamento entre os ambientes⁵ A Web dava os seus pulinhos, mas para sistemas distribuídos, usávamos soluções como o Distributed COM (DCOM), Common Object Request Broker Architecture (CORBA), e o Enterprise Java Beans (EJB). Coisas tão agradáveis e prazerosas quanto um tratamento de canal. Web A Web matou o arquivo.exe que utilizávamos, tornando o browser o sistema nervoso central da atividade nas empresas. Esqueça as teclas de função e os terminais agora você preenche ⁵ -Mas aqui mesmo na minha máquina (compila funciona rodou)!

7 Introdução: Uma breve história das Arquiteturas 4 tudo no navegador diretamente, com uma interface mais amigável. Exceto se o seu negócio é mais produtivo justamente no terminal 3270, motivo pelo o qual muitas empresas com código legado do Mainframe (Bancos e Companhias Aéreas) simplesmente optaram por ignorar a web inicialmente. Porém, isto criou um outro fator complicador: Com a Web ainda nos seus passos iniciais, poucos fornecedores eram capaz de oferecer funcionalidades realmente importantes para os seus usuários corporativos. Foi o momento da Ascenção do Internet Explorer, a sua briga com o Netscape, e o surgimento do ActiveX. O resultado final disso foi que aplicações eram criadas e homologadas para o uso em um navegador específico, especialmente o Internet Explorer. Porém, como a Microsoft optou por suspender o desenvolvimento do IE após a versão 6, fato que causou o lançamento da versão subsequente apenas cinco anos depois, combinado com a ausência de ferramentas de depuração para o mesmo e a ascenção do Mozilla Firefox iria criar, ironicamente, um efeito colateral inverso: Aplicações que só funcionavam no Firefox. Mobile Web Já em 2001 em diante, a Mobile Web criou um novo problema: Como manter nossas aplicações compatíveis com outro browser que não o IE, e sim oferecido pelo fornecedor do meu telefone celular. A resposta imediata era: Não haveria como como. Por isto, muitas aplicações foram reescritas para funcionar de forma compatível com um subconjunto de browsers (e falando o WAP), ou torcendo que fossem compatívels com um Mobile Transcoder específico. Isto, na prática, significava que agora poderíamos ter entre três artefatos (Navegador WAP, Navegador Desktop, e Banco de Dados) a até quatro (Servidor de Regras de Negócio). Mobile E aí desandou de vez: Surgiram os Smartphones. Nesta hora, já não era mais adequado falar HTML - Era necessário ter protocolos específicos para as aplicações. Quem foi relativamente esperto a época, simplesmente criou uma quarta aplicação, específica para servir a camada de negócio como API. O novo problema da época era justamente regressão: Como testar todos os tamanhos de tela de Android disponíveis. E as versões? Um atalho encontrado para o Mobile foi empacotar o motor de HTML na aplicação, criando o conceito da aplicação híbrida (Titanium, Apache Cordova⁶). Genial, porém ainda limitado à regressão. Para a Mobile Web, surgiram os designs responsivos, procurando agrupar tamanhos e telas diferentes e agrupando por funcionalidade. Javascript não intrusivo, frameworks para consolidar comportamentos de forma compatível (jquery, Prototype) ⁶ex-Phonegap

8 Introdução: Uma breve história das Arquiteturas 5 E surgem novas versões do Internet Explorer, novas versões do Mozilla Firefox, e Safari e o Google Chrome. Tantos usuários heterogêneos, tantas demandas. E tão poucos braços. E como ficavam nossas equipes? Bem, pra quem tinha Application Server (.NET, Java, Zope), pouco mudou, e tudo era uma questão de no próximo deploy. Na verdade, a única grande mudança significativa no modelo era a adoção de Controle de Versão (CVS, Subversion), a Integração Contínua, e alguma funcionalidade - mínima - para testes, geralmente Unitários. Porém, o débito técnico acumulou, e cada nova publicação demandava horas para acontecer, visto que afetava a disponibilidade da aplicação, os processos eram lentos, e a funcionalidade de publicação automática era limitada. Em geral, todo o código do backend era alterado de uma vez só. Como acumulou o débito técnico, geralmente um novo deploy mudava todos os endpoints possíveis: Camada de Negócio, Mobile, Browser Desktop, e o escambau. E pra quem não tinha (PHP e ASP Clássico)? Amigos, quem não tinha Controle de Versão não podia ter nada disso. Mas também, como eles também editavam tudo em produção, então tinham mais é que se dar mal. Retorno à Sanidade Algumas coisas aconteceram de dez anos pra cá que trouxeram uma nova perspectiva, como: Startups Claramente um movimento Hipster: Um Dinamarquês (sempre eles) decidiu criar um produto e resolveu fazer uma versão do movimento Punk Rock na Computação, com idéias revolucionárias como: Você não vai precisar disso, Não se repita e outras frases. Este Dinamarquês, conhecido como o DHH, pegou em 2003 uma linguagem obscura criada quase uma década antes (1995!!!) e criou uma plataforma, chamada Ruby on Rails. Várias idéias interessantes floresceram àquela época, e ser desenvolvedor Ruby se tornou uma coqueluche, por permitir que você pudesse ostentar uma vida baseada em código v1d4l0ka, com vários frameworks e ferramentas geniais. E vários valores/princípios legais aplicados, como o Sistemas de Controle de Versão Distribuídos (DVCS, como o Git), Platform as a Service (PaaS), e o código como única expressão necessária, através de Domain-Specific Languages (DSL). Mas com uma única restrição: Só podia codar em uma filial da Starbucks. e Cloud Um movimento mais acadêmico:

9 Introdução: Uma breve história das Arquiteturas 6 Em paralelo, um grande e-tailer cansou de receber visita de fornecedor propondo milagre. Ao invés disso, chamou um professor universitário da cadeira de Sistemas Distribuídos, e falou: -Cuida dessa merda, por favor!!!!11!1onze! No caso, era o Werner Vogels na Amazon.com. Embora o enfoque fosse resolver problemas de escalabilidade, aproveitou-se para divulgar um pouco da Caixa Preta existente na empresa, através de Palestras e Artigos Científicos. Algumas já eram práticas da empresa, mas não eram codificadas, como: Foco no Serviço: A página principal apenas agrega outros serviços, consumindo-os. Como exemplo, apenas a sua home page consome cerca de 80 serviços distintos. -Você construiu, então é você que roda! : Cada time era responsável não só pela criação do serviço, como pela sua manutenção. Um telefonema as duas da manhã tornou-se um ótimo fator de motivação, entre outras coisas, para punir, inibir e prevenir incidentes futuros. A Regra das Duas Pizzas: Se sua equipe não pode ser alimentada com apenas duas pizzas, ela está grande demais. Alguns meses depois, um funcionário propôs sublocar a infraestrutura de TI, visto que a mesma ficava configurada o tempo inteiro, mas ociosa na maior parte. Na falta de um nome agradável aos analistas, eles focaram no óbvio: Já que o usuário não sabe toda esta abstração que roda aí, vamos chamá-la como aparece no diagrama: -É nuvem, porra!, segundo relatos dos participantes da reunião que optaram por não se identificar. Voltando à idéia: A idéia de um memorando surgiu e inspirou a Amazon Web Services, que tornou-se o backbone de uma revolução. Não é verdade, porém, que a Amazon tenha disponibilizado toda a sua capacidade de processamento. Na verdade, ela criou os novos Data Centers (chamados de Regiões) e, após três meses, já havia provisionado capacidade equivalente à toda a sua planta original. E gradualmente migrou seus serviços para rodar na sua Nuvem. combinandinhos Os dois hipsters passaram a trocar figurinhas, e então tornou-se comum a figura do Empreendedor de Starbucks, dando origem ao Github, Heroku, Netflix, e várias outras empresas. Foco na simplicidade, na ausência de burocracia, preferindo o trabalho remoto, evitando reuniões, e fugindo da necessidade de manter o datacenter ou buscando torná-lo mais enxuto, por meio de movimentos como o Devops. Uma renascença, eu diria. Alguém aí falou em Devops? Se um era Hype e o outro era Nerd, Devops era algo meio Motim no Quartel, olha

10 E o que temos hoje? Mas se não sou Hipster, será que ainda tenho salvação? Monolitos, Application Servers Problemas de Escalabilidade Confusão entre Ops e Devs

11 E quais são os desafios? lead time curtos terceirização de serviços cloud computing times pequenos

12 O que nos ajuda? Agile Integração Contínua NoSQL / Big Data Cloud Devops / NoOps

13 Conceituando Microserviços Princípios Práticas Padrões