Arquitectura a escala, 2ª edición

Prefacio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Laarquitectura a escala trata de la modernización. Se trata de construir y actualizar tus aplicaciones críticas para satisfacer las necesidades de tus clientes digitales, cada vez más exigentes. Se trata de alta disponibilidad, se trata de diseñar la arquitectura de tus aplicaciones utilizando técnicas modernas de desarrollo y operaciones, se trata de organizar tus equipos de desarrollo para ayudar a que tus aplicaciones -y tu negocio- tengan éxito, se trata de escalar a tus días más grandes, se trata de utilizar los recursos disponibles en la nube para afrontar estos retos.

El proceso de arquitectura a escala es mucho más que gestionar un gran volumen de tráfico.

Quién debería leer este libro

Este libro está dirigido a arquitectos, gestores y directores que construyen y operan aplicaciones y sistemas a gran escala, ya sea en una organización de ingeniería o de operaciones. Si diriges a desarrolladores de software, ingenieros de fiabilidad de sistemas o equipos de operaciones, o bien diriges una organización que contiene aplicaciones y sistemas a gran escala, las sugerencias y orientaciones proporcionadas en este libro te ayudarán a que tus aplicaciones funcionen de forma más fluida y fiable.

Si tu aplicación empezó siendo pequeña y ha experimentado un crecimiento increíble (y ahora está experimentando algunos de los dolores de crecimiento asociados a ese crecimiento), puede que estés sufriendo una reducción de la fiabilidad y de la disponibilidad. Si luchas contra la gestión de la deuda técnica y los fallos asociados de la aplicación, este libro te proporcionará orientación para reducir esa deuda técnica y hacer que tu aplicación pueda manejar una escala mayor con más facilidad.

Por qué escribí este libro

Después de pasar siete años trabajando en Amazon construyendo aplicaciones altamente escalables tanto en el mundo minorista como en el de los Servicios Web de Amazon (AWS), me trasladé a New Relic, que estaba en pleno hipercrecimiento. La empresa sentía el dolor de necesitar los sistemas y procesos necesarios para gestionar aplicaciones altamente escalables, pero aún no había desarrollado plenamente los procesos y disciplinas para escalar su aplicación.

En New Relic, vi de primera mano las luchas de una empresa que pasaba por el proceso de intentar escalar, y me di cuenta de que había muchas otras empresas que experimentaban las mismas luchas cada día.

Ahora viajo por todo el mundo, hablando a clientes y a otras personas como tú sobre la nube, sobre el escalado, sobre la disponibilidad y sobre el proceso crítico de crear aplicaciones modernas. Hago presentaciones, mesas redondas, clases, seminarios. Hablo de tú a tú con líderes de ingeniería y ejecutivos, tanto para ayudarles a alcanzar sus objetivos como para aprender de ellos lo que funciona y lo que no. Escribo artículos. Concedo entrevistas. Participo en podcasts.

Mi intención con este libro es ayudar a otras personas que trabajan con aplicaciones de gran crecimiento a aprender procesos y buenas prácticas que puedan ayudarles a evitar los escollos que les esperan al escalar.

Tanto si tu aplicación se multiplica por diez como si sólo crece un 10% cada año, y tanto si el crecimiento es en número de usuarios, número de transacciones, cantidad de datos almacenados o complejidad del código, este libro puede ayudarte a construir y mantener tu aplicación para manejar ese crecimiento, manteniendo un alto nivel de disponibilidad.

Unas palabras sobre la balanza hoy

A medida que las aplicaciones crecen, empiezan a ocurrir dos cosas: se vuelven significativamente más complicadas y manejan volúmenes de tráfico significativamente mayores.

A mayor complejidad, mayor fragilidad. Más tráfico significa mecanismos más novedosos y complejos para gestionar el tráfico.

Los desarrolladores de aplicaciones rara vez incorporan la escalabilidad a sus aplicaciones desde el principio. A menudo pensamos que hemos incorporado la escalabilidad, y creemos que hemos hecho lo necesario para que nuestra aplicación escale hasta los niveles más altos que podamos imaginar. Pero la mayoría de las veces, encontramos fallos en nuestra lógica y en nuestras aplicaciones. Estos fallos aparecen sólo después de que empecemos a ver problemas de escalabilidad, y eso hace que escalar a mayores volúmenes de tráfico y mayores conjuntos de datos sea más difícil.

