- A Figma transferiu seus principais serviços, que já eram conteinerizados, do ECS para Kubernetes baseado em EKS, com o objetivo de reduzir limitações de longo prazo da plataforma sem downtime
- No ECS, a ausência de StatefulSets, a dificuldade de operar OSS baseado em Helm charts e as restrições de isolamento de nós eram grandes obstáculos; o Kubernetes abriu opções como o ecossistema CNCF, Keda, Karpenter e Istio
- A migração reduziu o escopo mantendo as abstrações de execução, deploy e ferramentas dos serviços, mudando apenas a orquestração; definições de serviço baseadas em Bazel e a configuração de 3 clusters EKS foram incluídas no escopo inicial
- Durante a transição, a Figma garantiu possibilidade de rollback por meio de testes de carga, migração gradual de tráfego com Weighted DNS, migração antecipada de serviços reais, ocultação de YAML bruto e colaboração com os donos dos serviços
- Até janeiro de 2024, a maioria dos serviços de maior prioridade havia sido migrada para EKS; depois de reduzir custos de superprovisionamento, aumentar a confiabilidade e melhorar a experiência de desenvolvimento, a empresa continuou com logging, autoscaling e migração para Graviton
Por que sair do ECS para Kubernetes
- No início de 2023, a Figma já executava todos os seus serviços em contêineres e usava o AWS Elastic Container Service (ECS) como plataforma de orquestração
- Ao avaliar a próxima geração da plataforma de computação, a empresa concluiu que continuar construindo em cima do ECS dificultaria, no longo prazo, criar os recursos desejados
- A Figma não era uma empresa que operava milhares de microsserviços, então o escopo da migração para Kubernetes podia ser gerenciado de forma realista
- Havia casos em que um novo serviço era necessário por isolamento ou desempenho, mas os serviços centrais forneciam modularização básica e isolamento de tráfego
- Mesmo novos produtos muitas vezes eram suportados adicionando lógica dentro dos serviços centrais existentes, em vez de criar novos serviços
Funcionalidades que faltavam no ECS
- O ECS não oferece suporte aos StatefulSets do Kubernetes, o que tornava difícil operar armazenamentos de dados de consenso com consistência forte, como o etcd
- A Figma contornava isso com código customizado que atualizava dinamicamente a associação ao cluster no momento em que o contêiner do etcd era iniciado
- Essa abordagem era frágil e difícil de manter; no Kubernetes, é comum usar a atribuição de rede com estado dos StatefulSets
- No ECS, era difícil executar conjuntos de serviços definidos por Helm charts
- No ECS on EC2, encerrar de forma elegante uma única máquina EC2 problemática também era trabalhoso
- No EKS, ao aplicar cordon em um nó ruim, o servidor de API respeita o procedimento de encerramento e pode mover os Pods para outras máquinas
Ecossistema CNCF e escolha da plataforma
- Continuar usando ECS dificultaria aproveitar tecnologias open source do ecossistema da Cloud Native Computing Foundation (CNCF)
- Autoscaling era uma preocupação importante para a próxima geração da plataforma de computação
- Na época, a Figma não aplicava autoscaling aos serviços conteinerizados
- Mesmo em horários de baixo tráfego, como noites e fins de semana, os serviços eram provisionados para suportar carga de pico, gerando custos desnecessários
- O Keda no ecossistema Kubernetes oferece suporte a scaling com base não só no uso de CPU, mas também no tamanho de filas do AWS SQS e em métricas customizadas do Datadog
- Um service mesh também poderia ser necessário no longo prazo
- O tráfego entre serviços existente era roteado por AWS Application Load Balancers (ALB) e Network Load Balancers (NLB)
- O NLB levava alguns minutos para registrar novos targets e remover targets existentes, o que reduzia a velocidade de deploys emergenciais e aumentava o tempo médio de recuperação de incidentes
- O Envoy oferece maior capacidade de customização e execução de filtros customizados
- A Figma já mantinha um cluster separado de máquinas Envoy como proxy na frente dos principais serviços e havia usado filtros customizados para reduzir carga durante incidentes
- No EKS há muitas opções open source, como Istio, mas no ECS seria necessário recriar funcionalidades semelhantes internamente
Vantagens operacionais de uma plataforma popular
- A Figma não quer ser a maior usuária de nenhum serviço ou software
- Os maiores usuários tendem a esbarrar primeiro nas arestas não polidas e nos limites de escala
- Kubernetes é usado por muitas grandes empresas em plataformas de computação enormes, então a Figma está entre os usuários bem menores em comparação
- Kubernetes ajuda a reduzir o vendor lock-in
- O EKS oferece os benefícios de um control plane com suporte do fornecedor
- Como os serviços são escritos para rodar em Kubernetes comum, o esforço para migrar para outra plataforma Kubernetes com suporte de fornecedor ou para uma plataforma auto-hospedada não é grande
- É mais fácil contratar engenheiros com experiência em Kubernetes
- Engenheiros com experiência prévia podem se adaptar rapidamente e trazer contexto para áreas que poderiam ser decisões novas para a Figma
Princípios para definir o escopo da migração
- Em grandes migrações, é mais seguro substituir apenas o sistema central que se deseja mudar e preservar, tanto quanto possível, as abstrações visíveis aos usuários da plataforma
- A Figma restringiu o escopo a fazer os serviços rodarem no EKS em vez do ECS, sem mudar a forma de executar serviços, a forma de fazer deploys nem as ferramentas de interação entre serviços
- Mesmo trabalhos que não parecem mudanças funcionais podem gerar efeitos de segunda ordem, fazendo com que cronogramas de grandes migrações cresçam facilmente
- Havia duas exceções
- Quando fazer o novo sistema se comportar como o antigo exigisse trabalho adicional excessivo, a empresa poderia aceitar os efeitos de segunda ordem e adotar a nova abordagem
- Decisões de “one-way door”, difíceis ou caras de mudar depois, poderiam adotar a nova abordagem desde o início
Melhorias incluídas no escopo
-
Experiência de desenvolvimento
- As definições de serviço ECS existentes eram criadas e modificadas principalmente com Terraform
- Um apply do Terraform criava um template de ECS task set com 0 instâncias; depois, no processo de deploy, o template era clonado, o hash da imagem era substituído e um task set com número de instâncias diferente de 0 era implantado no ECS
- Mesmo para adicionar uma única variável de ambiente, era necessário escrever e aplicar Terraform e depois executar o deploy; se a ordem não fosse seguida, a variável de ambiente não poderia ser usada com segurança no código, causando bugs
- No EKS, a empresa passou a manter a definição do serviço em um só lugar e a implantar a mudança em uma única etapa
- A Figma criou uma abordagem interna simples para definir serviços com arquivos de configuração Bazel, gerando automaticamente o YAML de definição de serviço e YAMLs de configuração como Ingress
- O YAML é gerado por ferramentas de CI no momento do commit de código e aplicado por meio do sistema interno de deploy
-
Confiabilidade
- Para cada serviço, 3 clusters EKS foram configurados para executar Pods e receber tráfego
- Se todas as operações acontecerem no nível do cluster, uma falha total pode ser reduzida a um impacto de um terço do serviço
- Em serviços capazes de repetir requisições ou fazer processamento assíncrono, a interrupção para usuários muitas vezes é minimizada
- Essa configuração aumentou bastante a complexidade operacional, incluindo o pipeline de deploy, mas a empresa concluiu que valia a pena aplicá-la já no momento da migração, em vez de adicioná-la depois
-
Eficiência de custos
- Trabalhos complexos de otimização de custos não foram amplamente incluídos no escopo da migração, mas o autoscaling de nós recebeu suporte desde o início
- Nos serviços ECS on EC2, as máquinas eram superprovisionadas para lidar com picos durante deploys
- No EKS, a Figma usa o Karpenter para expandir e reduzir nós dinamicamente conforme a demanda
Trabalhos excluídos do escopo
- O pipeline de logging existente era complexo
- Todos os logs eram primeiro gravados no CloudWatch
- Uma Lambda lia os logs e realizava transformações como remover determinados padrões e adicionar tags
- Depois, os logs eram gravados no Datadog e no Snowflake
- O custo do CloudWatch como armazenamento intermediário vinha aumentando
- A Figma planejou adotar o projeto CNCF Vector, que poderia processar e encaminhar logs como sidecar na stack EKS
- Porém, a empresa concluiu que não valia a pena assumir o efeito de segunda ordem de portar a lógica do log forwarder para a configuração do Vector, e excluiu isso do escopo da migração
- Autoscaling em nível de Pod também não foi incluído na migração
- A complexidade foi considerada alta demais
- Foi visto como um trabalho que poderia ser adicionado facilmente depois
- Os trabalhos excluídos se tornaram iniciativas posteriores e puderam trazer melhorias em paralelo à migração de outros serviços para EKS
Forma segura de execução
- Como a stack ECS existente era relativamente estável, a nova stack EKS e o processo de migração precisavam ser pelo menos tão confiáveis quanto ela
-
Testes de carga
- A Figma criou um serviço “Hello, World” e o escalou para executar o mesmo número de Pods do maior serviço da Figma
- Esse teste revelou a necessidade de ajustar o tamanho e a escala dos principais serviços de computação que sustentavam toda a plataforma
- O Kyverno é uma ferramenta de validação de segurança de cluster e, se não for dimensionado em tamanho suficiente, pode atrasar a inicialização de novos Pods
-
Rollout gradual
- Entradas de Weighted DNS foram usadas para mover o tráfego aos poucos dos serviços ECS existentes para os serviços correspondentes no EKS
- Controle fino de transferência e reversão de tráfego era essencial para uma migração segura
- Impactos inesperados podem ocorrer em pontos de inflexão desconhecidos, então era necessário reduzir o escopo do impacto e conseguir fazer rollback rapidamente
-
Execução antecipada de serviços reais
- Ao colocar workloads reais no sistema, é possível aprender muitas coisas que apenas o staging não revela
- A Figma migrou um serviço primeiro, antes mesmo de terminar a construção do ambiente de staging
- Essa migração antecipada ajudou a validar de ponta a ponta a capacidade de executar workloads e a encontrar gargalos e bugs
-
Abstração de YAML
- Permitir que usuários definam serviços diretamente em YAML bruto do Kubernetes poderia ser confuso
- A Figma ofereceu aos usuários um golden path, permitindo customizações apenas em casos especiais
- Isso esclarece o que os usuários podem e devem customizar, ao mesmo tempo em que impõe consistência por padrão, simplificando manutenção e mudanças futuras
-
Colaboração com donos dos serviços e alocação de pessoas
- A configuração de novos serviços ficou a cargo da equipe de plataforma, enquanto atualizações de monitoramento e alertas foram feitas em estreita colaboração com os donos dos serviços, que conhecem melhor a saúde de cada serviço
- Antes mesmo do início da migração, as opções e trade-offs foram discutidos de forma suficiente com os donos dos serviços
- Migrações de grande escala podem gerar problemas inesperados, interações complexas e bugs comuns, exigindo uma equipe com profundo conhecimento técnico e capacidade de depuração
Cronograma real da migração e resultados
- No 1º trimestre de 2023, a Figma criou o plano e obteve aprovação para seguir com a migração
- No 2º trimestre de 2023, criou o ambiente de staging e migrou um único serviço
- No 3º trimestre de 2023, o foco foi produção, testes de carga e preparação para migrar serviços adicionais
- Do 4º trimestre de 2023 até a primeira semana de janeiro de 2024, o tráfego dos serviços foi transferido lentamente
- Até janeiro de 2024, a maioria dos serviços de maior prioridade havia sido migrada para os novos clusters EKS
- O monólito que contém a lógica central de negócio
- Um serviço complexo que lida com o aspecto multiplayer da edição de arquivos no Figma
- Os serviços que compõem o Livegraph 100x, que enviam atualizações em tempo real para todos os clientes
- Como resultado, a empresa reduziu custos de superprovisionamento para deploys, aumentou a confiabilidade com a execução em 3 clusters e melhorou a usabilidade para desenvolvedores
- O trabalho completo ocorreu com incidentes pequenos e baixo impacto para clientes
- Houve um incidente em que um operador executou por engano uma operação que destruiu e recriou o CoreDNS em um cluster de produção
- Na configuração anterior, isso teria sido uma indisponibilidade total
- Na configuração com 3 clusters, o impacto ficou limitado a um terço das requisições
- Como a maioria dos serviços downstream repetiu as requisições, elas acabaram tendo sucesso
Melhorias nas ferramentas após o lançamento
- A Figma criou ferramentas para que os donos dos serviços pudessem depurar o que acontece nos clusters
- Verificar o número de instâncias em execução
- Acessar o shell de contêineres
- Executar operações como scaling emergencial
- Logo após o lançamento, a empresa recebeu feedback de que essa ferramenta de acesso não era suficientemente amigável
- Havia duas fontes de complexidade
- Com a introdução dos 3 clusters, os usuários precisavam executar comandos em vários clusters e adicionar o nome do cluster a cada comando
- Ao usar funções do Kubernetes RBAC para oferecer permissões mais granulares, os usuários precisavam entender quais funções possuíam e qual função era necessária para determinada operação
- A Figma interrompeu imediatamente outros trabalhos e ajustou a ferramenta para inferir automaticamente o cluster e a função adequados
- Os usuários não precisam mais perder tempo procurando funções, especialmente em emergências no meio da noite
Próximos passos
- A Figma continua migrando os serviços restantes enquanto melhora a nova plataforma de computação em paralelo
- As áreas de foco atuais são:
- Simplificar o desenho do pipeline de logging
- Dar suporte a autoscaling horizontal de Pods via Keda
- Migrar os serviços de maior custo da Figma para processadores Graviton para reduzir custos e criar um caminho para que outros serviços também rodem em Graviton
- A empresa também planeja explorar áreas nas quais ainda não investiu profundamente
- Avaliar ofertas de service mesh para melhorar a confiabilidade e a observabilidade da stack de rede
- Gerenciar mais recursos com AWS Controllers for Kubernetes (ACKs) para reduzir a dependência de Terraform e simplificar e unificar a stack
- Colaborar com a equipe de experiência de desenvolvimento para unificar a forma de executar serviços no ambiente de desenvolvimento e em outros ambientes
1 comentários
Comentários no Hacker News
Pessoalmente, gosto de Kubernetes. Opero várias lojas virtuais personalizadas pequenas, mas complexas, e também cuido de marketing, finanças e suporte ao cliente
Antes eu rodava tudo em servidores dedicados, mas a stack era bem complexa, então o deploy era um pesadelo, e no fim o peso dos deploys estava desacelerando uma empresa pequena
Levei um mês para aprender Kubernetes e migrar, e hoje opero cerca de 25 serviços, incluindo frontend, gestor de produtos, dashboard de logística, otimização de rotas de entrega, OSRM, ERP, mecanismo de recomendação, busca etc.
Ao centralizar a configuração do cluster em um só lugar, consegui organizar tudo em uma estrutura reproduzível e passei a saber exatamente o estado de cada serviço e qual versão estava em execução. Também passei a poder fazer rolling deploys sem indisponibilidade; é complexo, mas programadores lidam com coisas complexas por natureza. Arquivos de configuração do Nginx também são complexos
Quanto mais se aprofunda, mais se entende por que a arquitetura do Kubernetes faz sentido, e ele força você a seguir os 12-factor à risca. Se sua receita está diretamente ligada à disponibilidade e à estabilidade da stack, alta disponibilidade é mais do que só “algo bom de ter”. O custo de hospedagem também fica em torno de US$ 400 por mês, então não é tão caro
Eu tendo a confiar em Kubernetes, mas ele realmente é muito complexo. É uma ferramenta que resolve problemas difíceis. Se for multi-cloud, nem tem muito o que pensar, e se você quer uma infraestrutura complexa com correspondência 1:1 com o ambiente local, ele encaixa bem
Mas, se você tem menos de 100 desenvolvedores e só vai fazer deploy de contêineres na AWS, usar EKS em vez de ECS + Fargate em 2024 me parece insanidade
A migração em si para melhorar a base da infraestrutura é boa. Só achei curioso que uma das motivações era fazer os times usarem charts do Helm em vez de converter para Terraform
Na prática, raramente vejo alguém usar um chart Helm arbitrário de forma estável sem modificações, e, se você incentiva o uso, no fim os times acabam dando fork no chart e alterando tudo. Helm é uma ferramenta tão terrível que eu não gostaria de manter meus próprios charts Helm personalizados
Eu preferiria reescrever em Terraform, porque manter uma versão local me parece mais fácil. Se houver contraexemplos, gostaria de ouvir. Talvez hoje em dia a loucura do
indent 4do Helm e o problema de templates de string em múltiplas camadas já tenham desaparecidoDá para gerenciar workloads do Kubernetes com Terraform, mas eu não recomendaria. O próprio Kubernetes já tem estado, e quando o Terraform também tem estado, a combinação Terraform + Kubernetes vira sofrimento. Helm foi feito para Kubernetes; Terraform não
Isso não quer dizer que eu goste do Helm. YAML com template não é grande coisa, e a loucura do
indent 4continua aí. Kustomize é bom quando é simples, mas, quando o app fica complexo, acho pior que Helm. Por exemplo, para fazer deploy de um app com Ingress, certificado TLS e external-dns em vários ambientes, algo que poderia ser resolvido usando uma variável em três lugares acaba exigindo aplicar patch em três recursosHelm e Terraform são muito populares e por isso aparecem o tempo todo, mas no fim acho que vai surgir alguma ferramenta ainda não popularizada para substituir os dois
O problema do Terraform é que você precisa desenhar os workspaces para não ultrapassar o número recomendado de recursos por workspace, algo em torno de 100 a 200. Caso contrário, o plan fica muito lento porque passa a verificar bancos de dados e redes que você nem tocou nem pretende tocar, aumentando o tempo de deploy
Na prática, você acaba criando uma malha de workspaces do Terraform que disparam uns aos outros, e hoje não existe uma boa ferramenta open source que dê suporte adequado a isso
Pelo que vejo agora, o melhor é o Terraform instalar, como parte da infraestrutura, uma ferramenta de entrega contínua como o ArgoCD, e deixar os deploys do dia a dia a cargo da ferramenta de CD. E a maioria das ferramentas de CD exige que os deploys sejam empacotados com algo como Helm
Mas tem pegadinhas demais, então acabo gastando tempo refazendo e depurando o trabalho feito por outros engenheiros
Espero que a nova ferramenta
timoniganhe tração. Ela resolve quase todas as reclamações que tenho sobre Helm. Se você está procurando uma solução melhor, vale a pena dar uma olhada no timoniNós optamos por usar os charts Helm públicos como estão e fazer as customizações com
kustomize —enable-helmNo nosso caso, temos um chart Helm baseado em uma única aplicação/serviço, com padrões razoáveis, e todos os deploys estendem isso. Do lado de quem usa, a configuração necessária de Helm values é mínima, e quase nunca precisamos inserir nossos próprios templates, porque o chart base expõe pontos de ajuste suficientes
Conseguimos fazer deploy de uma boa parte dos charts de terceiros sem alterações, e às vezes adicionávamos a funcionalidade necessária via PR no upstream. Raramente precisávamos encapsular ou dar fork, e o número de charts de terceiros que usamos sem mudanças foi muito maior
Ao manter charts customizados, o helm unittest (https://github.com/helm-unittest/helm-unittest) ajuda bastante a evitar regressões
Nós até gerenciamos alguns recursos de Kubernetes, incluindo o ArgoCD, com Terraform, mas, em geral, fazer deploy de charts Helm via ArgoCD foi muito mais fácil de gerenciar e mais produtivo
Acho curioso haver tanto sentimento anti-Kubernetes no HN. Fico pensando se é porque a maioria de quem comenta é desenvolvedor acostumado com serviços como Heroku, fly.io e render.com, ou porque roda apps em VM
Isso não é um problema limitado a casos específicos, mas algo causado por incentivos profundamente desalinhados em toda a indústria, junto com uma espécie de corrida do ouro da era dos juros baixos
Sinceramente, do jeito que está hoje, em outras áreas isso pareceria um artesanato bem inútil. Há uma obsessão pouco saudável com ferramentas e meta-trabalho, enquanto o uso racional de recursos continua sendo jogado pela janela só para usar certas ferramentas. É uma espécie de situação de “engenheiro da FAANG temporariamente em dificuldade”
É difícil explicar quanto mais tempo leva, quanta especialização a mais exige, quanto mais frágil fica e quanto mais dinheiro custa construir em cima de Kubernetes em vez de usar os modelos de deploy disponíveis na AWS, como imagens de VM no EC2, Elastic Beanstalk, ECS/Fargate ou Lambda
Não quero instalar nem manter uma stack ELK ou Prometheus por conta própria. Também não quero lidar com plugin de CNI, Kafka, Postgres de alta disponibilidade, Argo, Helm e upgrades do control plane. Com os serviços equivalentes da AWS, dá para começar quase imediatamente, com manutenção praticamente zero, e os custos normalmente começam de forma linear a partir de algo próximo de zero
Dá para resolver problemas de negócio muito mais rápido e com muito mais eficiência. É a diferença entre superar muito as expectativas e fazer o time inteiro ficar atrasado por vários trimestres
Dito isso, se houver uma necessidade real de multicloud ou on-premises, eu não gostaria de usar outra coisa além de Kubernetes. Numa empresa grande com muitos engenheiros experientes que entendem Kubernetes, talvez isso nem seja tão ruim. Pelo menos nos lugares onde trabalhei, não era o caso
É bom ver empresas migrando principalmente para infraestrutura open source. Uma boa parte disso vem da CNCF (https://landscape.cncf.io), da ASF e de vários projetos no GitHub
Talvez o kata-containers resolva essa preocupação e me faça gostar de Kubernetes
No geral, Kubernetes não tem nada que eu pessoalmente ache muito legal. Contêineres, load balancer e YAML de megabytes eu já vi de sobra, e não parece algo interessante o suficiente para eu querer experimentar
Numa empresa desse tamanho isso talvez seja normal, mas é difícil acompanhar a tomada de decisão em migrações enormes ou projetos técnicos desse tipo. Porque não parece que a decisão surgiu de uma necessidade dos usuários ou da empresa
Tive a mesma sensação num texto parecido que a Figma publicou antes sobre banco de dados
Por exemplo, se a razão para querer ir para Kubernetes é que no ECS não dá para usar etcd/Helm, então a primeira pergunta deveria ser por que vocês querem usar etcd/Helm. Isso é realmente tão importante assim? Essa é mesmo exatamente a única forma de atingir os objetivos da empresa?
Quando a decisão se baseia nos desejos dos usuários, fica mais fácil verificar se as decisões subordinadas fazem sentido; mas quando se baseia em desejos técnicos, essas decisões subordinadas podem parecer plausíveis dentro do contexto técnico e, ainda assim, continuar incertas no contexto do usuário
Parece ser uma de duas coisas: ou eu não entendo organizações desse tamanho, ou é fundamentalmente difícil para organizações desse tamanho identificar e raciocinar sobre o que é valioso
Nós somos essencialmente um time de plataforma, e muitas vezes fazemos ferramentas para outros times de plataforma que criam ferramentas para apoiar os desenvolvedores da Figma que constroem a experiência real do produto. Quanto mais longe do usuário final, mais difícil fica inferir quais são as decisões corretas, mas ao mesmo tempo maior é a alavancagem
Se você constrói a plataforma direito, isso afeta a capacidade de todos os outros engenheiros de trabalhar com eficiência e eficácia. Grande parte desse impacto é indireta
Certamente havia a opção de dizer que, como não era possível dar suporte a etcd e Helm, eles deveriam encontrar outra solução alternativa. Mas esses dois também foram pontos de dados adicionais que nos empurraram para a conclusão de que estávamos operando a plataforma de Compute sobre blocos fundamentais errados
Mesmo que seja difícil raciocinar sobre isso, vale muito a pena tentar fazer bem. Porque, como time de plataforma, é assim que garantimos que estamos fazendo a coisa certa para chegar à melhor plataforma possível. Foi por isso que passamos muito tempo tomando essa decisão e achamos que era um tema interessante para escrever
É bem provável que boa parte das migrações de grandes empresas para Kubernetes seja motivada pelo desejo de multicloud ou híbrido com on-premises, além de mitigação de custos, disponibilidade e risco de lock-in
É preciso manter alinhados upgrades de VM, autenticação, backups, rotação de logs e tudo mais
No Kubernetes, você dá a cada um seu namespace, políticas e volumes, e com DaemonSet e uma stack Kubernetes/cloud-native dá até para ter agregação automática de logs
Também existe self-healing, entre outras coisas, e é difícil até explicar o quanto melhora
Por exemplo, quase não há armazenamentos de dados altamente disponíveis e consistentes que possam servir como equivalente a um arquivo
.pidem ambiente distribuído. O único que me vem à cabeça é o Zookeeper, mas ele é realmente doloroso de operar, exige versões antigas da JVM e, ainda assim, no geral é instávelA parte em que, quando o código do Terraform era aplicado, era criado um
task setdo ECS com 0 instâncias para subir um template de serviço e, depois, o desenvolvedor precisava duplicar essetask setde template ao implantar o serviço e fazer vários passos manuais, parece menos um problema do ECS e mais algo que tornou o Terraform + o modelo de gestão de deploy no ECS excessivamente complexoEntendo a parte de criar um template para validar antes do deploy real. Mas isso é um pouco discutível
Por isso classifiquei deliberadamente este item como um trabalho incluído no processo de migração, e não como um motivo fundamental para iniciar a migração
Ainda assim, dá para imaginar alguns cenários em que esse modelo passa a ser necessário. Por exemplo, quando há muitos serviços implantados no ECS e o tamanho do estado do Terraform cresce. Aí
planeapplyficam muito mais lentos, e pode ser bem mais seguro fragmentar o estado do Terraform replicando a configuração com base em templatesEra basicamente adicionar variáveis de ambiente ao arquivo do Terraform, fazer o merge e deixar o CI implantar. A maior parte das mudanças de configuração que fazíamos era tratada por esse processo
“Migrar para Kubernetes pode levar anos”, mas afinal o que estou lendo?
Para quem isso seria verdade? Também não entendo muito bem por que as empresas fazem esse tipo de migração em primeiro lugar. Onde está o valor de negócio e qual é o benefício para o cliente? É um projeto de “arte pela arte” porque a Figma pode fazer isso?
Mesmo em uma empresa muito estabelecida, com cerca de 30 anos de história e toda a bagagem que vem com isso, fizemos a migração para Kubernetes em um tempo bem menor. Só que não tentamos levar tudo para Kubernetes, apenas o que realmente se beneficiaria disso
Nossa proposta era mais ou menos esta: se migrarmos para Kubernetes, na mudança de datacenter planejada para o fim do ano não será preciso fazer nada além de manutenção. Caso contrário, seria necessário reimplantar os apps em novas máquinas ou VMs e lidar com toda a dor de cabeça decorrente disso. Se ainda não estivesse containerizado, containerizássemos agora e nós cuidaríamos do resto
A maior parte migrou e ficou muito satisfeita com o resultado. Por outro lado, serviços sensíveis à latência ou da área de computação de alto desempenho não tinham motivo para ser forçados a migrar, e nem tentamos encaixá-los à força
Quanto tempo levaria para sair disso?
Se o app já foi transformado em microsserviços, voltar atrás também não é simples
Quando leio um post de blog que menciona casualmente seis projetos da CNCF com nomes incríveis que nunca ouvi falar, só para obter uma funcionalidade aparentemente simples, sinto que fiquei para trás
Fico me perguntando seriamente se já chegou a hora de envelhecer e sair do desenvolvimento profissional de software
Só significa que você não está acostumado com uma abordagem de escalabilidade organizacional em que a equipe de plataforma abstrai hardware, logging, tentativas de repetição e assim por diante
Não é a única abordagem, então você pode muito bem estar acostumado com outras
Gostei deste texto porque ele explica de forma clara e coerente os ganhos e os motivos para ir para Kubernetes
Muitas equipes entram nisso sem saber o que vão ganhar, nem mesmo se precisam disso, mas os motivos apresentados aqui parecem razoáveis
Outros comentários já levantaram esse ponto: https://news.ycombinator.com/item?id=41194506 https://news.ycombinator.com/item?id=41194420
Por pura curiosidade, que outro sistema ou serviço moderno haveria em que uma pessoa em sã consciência se gabaria de ter migrado em menos de 1 ano?
Um sistema como Kubernetes normalmente fica no centro da infraestrutura e afeta tudo o que está rodando. Somando isso às restrições de equipe mencionadas no texto, um ano não soa tão ruim assim
Um exemplo que me vem à cabeça é quando a Amazon migrou totalmente do Oracle para bancos de dados relacionais da própria Amazon/de código aberto. Mas, pelo que lembro, isso levou vários anos. Se tivessem terminado em menos de um ano, certamente teriam se gabado disso
Mais do que a tecnologia em si, muitas vezes o problema é dívida técnica, complexidade de integração e disponibilidade de pessoal