Migração eficiente: do Laravel ao Hyperf

Palestra desenvolvida para o Ingá.php 2025

Transcript

1. MIGRAÇÃO EFICIENTE DO LARAVEL PARA O HYPERF
2. • Canionista / Montanhista • Atleta de CA • BJJ • DevParaná • UTFPR • schons.hashnode.dev • Co-Founder Polyglot.ai • Uma curiosidade… Luiz Schons
3. Disclaimer! 1. Não sou especialista em nada 2. Analise o cenário que você está 3. Não existe bala de prata 4. Estude e estude…
4. MIGRAÇÃO DE SOFTWARE UM POUCO DO QUE EU JÁ PASSEI
5. Vamos entender um pouco dessa história QUAL ERA O CENÁRIO QUE A GENTE ESTAVA?
9. Motivos 1. Decisões não assertivas no passado. 2. Programar pisando em ovos. 3. Performance (Não era culpa do Laravel). 4. Micro-serviço que não era micro. (Domínios) 5. O Deploy era tenso.
10. POR QUE HYPERF?
15. Motivos 1. Toda a equipe tinha conhecimento em PHP. 2. Coroutine & Non-Blocking System. 3. Desafio. 4. Performance (Swoole).
16. Swoole é uma runtime PHP que permite a programação assíncrona de alta performance, com suporte a coroutines, melhorando significativamente a capacidade de processamento e escalabilidade de aplicações web. ENTENDENDO SWOOLE
17. FPM X SWOOLE
18. COMO PLANEJAMOS?
19. 1. Definimos onde queríamos chegar: um software com uma experiência de desenvolvimento melhor (DX). 2. Entendemos melhor os domínios da aplicação. 3. Criamos um plano de ação. mas nem tudo são flores….
20. Começou o primeiro desafio
21. Procedimento 1º Migrar o banco de dados. 2º Migrar o framework
22. Começou o segundo desafio
23. MAS COMO DEFINIR DOMÍNIOS?
25. Elephant Migration AntiPattern
26. BIFURCAÇÃO TÁTICA OU DECOMPOSIÇÃO BASEADA EM COMPONENTES?
27. DECOMPOSIÇÃO BASEADA EM COMPONENTES • Refatoração. • Extração de componentes. • Incremental e controlada.
28. BIFURCAÇÃO TÁTICA • Réplicas dos serviços. • Remoção de partes indesejadas.
29. Arquitetura de Software: as Partes Difíceis: Análises Modernas de Trade-off Para Arquiteturas Distribuídas
30. Encontramos um problema Documentação desatualizada
31. Começou o terceiro desafio Documentação desatualizada Documentação + Architecture Decision Records (ADR)
32. Procedimento 1º Migrar o banco de dados. 2º Migrar o framework. 2º Entender os domínios e separar. 3º Documentar (software e decisões).
33. Voltando ao segundo desafio
34. 1. Muitas responsabilidades para um "micro-serviço" só. 2. Acoplamento muito forte entre diferentes domínios da aplicação. 3. Deploy impactava muito no ambiente de produção.
37. Procedimento 1º Migrar o banco de dados. 2º Migrar o framework. 2º Entender os domínios e separar. 3º Documentar (software e decisões). 4º Testes
38. MAS COMO A EQUIPE REAGIU?
40. 1. Comunicação interna bem alinhada com outros setores da empresa. 2. Suporte técnico e espaço para aprendizado contínuo. 3. Medo virou animação. 4. Evolução pessoal e do time.
43. MAS E AI? VALE A PENA?
45. Ainda tem muita coisa a evoluir, mas o primeiro passo foi dado.
46. Avalie a palestra