Reflexões sobre Serverless: De SOA (Service-oriented architecture) para Serverless — Parte 1
Autor: Diego Pacheco — Principal Software Architect at ilegra
A nova tecnologia é ótima. É muito importante abrir espaço para novas ideias, melhores soluções, mais baratas, mais rápidas e empolgantes. No entanto, mesmo com a tecnologia, existem princípios e lições aprendidas com as tecnologias anteriores que precisamos seguir, caso contrário, continuaremos cometendo os mesmos erros e talvez não aproveitemos totalmente a nova tecnologia. Por quê? Porque muitas vezes a nova tecnologia requer um novo modo de fazer as coisas e muitas vezes também exige que algumas coisas sejam mantidas dos movimentos anteriores. As empresas querem ser Serverless nos dias de hoje, muitas vezes porque os fornecedores de nuvem estão pressionando e por causa do custo benefício a curto prazo.
No entanto, a longo prazo, as soluções Serverless podem ser muito mais caras do que as soluções internas usando OSS. Não há bala de prata, você precisa entender o que você está fazendo para tirar máximo proveito de novas abordagens, tecnologias e idéias, em vez de apenas mover tudo de uma tendência para outra. Eu quero compartilhar alguns pensamentos de vários modelos de arquitetura e princípios que foram evoluindo de SOA para Apis, para Microservices, para Cloud-Native Microservices e para Serverless.
Por exemplo, o Serverless está seguindo em frente conforme alguns princípios da SOA, sabia?
Para este post, vou fornecer um conjunto de explicações sobre a minha visão da evolução da arquitetura.
De SOA para Serverless
SOA não é sobre tecnologia (SOA não é sobre ESB), SOA é sobre princípios, e esses princípios, hoje em dia, estão mais vivos do que você pode imaginar.
SOA foi a base de tudo. SOA é sobre abstrações (contrato) e o quadro geral (Service Orientation — SO), vendo todo o espectro do sistema e não deve ser usado como apenas um simples serviço sozinho ou um único projeto. Um dos principais benefícios do SOA é a abordagem de compatibilidade retroativa (BC). Soa não é uma tecnologia específica nem apenas um ESB.
Microservices são um tipo de SOA com dois aspectos diferentes. Em primeiro lugar, a granularidade que é menor do que a SOA, e SOA nunca deu uma receita sobre como poderia ser um serviço granular, mas, na minha experiência, muitas vezes era muito grande. Segundos Microservices são sobre o isolamento. Em outras palavras, eles têm SO dedicado, Servidores, repositório Git, construção de pipeline, e assim por diante. Microservices requer muito trabalho de DevOps. Os microsserviços não são a bala de prata, há problemas de domínio em que não faz sentido ter pequena granularidade e, portanto, isso poderia levar a um mau design e acoplamento. É muito importante falar sobre SOA em Microsserviços e contexto Serverless, porque esses modelos de arquitetura evoluem de um para outro e, se você vir o Serverless como algo independente (significando: não aprendendo com SOA e microsserviços), provavelmente estará fazendo isso errado.
Microservices necessitam de DevOps Engineering. Quando estamos fazendo microsserviços na nuvem, podemos usar a maioria dos benefícios da nuvem, fazendo microsserviços nativos da nuvem, o que pode ser feito usando NetflixOSS / Spring Boot Stacks ou, atualmente, você pode usar o Kubernetes com o Istio.
O que é Serverless?
FaaS e Serverless são coisas diferentes. Muitas vezes as pessoas pensam que o Serverless é apenas sobre o FaaS. Muitas vezes, o Serverless está relacionado ao FaaS. No entanto, é mais provável que você tenha o Serverless quando estiver fazendo o FaaS, mas você pode estar fazendo o Serverless sem ter FaaS. Porque o Serverless é um modelo de nuvem, onde muitas vezes o provedor de nuvem cuida da operação para você. Esse é o caso dos Serviços Gerenciados para Bancos de Dados, como o Aurora, mas também de outros mecanismos, como o Kafka, o MongoDB e muito mais. FaaS (que foi chamado microservices por um breve momento — para algumas pessoas) é a evolução dos microsserviços, no entanto, o FaaS é orientado por eventos e os microsserviços podem ser controlados tanto por eventos como também podem ser RPC.
Serverless e Kubernetes
O Kubenetes é o caminho para nuvem multi-cloud / poly-cloud. Ks é a especificação de código aberto / padrão de nuvem aberta, o que significa que você pode usar a nuvem sem ficar bloqueado por um fornecedor de nuvem. Os Kubernetes permitem que você execute todos os tipos de cargas de trabalho de RPC, Analytics / Batch / Streaming, Treinamento de Machine Learning e também Serverless. O legal sobre rodar Serverless no kubernetes é o fato de que tudo é portátil, não apenas o código rodando no Serverless, mas também toda a infraestrutura que é ótima. Em algum lugar no futuro, a nuvem deve ser sobre o custo de mover as coisas ao redor, sendo melhor não apenas para um melhor uso da reserva de nuvens, mas também para negociações estratégicas.
Serverless requer menos trabalho de DevOps, isso não significa que você pode fazer NoOPS. Isso significa que você tem menos trabalho no DevOps / Ops. Você ainda precisa automatizar a implementação de suas funções (caso você esteja fazendo o Serverless com Faas), se você pensar no CloudSQL ou no RDS, terá mais coisas para automatizar. O fim do Serverless tem menos partes móveis de você e mais peças para o provedor de nuvem que está fornecendo o serviço.
Existe uma especificação aberta para o Serverless chamada * Cloud Events *. Eventos da nuvem descrevem os eventos (entradas, saídas) de uma maneira padrão. Isso soa como um contrato de SOA? Sim. Também vemos o mesmo disposto a ter portabilidade como vimos no SOA Manifesto. Se você não acha que este é o futuro, você não precisa aceitar minhas ideias, mas aceite as do Kelseys.
Publicado originalmente http://diego-pacheco.blogspot.com/2019/03/reflections-on-serverlessfrom-soa-to.html
