Tecnologia sem servidor ou Kubernetes na AWS

Muitos clientes da AWS adotam como padrão tecnologias de código aberto que são amplamente suportadas. O código aberto pode permitir que uma organização encontre as competências certas e evitar alguns riscos relacionados ao aprisionamento tecnológico. Fazer as escolhas erradas em um ecossistema de código aberto pode levar ao bloqueio em abstrações e integrações locais. Além disso, a responsabilidade de fazer com que diferentes componentes de código aberto funcionem juntos geralmente cabe à organização responsável pela escolha. É comum que as organizações gastem muito tempo mantendo integrações de código aberto.

Observações:

• Considere fontes da comunidade e o apoio de empresas ou fundações ao realizar esses investimentos. Os investimentos nesses projetos não são apenas financeiros. Você também precisa investir no treinamento e na educação de sua equipe sobre as tecnologias usadas. 
• E talvez você incorra em algumas dívidas técnicas (devido ao trabalho envolvido na manutenção dessas integrações), pois esses componentes e as integrações associadas normalmente precisarão ser atualizados.
  
• Visite o Blog de código aberto da AWS para obter ideias sobre implementações de código aberto.
  

Ao selecionar uma estratégia moderna de desenvolvimento de aplicações, é importante que ela acomode toda uma variedade de padrões de workload. Ao entender seus padrões de workload, você pode fazer escolhas de arquitetura de forma mais fácil. Por exemplo, aplicações Web, microsserviços baseados em API, aplicações orientadas a eventos, streaming e mensagens, pipelines de dados, automações de TI e muito mais. Algumas workloads terão performance melhor ou serão mais econômicas em um ambiente computacional do que em outro tipo de ambiente.

Para o desenvolvimento com o AWS Serverless, serviços como o App Runner e o AWS Batch foram projetados para acomodar prontamente as demandas de um determinado tipo de workload. As workloads que usam essa abordagem serão mais fáceis de desenvolver, apresentarão melhor performance ou serão economicamente mais eficientes, embora isso ocorra às custas da flexibilidade.

O Kubernetes fornece consistência em ambientes na nuvens e on-premises, se exigido pela sua organização.

As workloads não vivem isoladamente. Elas são sustentadas por tecnologias como bancos de dados, mensagens, streaming, orquestração e outros serviços. Uma estratégia eficaz de desenvolvimento de aplicações modernas requer integração com esses serviços. As integrações gerenciadas simplificam tanto as despesas gerais de operação quanto o gerenciamento da infraestrutura subjacente.

As opções do AWS Serverless estão profundamente integradas ao ecossistema da AWS. O AWS Lambda pode se inscrever em eventos de mais de 200 outros serviços. As extensões do AWS Lambda, por exemplo, permitem a integração com ferramentas de monitoramento, observabilidade, segurança e governança. O Lambda invoca uma determinada função em um ambiente de execução, o qual fornece um runtime seguro e isolado em que o código da função é executado. 

As ofertas gerenciadas pela AWS para Kubernetes fornecem integrações com ofertas gerenciadas. O próprio Kubernetes possui um rico ecossistema de parceiros, oferecendo integração com várias outras tecnologias.

Muitos clientes precisam criar experimentos para validar ideias. Esses protótipos podem ser a ideia para uma nova aplicação e/ou ser descartados se não forem bem-sucedidos. A capacidade de fornecer um ambiente em que você possa escrever, implantar e validar ideias rapidamente é essencial para um ambiente saudável. Esse ambiente geralmente é deixado de lado durante a criação de uma estratégia moderna de desenvolvimento de aplicações, mas a capacidade de inovar dentro da empresa pode depender dele. Permitir que as equipes usem serviços que podem ser utilizados para criar, testar e iterar rapidamente é inestimável para a descoberta de novas oportunidades de negócios.

