Arquitetura

A evolução dos servidores Web, o que usar e o que aposentar na sua empresa

~ Marco Mendes ~ 1 comentário

Servidores Web já existem há quase 30 anos e são a peça mais importante para suportar a Internet como a conhecemos. Embora muitos desenvolvedores não deem a devida importância para eles, é fundamental conhecer essa importante fauna e como podemos tirar vantagens de algumas tecnologias modernas para o suporte a estilos modernos como APIs e microsserviços.

Primeira geração – Servidores Web Baseado em processos

Reconstituição de trilobites vivos.

Anos de atividade: 1990 a 2000
Status: Extinto

O primeiro servidor Web foi desenvolvido a partir do utilitário inetd do Linux, que é um programa utilitário que responde requisições de um cliente em um certo porto e faz o despacho da requisição para um programa.

No começo dos anos 90, um programa específico foi desenvolvido para lidar com requisições http. Esse programa se chama httpD (Http Daemon), desenvolvido pela NCSA (National Center for Supercomputing Applications da Universidade de Illionis.

Como aplicações Web tendem a gerar um tráfego alto composto por múltiplas requisições de tempo de vida curto, esse tipo de mecanismo não é usado para fins profissionais. Com o tempo, peças específicas de software foram desenvolvidas para tratar com escalabilidade e segurança requisições HTTP. Ao mesmo tempo, é importante destacar o servidor Web mais popular do planeta, o Apache HTTP Server, foi desenvolvido a partir do utilitário NCSA httpD.

Segunda geração – Servidores Web baseados em Threads

Um Carcharias taurus.

Anos de atividade: 1995 – atual
Status: Em plena atividade

A história desses servidores se confunde com a história do Apache HTTP Server. Em linhas gerais, o Apache HTTP Server  surgiu a partir de utilitários simples para responder a requisições HTTP e foi evoluído para incluir características hoje fundamentais em aplicações Web tais como suportar:

  • Múltiplos clientes simultâneos através de multi-threading;
  • APIs de extensibilidade para a construção e distribuição de novos módulos;
  • Transporte seguro (SSL) e mecanismos de autenticação e autorização de páginas.

Esses servidores se tornaram dominantes na Web ainda nos anos 90 e exemplos de servidores dessa categoria incluem o Microsoft IIS  e NGINX. Enquanto o primeiro servidor é dominante para aplicações desenvolvidas em ASP e ASP.NET, o segundo foi desenvolvido como uma opção mais performática do Apache HTTP Server.

Servidores Web de Terceira Geração – Os temíveis e monstruosos Servidores de Aplicação 

Elephant white background.png

Anos de atividade: 2000 – atual
Status:  Em risco de extinção

A tecnologia Java EE era no final dos 90 o esforço mais sofisticado de organização de plataformas servidoras, inspirados por modelos hoje legados como o CORBA. Servidores Java EE trazem, por especificação, uma enorme coleção de serviços embutidos (out of the box), tais como linguagens de páginas dinâmicas, gerência de memória, operação clusterizada, controle transacional distribuído, modelos de componentes distribuídos e conectores com plataformas legados, entre outros).

Como consequência dessa enormidade de serviços, empresas como IBM, BEA, SUN, TIBCO, Fujitsu, Oracle e JBOSS, entre outras, começaram a desenvolver servidores Web com esteroides. Essas peças foram apelidadas de “servidores de aplicação” e são servidores Web que foram desenvolvidos para rodar aplicações servidoras.

No mundo Microsoft, a combinação do IIS, .NET Framework, MSMQ e Windows pode ser vista, com alguma liberdade arquitetural, com um servidor de aplicação Microsoft que hospeda e roda aplicações .NET

A história do Java EE e .NET se confundiu durante muito tempo com esses tipos de servidores Web. Algumas servidores de aplicações populares incluem:

  • IBM Websphere Application Server
  • Oracle Internet Applicaton Server (antigo BEA Weblogic)
  • Redhat Wildfly  (JBOSS Application Server)
  • Microsoft IIS + MSQM + .NET Framework
  • Microsoft BizTalk