Esto conduce a una complejidad aún mayor y a una fragilidad aún mayor.

En última instancia, este ciclo de escala/abertura/escala/complejidad se convierte en una espiral mortal para una aplicación, ya que experimenta caídas de tensión, apagones y otros problemas de calidad de servicio y disponibilidad.

Pero estos son tus problemas. A tus clientes no les importan estos problemas. Sólo quieren utilizar tu aplicación para hacer el trabajo que esperan que haga. Si tu aplicación no funciona, es lenta o incoherente, los clientes simplemente la abandonarán y buscarán competidores que puedan gestionar su negocio.

¿Cómo podemos mejorar la escalabilidad de nuestras aplicaciones, incluso cuando empezamos a alcanzar estos límites? Obviamente, cuanto antes consideremos la escalabilidad en el ciclo de vida de una aplicación, más fácil será escalarla. Sin embargo, no queremos sobrediseñar nuestras aplicaciones para que sean escalables más allá de lo necesario. En cualquier momento del ciclo de vida, hay muchas técnicas que puedes utilizar para mejorar la escalabilidad de tu aplicación.

Pero antes de que puedas considerar técnicas para escalar tu aplicación, debes poner en forma la disponibilidad de tu aplicación. Nada más importa hasta que des este salto y realices estas mejoras. Si no implementas estos cambios ahora, por adelantado, descubrirás que a medida que tu aplicación escale, empezarás a perder de vista cómo está funcionando, y comenzarán a producirse problemas aleatorios e inesperados. Estos problemas crearán interrupciones y pérdidas de datos, y afectarán significativamente a tu capacidad para construir y mejorar tu aplicación. Además, a medida que aumentan el tráfico y los datos, estos problemas simplemente empeoran. Antes de hacer nada, pon en orden tu gestión de la disponibilidad y los riesgos.

Novedades de la segunda edición

Aunque muchos de los conceptos tratados en este libro son en su mayoría intemporales, muchos (como la informática sin servidor) han tenido que actualizarse para reflejar los cambios del sector en los últimos cuatro años.

Además, he pasado los últimos años viajando por todo el mundo hablando y dando conferencias sobre estos temas. He aprendido mucho de las diversas interacciones con clientes y otros expertos, y he incorporado gran parte de lo aprendido a esta edición.

También se ha añadido a este libro una amplia actualización sobre la utilización de la nube.

Por último, el contenido se ha reestructurado y reorganizado considerablemente con respecto a la primera edición para que la información sea más accesible y pertinente.

Utilizar la nube

Los servicios basados en la nube están creciendo y expandiéndose a velocidades extremadamente altas. El software como servicio (SaaS) se está convirtiendo en la norma para el desarrollo de aplicaciones, principalmente por la necesidad de proporcionar estos servicios basados en la nube. Las aplicaciones SaaS son especialmente sensibles a los problemas de escalado debido a su naturaleza multiinquilino.

A medida que nuestro mundo cambia y nos centramos cada vez más en servicios SaaS, servicios basados en la nube y aplicaciones de gran volumen, el escalado adquiere cada vez más importancia. No parece haber un final a la vista para el tamaño y la complejidad hasta los que pueden crecer nuestras aplicaciones en la nube.

Los mismos mecanismos que hoy son tecnología punta para gestionar la escala, mañana no serán más que inquilinos básicos, y las soluciones a los problemas de escala del mañana harán que las soluciones de hoy parezcan simplistas y minimalistas. Nuestra industria exigirá sistemas y arquitecturas cada vez más complejos para gestionar la escala del mañana.

Naturalmente, con el paso del tiempo, parte del material de este libro quedará anticuado. Mi intención es proporcionar todo el contenido posible que resista el paso del tiempo.

Servicios frente a microservicios

