DEV Community: Felipe Freitas

Separando o Deploy do Release - Como Entregar Valor com Segurança e Flexibilidade

Felipe Freitas — Wed, 16 Oct 2024 19:51:27 +0000

Ainda é comum encontrar equipes de desenvolvimento que associam cada deploy em produção diretamente a uma nova release do produto. Embora esses dois conceitos estejam interligados, tratá-los como sinônimos pode limitar a flexibilidade e aumentar os riscos. Ao separar o deploy da release, as equipes ganham mais controle sobre o ciclo de vida do software, possibilitando uma entrega mais segura e previsível. Estratégias como Feature Flags, Canary Releases e Blue-Green Deployment permitem realizar deploys frequentes sem expor os usuários a mudanças imediatas, facilitando a experimentação, a mitigação de riscos e a entrega contínua de valor. Para as empresas, isso significa maior agilidade para responder ao mercado, melhor experiência do usuário e um caminho mais seguro para inovação.

Deploy vs. Release

Antes de mais nada, é importante definir o que entendemos por deploy e release:

Deploy: Refere-se ao processo de transferir código para um ambiente seja o de desenvolvimento, homologação ou produção. O código pode incluir novas funcionalidades, correções de bugs, ou até mesmo pequenos ajustes que não são perceptíveis para o usuário final.
Release: É o momento em que uma nova versão de uma aplicação é disponibilizada ao usuário final. Ela pode englobar um conjunto de novas funcionalidades ou uma mudança significativa no sistema.

Logo, um deploy em produção pode ocorrer sem que os usuários percebam uma nova "release", pois os mecanismos de ativação dessas funcionalidades podem ser controlados de diferentes formas.

Para empresas que adotam práticas de alta performance, o deploy frequente é uma realidade. De acordo com o State of DevOps Report 2023, equipes de elite realizam deploys sob demanda, o que pode significar vários deploys por dia, dependendo da necessidade. Essas equipes têm a capacidade de fazer mudanças em produção de forma frequente e segura.

Manter o código em produção antes de liberá-lo proporciona às equipes de desenvolvimento tempo para testes adicionais e ajustes sem impactar diretamente os usuários. Empresas que implementam essa prática reportam uma menor taxa de falhas por deploy, aumentando a previsibilidade dos lançamentos e a confiança no processo de entrega.

Estratégias para Manter Deploy e Release Separados

Existem várias estratégias que permitem separar o deploy do release, oferecendo benefícios tanto técnicos quanto de negócio. Vamos explorar as principais técnicas: Feature Flags, Blue-Green Deployment, Canary Releases, Rolling Deployment e A/B Testing.

1. Feature Flags

As Feature Flags permitem que novas funcionalidades sejam ativadas ou desativadas dinamicamente, sem a necessidade de novos deploys. Isso significa que o código está presente, mas desativado, aguardando o momento ideal para ser liberado. A prática de Feature Flags não apenas melhora a flexibilidade, como também aumenta a segurança.

Benefícios das Feature Flags:

Ativação dinâmica de funcionalidades.
Facilidade para testes A/B.
Desativação rápida em caso de problemas.

2. Blue-Green Deployment

No Blue-Green Deployment, dois ambientes de produção são mantidos: Blue (ativo) e Green (inativo). O código é implantado no ambiente inativo (Green) e, quando pronto, o tráfego de produção é redirecionado para ele. Isso garante um processo de transição suave entre versões e evita interrupções.

Benefícios:

Zero downtime durante o lançamento.
Rollback rápido e seguro.

3. Canary Releases

No Canary Releases, apenas uma pequena porcentagem de usuários recebe as novas funcionalidades inicialmente. Isso permite que a equipe monitore o desempenho e identifique potenciais problemas antes de realizar um rollout completo.

Benefícios:

Testes em produção com risco minimizado.
Identificação precoce de problemas.

4. A/B Testing

O A/B Testing permite que diferentes versões de uma funcionalidade sejam testadas simultaneamente com subconjuntos de usuários, possibilitando que as equipes avaliem a eficácia de mudanças e ajustem funcionalidades antes do lançamento para todos os usuários.

