El hecho de que Google, Amazon o Facebook lo hagan no significa que debas hacerlo. Aquí hay cuatro ‘mejores prácticas’ para ignorarlos sin pedirles permiso.
por Matt Asay
Hace años, Google luchó con cómo lanzar sus ofertas en la nube. En 2017, sugerí que la empresa debería ayudar a las empresas principales a “funcionar como Google”, pero en una conversación con un alto ejecutivo de productos de Google Cloud, sugirió que la empresa evitaba este enfoque. ¿La preocupación? Que tal vez las empresas principales no compartieran las necesidades de Google, o tal vez Google simplemente las intimidaría.

Si eres de los simples mortales que manejan TI en empresas más convencionales (léase: casi todo el mundo), no temas. Resulta que hay muchas cosas que Google podría hacer que no tienen sentido para sus propias necesidades de TI.
Pregúntele a Colm MacCárthaigh, ingeniero de AWS y uno de los autores del servidor HTTP Apache, quien pidió “ejemplos de cosas técnicas que no tienen sentido para todos solo porque Amazon, Google, Microsoft, Facebook” las hacen. Las respuestas (garantías de tiempo de actividad excesivas, ingeniería de confiabilidad del sitio, microservicios y monorepos entre los aspectos más destacados) son instructivas.
Garantías de tiempo de actividad excesivo
“Cinco o más de cinco nueves garantías de disponibilidad”, dice Pete Ehlke . “Fuera de la medicina y los centros de llamadas al 911, no puedo pensar en nada menos que la escala de FAANG [Facebook, Amazon, Apple, Netflix y Google] que en realidad necesita cinco nueves, y el ROI prácticamente nunca funciona”.
Recuerdo bien este de la variedad de nuevas empresas para las que trabajé, así como cuando estuve en Adobe ( cuyos compromisos de nivel de servicio tienden a no ser de cinco nueves, pero posiblemente son más altos de lo necesario). ¿Estarás bien si el juego multijugador falla? Sí. ¿Qué pasa con Office 365 durante unos minutos o incluso horas? Si y si.
Ingeniería de confiabilidad del sitio
SRE (nombrado en múltiples respuestas a MacCárthaigh) salió de Google en 2003 y fue diseñado para infundir ingeniería con un enfoque operacional, un poco giro en devops (aunque es anterior al movimiento devops) . Algunos principios básicos guían a SRE :
- Acepta el riesgo
- Utilizar objetivos de nivel de servicio (SLO)
- Eliminar el trabajo
- Monitorear sistemas distribuidos
- Aproveche la automatización y adopte la simplicidad
O, como lo describe Ben Traynor, quien desarrolló la práctica SRE de Google :
Básicamente, SRE está realizando un trabajo que históricamente ha sido realizado por un equipo de operaciones, pero utilizando ingenieros con experiencia en software y confiando en el hecho de que estos ingenieros están predispuestos inherentemente y tienen la capacidad de sustituir el trabajo humano por la automatización. En general, un equipo de SRE es responsable de la disponibilidad, la latencia, el rendimiento, la eficiencia, la gestión de cambios, la supervisión, la respuesta a emergencias y la planificación de la capacidad.
Los SRE dedican gran parte de su tiempo a la automatización, con el objetivo final de automatizar su trabajo. Dedican un tiempo considerable a “operaciones / tareas de guardia y a desarrollar sistemas y software que ayudan a aumentar la confiabilidad y el rendimiento del sitio”, dice Silvia Pressard.
Esto suena importante, y más aún si equipara la “confiabilidad del sitio” con la “disponibilidad comercial”. Pero, ¿realmente necesitan la mayoría de las empresas que sus desarrolladores se conviertan en expertos operativos? La SRE puede ser fundamental en Google o Amazon, pero podría decirse que es un gran impulso para la mayoría de las empresas, ya que asigna a los desarrolladores una carga operativa demasiado grande para que la administren con éxito.
Arquitectura de microservicios
Como comentarista “Buzzy” le dice ella, “Sin duda microservicios. El número de empresas de 20 empleados en total que he tenido que hablar desde esa cornisa … ” Tampoco es el único en llamar a los microservicios como una complicación innecesaria para la mayoría de las empresas. Muchas de las respuestas al tweet de MacCárthaigh mencionaron microservicios.
Como ha argumentado Martin Fowler , “Si bien [los microservicios] es una arquitectura útil, muchas, de hecho la mayoría, de las situaciones funcionarían mejor con un monolito”. ¿Esperar lo? ¿No son los monolitos una reliquia malvada del pasado? Por supuesto que no es tan simple. Como he escrito ,
La gran promesa de los microservicios es la libertad. Libertad para dividir una aplicación en distintos servicios que se pueden implementar de forma independiente. Libertad para construir estos servicios dispares con diferentes equipos usando su lenguaje de programación preferido, herramientas, base de datos, etc. En resumen, libertad para que los equipos de desarrollo hagan las cosas con una burocracia mínima.
Pero para muchas aplicaciones, esa libertad tiene costos innecesarios, como destaca Fowler:
- Distribución: Los sistemas distribuidos son más difíciles de programar, ya que las llamadas remotas son lentas y siempre corren el riesgo de fallar.
- Consistencia eventual: mantener una consistencia sólida es extremadamente difícil para un sistema distribuido, lo que significa que todos tienen que gestionar la consistencia eventual.
- Complejidad operativa: necesita un equipo de operaciones maduro para administrar muchos servicios, que se redistribuyen con regularidad.
Sam Newman subraya este último punto : “Para un equipo pequeño, una arquitectura de microservicio puede ser difícil de justificar, ya que se requiere trabajo solo para manejar la implementación y la administración de los microservicios en sí”.
No quiere decir que un enfoque de microservicios siempre sea incorrecto. No, es simplemente una sugerencia de que no deberíamos usar un enfoque más complicado (pero escalable) simplemente porque los hiperescaladores lo usan (generalmente porque la escala es muy crítica).
Un monorepo para gobernarlos a todos
Ya sean microservicios o de naturaleza monolítica, probablemente no debería almacenar su código en un “monorepo”. Esta fue una respuesta común a la solicitud de MacCárthaigh. Monorepos almacena todo el código de una empresa en un único sistema de control de versiones (VCS), para aprovechar los (supuestos) beneficios de reducir la duplicación de código y aumentar la colaboración entre equipos.
Esa es la teoría.
La práctica, sin embargo, es muy diferente. “Rápidamente se vuelve irrazonable que un solo desarrollador tenga todo el repositorio en su máquina, o que busque en él usando herramientas como grep”, dice Matt Klein, un ingeniero que ha construido algunos de los sistemas más sofisticados en Amazon, Twitter y ahora Lyft. “Dado que un desarrollador solo accederá a pequeñas porciones del código base a la vez, ¿existe alguna diferencia real entre verificar una parte del árbol a través de un VCS o verificar varios repositorios? No hay diferencia “.
Klein continúa:
En términos de colaboración y uso compartido de código, a escala, los desarrolladores están expuestos a subsecciones de código a través de herramientas de capa superior. Si el código está en monorepo o polyrepo es irrelevante; el problema que se está resolviendo es el mismo, y la eficacia de la colaboración y el intercambio de código tiene mucho que ver con la cultura de ingeniería y nada que ver con el almacenamiento de código .
Tú eres tú
Por supuesto, algunas empresas pueden beneficiarse de monorepos o disponibilidad de cinco nueves o microservicios o SRE. También podrían beneficiarse de desarrollar su propio marco, construir su propia infraestructura o cualquiera de las otras cosas que los comentaristas de MacCárthaigh se burlan. El punto es que solo porque Google, Facebook, Amazon u otro hiperescalador lo haga, no significa que debas hacerlo. En caso de duda, duda. Comience con las necesidades individuales de su empresa y descubra el enfoque correcto para crear y administrar software de acuerdo con quién es usted, no quién desearía ser.
Fuente: https://www.infoworld.com/article/3585176/no-you-dont-have-to-run-like-google.html
¿Qué es un monorepo?

En los sistemas de control de revisiones, un monorepo (“mono” del griego μόνος, mónos, ‘single, alone’ y “repo” abreviatura de repositorio) es una estrategia de desarrollo de software en la que el código de muchos proyectos se almacena en el mismo repositorio. A partir de 2017, varias formas de esta práctica de ingeniería de software tenían más de dos décadas, pero el concepto general se había nombrado recientemente. Se han hecho muchos intentos para diferenciar entre aplicaciones monolíticas y otras formas más nuevas de monorepos.
Google , Facebook , Microsoft, Uber, Airbnb y Twitter emplean monorepos muy grandes con diversas estrategias para escalar sistemas de compilación y software de control de versiones con un gran volumen de código y cambios.