Hay mucha controversia en la industria sobre el uso de los términos servicio y microservicio. A mí personalmente no me gusta el término microservicio porque implica un tamaño específico de un servicio que no es necesariamente una suposición saludable. Muchos servicios son pequeños, y algunos son verdaderamente "micro", pero muchos son también mucho más grandes. La determinación del tamaño adecuado se basa en el contexto y está sujeta a muchas preocupaciones y criterios,¹ y en mi opinión el uso del término microservicios sesga este debate. Sin embargo, reconozco que el término microservicio ha ganado gran popularidad en la industria.

También hay personas que encasillan el uso del término servicio como parte del término SOA y encasillan aún más estos términos para referirse a un tipo concreto de oferta de arquitectura que fue popular hace una década o más. Estas comparaciones me parecen inexactas y confusas.

Mi preferencia personal es utilizar el término servicio, pero reconozco que mucha gente utiliza el término microservicio. Así que tiendo a utilizar ambos términos en mis conversaciones con otras empresas, dependiendo del contexto. En mi opinión, ambos términos significan exactamente lo mismo.

Sin embargo, hay otro uso de la palabra servicio que merece la pena comentar. Es cuando te refieres a un servicio externo, como cuando dices "Amazon ofrece el servicio Amazon S3". Este uso de la palabra servicio es aparentemente distinto, y parece un uso diferente de la palabra servicio, pero en realidad es lo mismo. Un "servicio" es un módulo de software que proporciona una funcionalidad muy específica y los datos que soportan esa funcionalidad. Que el servicio lo escriban tus desarrolladores o los ingenieros de Amazon es irrelevante. Sin embargo, reconozco que a veces es importante distinguir entre estos dos tipos de servicios.

Así es como utilizaré estos términos en este libro. Utilizaré ambos términos indistintamente, dependiendo del contexto. Definitivamente, en este libro verás mi predisposición hacia la palabra servicio. Debes asumir que ambos términos significan exactamente lo mismo. Cuando me refiera a un tipo concreto de servicio prestado por otra empresa, como un servicio en la nube, así lo indicaré. En estos casos, verás el uso de términos como "servicio AWS" o "servicio en la nube" o "servicio SaaS".

Experiencias digitales modernas de los clientes

En nuestro mundo digital moderno, las aplicaciones de software se convierten en la cara de nuestra marca y nuestra empresa. La forma en que nuestros clientes interactúan con nosotros es a través de nuestro software. Nuestras aplicaciones no son sólo una parte de la experiencia del cliente. En muchos casos, son toda la experiencia del cliente. El software es fundamental para nuestro éxito, y los clientes modernos esperan que nuestras aplicaciones también sean modernas. La forma en que nuestros clientes perciben nuestras marcas y nuestra empresa depende en gran medida de cómo perciben nuestro software.

Una aplicación no moderna

Considera este ejemplo: mi hijo tiene una aplicación en su smartphone que tiene que utilizar para obtener algunas de sus prestaciones médicas. Es una aplicación gubernamental, creada y gestionada por el gobierno de EEUU.

Esta aplicación no funciona siempre. Cuando inicias la aplicación a una hora extraña del día, recibes un mensaje de error. El mensaje de error dice: "Esta aplicación sólo está disponible para su uso entre las 9 y las 17 horas, de lunes a viernes, hora del Este".

Sí, es cierto. Se trata de una aplicación de software móvil en su smartphone, y el software está desactivado excepto durante el horario laboral de la Costa Este.

¿Puede funcionar tu empresa con una aplicación como ésta? ¿Puede funcionar con este tipo de restricción en su uso? ¿Puede cualquier empresa comercial poner límites como éste a sus clientes y seguir funcionando?

No, apuesto a que no hay ni una sola empresa comercial que pueda sobrevivir y tratar a sus clientes de esta manera. En lugar de eso, tenemos que proporcionar a nuestros clientes experiencias memorables. Nuestras aplicaciones deben funcionar siempre que nuestros clientes quieran utilizarlas. Todo tiene que funcionar el 100% del tiempo, 24 horas al día, 7 días a la semana. Si no, decepcionamos a nuestros clientes, y los clientes decepcionados se van.

Navegar por este libro