Servidores Web de Quarta Geração – Servidores Leves Embarcados em Aplicações

Anos de atividade: 2010 – atual
Status: Em plena atividade

A partir de 2010, um movimento de minimalismo começou a tomar conta da comunidade de desenvolvimento Web. Os motivos estão ligados a problemas de escalabilidade e o peso de várias soluções dos servidores de terceira geração. Alguns desses servidores de terceira geração exigem pelo menos 1 GB de memória para funcionamento, ocupam dezenas de gigabytes de espaço em disco, requerem processadores de última geração para performer e alocam centenas de threads quando são instanciados.

Um exemplo de servidor Web de quarta geração é Express do Node.JS. Ele é um servidor minimalista que opera junto da própria aplicação .JS que está sendo executada. Ele ocupa um espaço mínimo de memória (entre 10 a 20 megabytes), poucos megabytes de espaço disco e usa recursos mínimos de CPU.

E as próprias comunidades Java EE e .NET começam a desenvolver soluções minimalistas para servidores Web.

No mundo Java EE, a Spring (hoje Pivotal) entregou soluções minimalistas como o Spring Boot . O Eclipse Jetty  e o KumuluzEE  são outras soluções nesse sentido.

No mundo .NET, a versão mais recente do ASP.NET e o projeto .NET Core são exemplos nesse sentido com os servidores leves e embarcados como o Kestrel e o HTTP.sys. Aplicações ASP.NET Core podem rodar sem a necessidade de servidores como o IIS. Essa nova geração de servidores Web elimina o modelo tradicional e empacotamento e distribuição de aplicações (assemble & deploy). Ao invés, a própria aplicação Java, C ou JS servidor é executada como um servidor Web em um modelo chamado de aplicação auto hospedada (self-host application). Essa nova geração é útil para o desenvolvimento no estilo arquitetural de microsserviços.

Comparação da Fauna de Servidores Web

Para facilitar a sua escolha e evolução arquitetural, montei uma tabela de referência aqui.

E você, que fauna está alimentando na sua empresa?

Tecnologias Web em 2018: O que escolher ao começar um novo projeto

~ Marco Mendes ~ Deixe um comentário

Tomar decisões sobre que tecnologias usar em um novo projeto Web não é simples. A indústria de software apresenta opções como nunca antes e é facil ficar perdido dentro de tantas opções de bibliotecas, componentes, frameworks, IDEs e ferramentas de scaffolding.

Observo em base diária o que colegas, parceiros de negócio, clientes e pessoas da comunidade estão usados. E com base nessas observações expresso aqui algumas opiniões fundamentadas para facilitar a sua jornada na escolha de novas tecnologias Web.

  1. Considere o uso profissional de tecnologias JavaScript

JavaScript? Sei não? Isso é realmente sério?

Sim. Javascript é somente a linguagem mais usada no mundo Web hoje para o desenvolvimento de aplicações. Por exemplo, uma pesquisa com 64 mil desenvolvedores realizada pelo sítio StackOverflow mostrou o JS sendo por 67% dos desenvolvedores.

E veja. Não estou falando apenas de bibliotecas acessórias como jQuery e jQueryUI. Afinal, estas boas bibiotecas já são usadas no Brasil há mais de 10 anos.

Estou falando aqui dos seguintes aspectos:

  • substituição de tecnologias de apresentação com o padrão arquitetural MVC (ex. JSF, ASP.NET Razor) pelo padrão arquitetural MVVM (ex. Google Angular 5, Facebook React ou VueJS);
  • uso de frameworks de testes de unidade em JavaScript. Bons exemplos incluem o CucumberJS, Jasmine, Karma ou Protractor;
  • uso de ferramentas para distribuição eficientes dos pacotes JavaScript com uso de recursos de minificação e embaralhamento do código. Ferramentas particularmente úteis nesse aspecto incluem o WebPack3 e o Parcel.
  • uso de linguagens baseadas em JavaScript que aumentam o nível de abstração e possuem compilação estática de código. A linguagem Microsoft TypeScript tem expandido a sua popularidade e se consolidado neste aspecto.
  • depuração eficiente de código cliente (logging). Ferramentas com o LogRocket e o Elmah são uma ajuda e tanto neste contexto.
  • uso de IDEs leves e modernas. Brilham aqui IDEs como o Visual Studio Code e WebStorm.