Benefícios:

Tomada de decisões baseada em dados reais.
Melhoria contínua de funcionalidades. ### 5. Rolling Deployment

O Rolling Deployment é uma estratégia na qual a nova versão do sistema é implantada gradualmente, substituindo aos poucos as instâncias da versão antiga, até que todas as instâncias estejam executando a versão mais recente. Isso minimiza o impacto em produção, uma vez que sempre há instâncias ativas da versão anterior enquanto a nova versão está sendo implantada.

Benefícios:

Evita downtime, mantendo instâncias ativas durante o processo.
Permite rollback parcial em caso de problemas durante a implantação.
Reduz o risco de falhas em massa.

Impacto no Negócio e Produto

1. Lançamentos Mais Previsíveis e Menos Arriscados

A separação entre deploy e release permite que o lançamento de novas funcionalidades seja mais previsível, reduzindo os riscos de interrupções inesperadas para o usuário final. Empresas que adotam essa separação têm menos falhas em produção, o que impacta diretamente a confiança do cliente e a percepção de qualidade do produto. Essa previsibilidade ao lançar funcionalidades de forma suave e sem interrupções também influencia positivamente a taxa de satisfação dos clientes.

2. Agilidade para Reagir a Oportunidades de Mercado

Manter o código em produção antes de liberá-lo para todos os usuários oferece às empresas uma vantagem significativa na resposta rápida a mudanças de mercado, como novas regulamentações ou feedbacks de clientes. Essa prática permite ajustes imediatos sem a necessidade de longos ciclos de desenvolvimento e grandes releases, garantindo que as empresas estejam preparadas para capturar oportunidades com agilidade. Empresas que implementam Continuous Delivery (CD) podem responder a mudanças em tempo real com maior precisão e eficiência, permitindo que novas funcionalidades ou ajustes sejam implementados de maneira segura e incremental.

3. Decisões Baseadas em Dados

Técnicas como Feature Flags e A/B Testing permitem que decisões de produto sejam baseadas em dados reais pois permite que as empresas coletem dados valiosos sobre o comportamento do usuário antes de liberar uma funcionalidade para todos, o que resulta em funcionalidades mais adequadas ao comportamento dos usuários. Decisões orientadas por dados levam a mais confiança, proatividade e otimização de custos. O uso de dados para monitorar e medir a eficácia de um deploy permite ajustes precisos no momento de uma release, melhorando a experiência do usuário e minimizando riscos

4. Redução de Custos com Suporte e Manutenção

Uma das maiores vantagens das práticas de deploy ágil e entrega contínua é a redução significativa de custos com suporte e manutenção. Ao implantar código em pequenos incrementos e com controle rigoroso sobre a liberação de funcionalidades, as empresas conseguem evitar grandes mudanças disruptivas, o que diminui a necessidade de intervenções de emergência no suporte. Como o código é testado em produção em pequenos lotes, os incidentes são detectados e resolvidos antes que atinjam uma parcela significativa de usuários. Isso diminui o volume de problemas de suporte que requerem solução imediata, resultando em economia de tempo e dinheiro.

Integração com Metodologias Ágeis

No contexto de metodologias ágeis, a separação entre deploy e release permite uma entrega contínua de valor ao longo das sprints. Em vez de aguardar até o fim de cada sprint para liberar todas as funcionalidades de uma vez, as equipes podem realizar deploys frequentes, mantendo novas funcionalidades em "standby" até que estejam maduras para serem ativadas. Essa abordagem garante maior flexibilidade na priorização de tarefas e no planejamento de lançamentos, possibilitando ajustes com base em feedbacks e minimizando o risco de grandes interrupções ou retrabalhos.

Essa prática não só facilita a validação incremental de funcionalidades ao longo do ciclo de desenvolvimento, como também protege a estabilidade do ambiente de produção. Ao implantar funcionalidades de maneira controlada, as equipes podem testar e verificar partes do código em produção sem afetar diretamente os usuários, mantendo a consistência da entrega de valor sem comprometer a qualidade ou a segurança do sistema.

