Startups, ¿Queres realmente pagar o imposto de microservizos?

Por que dividir a súa base de código demasiado cedo pode destruír silenciosamente a velocidade do seu equipo - e que facer no seu lugar. . Por que dividir a súa base de código demasiado cedo pode destruír silenciosamente a velocidade do seu equipo - e que facer no seu lugar para unha startup, Aquí é onde a arquitectura fundamental da súa startup xoga un gran papel; ademais, cousas como a súa pila de tecnoloxía e a elección da linguaxe de programación afectan directamente á velocidade do seu equipo. your survival depends on how quickly you can iterate, ship features, and deliver value to end-users Tiven esta experiencia ao traballar en proxectos de campo verde para startups de estadios iniciais, onde se tomaron decisións cuestionables en termos de arquitectura de software que levaron a servizos semi-acabados e , e que loitan por manter a complexidade innecesaria. configuracións locais fráxiles, sobre-enxeñeiradas e rotas demoralized teams Antes de mergullarse en trampas específicas, aquí está o que realmente se está rexistrando ao introducir microservizos prematuramente: Microservices Early On: What You’re Paying For Pain Point Real-World Manifestation Developer Cost Deployment Complexity Orchestrating 5+ services for a single feature Hours lost per release Local Dev Fragility Docker sprawl, broken scripts, platform-specific hacks Slow onboarding, frequent breakage CI/CD Duplication Multiple pipelines with duplicated logic Extra toil per service Cross-Service Coupling "Decoupled" services tightly linked by shared state Slower changes, coordination tax Observability Overhead Distributed tracing, logging, monitoring Weeks to instrument properly Test Suite Fragmentation Tests scattered across services Brittle tests, low confidence Complexidade da implantación Orchestrating 5+ servizos para unha única característica Hours lost per release Local Dev Fragilidade Docker spread, scripts rotos, hacks específicos da plataforma Slow onboarding, frequent breakage Duplicación CI/CD Múltiples pipelines con lóxica duplicada Extra toil per service Conexión de servizos Servizos "desconectados" estreitamente ligados polo estado compartido Slower changes, coordination tax Observación xeral Seguimento distribuído, rexistro, seguimento Weeks to instrument properly Proba Suite Fragmentación Probas espalladas por servizos Brittle tests, low confidence Imos desempacar por que os microservizos adoitan retroceder cedo, onde realmente axudan, e como estruturar os sistemas da súa startup para velocidade e supervivencia. Os monolitos non son o inimigo Se está a construír algún produto SaaS, mesmo un simple envasador de bases de datos SQL pode eventualmente traer moita complexidade interna na forma na que funciona a súa lóxica empresarial; ademais, pode acceder a varias integracións e tarefas de fondo que permiten transformar un conxunto de datos a outro. Co tempo, ás veces funcións innecesarias, é inevitable que a túa aplicación poida crecer desordenada. : Monoliths, even when messy, keep your team focused on what matters most permanecer vivo Entrega de valor ao cliente A maior vantaxe dos monólitos é a súa simplicidade na implantación. En xeral, tales proxectos están construídos en torno a marcos existentes - podería ser Django para Python, para C#, Nest.js para aplicacións de Node.js, etc. Ao adherirse á arquitectura monolítica, obtén a maior vantaxe sobre os microservizos fantais - un amplo apoio da comunidade de código aberto e os mantedores de proxectos que deseñaron esas estruturas para traballar como un único proceso, unha aplicación monolítica. Asp.net Páxina Nunha startup inmobiliaria onde lideraba o equipo front-end, e ocasionalmente consultou ao equipo de backend sobre as opcións tecnolóxicas, tivemos unha interesante evolución dunha aplicación baseada en Laravel. Co tempo, evolucionou nunha suite rica en recursos que manexaba centos de gigabytes de documentos e se integraba con decenas de servizos de terceiros. O equipo baseouse fortemente nas mellores prácticas recomendadas pola comunidade Laravel.Que disciplina pagou, puidemos escalar significativamente as capacidades da aplicación, mentres aínda atende ás necesidades e expectativas do negocio. Curiosamente, nunca tivemos que desconectar o sistema en microservizos ou adoptar patróns de infraestruturas máis complexos. Evitamos unha gran cantidade de complexidade accidental dese xeito. A simplicidade da arquitectura deunos peso. , que expón por que a simplicidade é unha superpotencia desde cedo. “Maior Monólito” A xente a miúdo sinala que é difícil facer monólitos escalables, pero é mala modularización O monolito que pode traer tales problemas. dentro Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting. Pero non son os microservizos a “mellor práctica”? Moitos enxeñeiros chegan a microservizos cedo, pensando que son "o camiño correcto".E seguro - a escala, poden axudar. Os microservizos só se pagan cando tes problemas de escala real, grandes equipos ou dominios que evolucionan de forma independente. Antes diso? estás a pagar o prezo sen obter o beneficio: infraestrutura duplicada, configuracións locais fráxiles e iteración lenta. Finalmente por esa razón exacta - demasiado custo, non suficiente valor. Segment Reverter a súa división de microservizos Takeaway: Microservices are a scaling tool — not a starting template. Onde os microservizos van mal (especialmente no inicio) Nun equipo de estadios iniciais que aconsellei, a decisión de dividir os servizos creou máis coordinación de PM-enxeñaría en xeral que un beneficio técnico.A arquitectura non formou só o código, senón como planificamos, estimamos e enviamos.Este imposto organizacional é fácil de perder - ata que é demasiado tarde. Aquí están os antipatróns máis comúns que crecen no inicio. Os límites arbitrarios do servizo En teoría, moitas veces podes ver suxestións sobre como dividir as túas aplicacións por dominios de lóxica empresarial -servizo de usuarios, servizo de produtos, servizo de pedidos, etc. Isto a miúdo emprégase a partir de conceptos de deseño orientado a dominios ou arquitectura limpa -que teñen sentido a escala, pero en produtos de estadio inicial, poden ossificar a estrutura prematuramente, antes de que o propio produto sexa estable ou validado. Bases de datos compartidas Servizos cruzados requiren fluxos de traballo sinxelos Conexión disfrazada como "separación" Nun proxecto, vin un equipo separando o usuario, a autenticación e a autorización en servizos separados, o que levou á complexidade da implantación e ás dificultades na coordinación de servizos para calquera operación de API que estaban construíndo. En realidade, a lóxica empresarial non mapea directamente os límites do servizo.A separación prematura pode facer que o sistema sexa máis fráxil e moitas veces é difícil introducir cambios rapidamente. En vez diso, illar garrafas cirúrxicamente - baseado na dor de escala real, non a elegancia teórica. Cando adestrei equipos de estadios iniciais, ás veces usamos bandeiras internas ou trampas de implementación para simular futuras divisións de servizo - sen a carga operativa inmediata. Takeaway: Don’t split by theory — split by actual bottlenecks. Repositorio e infraestrutura Sprawl Ao traballar na aplicación, normalmente un seguinte conxunto de cousas é importante: Coherencia de estilo de código (linting) Probas de infraestruturas, incluíndo probas de integración Configuración do ambiente local Documentación Configuración CI/CD Se o seu proxecto está estruturado como un monorepo, pode simplificar a súa vida tendo unha configuración CI/CD central (cando traballa con GitHub Actions ou GitLab CI). Para un equipo de tres persoas, isto é brutal.O cambio de contexto entre repositorios e ferramentas engade ata o tempo de desenvolvemento de cada característica que se envía. Mitigación de problemas mediante o uso de monorepos e unha única linguaxe de programación Para proxectos iniciais, o máis importante é manter o código nun monorepo. Isto asegura que hai unha única versión de código que existe en prod, e é moito máis fácil coordinar as revisións de código e colaborar para equipos máis pequenos. Para proxectos de Node.js, recomendo fortemente usar unha ferramenta monorepo como ou As dúas: nx turborepo Simplificar a configuración de CI/CD en subproxectos Soporte de cache de construción baseado en gráficos de dependencia Trata os servizos internos como bibliotecas TypeScript (a través de importacións ES6) Estas ferramentas aforran tempo se non se gastan escribindo código adhesivo ou reinventando a orquestración. As árbores complexas de adicción poden crecer rápido O axuste de rendemento CI non é trivial Pode necesitar ferramentas máis rápidas (como o bucle) para manter os tempos de construción abaixo Para resumir: Xogando como ou dá aos pequenos equipos velocidade monorepo - se está disposto a investir en mantelos limpos. nx turborepo Cando se desenvolve microservizos, unha boa idea ao comezo do desenvolvemento é usar un único O espazo de traballo coa Directiva en Finalmente, como o software escala, é posible separar sen esforzo Módulos en repositorios separados. go go replace go.mod go Takeaway: A monorepo with shared infra buys you time, consistency, and sanity. Dev local roto = velocidade roto If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity. Os proxectos iniciais adoitan sufrir de: Documentación faltante Dependencia obsoleta Hacks específicos do sistema operativo (olá, configuracións só para Linux) Na miña experiencia, cando recibín proxectos de equipos de desenvolvemento anteriores, a miúdo foron desenvolvidos para un único sistema operativo. Algúns desenvolvedores preferiron construír en macOS e nunca se molestaron en apoiar os seus scripts de shell en Windows. Nos meus equipos pasados, tiven enxeñeiros que traballaban en máquinas Windows, e moitas veces requiría reescribir scripts de shell ou comprender e reverter completamente o proceso de enxeñaría para que o ambiente local funcionase. Co tempo, estandarizamos a configuración ambiental en todos os sistemas operativos de desenvolvedores para reducir a fricción de embarque - un pequeno investimento que aforrou horas por novo enxeñeiro. Foi frustrante - pero ensinou unha lección duradeira sobre como é importante que o código funcione en calquera portátil que o novo desenvolvedor poida Noutro proxecto, un desenvolvedor solo creou unha configuración de microservizos fráxil, que o fluxo de traballo de executar contedores Docker montado nun sistema de arquivos local. Pero embarcar un novo desenvolvedor front-end cun portátil Windows máis vello converteuse nun pesadelo. Tiveron que montar dez contedores só para ver a interfaz de usuario. Todo rompeu -volumes, rede, compatibilidade de contedores- e a configuración foi moi mal documentada. Acabamos hackeando un proxy Node.js que imitaba a configuración nginx/Docker sen contedores. Non era elegante, pero permitiu que o desenvolvedor se desbloquease e comezase a contribuír. Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster. Idealmente, o obxectivo é Se non é posible, entón manter un ficheiro README actualizado con instrucións para Windows / macOS / Linux é unha obriga. Hoxe en día, hai algúns idiomas de programación e cadeas de ferramentas que non funcionan ben en Windows (como OCaml), pero a moderna pila popular só funciona ben en todos os sistemas operativos amplamente utilizados; limitando a súa configuración local a un único sistema operativo, é a miúdo un síntoma de baixo investimento en DX. Tip: git clone && make up Tecnoloxía Mismatch Ademais da arquitectura, a súa pila de tecnoloxía tamén forma como os microservizos se fan dolorosos - non todos os idiomas resplandecen nunha arquitectura de microservizos. Node.js e Python: Excelente para iteracións rápidas, pero xestionar os artefactos de construción, as versións de dependencia e a consistencia do tempo de execución entre os servizos faise dolorosa rapidamente. Go: Compila a binarios estáticos, tempos de construción rápidos e baixa sobrecarga operativa. Se buscas rendemento, quizais busques o JVM e o seu ecosistema e a capacidade de implantar artefactos a escala e executalos en arquitecturas baseadas en microservizos. É bastante frecuente que os equipos se decaten de que hai grandes problemas coa súa elección de tecnoloxía que non eran evidentes ao principio, e que tiveron que pagar o prezo de reconstruír o back-end nunha linguaxe de programación diferente (como Forzáronse a facer algo sobre a base de código Python 2 e migraron a Go). Estes rapaces Pero, pola contra, se realmente necesitas, podes conectar varias linguas de programación con protocolos como Cando chegas ao punto de que queres enriquecer o teu conxunto de recursos con funcionalidades de Machine Learning ou empregos baseados en ETL, simplemente construirías separadamente a túa infraestrutura baseada en ML en Python, debido ao seu rico ecosistema de bibliotecas específicas de dominio, que naturalmente carece calquera outra linguaxe de programación. gRPC Takeaway: Match the tech to your constraints, not your ambition. Complexidade oculta: Comunicación e seguimento Os microservizos introducen unha rede invisible de necesidades: Servizo Descubrimento API versións Retrasos, circuítos de corte, fallbacks Traxectoria distribuída Rexistro centralizado e alerta Nun monólito, un bug pode ser un simple rastro de pila. Nun sistema distribuído, é "por que o servizo A falla cando a implantación de B demora C en 30 segundos?" Tería que investir completamente na súa pila de observabilidade. Para facelo "correctamente", require instrumentar as súas aplicacións de maneiras específicas, por exemplo, integrar OpenTelemetry para apoiar o rastrexo, ou confiar nas ferramentas do seu provedor de nube como AWS XRay se vai cun sistema sen servidor complexo. Funcionamento da produción. actually Por suposto, algunha das instrumentacións de observabilidade é necesaria para ser realizada en aplicacións monolíticas, pero é moito máis sinxelo que facelo en termos do número de servizos dun xeito consistente. Entendemos que Son un compromiso para unha nova clase de desafíos de enxeñaría. Tip: distributed systems Non son libres. Non son libres. Cando os microservizos Fai sentido do do A pesar das dificultades mencionadas con microservizos, hai ocasións en que a desconexión a nivel de servizo é realmente moi beneficiosa. Isolamento de carga de traballo: un exemplo común para iso sería nas mellores prácticas de AWS sobre o uso de notificacións de eventos S3 - cando unha imaxe é cargada a S3, desencadea un proceso de cambio de imaxe / OCR, etc. Por que é útil: podemos desconectar as bibliotecas de procesamento de datos obscuros nun servizo autónomo e facelo unha API centrada exclusivamente no procesamento de imaxes e xerando saída dos datos cargados. Necesidades de escalabilidade diverxente: - Imaxina que está a construír un produto de IA. Unha parte do sistema (API web) que desencadea as cargas de traballo ML e mostra os resultados pasados non é intensiva en recursos, é lixeira, porque interactúa principalmente coa base de datos. Diferentes requisitos de execución: - Digamos que ten algunha parte herdada do código escrito en C++. Ten 2 opcións - converter magicamente na súa linguaxe de programación principal ou atopar formas de integralo cunha base de código. Dependendo da complexidade desa aplicación herdada, tería que escribir código adhesivo, implementando redes adicionais / protocolos para establecer interaccións con ese servizo, pero a liña de fondo é - probablemente terá que separar esta aplicación como un servizo separado debido a incompatibilidades de execución. Organismos de enxeñaría a gran escala loitaron con desafíos similares. por exemplo, o equipo de enxeñaría de Uber - non por pureza teórica, senón en resposta á verdadeira complexidade entre equipos e a escalada de límites.O seu post é un bo exemplo de como os microservizos poden funcionar cando ten a madurez organizacional e a capacidade operativa para apoialos. documentaron a súa transición a unha arquitectura de microservizos orientada a dominios Nun proxecto, que tamén sucede a ser un inmobiliario, tivemos código dun equipo anterior que executa cargas de traballo de análise baseadas en Python que cargan datos en db MS-SQL, descubrimos que sería un desperdicio construír sobre el unha aplicación Django. Takeaway: Use microservices when workloads diverge — not just because they sound clean. Guía práctica para startups Se está enviando o seu primeiro produto, aquí está o playbook que recomendaría: Comezar monolítico. Escolla un marco común e concéntrase en facer as funcións. Todos os marcos coñecidos son máis que suficientes para construír algunha API ou sitio web e servir aos usuarios. Non siga o hype, manteña a forma aburrida de facer as cousas; pode agradecer a si mesmo máis tarde. Non te preocupes por dividir o teu código en múltiples repositorios. Traballei con fundadores que querían separar o repositorio para reducir o risco de que os contratistas copiasen IP, unha preocupación válida. Pero na práctica, engadiu máis fricción que seguridade: construcións máis lentas, CI/CD fragmentado e mala visibilidade entre equipos. A protección IP marxinal non valeu a pena o arrastre operativo, especialmente cando os controles de acceso axeitados dentro dun monorepo eran máis fáciles de xestionar. Fai o traballo de maquillaxe. Se leva máis, ser moi específico sobre os pasos, gravar un vídeo / Loom, e engadir capturas de pantalla. Se o seu código vai ser executado por un desenvolvedor internado ou junior, probablemente vai bater un bloque, e vai gastar tempo explicando como solucionar un problema. Descubrín que documentar todos os posibles problemas para cada sistema operativo elimina o tempo gasto clarificando por que certas cousas nunha configuración local non funcionaron. Inverte cedo en CI/CD. Mesmo se é un HTML sinxelo que só podes scp a un servidor manualmente, podes automatizar isto e confiar no control de fonte con CI/CD para facelo. Cando a configuración é correctamente automatizada, só esquece a súa infraestrutura de integración continua e concéntrase en recursos. Vin moitos equipos e fundadores cando traballan con equipos outsourcados a miúdo son baratos en CI/CD, e que resulta no equipo sendo desmoralizado e molestado por procesos de implementación manual. División cirúrxica. División só cando resolva claramente un doloroso bloqueo de botella. Se non, invista na modularidade e as probas dentro do monólito - é máis rápido e máis fácil de manter. E sobre todo: optimize for developer velocity. Os microservizos prematuros levan o osíxeno lentamente - ata que un día non podes respirar. Velocity is your startup’s oxygen. Takeaway: Start simple, stay pragmatic, and split only when you must. Se segues un enfoque baseado en microservizos Eu tiña proxectos baseados en micro-servizos creados antes do que deberían ser feitos, e aquí están as seguintes recomendacións que podo dar sobre iso: Avaliar a súa pila técnica que potencia a súa arquitectura baseada en micro-servizos. Investir en ferramentas de experiencia do desenvolvedor. Cando ten separación baseada en servizos, agora ten que pensar en automatizar a súa pila de microservizos, automatizando a configuración en ambientes locais e de produción. En certos proxectos, tiven que construír un CLI separado que realiza tarefas administrativas no monorepository. Un proxecto que contiña 15-20 implementacións de microservizos, e para o ambiente local, tiven que crear unha ferramenta de cli para xerar arquivos docker-compose.yml dinámicamente para comezar de xeito sinxelo para o desenvolvedor regular. Concéntrase en protocolos de comunicación fiables ao redor da comunicación de servizo. Se é mensaxería asínc, asegúrese de que os seus esquemas de mensaxes sexan consistentes e estandarizados. Se é REST, concéntrase na documentación OpenAPI. Os clientes de comunicación interservizo deben implementar moitas cousas que non saen da caixa: retiros con retrocesos exponenciais, timeouts. Un cliente gRPC típico require que calcule manualmente esas cousas adicionais para asegurarse de que non sofre de erros transitorios. Asegúrese de que a configuración da unidade, a proba de integración e a configuración de probas de extremo a extremo é estable e escala coa cantidade de separacións de nivel de servizo que introduza na súa base de código. En proxectos máis pequenos que usan cargas de traballo baseadas en micro-servizos, probablemente preferiría unha biblioteca compartida con axudantes comúns para instrumentar a súa observabilidade, o código de comunicación dun xeito consistente. Unha consideración importante aquí é manter a súa biblioteca compartida tan pequena como sexa posible. Engadir rexistros de JSON estruturados e crear diferentes IDs de correlación para debugar as cousas unha vez que se implementa a súa aplicación. Mesmo os axudantes básicos que saen información de rexistro rica (ata que instrumentou a súa aplicación con instalacións de rexistro / rastrexo axeitadas) a miúdo aforran tempo descubrindo fluxos de usuario lixeiros. Para resumir: se aínda está indo para microservizos, debes comprender previamente o imposto que vai pagar en termos de tempo de desenvolvemento adicional e mantemento para facer a configuración viable para cada enxeñeiro no teu equipo. Takeaway: If you embrace complexity, invest fully in making it manageable. Conclusión Dividirse só cando a dor o fai evidente. Premature microservices are a tax you can’t afford. Stay simple. Stay alive. Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add. Recursos relacionados Monólito primeiro - Martin Fowler O Monólito Maior - DHH / Basecamp Adeus Microservizos: De 100 de nenos problemáticos a 1 superestrela - Segmento Eng. Desconstruíndo o Monolito - Shopify Eng. Arquitectura de microservizos orientada a dominios - Uber Eng. Go + Servizos = Un Proxecto Goliat - Academia Khan