Ao adotar um ecossistema JavaScript sólido, você terá em sua mão o que as melhores empresas do mundo estão usando para desenvolvimento Web. Terá também tecnologias mais simples e eficientes e mais capacidade de se adaptar aos próximos anos.

Deixo aqui uma referência para um relatório bem legal chamado The State of Javascript 2017 e alguns gráficos interessantes desta pesquisa.

Popularidade de frameworks JavaScript para Front-end — https://stateofjs.com/2017/front-end/other/
Popularidade de frameworks JavaScript Back-end— https://stateofjs.com/2017/back-end/other/
Popularidade de frameworks para Testes em JavaScript — https://stateofjs.com/2017/testing/other/
Popularidade de ferramentas de build em JavaScript — https://stateofjs.com/2017/build-tools/other/

2. Use APIs REST para expor suas funcionalidades de negócio

Não importa se você desenvolve em PHP, Python, C# ou Java. O que você deve evitar é que a camada Web faça acesso direto a funcionalidades backend sem o uso de APIs.

O código servidor não deve ficar preso ao código HTML (o JSF e o ASP.NET Web Forms são contra-exemplos desta recomendação). O código servidor deve ser escrito com a possibilidade de reuso por aplicaçõees móveis e também aplicativos de internet das coisas, conforme mostrado na figura abaixo.

Aplicações Web modernas devem expor APIs

Ao fazer isso, você trará os seguintes benefícios para a sua empresa:

  • Potencializar o uso de código legado. APIs REST podem encapsular códigos em tecnologias antigas como PL-SQL, COBOL, Natural.
  • Habilitar competências específicas no seu time. Não é incomum que pessoas que conheçam muito bem Java, C# ou PL-SQL não consigam ter o mesmo nível de excelência em desenvolvimento moderno Web com React ou Angular5. E isso permite que você tenha dois perfis distintos nesta situação, que são os Back-end developers e Front-end developers.

Se você já começou a usa jornada com APIs, use este estilo de forma consistente. Deixo aqui algumas recomendações de tecnologias de suporte para testes e aperfeiçoamento das suas APIs:

3. Evolua as linguagens do lado servidor

Se você trabalha com Java, não deixe de usar os diversos recursos funcionais do Java 8. Embora os recursos já existem desde 2014, muitos desenvolvedores não estão fazendo uso destes elementos. E considere o uso de recursos recém lançados do Java 9 tais como melhorias na API de Streams, distribuição modular, cache e suporte a JavaScript servidor.

Se você trabalha com C#, é hora de considerar o novo ecossistema de tecnologias do .NET Core e .NET Standard, que está na sua segunda geração já.

O ASP.NET Core, por exemplo, tem obtido apoio muito forte da comunidade e conta com os primeiros projetos em produção no Brasil.

E, com o .NET Core 2, foi lançado também a biblioteca do .NET Standard que permite que desenvolva ou refatore módulos que poderão operar simultaneamente na nova arquitetura do .NET Core, arquitetura legada do .NET Framework e também o próprio Xamarin para aplicaçativos móveis.

Se você trabalha com linguagens dinâmicas, considere o Python 3. Esta linguagem tem experimentado um crescimento expressivo devido ao mercado de ciência de dados e big data.

4. Simplifique a sua distribuição com aplicações auto-hospedadas e contêineres

Entre 1995 e 2010, o mercado foi domaindo pelos servidores de aplicação clássicos, como por exemplo o Microsoft IIS, Apache Tomcat, JBOSS Application Server e produtos similares de empresas como IBM ou Oracle.

Nos últimos dois anos, temos observados muitas empresas usando soluções mais simples em ambientes de produção com o uso de tecnologias diversas tais como:

Dentro das tecnologias de conteineres, começe a adotar o Docker e considere tecnologias de suporte para o gerenciamento de conteineres como por exemplo o Rancher e orquestração de contêineres como o Google Kubernetes.