Muitos clientes querem garantir que suas aplicações possam ser executadas e facilmente migradas ou movidas para um ambiente diferente. Eles querem poder preservar a opção de migrar provedores de nuvem ou executar uma aplicação on-premises e na nuvem. Isso geralmente inclui a necessidade de oferecer suporte a estruturas de linguagem e cenários de desenvolvimento populares. Por exemplo, desenvolvedores de Java podem querer usar Spring ou Python, enquanto engenheiros de dados talvez queiram usar PyTorch. Selecionar uma abordagem moderna ao desenvolvimento de aplicações não será suficiente por si só. Isso exigirá o uso de práticas recomendadas e de uma arquitetura para alcançar a portabilidade das aplicações. Recomendamos desenvolver competências em arquiteturas de software e criar pacotes que permitam portar com mais facilidade a lógica de negócios diferenciadora entre serviços de computação.

As aplicações criadas com algumas tecnologias podem ser executadas com mais eficiência em alguns serviços de computação do que em outros. Os serviços de contêiner geralmente são um alvo de migração melhor para aplicações antigas do que o Lambda, que exigiria uma mudança na arquitetura.

Deve haver uma diferença clara entre portabilidade de aplicações e automação. Na maioria das vezes, a escolha entre o AWS Serverless ou o AWS Kubernetes tem pouco a ver com o fato de uma aplicação ser portátil ou não. Em vez disso, as ferramentas usadas pelas equipes de infraestrutura e pelas equipes de DevOps é que são um fator-chave. Os clientes que escolhem a abordagem do Kubernetes na AWS geralmente buscam portabilidade de infraestrutura e ferramentas de implantação.

As competências da sua organização são um fator importante na decisão de adotar uma abordagem de tecnologia sem servidor ou baseada em contêiner para o desenvolvimento de aplicações modernas. Tanto os sistemas com tecnologia sem servidor quanto os contêineres exigirão algum investimento nas equipes de DevOps e engenharia de confiabilidade do site (SRE). A criação de um pipeline automatizado para implantar aplicações é comum na maioria das aplicações modernas.

Algumas opções elevam a quantidade de gerenciamento. Por exemplo, algumas organizações têm as competências e os recursos necessários para executar e gerenciar uma implementação do Kubernetes porque investem em equipes de SRE fortes para gerenciar clusters do Kubernetes. Essas equipes lidam com atualizações de cluster frequentes (por exemplo, o Kubernetes disponibiliza três lançamentos importantes por ano e descontinua as versões antigas).

O tamanho da organização é um fator-chave, pois startups menores podem ter uma pequena equipe de TI composta por pessoas que desempenham várias funções, enquanto empresas maiores podem comportar centenas de workloads na produção ao mesmo tempo.

As decisões de arquitetura trazem vantagens e desvantagens, e uma delas geralmente é o custo. É comum ter dificuldade para estimar o custo de aplicações modernas devido à natureza dinâmica dos componentes envolvidos. Embora seja mais fácil estimar o custo de um conjunto fixo de servidores, você também paga por esses servidores mesmo quando eles não agregam valor comercial.

Ambas as abordagens oferecem várias formas de atingir as metas de custo para suas workloads. A escolha de alto nível entre as abordagens deve considerar o custo não apenas dos recursos, mas também do esforço na criação e na manutenção dessa estratégia. A Calculadora de Preços da AWS pode ser útil para entender os custos de uma determinada workload.

A criação com o AWS Serverless e o Kubernetes na AWS permite que criar workloads eficientes, escaláveis e resilientes. Assim, você pode atender aos requisitos técnicos necessários. Os serviços com os mais altos níveis de abstração gerenciam o posicionamento nas zonas de disponibilidade da AWS e a escalabilidade do ambiente, melhorando a performance e a resiliência. Níveis mais baixos de abstração permitem que você tenha mais controle sobre como sua workload é escalada. As principais desvantagens são custos e complexidade do gerenciamento.