Conclusão

A separação entre deploy e release não só otimiza a eficiência técnica, como também gera impactos positivos para o negócio. Técnicas como Feature Flags, Canary Releases, Blue-Green Deployment e A/B Testing são essenciais para garantir que o valor seja entregue aos clientes de forma segura e controlada, permitindo que as equipes alinhem suas entregas com objetivos estratégicos. Além de melhorar a experiência do usuário, essas práticas aumentam a flexibilidade e mitigam o risco de interrupções, contribuindo para um processo mais ágil e responsivo.

Referências

State of DevOps Report 2023. Disponível em: https://services.google.com/fh/files/misc/2023_final_report_sodr.pdf
How Being a Data-Driven Company Leads to Better Outcomes_. Harvard Business Review. Disponível em: https://hbr.org/2020/02/how-being-a-data-driven-company-leads-to-better-outcomes
Feature Toggles (aka Feature Flags). Hodgson, Pete. Disponível em: https://martinfowler.com/articles/feature-toggles.html

Modernizando Plataformas Monolíticas - Minha experiência com o Strangler Pattern

Felipe Freitas — Thu, 03 Oct 2024 17:55:21 +0000

Nos últimos tempos, tenho trabalhado na modernização de uma plataforma que, com o passar dos anos, começou a enfrentar desafios de performance e manutenção. Com o passar do tempo, sistemas de software tendem a sofrer com algo conhecido como entropia de software. Isso acontece quando o código vai se tornando cada vez mais complicado e desorganizado à medida que novas funcionalidades são adicionadas, bugs são corrigidos e ajustes rápidos são feitos. A entropia vai se acumulando, e de repente, o sistema que antes funcionava bem vira um labirinto cheio de dependências que dificultam a manutenção e afetam a performance.

Esse aumento da entropia é comum em sistemas monolíticos. À medida que o sistema cresce, fica cada vez mais difícil adicionar ou mudar algo sem quebrar outras partes, e a performance acaba caindo.

Foi aí que comecei a aplicar o Strangler Pattern, em vez de tentar reescrever o monolito do zero, essa abordagem incremental vem me permitindo transformar o sistema sem derrubar tudo de uma vez.

O que é a Entropia de Software?

A entropia de software é um fenômeno comum em sistemas que vão crescendo e evoluindo com o tempo, especialmente em sistemas monolíticos. No contexto da engenharia de software, o termo "entropia" é emprestado da física e refere-se à desordem ou ao aumento da complexidade em um sistema. Quanto mais tempo um sistema é mantido e mais mudanças são feitas nele, mais ele tende a se desorganizar e ficar difícil de entender e modificar. Isso acontece por uma série de razões:

Correções de bugs e implementações rápidas acabam sendo feitas sem o devido planejamento, o que resulta em “remendos” no código.
Novas funcionalidades são adicionadas, muitas vezes sobre partes já antigas e mal documentadas, aumentando a complexidade do código.
Dependências e interligações começam a surgir em excesso, tornando o sistema mais frágil – qualquer pequena alteração pode ter um efeito cascata em outras partes do sistema.

Com o tempo, essas mudanças incrementais tornam o sistema menos eficiente e mais difícil de manter, e isso pode resultar em problemas graves de performance, bugs recorrentes e aumento dos custos de manutenção. Além disso, a entropia do software cria barreiras para que novos desenvolvedores entendam e trabalhem no sistema, desacelerando o ritmo de entrega e inovação.

https://blog.chatbotslife.com/software-entropy-explained-causes-effects-and-remedies-baada6ae083b

Como o Strangler Pattern entra em cena?

O Strangler Pattern é uma estratégia de refatoração usada para modernizar sistemas monolíticos de maneira gradual. Em vez de tentar reescrever o sistema inteiro de uma só vez – o que pode ser arriscado e demorado – essa abordagem permite que você migre funcionalidades específicas para novas implementações de forma controlada e progressiva.