5. Considere estilos arquiteturais complementares

O uso dos padrões MVC e MVVM ainda é dominante no desenvolvimento Web. Para para problemas alternativos temos vistos estilos arquiteturais complementares tais como:

  • Microsserviços, que permitem escrever novos produtos como um conjunto de serviços pequenos e independentes. Tenho um artigo introdutório ao tema aqui (Não Alimente Seus Paquidermes). Tecnologias como o Lumen, Flask, SpringBoot e .NET Core são mais interessantes para este cenário.
  • Nanosserviços (ou serverless ou funções como serviços), que são tipos de microsserviços que operam sobre nuvem públicas sem a necessidade de aluguel de máquinas. Você cria e distribui o seu código e é tarifado pelo uso de CPU e memória do seu código em ambiente de produção. O AWS Lambda, Azure Functions e Google Functions são exemplos muito promissores destas tecnologias.
  • Segregação de comandos e consultas (CQRS), cujo objetivo é acelerar a performance de aplicações através da segregação do código de consulta dos códigos de comandos de atualização do banco de dados.
Padrão Arquitetural CQRS — https://martinfowler.com/bliki/CQRS.html
  • Persistência poliglota, que consiste do uso de diferentes estratégias e tecnologias de persistência de dados para situações específicas em aplicações Web. Por exemplo, armazenar e indexar um conjunto de imagens ou criar um cache pode ser eficientemente resolvido em bancos de dados do tipo chave/valor como por exemplo o Redis. Um exemplo prático é a arquitetura da Stack Overflow, mostrada no esquema abaixo.
Arquitetura Web do Stack Overflow — https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

Iniciando a transição

Antes de adotar em larga escala novas tecnologias, é sempre importante lembrar de algumas recomendações arquiteturais:

  • Faça provas de conceitos para reduzir riscos e testar estas novas tecnologias na sua realidade;
  • Faça treinamentos e garanta que cada pessoa do seu time tenha sido devidamente treinado;
  • Não deixe que o conhecimento de uma tecnologia fique na mão de um especialista — pessoas vem e vão e você pode ficar em maus lençóis se confiar em apenas uma única pessoa.
  • Não adote tecnologias apenas porque elas estão populares. Veja como elas podem resolver os problemas reais de negócio da sua organização. Faça testes e esteja preparado para o pior.

A fábula dos porcos assados (e os sistemas de informação)

~ Marco Mendes ~ Deixe um comentário

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque.  O tempo passou, e o sistema de assar porcos continuou basicamente o mesmo.

Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados demais ou parcialmente crus. As causas do fracasso do sistema, segundo os especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias e o Bureau Orientador de Reforma Igneooperativas.

Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? E com os acendedores de diversas especialidades? E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Hein?.”

“Não sei”, disse João, encabulado.

“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo?.”

“O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos engenheiros em porcopirotecnia? Vamos, diga-me!”.

“Não sei, senhor.”

“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer problemas para o senhor no seu cargo.”

João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.”

Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito mais frequência do que imaginaria na área de Tecnologia de Informação.

Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas fábricas que participaram deste processo.

Também tive a oportunidade de ver um time de produto que herdou uma arquitetura Web absurdamente complexa de um  “arquiteto super inteligente” de uma fábrica de software. O efeito desta arquitetura é o que time demora 3 semanas para implementar um cadastro de complexidade média.

Estas histórias reais me lembram do conceito de complexidade acidental e complexidade essencial, popularizado na TI por Neal Ford.

A complexidade essencial representa a dificuldade inerente a qualquer problema. Na nossa fábula acima, acender fogo era necessário para assar os porcos.  A complexidade decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é diferente. Consiste em todas as formas imposta externamente de que o software se torne complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não podem ser pronunciados são exemplos de complexidade acidental na TI.

Tomo a liberdade aqui de expandir a definição original do autor, pensada para arquiteturas de software, para arranjos essenciais e arranjos acidentais.

Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e times de desenvolvedores que trabalham em salas separadas e com processos cascatas são exemplos de arranjos acidentais. E os  “gerentes de projetos” que ficam atrás das suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos acidentais.

Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a aplicação de práticas do Lean Software Development, um corpo de práticas muito legais para você descomplicar a sua TI e a forma como entrega e mantém software.

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
― Edsger W. Dijkstra

