A programação de Sistemas Distribuídos não é simples e, apesar da evolução das plataformas e ferramentas desde COM, CORBA, RMI, Java EE, Web Services, Arquitetura Orientada a Serviços (SOA), e assim por diante, é mais uma arte do que uma ciência.
Brendan Burns descreveu muitos dos padrões que permitem a programação de sistemas distribuídos no blog que escreveu em 2015. Logo depois, junto com David Oppenheimer, ambos colaboradores originais do Kubernetes, apresentaram um artigo na Usenix baseado em design patterns e containers.
O InfoQ conversou com Brendan Burns, que recentemente publicou o livro "Designing Distributed Systems, Patterns and Paradigms for Scalable Microservices", sobre padrões de sistemas distribuídos e como os containers permitem isso.
InfoQ: Os Sistemas Distribuídos existem há décadas. O que há de novo no livro? Se sou um programador ou um arquiteto, por qual razão deveria adquiri-lo, além do fato de ser gratuito?
Brendan Burns: Acho que demora algum tempo para publicar livros que apresentam padrões. E, geralmente é o resultado de alguma tecnologia transformacional que torna os padrões mais fáceis de serem discutidos abstratamente. Por exemplo, o livro Gang of Four, surgiu quase dez anos depois do desenvolvimento da programação orientada a objetos, mas claramente esse livro (e todos os livros de padrões dos anos 90) são inspirados por programação orientada a objetos.
Para mim, foi momento de transformação de containers e orquestração de containers que me inspirou a escrever este livro. Pensei: "Finalmente temos uma linguagem e vocabulário comuns com o qual podemos discutir esses padrões". Naturalmente, temos todos esses recém-chegados indo para a nuvem e para sistemas distribuídos, o que também faz parte da motivação. As pessoas precisam aprender as lições por meio de livros, e não construindo sistemas quebrados.
InfoQ: Em sua palestra no Kubecon 2017, foi falado sobre como tornar a programação de sistemas distribuídos em um desafio tão simples quanto fazer um curso básico de TI. Assim sendo, temos uma pergunta em duas partes. Primeiro, foi imaginado que o Kubernetes teria adoção tão ampla e tão rápida quanto foi evidenciado no Kubecon? E, segundo, como os containers e Kubernetes ajudam na programação de sistemas distribuídos?
Burns: Acho que como fundadores, junto com Joe, Craig, estamos realmente entusiasmados com o nível de interesse e uso do Kubernetes. Acho que sempre esperávamos que isso pudesse ajudar a levar à adoção de padrões e práticas nativas na nuvem, mas ainda é realmente incrível vê-lo acontecer. E falar para todas essas pessoas que estão apostando seus negócios ou aplicativos no Kubernetes, é uma incrível quantidade de confiança. Mas acho que isso realmente é resultado da qualidade e comprometimento de toda a comunidade e ecossistema do Kubernetes. É realmente um esforço mundial. Quando se pensa em todas as coisas que nos dividem, estarmos unidos em torno deste software, o que é muito inspirador.
Acho que o objetivo do Kubernetes, o tempo todo, era ser um sistema autônomo para sistemas distribuídos. Gosto de fazer uma analogia entre um avião voando manualmente e um drone quadcopter. O quadcopter é muito mais fácil de voar porque tem um controlador on-board para mantê-lo nivelado, e só é preciso dizer onde quer que ele vá. O mesmo vale para o Kubernetes: diga o que quer que seja verdadeiro, e ele será responsável por manter o número correto de réplicas, reagindo a falhas de aplicativos ou falhas de máquinas. É como ter freios anti-bloqueio para o seu aplicativo distribuído, como um computador no circuito para reagir automaticamente e mantê-lo seguro. Além disso, acho que com coisas como balanceadores de carga de serviço e coisas do tipo, isso realmente torna fácil cair no "poço do sucesso" e implementar seus aplicativos de forma escalável e desacoplada.
InfoQ: Ainda sobre a palestra no Kubecon 2017, foi falado da democratização do desenvolvimento de sistemas distribuídos com um tempo de execução nativo na nuvem chamado de Metaparticle. O que exatamente quer dizer com isso? O Istio é um bom exemplo disso?
Burns: Bem, o Metaparticle é uma maneira de repensar como projetamos e construímos sistemas. Atualmente, escrevemos código para cada máquina e usamos arquivos YAML para descrever como todos esses programas individuais se encaixam. Ao longo do caminho, temos que aprender e usar vários aplicativos diferentes, formatos de arquivo, e idiomas para descrever o sistema. É muito complicado e muito difícil para novos desenvolvedores pegarem e usarem.
A Metaparticle é uma tentativa de dizer: "Podemos fazer tudo isso em uma única linguagem de programação?" É realmente uma experiência para permitir que desenvolvedores mais inexperientes traduzam suas habilidades em padrões nativos da nuvem. Acho que o Istio é diferente, pois trata sobre tornar mais observáveis e dinâmicos os sistemas existentes. É uma ferramenta para pessoas que já sabem como construir sistemas nativos na nuvem, mas querem que seja mais fácil monitorá-los e adaptá-los.
InfoQ: Como sugerido em sua palestra, se as linguagens tiverem que fornecer ligações nativas na nuvem para facilitar o desenvolvimento, provavelmente estarão a anos de fazê-lo em um formato padronizado. É apenas uma questão de tempo até que isso aconteça? Enquanto isso, o ecossistema fornecerá ferramentas e plataformas para resolver alguns dos desafios associados ao desenvolvimento de sistemas distribuídos?
Burns: Sim, acho que existem duas classes diferentes de soluções. Há coisas que suavizam as experiências existentes e eliminam a dor. As ferramentas como Helm e Draft, bem como toda a integração do VS Code, são ótimas para isso. Acho que veremos uma evolução constante dessas ferramentas para tornar o Kubernetes cada vez mais fácil para aqueles que já são desenvolvedores nativos da nuvem.
Acho que há uma classe separada de coisas que são transformacionais e capacitam toda uma nova classe de desenvolvedores para se tornarem nativos da nuvem. Pense nisso como uma ótima IDE para C++, não pode fazer de você um bom programador de C++, mas ainda pode fazer um bom programador de C++ realmente feliz. Depois, há linguagens como Java ou C# que capacitam um novo grupo de desenvolvedores. Acho que ambas as coisas são necessárias neste espaço.
InfoQ: Quase todo mundo que programou sistemas distribuídos acabou fazendo suposições incorretas, por exemplo, como postulado nas oito falácias da computação distribuída. Os padrões de design distribuídos explicados em seu livro ajudam a aliviar alguns desses problemas e, em caso afirmativo, como?
Burns: Acho que o livro te ajuda a aplicar padrões que constroem sistemas mais robustos, e definitivamente fala sobre as considerações de design que devem ser pensadas ao construir seu sistema. Outra coisa que espero é que isso dê às pessoas uma linguagem comum para discutir seus sistemas, então não precisamos aprender as mesmas lições várias vezes, mas ao invés disso, estamos todos aprendendo e ensinando uns aos outros sobre os mesmos padrões. Porém, não existe mágica: as pessoas ainda precisam aprender muito por meio da experiência prática.
InfoQ: Muitas palestras no Kubecon pareciam fazer o desenvolvimento algo chato (deveria apenas ser funcional). Onde estamos como comunidade hoje? Se puder deixar sua imaginação falar, como seria daqui a cinco anos comparado com como estamos hoje?
Burns: Bem, realmente espero que falar sobre Kubernetes seja algo como falar sobre Posix, ou o conjunto de instruções x86. É algo que vale a pena fazer, e é algo que todo mundo tem que aprender para ajudar no trabalho, mas não é realmente uma fonte de entusiasmo. Espero que seja como falar sobre garbage collection ou programação orientada a objetos. É uma ferramenta importante para ajudar a fazer o seu trabalho, mas não é uma novidade e nem algo em que haja fãs.
E também espero que, ao olhar para trás, digamos: "Nossa, veja conseguimos fazer porque tivemos essa grande camada de abstração como base para construirmos"; porque o Kubernetes não é o fim, é uma ótima base, mas temos muito mais para construir sobre ele.
Os exemplos de código discutidos no livro estão disponíveis para download no repositório do Burns, no GitHub.