Propongo hablar sobre cuándo se necesitan microservicios y cuándo no. Spoiler: depende del proyecto.

Nosotros, los desarrolladores de software, tenemos una profesión bastante interesante. Podemos codificar de forma segura durante días y luego leer un artículo sobre algo, y cuestiona todo nuestro trabajo, porque algunos Netflix le dijeron a XYZ.

Solo así, debido a la opinión de una persona o empresa, comienzas a dudar de todo lo que has estado haciendo durante muchos años, incluso si todo funcionó a la perfección.

No eres Google (a menos que seas Google)

Cuando leemos HackerNews y otros sitios de noticias, a menudo vemos mensajes técnicos de Google, Netflix, Amazon y Facebook, y les gusta hablar sobre cuántos cientos o miles de servicios lanzan. Hablan sobre los beneficios de hacer las cosas a su manera. Esta es una tendencia de los últimos años.

Pero seamos sinceros. Es poco probable que tenga 1000 desarrolladores que estén trabajando en un proyecto masivo con más de 10 años de historia.

El hecho de que Google haga esto no significa que debas hacerlo tampoco.

Trabajamos en una galaxia completamente diferente. Google se enfrenta a problemas que probablemente nunca encontraremos, pero al mismo tiempo podemos hacer cosas que Google no puede hacer.

¿Cómo comienzan la mayoría de los proyectos de software?

Muchos proyectos comienzan con una persona que hace todo el trabajo. Hay un millón de ejemplos, pero echemos un vistazo a Shopify. Inicialmente, el servicio codificó Tobias Lyutke (estaba basado en Ruby on Rails y, por cierto, aún funciona en rails).

¿Crees que Tobias dudaba, pensando minuciosamente en la arquitectura ideal para microservicios, antes de escribir la primera línea de código?

Diablos no No estuve presente cuando desarrollé la primera versión de Shopify, que originalmente era solo una tienda en línea para hacer snowboard, pero si Tobias se parece a mí (un desarrollador típico), el proceso se vería así:

1. Aprenda nuevas tecnologías mientras escribe el producto original.
2. Escriba un código bastante no estándar (desagradable), pero totalmente funcional.
3. Vea cómo funciona todo junto y emocione.
4. Refactorice como "quemar con fuego" y mejore el código cuando ocurra un problema.
5. Repita este ciclo cuando agregue nuevas funciones y comience en un entorno de producción.

Esto puede parecer un ciclo muy simple, pero me llevó unos 20 años de programación descubrir qué tan profundo es.

Usted no mejora como programador, pensando teóricamente en la configuración óptima antes de escribir la primera línea de código. Mejora al escribir mucho código con la intención absoluta y explícita de reemplazar casi todo lo que escribe con un código mejor, tan pronto como comience a experimentar problemas reales.

El código original que reemplazó no es pérdida de tiempo o esfuerzo. Con el tiempo, te ayuda mucho a mejorar tu nivel. Este es un ingrediente secreto.

Hablar sobre abstracciones de código

Como desarrolladores, todos hemos escuchado la frase "SECO: no te repitas", y en general es un consejo razonable no volver a hacer el trabajo. Pero a menudo vale la pena hacerlo.

Vale la pena repetirlo cuando intentas abstraer algo sin comprenderlo completamente y crear lo que se llama abstracción permeable.

Por lo general, hago el trabajo tres veces incluso antes de PENSAR en refactorizar algún código y eliminar duplicados. A menudo, solo después de la 4ta o 5ta vez tomo algunas medidas.

Realmente necesita ver varias veces cómo duplica el código en diferentes situaciones antes de que quede claro qué traducir exactamente en variables y eliminar de los lugares donde este código se escribió originalmente.

Niveles de abstracción, desde código incrustado hasta bibliotecas externas:

1. Escribe el código en línea.
2. Duplicar el código en varios lugares diferentes.
3. Extraer código duplicado en la función, etc.
4. Usa estas abstracciones por un tiempo.
5. Vea cómo este código interactúa con otro código.
6. Extraer la funcionalidad general en la biblioteca interna.
7. Durante mucho tiempo use la biblioteca interna.
8. Realmente entiendo cómo se juntan todas las piezas.
9. Cree una biblioteca externa (código abierto, etc.), si eso tiene sentido.

El punto es que no puedes "inventar" una buena biblioteca o marco. Casi todas las herramientas exitosas que utilizamos hoy provienen de proyectos del mundo real. Allí, nuestra herramienta favorita se extrae de casos reales de uso interno.

Rails es un gran ejemplo. DHH (autor de Rails) no se despertó un día y dijo: “¡Oh! Es hora de crear los modelos /, controladores / y vistas /! Directorios ".

No Desarrolló Basecamp (el producto real), luego aparecieron ciertas plantillas, y estas plantillas se generalizaron y luego se extrajeron de Basecamp en Rails. Este proceso todavía está en curso hoy, y en mi opinión, esta es la única razón por la cual Rails sigue siendo tan exitoso.

Esta es una tormenta ideal de abstracciones muy bien administradas (léase: no desarrolladas teóricamente) combinadas con un lenguaje de programación que le permite escribir código atractivo. Esto también explica por qué casi todos los marcos como "Rails, solo en XYZ" no funcionan. Se saltan los componentes clave de la cadena de abstracción y piensan que simplemente pueden duplicar Rails.