Algumas boas práticas sobre APIs

~ Marco Mendes ~ 1 comentário

Existe ainda alguma confusão sobre APIs. Muitos gestores acreditam que uma API é um algum termo nerd discutido nos porões do desenvolvimento de software. E muitos desenvolvedores acreditam que uma API é apenas um conjunto de funções expostas a partir da sua IDE para habilitar a integração da sua aplicação com algum front-end.

Outros gestores e desenvolvedores mais atentos já observaram que APIS são ferramentas que podem aumentar suas receitas e reduzir o TCO de seus códigos legados. Um exemplo muito bacana no contexto brasileiro é como market places tem aumento o faturamento de grandes redes varejistas. E já existem também congressos temáticos no Brasil para discutir as possibilidades de negócio como por exemlo o API Experience.

APIs, definitivamente, vieram para ficar. APIs podem potencializar aplicações legadas, abrir novos canais de parcerias de negócio e até mesmo criar novos produtos para as suas áreas de negócio.  E isso é muito bom para que TIs possam prover mais alinhamento e valor de negócio.

Mas como podemos nos locomover no mundo das APIs? Como iniciar e gerar valor com elas?

Se você perguntar para algum fornecedor de ferramenta que precisa alimentar seus filhos a resposta vai ser – Compre a minha ferramenta mágica de API Management. “Ela irá centralizar, segurar, governar e resolver todos os problemas de API da sua organização.” Infelizmente, isso não é verdade e nos leva à primeira diretriz

1. Não compre uma ferramenta de API Management (até que você tenha estabelecido uma cultura mínima de APIs na sua empresa)

Tenho observados casos de fracasso de empresas que tem adotado ferramentas de APIs sem estabelecer API Teams e formar desenvolvedores que entendam minimamente do protocolo HTTP e do estilo REST.

2. Comece pelos fundamentos básicos e apenas depois avance para as tecnologias

Você é o desenvolvedor ultra mega blaster especialista em ASP.NET Web API e SpringBoot, certo?  Mas você ainda acredita que o POST é para incluir um recurso, PUT é para alterar um recurso. E você também nao sabe o significado da palavra idempotência e o seu efeito prático. E você ainda acredita que REST implica em HTTP. Se sim, pare por um momento e fundamente seus conhecimentos.

Conheço muitos “especialistas” em APIs que nunca leram a RFC do protocolo HTTP – https://tools.ietf.org/html/rfc2616 ou as seções centrais do trabalho de origem de Roy Fiedling sobre REST. É como você conhecer um padre que nunca leu uma bíblia ou um cirurgião que nunca leu um livro de anatomia. Os resultados podem ser muito ruins.

Conhecer os fundamentos do protocolo HTTP, REST e princípios arquiteturais para produzir aplicações escaláveis é vital para usar bem os ótimos produtos de API de mercado.

3. Trate APIs como produtos de negócio

No mais recente relatório da APIgee (State of API Report 2017), empresa especialista em APIs comprada pelo Google, foi observado que as empresas mais bem sucedidas no uso de APIs tem tratado APIs como produtos de negócio.

Tratar APIs como produtos aproxima a TI das áreas de negócio, cria valor e potencializa a criação de novos negócios com empresas parceiras.

4. Use tecnologias simples

Não complique o uso de APIs com tecnologias pesadas. Devemos aprender algo com o fracasso dos ESBs e servidores de orquestração BPMS/SOA na primeira década do século XXI.

Fuja dos protocolos  SOAP e WS-*, exceto se você precisa interoperar com governo. E mesmo assim, crie fachadas REST sobre HTTP para não expor complexidades para os seus clientes.

Use produtos leves e de fácil aprendizado, como o ASP.NET Web API, Spring Boot ou Node.JS. Realiza provas de conceitos e crie experimentos. Estabeleça aprendizados e compartilhe experiências na sua empresa.

4.  Crie APIs Robustas

