Trabalhando num sistema crítico
Vložit
- čas přidán 12. 09. 2024
- Alguns softwares são tão críticos que programadores precisam trabalhar de forma diferente para atualizá-los, deploys frequentes são um risco, estratégias diferentes de single tenancy vs single tenancy devem ser adotadas entre vários outros detalhes que eu descrevo nesse vídeo.
Doações pro Rio Grande do Sul:
PIX: enchentes@vakinha.com.br
www.vakinha.co...
Evolua com desafios técnicos inspirados em testes reais de empresas de tecnologia:
💪 devgym.com.br/
🎥 Nesse vídeo eu usei:
Microfone: amzn.to/3zujQII
Câmera (lente kit padrão): amzn.to/2UQspip
Tripé: amzn.to/2UM6Xv4
Editor de vídeo com efeitos de zoom: www.screen.stu...
▶️ Redes sociais
Instagram: / filhodanuvem
Twitter: / filhodanuvem
GitHub: github.com/fil...
Eu gravei dois vídeos no mesmo dia em que o áudio saiu um pequeno ruído, peço perdão por isso 😅
Um dos únicos canais de tech que foge da mediocridade e realmente fala sobre assuntos fodas! Parabéns, meu maninho, conteúdo de qualidade! Não aguento mais ver fazedores de CRUD que não sabem nada de software.
Valeu mano, será que resistimos as notícias de IA e reacts de vídeos? Haha.
@@Filhodanuvem salve @manodeivyn 🤣
o que seria um fazedor de crud? tipo o cara so sabe receber a request e gravar no banco? o que exatamente esse termo é?
Crud é um acrônimo pra create read update delete. Aplicações que salvam, editam, deletam e fazem leitura de uma informação no banco.
Fazedor de CRUD ou "Arrastador de CARD" é aquele profissional que se acha engenheiro de software e só sabe fazer isso ai.... nada de crítido é jogado na mão desse "profissional" e fica lá sentado esperando task.
Trabalho em grandes bancos, geralmente mainframes, essa estrategia que vc exemplificou é utilizada a bastante tempo, eu diria a uns 30 anos pelo menos. É interessante saber que as "coisas velhas" se reciclam e ganham uma "cara nova"
Que legal essa sua experiência. Realmente, a nossa área não mudou muito, as ferramentas sim mas os conceitos por trás são os mesmos.
É fascinante ouvir essas história. Tudo o que vem na minha cabeça é: não vejo a hora de lidar com isso. A todo instante ficava lembrando de conceitos de SRE, system design... Parabéns por mais um vídeo! Que venham mais.
Valeu cara, quando menos esperar vai estar vivendo isso.
Seu conteúdo agrega muito. Eu nunca ia saber dessas particularidades no trabalho com grandes clientes.
Valeu Geovani, a intenção é essa, fico feliz.
Já tava com saudades do teus videos meu amigo.
Trabalhei em um gateway de pagamentos do banco laranja e entendo um pouco disso que vc passou, baita aprendizado!
Valeu mano Rafael. Hoje em dia tem dois bancos laranjas haha mas legal que tu entende bem essas dores
Excelentes pontos, muito bem levantados e explicados. Ate me inscrevi. Parabens!
Valeu mano, que bom que curtiu a ponto de se inscrever. Bem vindo.
Excelente explicação, toma mais um escrito.
Seu vídeo é o primeiro em muito tempo que consigo assistir até o final sem por no 2x.
Obrigado por compartilhar e estarei por aqui sempre. Abraço
Valeu mano, que bom que agregou
Pelo tamanho da responsabilidade desses desenvolvedores ainda mais quando mexe com banco, o salário deve ser enorme
Acho que tem uma valor pra pagar o stress sim, nessa experiência foi o maior salário da carreira.
@@Filhodanuvem eu tenho uma dúvida, eu estava fora da área desde 2015, aí voltei em 2022, aí tive que dar uma boa atualizada já que foram muitos anos fora, então peguei um freelancer de uma plataforma para um estúdio fotográfico para fazer para colocar no portfólio, e fiz alguns projetos pessoais tbm para o portfólio. A pergunta é, com essa experiência é possível conseguir vagas back end na Europa?
@Kimitri o que essa plataforma fazia ?
@@Filhodanuvem é um ecommerce de serviços de fotografia, com integração com banco do Brasil, ciclo. Armazenagem e gerenciamento de fotos com os aws, e cloudflare, e tbm tem gerenciamento de estoque, e mais uma série de coisas. Ele é todo personalizado pq o produto além das fotos, são os serviços e agendamentos, é muito grande não sei como explicar melhor.
Caralho, quanto tema importante em um só único vídeo, microservicos, instâncias, gracefull shutdown, mto bom 👍
Não sei se já tem no canal mas seria interessante entrar no tema do gracefull shutdown pq eh algo mto importante e pode impactar negativamente nos dados do banco de dados quando os processos são interrompidos. Parabéns
Valeuuu pelo comentário e sugestão 📝
Muito bom! Além de todo o conhecimento agregado, descobri uma nova ferramenta pra rabiscar arquitetura de software kkkkkkkk. Sou fissurado nessas ferramentas!
Hahahaha boa, também gosto muito.
Talvez os deploys pudessem ocorrer com maior frequência se houvesse um sistema de "graceful startup", onde o novo pod aguardaria pronto pelo graceful shutdown para assumir os valores de portas do pod antigo. Neste método, deploys feitos muito próximos um do outro poderiam substituir o anterior antes que subisse no ambiente.
Interessante isso, já vivenciou algo assim com k8s? Pergunto porque até onde eu sei o comportamento default de um replicaset é matar um pod pra depois subir outro. E pelo o que entendi da sua proposta seria bom que a nova versão estivesse no ar já pronta pra se conectar na porta assim que o graceful shutdown notificar. Não sei se da pra mudar esse comportamento do k8s mas é a boa ideia.
Não fui eu que implantei essa arquitetura no começo da empresa mas lembro que estabelecer a conexão TCP com o banco central incluída algumas fases tipo troca de mensagem handshake e tals, não lembro se esse era um fato pra evitar criar novas conexões ( ex: os 3 segundos iniciais é de handshake)
@@Filhodanuvem fala mano, essa sugestão que o Giu falou existe em PRD porém acho que não é comum. Mas o time de SRE de onde trabalho customizou assim, subindo os pods, deixando eles up mas só recebendo requisição apos a morte de x anteriores.
Particularmente não sei como é feito, pois não tenho acesso a essa config já que ele é importado de outro canto
Filassss... é sempre um desafio em projetos de banco né? É complexo demais gerenciar se todos os serviços processaram as mensagens rsrs em um projeto um pouco mais simples com poucos clientes ok mas do tamanho que descreveu... meo deooooos! Que desafio!!! Isso torna o adolescente um adulto 🤣
Muito legal você também ter falado sobre os termos single tenant e graceful shutdown, no meu trampo fiz uma abordagem pra isso em um serviço mas não sabia o nome kkkk
Nossa, nesse ambiente aí, cada mensagem que caída numa dead letter gerava um alerta de incidente. Como tudo era pagamento, qualquer mensagem era um pagamento não processado. Pensa numa saude mental debilitada hahaha
parabéns, muito interessante o conteúdo e o tempo do vídeo está excelente.
Valeu Eduardo. Que bom que achou o vídeo direto, tenho tentado ao máximo não enrolar.
Muito bom! Como estatístico, me lembra um cafo clássico de modelagem de filas. Só que com mais recursos de gerenciamento.
Valeu Eduardo, é bem por aí mesmo
Wouuu! Massa demais a experiência. Com certeza vai ajudar a pensar melhor em implementações futuras aqui na empresa.
Bem diferente neh? Espero que ajude :)
Sim, sim. Eu já agendei com um dev aqui para discutirmos sobre a partir das suas considerações.
a BEAM, runtime do Erlang/Elixir/Gleam entre outras, consegue fazer upgrade de código sem reiniciar. Não se encaixa muito bem nesse mundo de kubernetes, mas nesses casos, é um recurso precioso.
Acredito que a JVM tenha algum recurso parecido
Legal, esse ambiente do erlang é bem famoso por esses cenários críticos mesmo tipo telefonia, mas nunca usei.
Conteúdo muito top! Pode trazer mais sim.
Valeu mano
Interessante esses diferenciais da sua plataforma, parabéns
Valeu mano
São todas soluções interessantes. Deduzi que você trouxe um resumo dos requisitos, principalmente nas regras de comunicação com o banco central.
Dependendo da flexibilidade ali naquele ponto, seria possível entregas mais frequentes sem impactar os clientes. Mas entendo também que às vezes não é um impedimento técnico, mas sim uma mitigação de risco.
Boa! Acho que é um misto de muitas coisas sim, tem um pouco da natureza crítica do negócio, da qualidade de serviço que é preciso ser entregue mas também a cultura dos clientes e da própria empresa. Claro que se fosse algo crítico teria que ir pra produção, mas esse mundo muda pouco, depois da solução pronta e estável não é como se a aplicação precisasse de muitas melhorias.
Boa! Acho que é um misto de muitas coisas sim, tem um pouco da natureza crítica do negócio, da qualidade de serviço que é preciso ser entregue mas também a cultura dos clientes e da própria empresa. Claro que se fosse algo crítico teria que ir pra produção, mas esse mundo muda pouco, depois da solução pronta e estável não é como se a aplicação precisasse de muitas melhorias.
Manda mais mano, curto de mais seus vídeos!
Boaaa
Que canal foda parabéns pelo conteúdo!
Valeu Felipe, que bom que curtiu.
Interessante saber um pouco mais dessa dinâmica
Valeu Gilmar
Muito bom!!!
Valeu 🙏
Canary deployment nao resolveria ? Pois voce mantem a versao estavel em produção e escala mais pods com a versao nova e vc vai alterando em % a quantidade de trafego que vai cair na nova versao...
Assim voce nao tem indisponibilidade no seu deploy
No protocolo TCP (em resumo) cada máquina (ip) so pode manter uma conexão com um outro ip de destino na mesma porta. E do meu lado não há controle de se conectar em outra porta porque o acordo com o banco central é “pagamentos que vem do ip tal conectado na porta x ou y representam o Santander” . Basicamente no canary existiria uma terceira conexão.
Bem vindo ao clube
Hahahaha
Levantar uma questão, será que grande parte dos problemas levantados não seriam resolvidos em um ambiente serverless? Quais os impedimentos para utilizar serverless no mercado financeiro?
A própria arquitetura do “banco central” exige a conexão permanente TCP, se usássemos serverless a lambda perderia a conexão assim que fosse desligada.
Além disso dependendo da linguagem que você usa em serverless tu vai sofrer com cold start, nesse cenário você precisa resolver o pagamento o mais rápido possível, perderíamos um tempo subindo a lambda.
Faz sentido. Mesmo com lambda, vc ia ter que manter a conexão aberta de alguma maneira, o que o forçaria a retornar ao menos essa parte da aplicação para algo gerenciado. Ainda imagino que o throughput disso deve ser monstruoso, para justificar essa necessidade de uma conexão permanente.
Bom conteúdo, sucesso!
Mano continue fazendo videos que eu irei continuar assistindo.
Opaaa, combinado 🤝
Como sempre, incrível. Sucesso nuvem! 💪
Valeu mano por sempre aparecer aqui
Que visão top parabéns
Valeu mano
Video maneiro man!
Valeuu
Vim do Embbed C, tô indo pra back-end com C#, eu vejo essas coisas n críticas e me dá ânsia toda vez q da deploy kkkkkķkkk
Maluco codar pra embarcado é tentativa única e funcionou rodando liso, pra mexer naquilo tem q ser pq é mto necessário e é algo crítico
Hahahahah esse problema eu nunca passei e acho muito difícil eu passar.
Ótimo vídeo, como sempre. Por curiosidade, por que você trocou o Clojure pelo Go?
Valeu Luís. Olha, sinceramente minha ida pro clojure foi muito mais pra sair do PHP e ter outras experiências mas meu objetivo sempre foi go. Como na época não tava conseguindo uma oportunidade na linguagem aceitei o desafio.
Existe algo chamado socket takeover que poderia ser usado nessa situação, onde um processo pode continuar uma conexão iniciada por outro.
Que legal, não conhecia essa parada não
Conteúdo maravilhoso!
Valeu mano
Trabalhei com algo assim tmb mas era elixir. Então quase tudo q k8s tenta fazer a BEAM já faz a anos e com qualidade afinal telefonia da Inglaterra e até WhatsApp rodam nela ne
Legal, já ouvi dizer mesmo que a máquina virtual do earlang é incrível pra esses ambientes de alta disponibilidade
O mais legal é que quem já hospedou algum jogo online já deve ter passado por situações similares kkk
Haha eu vejo muita semelhança também entre indústria de jogos e fintechs
Show. Era a API da SEPA?
FPS, tipo um pix do uk
Eu sou super leigo nessa complexidade. Mas e se ao invés de atualizar um serviço vc agregasse outro serviço que a partir do momento que ele subisse ele assumisse as novas requisições e o anterior após terminar o que tinha em fila fosse desligado. Será que daria certo? Não sei se vc me entendeu.
Essa dúvida é boa. Eu não sou expert em redes mas vamos lá, as conexões de rede são feitas através de portas, quando a gente se conecta no redis por exemplo, a gente passa o ip/host e a porta do servidor. O protocolo TCP diz que não dá pra ter duas conexões com os mesmos ip e porta na origem e no destino. Então quando o serviço novo subisse, ele teria que se conectar numa porta diferente, o que acaba definindo outra conexão e não a mesma. O serviço do banco central registra de forma fixa quais as portas TCP representam os pagamentos do santander. Na hora de assinar contrato de papel mesmo eles falam “a porta do Santander é a 1001 e a 1002” então não existia flexibilidade de usar qualquer porta.
Se tinha um failover, qual era o problema de atualizar mais frequentemente o serviço?
Sobrecarregar o outro pod que lidaria sozinho com o tráfego, aumentar o tempo de resposta dos pagamentos já que por um momento a throughput. Causar frequentes desconexoes também seria percebido pelo lado do banco central, acabaria criando uma reputação ruim pro serviço, como se nossa disponibilidade não fosse tão alta.
Entendi. O protocolo demanda essa conexão persistente
mas é assim porque provavelmente no passado os dev faziam muita cagada nos deploy e o uptime não era garantido.
Sem cumprir o uptime direitinho partiram para a soluc'ão ideal para não ter downtime por conta de atualizações frequentes.
ou seja. deixam de atualizar novas versões para ganhar uptime.
Acho que não, o time era bem maduro. Essa era uma característica dos sistemas críticos, existiam outros que todo mundo era bem livre pra fazer deploy.
Mano, eu vi algo sobre uma arquitetura chamada de config server, que manter uma instância que serviria apenas para fornecer as variáveis de ambiente. Essa instância poderia ser usada nesse caso ao invés do lance dos arquivos?
Provavelmente deve ser algo como o Vault da Hashicorp, eu vi uma galera de segurança recomendando que a aplicação vá atrás dos secrets que são guardados nesses servidores de cofre. Acho que a sua sugestão funcionaria sim, só fico pensativo que a aplicação teria que fazer uma request a cada x tempos pra entender se o valor mudou. Sendo um arquivo a aplicação consegue entender algo até pelo metadado do arquivo (última data de modificação). É mais rápido. (Eu não amo arquivo de configuração não, só pensando em voz alta)
@@Filhodanuvem faz sentido msm
Curti o vídeo. Só achei estranho a cultura de fazer deploy em produção todos os dias. Nunca deparei com um ambiente assim. Tudo é bem programado e testado antes e sempre aprovado com uma change
Quanto mais testes automatizados temos num projeto mais segurança temos de colocar ele em produção, mesmo sem testes manuais. Quanto mais teste automatizado mais rápido uma mudança vai pra prod, alguns fazem Continuous deployment que a grosso modo quer dizer que quando você faz merge na master, todos os testes automatizados já garantiram que nada vai quebrar e automaticamente um deploy é feito. Outro tópico que ajuda a entregar código constante são as feature flags, você faz deploy mas nada muda pro usuário até que você ligue uma flag.
A talk mais histórica é essa aqui, que o Flickr cita fazer mais de 10 deploys por dia. A talk acabou sendo o começo do movimento devops também.
czcams.com/video/LdOe18KhtT4/video.htmlsi=KASjkZXKue8uHF8a
Toda vez que abro OLX, lembro de você
Hahahahahah sempre que eu uso Olx fico pensando “será que a análise de anúncio ainda é por aquele código?” Haha
Que foda 😮😮
top
Valeu
o que é restata? reset? reiniciar?
Dependendo da linguagem de programação e do programa, quando você roda o programa ele fica rodando pra sempre, ligado, por exemplo um site está sempre no ar, então essa aplicação está rodando. Restartar quer dizer parar o programa e roda-lo de novo. Mesmo processo que fazemos com o sistema operacional.
seu time era gerenciado por Indiano?
Que isso cara hahaha não tinha indiano não. A empresa foi fundada (e consequentemente essa arquitetura) por ingleses.
trampou na Dock é?
Não rsrs mas deve ter muita empresa com uma arquitetura parecida
Do you sell channel?
My channel? No, I don’t.
Mais...
Valeuu
Mais
Valeuuu
Mais
Opa, bora! Já pensando nos próximos exemplos pra trazer.
Mais
Valeuuu Rafael