O nome "Strangler" é inspirado em uma planta parasita que cresce ao redor de uma árvore, eventualmente substituindo-a. No contexto de software, a ideia é "estrangular" o monolito antigo, migrando suas funcionalidades para componentes novos e mais eficientes. Com o tempo, o sistema monolítico é substituído de forma incremental por serviços modernos, sem a necessidade de reescrever tudo de uma vez.

Como o Strangler Pattern funciona na prática?

Identificação de funcionalidades: O primeiro passo é identificar as funcionalidades ou módulos mais críticos ou problemáticos no sistema. Muitas vezes, essas são as partes que mais afetam a performance ou que são mais difíceis de manter.
Desenvolvimento de novos serviços: Após identificar as áreas chaves, começamos a desenvolver serviços independentes que substituem essas partes específicas. Importante: o sistema antigo continua rodando enquanto os novos serviços são testados e implementados.
Decomposição contínua: Ao longo do tempo, seguimos esse processo até que o sistema antigo seja completamente "estrangulado" e substituído pelos novos serviços.

Por que usar o Strangler Pattern?

Essa abordagem tem várias vantagens, especialmente em ambientes onde uma reescrita completa do sistema não é viável:

Redução de riscos: Ao invés de realizar uma reescrita completa, o Strangler Pattern permite que a transição ocorra de forma incremental e segura. Isso reduz drasticamente o risco de falhas catastróficas, uma vez que você pode testar cada nova parte à medida que a antiga vai sendo substituída.
Evolução contínua: O sistema evolui de forma incremental, com novas funcionalidades sendo adicionadas aos novos serviços sem adicionar mais complexidade ao antigo sistema.
Escalabilidade: Novos serviços podem ser escalados de forma independente, aumentando a eficiência e a resposta do sistema.
Manutenção facilitada: Cada serviço novo é construído com uma arquitetura mais moderna e organizada, facilitando a manutenção e evolução contínua do sistema.

Na minha experiência, essa abordagem foi essencial para lidar com a entropia acumulada e, ao mesmo tempo, garantir que não houvesse interrupções drásticas no serviço. O Strangler Pattern tem permitido modernizar a plataforma gradualmente, começando pelas partes que mais impactavam a performance e causavam sobrecarga.

https://microservices.io/patterns/refactoring/strangler-application.html

Impacto na performance e manutenção

Desde que comecei a aplicar o Strangler Pattern, já percebi várias melhorias:

Performance: A separação das partes críticas para novos serviços mais eficientes reduziu gargalos e melhorou o tempo de resposta do sistema.
Manutenção: A modularização tornou o código mais organizado, facilitando a identificação e correção de problemas, além de reduzir o risco de criar novos bugs ao fazer alterações.
Novas Funcionalidades: Implementar novos recursos ficou muito mais rápido e menos arriscado, já que agora o sistema é mais modular e estável.

Um processo contínuo

Estou no meio dessa jornada de modernização, e o Strangler Pattern tem se mostrado uma abordagem muito eficaz. A transição está acontecendo de forma gradual, o que me permite focar nas partes mais problemáticas e resolver os problemas de forma eficiente, sem grandes interrupções.

Se você também está enfrentando o desafio da entropia de software e está procurando uma forma de modernizar seu sistema, o Strangler Pattern pode ser uma excelente escolha. Ele permite refatorar e melhorar gradualmente o sistema, sem riscos significativos de uma interrupção drástica, e ajuda a deixar o sistema mais escalável, eficiente e fácil de manter.

Conclusão

Modernizar sistemas pode ser um desafio, mas com a abordagem certa, como o Strangler Pattern, é possível realizar essa transição de forma incremental e obter resultados significativos. No meu caso, essa abordagem foi a chave para transformar uma plataforma antiga em algo mais ágil, escalável e muito mais fácil de manter.

Referências

https://microservices.io/patterns/refactoring/strangler-application.html

https://blog.chatbotslife.com/software-entropy-explained-causes-effects-and-remedies-baada6ae083b