Gestionar la escala no es sólo gestionar el volumen de tráfico: también implica gestionar el riesgo y la disponibilidad. A menudo, todas estas cosas son formas distintas de describir el mismo problema, y todas van de la mano. Por tanto, para debatir adecuadamente sobre la escala, debemos considerar también la disponibilidad, la gestión del riesgo, los procesos del equipo/organización y los paradigmas de la arquitectura moderna, como los microservicios y la computación en nube.

Como tal, este libro está organizado en cinco partes principales, cada una de las cuales representa un principio fundamental de la arquitectura a escala. Echemos un vistazo a cada una de ellas.

Principio 1. Disponibilidad: Mantener la disponibilidad en las aplicaciones modernas

El software moderno debe mantener un alto nivel de disponibilidad. Los clientes no toleran las interrupciones. Si tu aplicación no funciona cuando tu cliente la necesita, no seguirá siendo cliente durante mucho tiempo.

La Parte I trata de la importancia de la disponibilidad de las aplicaciones para nuestros clientes, y de cómo se ve afectada por el escalado de las aplicaciones. Comprender, medir y mejorar la disponibilidad son los temas centrales de estos capítulos.

Los capítulos de esta parte incluyen:

• Capítulo 1, Comprender, medir y mejorar tu disponibilidad

• Capítulo 2, Dos Errores de Altura-Tener Espacio para Recuperarse de los Errores

Principio 2. Arquitectura moderna de aplicaciones: Utilización de servicios

El software moderno requiere el uso de arquitecturas de aplicación modernas. Las arquitecturas de aplicaciones modernas requieren alejarse de las aplicaciones monolíticas y adoptar arquitecturas basadas en servicios.

Las aplicaciones monolito son extremadamente difíciles de escalar, tanto desde el punto de vista del escalado del tráfico como desde el punto de vista de tu capacidad para escalar el tamaño de tu organización para trabajar en la aplicación. Cuanto mayor sea el monolito, más lento será realizar cambios en la aplicación, menos personas podrán trabajar en ella y gestionarla eficazmente, y mayor será la probabilidad de que las variaciones y el crecimiento del tráfico repercutan negativamente en la disponibilidad.

Las arquitecturas orientadas a servicios resuelven estos problemas proporcionando una mayor flexibilidad de escalado en función de las necesidades de tráfico. Además, proporcionan un marco escalable para permitir que organizaciones de desarrollo más grandes trabajen en la aplicación, permitiendo que las propias aplicaciones se hagan más grandes y complejas.

Los capítulos de la Parte II incluyen:

• Capítulo 3, Utilizar los servicios

• Capítulo 4, Servicios y datos

• Capítulo 5, Afrontar los fallos del servicio

Principio 3. Organización: Adaptar tu organización a las aplicaciones modernas

No puedes construir software moderno a menos que tu organización de desarrollo utilice procesos y procedimientos modernos. Esto incluye las responsabilidades de propiedad del servicio y los procesos de desarrollo.

No importa lo escalable que sea tu aplicación; no puedes escalar tu aplicación si tu organización de desarrollo no está estructurada para soportarlo, o si tu organización no tiene la cultura adecuada para impulsar una mayor disponibilidad y una mayor escalabilidad.

Organizar tus equipos para apoyar mejor tus necesidades de escalabilidad creará una cultura que apoye las necesidades de escalabilidad de tu aplicación.

Los capítulos de la Parte III incluyen:

• Capítulo 6, Apropiación del Servicio-STOSA

• Capítulo 7, Niveles de servicio

• Capítulo 8, Acuerdos de nivel de servicio

Principio 4. Riesgo: Gestión de riesgos para aplicaciones modernas

No puedes eliminar todos los riesgos de un sistema. Simplemente no es posible. Todos los sistemas complejos tienen un riesgo inherente. En cambio, debemos aprender a gestionar el riesgo y utilizarlo como herramienta para evaluar la deuda técnica y tomar decisiones sobre las mejoras de las aplicaciones.

Comprender el riesgo, medirlo y priorizar las actividades en función del riesgo medido son herramientas importantes para crear aplicaciones de gran escala y alta disponibilidad.