De abstracciones a microservicios

Para mí, los microservicios son solo otro nivel de abstracción. Este no es necesariamente el paso 10 en la lista anterior, porque no todas las bibliotecas están diseñadas para microservicios, pero a nivel conceptual parece ser así.

Los microservicios no están donde comienza, al igual que no trataría de crear la biblioteca de código abierto externa perfecta antes de escribir al menos una línea de código. En este momento, ni siquiera sabes lo que estás desarrollando.

Una arquitectura basada en microservicios es en lo que un proyecto puede convertirse con el tiempo cuando se encuentra con problemas reales.

Quizás nunca encuentre estos problemas, y muchos de ellos pueden resolverse de manera diferente. Echa un vistazo a Basecamp y Shopify. Ambos funcionan bien como aplicaciones monolíticas.

No creo que nadie los llame pequeños, aunque no funcionan en una escala de Google.

Shopify gana $ 17 millones por mes en monolito

A mediados de 2018, Shopify ha anunciado públicamente que más de 600,000 tiendas en línea operan en su plataforma.

Shopify es una aplicación SaaS que tiene la tarifa más barata de $ 29 por mes, y tengo la sensación de que muchas compañías eligen la tarifa de $ 79 por mes. En cualquier caso, incluso si 600,000 clientes usaron el plan más barato por $ 29, este es un ingreso de $ 17.4 millones por mes solo de la línea SaaS de su negocio.

La aplicación Basecamp es otra gran aplicación monolítica. Lo interesante de Basecamp es que solo tienen unos 50 empleados, y solo algunos de ellos son desarrolladores de software que trabajan en el producto principal.

Quiero decir que puedes llegar MUY lejos sin tener que pasar por la madriguera de los microservicios. No cree microservicios así como así.

¿Cuándo deben usarse los microservicios?

Todo depende de tu decisión. Esta es solo una de esas cosas en las que no buscarás en Google "microservicios contra el monolito". Si realmente necesita microservicios, ya lo sabrá.

Pero puede haber una situación en la que tenga un grupo de desarrolladores que estén mejor preparados para trabajar en partes individuales de la aplicación. La presencia de docenas de equipos que trabajan en varios componentes del producto de forma aislada es una de las razones razonables para usarlo para microservicios.

Tenga en cuenta que si tiene un equipo pequeño que crece lentamente con el tiempo, puede comenzar con uno o dos microservicios. En tal situación, probablemente no debería dividir el monolito de una vez en 100 microservicios, comenzando desde una cantera.

¿Vale la pena el juego?

También vale la pena mencionar que la transición a microservicios va acompañada de su propio conjunto de problemas. Cambia un problema por otro, por lo que debe sopesar los pros y los contras de si el juego vale la pena específicamente para su proyecto.

Uno de los principales problemas es el monitoreo. De repente, obtienes una gran cantidad de servicios que pueden escribirse en diferentes conjuntos de tecnología, ejecutarse en múltiples máquinas, y necesitas una forma de rastrearlos en detalle.

Esta es una tarea difícil, porque idealmente nos gustaría que todos los microservicios utilicen un único servicio de monitoreo.

Probablemente no desee desarrollar sus propias herramientas, ya que esto en sí mismo puede convertirse en un trabajo completo. Esta es la razón del éxito de empresas como LightStep . Este es uno de los servicios de monitoreo más interesantes que he encontrado.

Su producto está más enfocado en aplicaciones a gran escala (es comprensible por qué), pero también funciona para proyectos pequeños. Hace poco escuché sobre ellos porque fueron presentados en Cloud Field Day 4 .

En cualquier caso, el monitoreo es solo una de las muchas dificultades, pero decidí mencionarlo porque es uno de los problemas más dolorosos.

Pensamientos finales

Básicamente, escribí este artículo por dos razones:

En primer lugar , hace dos semanas visité Cloud Field Day 4 y accidentalmente participé en un podcast grupal sobre un tema relacionado. Debería lanzarse en unos pocos meses, pero aquí quería detenerme en algunos puntos.

En segundo lugar , como autor de cursos en línea, recibo muchas preguntas sobre cómo crear mis propias aplicaciones.

Muchos desarrolladores se "congelan", tratando de dividir sus aplicaciones en servicios aislados incluso antes de escribir la primera línea de código. Llega al punto de que desde el principio intentan usar varias bases de datos para los componentes de la aplicación.

Este momento les impide avanzar y, como colega de desarrollo, sé lo difícil que es quedarse atrapado en la indecisión (¡lo tenía!).

Por cierto, actualmente estoy trabajando en una aplicación SaaS bastante grande, una plataforma para alojar cursos personalizados. En este momento estoy trabajando solo en un proyecto, y puedes estar seguro de que acabo de abrir el editor y comencé a escribir código el primer día.

Guardaré el proyecto como una aplicación completamente monolítica, hasta que tenga sentido implementar microservicios, pero mi instinto me dice que ese momento nunca llegará.

¿Qué opinas de esto? Déjame saber en los comentarios.