https://martinfowler.com/bliki/StranglerFigApplication.html

Containers vs. Serveless

Felipe Freitas — Wed, 13 Oct 2021 20:02:01 +0000

O que são containers

Um contêiner é um pacote leve, autônomo e executável de um software que inclui tudo o que é necessário para executá-lo: código, tempo de execução, ferramentas do sistema, bibliotecas do sistema e configurações. Eles podem ser executados em qualquer lugar em um único pacote, de forma rápida, consistente e confiável, independentemente do ambiente de implantação.

Como os contêineres compartilham recursos do sistema com o servidor host em vez de emular um sistema operacional virtual, eles são mais eficientes do que as máquinas virtuais. Ao isolar um aplicativo do ambiente de host externo, os contêineres permitem a implantação de aplicativos sem conflitos.

Os contêineres corrigem o problema de execução do software quando ele é movido de um único ambiente de computação, essencialmente, isolando-o do ambiente, possibilitando mover aplicativos em contêineres facilmente entre hosts.

Qualquer tipo de aplicativo pode ser executado em um contêiner. Um aplicativo em contêiner será executado da mesma maneira, não importa onde esteja hospedado. Os contêineres podem ser facilmente movidos e implantados onde necessário independentemente de seu conteúdo.

O que é serveless

Serveless não significa que não haja servidores envolvidos. Serverless é um serviço de computação baseado em nuvem e, assim como tudo na nuvem, ele é executado em servidores. Portanto, sua experiência é sem servidor, mesmo que a infraestrutura subjacente não seja.

Serveless é uma arquitetura de execução na qual o código do aplicativo é executado sob demanda. Da perspectiva do usuário, o único trabalho necessário para executar o código é carregá-lo e acionar quando ele deve ser executado. É por isso que é chamado de sem servidor - não há servidor para manter.

Os aplicativos serveless são hospedados por um fornecedor terceirizado que cobra apenas com base no tempo de execução de cada função. O provedor de nuvem gerencia dinamicamente a alocação de recursos da máquina. Serverless permite escrever e implantar código sem o incômodo de gerenciar a infraestrutura subjacente, o que aumenta a produtividade do desenvolvedor. Você está abstraindo totalmente a infraestrutura.

Todo o aplicativo ou parte de um aplicativo é dividido em várias funções, cada uma das quais é acionada em resposta a um evento como uma solicitação HTTP, a chegada de uma nova mensagem na fila de mensagens ou o salvamento ou modificação de um novo objeto no armazenamento. É possível executar essas funções em um determinado momento ou periodicamente, um recurso que é útil para tarefas cron.

Serveless é ótimo se você tiver picos repentinos de tráfego que precisam ser detectados e tratados instantaneamente. O aplicativo é totalmente encerrado se não houver tráfego. Você paga apenas pelos recursos que usa. Sem uso, sem custos.

Serveless é muito adequada para uma variedade de tarefas, mas está longe de ser um substituto completo para implantar e gerenciar seus próprios contêineres. Serveless é projetado para funcionar em conjunto com os contêineres, em vez de substituí-los.

O que essas tecnologias tem em comum?

Permitem que os desenvolvedores se concentrem em seu código em vez de na infraestrutura. Isso aumenta a velocidade de desenvolvimento.

Ambos são perfeitamente adequados para microsserviços e arquiteturas baseadas em componentes. Ao usá-los, a implantação e o escalonamento costumam ser mais rápidos e econômicos do que na arquitetura monolítica clássica, porque você está manipulando pequenas partes do aplicativo em vez de tudo.

Apesar dessas semelhanças, cada tecnologia tem suas próprias vantagens, desvantagens e casos de uso.

Prós Containers