Los capítulos de la Parte IV incluyen:

• Capítulo 9, Utilizar la gestión de riesgos en la arquitectura a escala

• Capítulo 10, Días de juego

• Capítulo 11, Construir sistemas con riesgo reducido

Principio 5. La Nube: Utilizar la Nube

La alta disponibilidad en una aplicación moderna requiere un escalado ágil. Ya no podemos permitirnos tener un exceso de capacidad de infraestructura para satisfacer las necesidades máximas de nuestra aplicación. En su lugar, debemos asignar y consumir dinámicamente recursos de infraestructura, bajo demanda, en función de nuestras necesidades actuales.

Las infraestructuras dinámicas, y las aplicaciones que pueden soportar y optimizar infraestructuras dinámicas, son un componente arquitectónico crítico para crear aplicaciones de gran escala y alta disponibilidad.

Las infraestructuras dinámicas son la ventaja fundamental de la nube pública. Utilizar la nube pública es esencial para mantener tu aplicación altamente disponible a escala.

Los capítulos de la Parte V incluyen:

• Capítulo 12, Primeros pasos Arquitectura a escala con la nube

• Capítulo 13, Cinco tendencias de la industria cambiadas por la nube

• Capítulo 14, Tipos de SaaS y Tenencia

• Capítulo 15, Distribuir tu aplicación en la nube de AWS

• Capítulo 16, Infraestructura gestionada

• Capítulo 17, Asignación de recursos en la nube

• Capítulo 18, Sin servidor y funciones como servicio

• Capítulo 19, Informática de perímetro

• Capítulo 20, Impacto geográfico en el uso de la nube

Estos son los cinco principios fundamentales para crear aplicaciones que satisfagan las necesidades modernas de nuestros clientes. Estos principios constituyen la base de la Arquitectura a Escala.

Recursos en línea

El sitio web Architecting for Scale(www.architectingforscale.com) ofrece información adicional sobre este libro, incluidos enlaces a material complementario. Puedes encontrar más información sobre mí en mi sitio web www.leeatchison.com, y también puedes seguir mi blog en www.leeatscale.com.

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas:

Consejo

Este elemento significa un consejo o sugerencia.

Nota

Este elemento significa una nota general.

Aprendizaje en línea O'Reilly

Nota

Durante más de 40 años, O'Reilly Media ha proporcionado formación tecnológica y empresarial, conocimientos y perspectivas para ayudar a las empresas a alcanzar el éxito.

Nuestra red única de expertos e innovadores comparten sus conocimientos y experiencia a través de libros, artículos, conferencias y nuestra plataforma de aprendizaje online. La plataforma de aprendizaje en línea de O'Reilly te ofrece acceso bajo demanda a cursos de formación en directo, rutas de aprendizaje en profundidad, entornos de codificación interactivos y una amplia colección de textos y vídeos de O'Reilly y de más de 200 editoriales. Para más información, visita http://oreilly.com.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Norte
• Sebastopol, CA 95472
• 800-998-9938 (en Estados Unidos o Canadá)
• 707-829-0515 (internacional o local)
• 707-829-0104 (fax)

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Puedes acceder a esta página en https://oreil.ly/architecting-for-scale-2e.

Envía un correo electrónico a [e-mail] para comentar o hacer preguntas técnicas sobre este libro.

Para más información sobre nuestros libros, cursos, conferencias y noticias, consulta nuestro sitio web en http://www.oreilly.com.

Encuéntranos en Facebook: http://facebook.com/oreilly

Síguenos en Twitter: http://twitter.com/oreillymedia

Míranos en YouTube: http://www.youtube.com/oreillymedia

Agradecimientos

Aunque hay más personas que ayudaron a hacer posible este libro de las que podría enumerar aquí, quiero mencionar a varias personas que me fueron especialmente útiles:

• Ken Gavranovic, la palabra amigo no basta para describirte. Confía siempre en el poder de los monos.

• Bjorn Freeman-Benson, que me apoyó significativamente en las primeras fases del desarrollo de la primera edición de este libro, y que me brindó oportunidades en New Relic que me ayudaron a obtener las ideas que necesitaba para este libro. Me alegro mucho de que nuestra amistad haya continuado más allá de aquellos días en los que trabajamos juntos directamente.