APIs não devem expor funções de negócio (e não tabelas de banco de dados). Muitos times tem criado APIs que operam como CRUDs das tabelas de seus banco de dados. E esta anti-prática já foi documentada aqui como algo ruim pela ThoughtWorks (Anemic REST). Se você encontrar uma API anêmica na sua máquina, copie a mesma para o diretório /dev/null.

APIs devem ter automação de testes. Em 2017, isso nem deveria ser mais lembrado. Ainda assim, é assombroso que existam desenvolvedores por aí que ainda não acreditam em testes de unidade. Mas é assombroso que também existam políticos corruptos no Brasil!

Mas de volta aos testes de unidade, ferramentas como o Swagger, PostMan ou frameworks XUnit são aliados poderosos neste sentido e podem ajudar a manter as suas APIs integras.

APIs devem ter documentação, preferencialmente em um formato navegável e que permita o consumo da API em modelo self-service pelos desenvolvedores de clientes das APIs. Novamente ferramentas bacanas existem aqui com o Swagger, Apiary ou o Slate API Docs Generator.

APIs devem ser baseadas pelo menos no nível 2 de Maturidade RESTful de Richardson

Mas quem é Richardson? E o que ele tem a ver com o meu trabalho?
Leia aqui porque isso é importante para você.

APIs devem ser consistentes entre desenvolvedores e times. Crie com o seu time um padrão apropriado para criar APIs.

Você pode usar algumas boas práticas de mercado e adaptá-las para a sua realidade. Por exemplo, recomendo estes pontos de partida para você o seu time:

5. Governe as suas APIs (Sim! Agora você pode adotar uma ferramenta de API Management)

Você já um API Team, já sabe usar o protocolo HTTP e já começou a estabelecer uma cultura de APIs. Muito bom! Agora você pode baixar uma ferramenta aberta ou comprar uma ferramenta de API Management.

Opções não faltam para você e recomendo o excelente relatório do Forrester de integração híbrida. Use-o como ponta de partida para você selecionar os seus candidatos, fazer provas de conceitos e dar o próximo passo em termos de maturidade na sua organização.

Bons estudos e boas APIs!

API Nerd do Dia – https://developer.marvel.com
(Para aprender como fazer uma boa API com os seus quadrinhos e filmes preferidos).

 

Microsserviços e Outros Padrões de Arquitetura de Software

~ Marco Mendes ~ Deixe um comentário

Desde que a Uber, Netflix e outras grandes empresas começaram a publicar as vantagens econômicas de produtividade e escalabilidade da adoção do padrão de microsserviços, este estilo arquitetural começam a ganhar muita atenção da comunidade técnica de TI. E isso ganhou ainda mais força com a publicação de um artigo de James Lewis e Martin Fowler sobre o tema.

Ao mesmo tempo, existe ainda muita confusão sobre este estilo, que é confundido com a criação de APIs, SOA ou ESB. Algumas distinções importantes incluem:

  • Cada microsserviço possui o seu próprio banco de dados;
  • Serviços trocam informações através de chamadas REST ou filas de mensagens; (e não através de protocolos WS-* ou com acesso ao banco de dados do serviço vizinho)
  • Não existe a figura de barramentos do tipo ESB (Enterprise Service Bus);
  • A governança dos serviços é executável, fornecida por ambientes de PAAS tais com o Azure ServiceFabric, Netflix OSS, CA API Gateway ou Pivotal Cloud Foundry.

Para ajudar a lançar luz sobre o tema e reduzir esta confusão, a Safari anunciou um minilivro gratuito sobre o tema de padrões de arquitetura de software do arquiteto Mark Richards. É um livro de leitura fácil e que possui figuras simples que permitem conhecer este padrão de microsserviços e também outros estilos arquiteturais tais como o estilo em camadas, baseado em eventos, microkernel e baseado em espaços (cloud architectures).

E, para aqueles que estão muito ocupados no momento para ler o livro, republico aqui a tabela final do livro com um comparativo das forças e fraquezas do padrões ao longo de seis critérios de análise.

captura-de-tela-2016-11-26-as-13-32-08