A principal vantagem de um contêiner é que você pode combinar o aplicativo e todas as suas dependências em um pequeno pacote organizado e executá-lo em qualquer lugar. Isso fornece um nível sem precedentes de flexibilidade e portabilidade e permite que você continue sendo um provedor agnóstico baseado em nuvem.
Os contêineres podem ser executados em qualquer servidor Linux moderno, bem como em certas versões do Windows.
As soluções baseadas em contêiner podem ser facilmente transferidas entre provedores de nuvem.
Você pode configurar seu próprio ambiente de host local ou usar um serviço de nuvem pública como ECS.
Você pode colocar em contêineres um aplicativo escrito em qualquer tipo de linguagem.
Os contêineres podem funcionar pelo tempo que você precisar.
No ecossistema de containers, existem ferramentas abrangentes para a análise de containers.
Você pode gerenciar todos os recursos, definir todas as políticas, monitorar a segurança e determinar como seu aplicativo é implementado e como se comporta. Você pode depurar e monitorar como quiser. Este não é o caso do serveless pois tudo é gerenciado pelo seu provedor de nuvem.
Os contêineres de sua equipe terão o mesmo ambiente de desenvolvimento, independentemente do sistema operacional usado. Isso torna incrivelmente fácil para equipes maiores serem eficientes.
Crucial para qualquer aplicativo empresarial, os contêineres permitem testes e depuração abrangentes, bem como monitoramento de desempenho. Os microserviços podem ser ajustados para atender aos requisitos de desempenho do sistema subjacente. Com total controle sobre o ambiente do contêiner, vem todo o poder para observar o que acontece dentro e fora dos contêineres. Isso permite depuração e teste eficazes e abrangentes, usando uma gama completa de recursos, bem como monitoramento de desempenho em profundidade em todos os níveis.
A tecnologia de contêiner permite que você torne seus aplicativos tão grandes quanto desejar.

Contra Containers

Você precisa saber mais sobre o ambiente e os diferentes recursos ao seu alcance. É uma curva de aprendizado íngreme para todos, porque basicamente você é quem implanta e gerencia o programa.
Usar contêineres significa que você não terá escalonamento automático. É algo que você precisa configurar sozinho. Felizmente, ferramentas específicas do fornecedor, como AWS Auto Scaling, tornam isso mais fácil.
Os contêineres também podem ser dimensionados de acordo com a demanda. Em contraste com o serveless, o dimensionamento do contêiner é de responsabilidade do usuário.
O Kubernetes normalmente é escalonado de acordo com o uso de CPU ou memória. Em arquiteturas baseadas em eventos, o Kubernetes costuma reagir tarde demais, pois o número de mensagens pendentes na fila não afeta o escalonamento. Esse problema pode ser contornada com um sistema de observabilidade das filas e ativando triggers para escalonar um serviço.

Prós Serveless

Você nunca paga pelo tempo ocioso de suas funções, portanto, se não houver tráfego, não haverá cobrança na sua fatura mensal. Quase todos os provedores sem servidor têm níveis gratuitos, que incluem uma quantidade fixa mensal de solicitações e tempo de execução. Normalmente, o volume fornecido é mais do que suficiente para que um pequeno site ou startup opere gratuitamente.
A escalabilidade é o ponto forte do serverless. As funções sem servidor são dimensionadas automaticamente conforme necessário de acordo com a demanda, sendo que o dimensionamento é realizado inteiramente pelos provedores de nuvem. Isso economiza esforço administrativo e reduz a complexidade.
As tecnologias serveless podem ser escalonadas de zero à carga de pico. Para um grande número de eventos, o provedor de nuvem garante que as funções serveless sejam dimensionadas rapidamente para lidar com os eventos. Isso torna os aplicativos serveless particularmente adequados para arquiteturas baseadas em eventos e aplicativos de negócios com picos de carga.
Você não precisa gerenciar nenhuma infraestrutura. Não há atualizações do sistema operacional para instalar, nem patches de segurança, o provedor cuida disso para você.
Ajudam a reduzir o tempo de desenvolvimento e a colocar seus produtos no mercado com mais rapidez. Se você não tem que se concentrar em sua infraestrutura, então você pode gastar seu tempo construindo o melhor produto possível.

Contra Serveless