• Kevin McGuire, que ha sido un amigo y confidente. Empezamos juntos en New Relic, y fue su previsión e imaginación lo que ha ayudado a dar a mi carrera el enfoque y la dirección necesarios que hoy me guían.

• Abner Germanow, Darren Cunningham, Jay Fry, Bharath Gowda y Robson Grieve, que se arriesgaron conmigo y lucharon para conseguirme mi puesto de liderazgo de pensamiento en New Relic. Los días que trabajé con todos vosotros fueron, con diferencia, los más divertidos, gratificantes y personalmente satisfactorios que he tenido nunca. Echo mucho de menos esos momentos. Abner en particular, sin ti no tendría la carrera que tengo hoy. Me guiaste en este nuevo papel y me ayudaste a pasar de ingeniero y arquitecto a estratega, experto y líder de opinión. Gracias por creer en mí y guiarme en ese camino.

• Jim Gochee, que me introdujo en la magia que era New Relic, como producto y finalmente como carrera.

• Lew Cirne, cuya visión nos ha dado a New Relic y a mí una carrera y un hogar. La alegría y el entusiasmo que te embargan después de reunirte con Lew cara a cara son muy contagiosos y te dan mucho poder. No es de extrañar que New Relic tenga tanto éxito.

• Kevin Downs, mi amigo y compañero de nube. Saluda al ratón de mi parte. Ah, y por cierto, los contenedores mandan.

• Brandon SanGiovanni, amigo mío. Desde MLB hasta Marvel y Mickey, te has enfrentado en primera persona a muchos de los retos de los que hablo en este libro, ¡y sigues vivo y sonriendo! Gracias por tu apoyo, tus conocimientos y, lo que es más importante, tu amistad.

• Abbas Haider Ali, a quien respeto mucho. Ambos somos líderes de opinión en el sector, y es estupendo tener a alguien con quien intercambiar ideas y de quien recibir sugerencias. Su aportación en los primeros borradores de este libro lo ha mejorado sustancialmente. Muchas gracias.

• Kurt Kufeld, que fue mi mentor y me ayudó a encajar en ese mundo extraño, caótico, desafiante, agotador y, en última instancia, enormemente gratificante llamado Amazon.

• Greg Hart, Scott Green, Patrick Franklin, Suresh Kumar, Colin Bodell y Andy Jassy, que me dieron oportunidades en Amazon y AWS que nunca habría imaginado.

• Brian Anderson, mi editor original, y Kathleen Carr, mi editora actual en O'Reilly. Juntos, son los responsables de que este libro y muchos otros proyectos de O'Reilly Media se hagan realidad. Brian hizo posible la primera edición de este libro. Kathleen me animó y me permitió crear la segunda edición, muy ampliada, junto con varios cursos, formaciones y sesiones de conocimiento.

• Amelia Blevins, de O'Reilly, que hizo importantes sugerencias editoriales sobre el formato, la maquetación y el contenido de esta segunda edición ampliada del libro. Estas sugerencias supusieron una enorme diferencia en la calidad y legibilidad del libro. Si te gusta la nueva estructura de esta segunda edición, tienes que agradecérselo a Amelia.

A todas las personas que se pusieron en contacto conmigo tras leer la primera edición de este libro, dándome sus elogios, ánimos y sugerencias, les doy las gracias por ayudarme a mantener la motivación y darme ideas para las mejoras que se han introducido en esta segunda edición.

A mi familia, y especialmente a mi esposa, Beth, que es mi luz y guía constantes en esta vida que tenemos juntos. Mis días son más brillantes y mi camino más claro porque ella está conmigo.

A todas estas personas, y a todas las que no he mencionado, mi más sincero agradecimiento.

No puedo terminar sin mencionar también a los peludos: Issie, la spaniel roncadora, y Abbey, la alegre corgi. Y, por último, a Budha, el gatito loco, que ha contribuido a este libro con más de una errata.

¹ Hablo del dimensionamiento de los servicios con más detalle en "Dividir en servicios".