O serverless é executado em plataformas de host específicas, muitas das quais são baseadas na nuvem pública (como AWS Lambda ou Azure Functions).
As estruturas serveless suportam um número limitado de linguagens que variam de plataforma para plataforma.
A maioria das plataformas serveless são projetada para suportar cargas de trabalho stateless. No entanto você pode se conectar a serviços de armazenamento externo (como S3 no AWS), as funções (Lambdas) em si não podem ter estado. Isso traz novos requisitos de segurança para os dados.
As funções serveless são projetadas para serem executadas por um curto período antes de serem encerradas.
Não podem ser migradas facilmente entre provedores de nuvem. Isso se deve à implementação específica do provedor de nuvem de produtos sem servidor, como AWS Lambda e Azure Functions. Por exemplo, para migrar uma função AWS Lambda para uma função do Azure, os gatilhos (por exemplo, gatilhos HTTP, gatilhos de fila, gatilhos de banco de dados) teriam que ser reescritos.
Como os servidores permanecem frios antes que um aplicativo faça ping neles, há uma certa latência envolvida na execução de tarefas. Para aplicativos em que a velocidade é fundamental, como e-commerce e páginas de pesquisa, o serveless pode não ser a solução ideal.
O tempo de execução é gerenciado pelo provedor de nuvem, o que representa desafios adicionais na análise de desempenho. Sem a capacidade de instalar agentes para recuperar métricas diretamente do tempo de execução, deve-se confiar totalmente nos recursos das plataformas em nuvem.
Aplicativos complexos podem ser difíceis de construir usando uma arquitetura serveless. Você terá que fazer muita coordenação e gerenciar dependências entre todas as funções sem servidor, o que pode ser uma tarefa difícil para aplicativos grandes e complicados.
Observabilidade, monitoramento e depuração não são fáceis de fazer com a abordagem serveless.

Casos de uso serveless vs. contêiner

Os contêineres são ideais para situações em que você precisa:

Suportar aplicativos mais complexos e de longa execução, onde você precisa de um alto nível de controle ambiental e tem os recursos para configurar e manter o aplicativo.
Manter a paridade do ambiente à medida que o código do sistema desce na cadeia de entrega (CI/CD).
Mover aplicativos rapidamente entre diferentes servidores host.
Manter a capacidade de mover cargas de trabalho entre o local e a nuvem.
Disponibilizar serviços de forma contínua.
Quando precisar de flexibilidade e controle total do seu sistema ou quando precisar migrar serviços legados.
Construir uma solução que interaja com fornecedores e/ou bibliotecas terceiras, que dependam de diferentes protocolos ou exija linguagens específicas para desenvolvimento.
São perfeitos para um aplicativo ou um grande site de comércio eletrônico. Um site como este contém muitas partes, como listas de produtos, processamento de pagamentos, gerenciamento de estoque e muito mais. Você pode usar contêineres para empacotar qualquer um desses serviços sem se preocupar com limites de tempo ou problemas de memória.

Enquanto isso, serveless é ótimo quando você deseja:

Quando você precisa de velocidade de desenvolvimento mais rápida, escalonamento automático e custos de tempo de execução drasticamente menores.
Executar o código que consome muitos recursos rapidamente, de forma pontual.
Executar quantidades finitas de código de aplicativo na nuvem sem ter que configurar um servidor virtual ou pagar por recursos de nuvem contínuos.
Serveless é melhor usado para aplicativos que precisam ser capazes de realizar tarefas, mas não necessariamente precisam ser executados. Por exemplo, serveless é uma ótima opção para um aplicativo de Internet das Coisas (IoT) que detecta a presença de água para detectar vazamentos em uma instalação de armazenamento de água. O aplicativo não precisa ser executado o tempo todo, mas precisa estar pronto para agir em caso de vazamento.

Como pode ser observado, ambas estruturas possuem fortes pontos positivos e são totalmente complementares permitindo que arquiteturas possam utilizar o melhor dos dois mundos, coexistindo serverless e containeres na solução de diferentes problemas computacionais