Prefacio
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Cuando empecé a indagar en el ámbito del software como servicio (SaaS), esperaba encontrar muchas guías de buenas prácticas. Después de todo, el SaaS no era un concepto nuevo. Había múltiples ejemplos de empresas SaaS de éxito y un sentimiento general de que el SaaS se estaba estableciendo como el modo preferido de entrega para muchas empresas. Para mí, esto significaba que estaría absorbiendo y aplicando un conjunto de pautas y estrategias ya existentes. Sorprendentemente, no fue así.
Cuanto más me adentraba en las soluciones de los clientes y más escudriñaba el sector en busca de orientación, más empezaba a darme cuenta de la poca claridad que había en torno a lo que significaba diseñar, construir y operar entornos SaaS. Creo que parte de esto era el subproducto de la ambigüedad natural que conlleva poner una etiqueta a cualquier tecnología. La falta de absolutos ha creado mucho espacio para definiciones y opiniones contrapuestas sobre cómo debe ser el SaaS. Esto ha abierto la puerta a que empresas con implementaciones y enfoques fundamentalmente diferentes se etiqueten a sí mismas como SaaS. De hecho, sigo viendo que muchas empresas emprenden su viaje hacia el SaaS con opiniones muy diferentes y desalineadas sobre lo que significa para ellas adoptar un modelo de prestación SaaS.
No hay nada inherentemente malo en esto. Está bien tener ideas diferentes sobre lo que significa ser SaaS. Sin embargo, esto se convierte en un problema mayor cuando tienes que trabajar con clientes que te buscan como experto en SaaS. Como experto, no puedes decir a los clientes que construyan lo que quieran. La vaguedad no funciona con equipos que confían en que les indiques estrategias y patrones de buenas prácticas probadas. Para hacer mi trabajo, realmente necesitaba poder entrar en nuestra discusión con un punto de vista claro sobre lo que significa construir una arquitectura y un negocio SaaS de buenas prácticas. Tenía que ser capaz de aportar más definición al panorama del SaaS de forma que ayudara a los equipos a comprender las compensaciones, los patrones de arquitectura y las consideraciones operativas que darían forma directa a su arquitectura multiinquilino. Conseguirlo significaba que tendría que crear una taxonomía clara de los principios y estrategias del SaaS que pudiera abarcar una serie de dominios, cargas de trabajo, perfiles de clientes, etc. En muchos aspectos, también se trataba de alejarse intencionadamente de nociones muy amplias de lo que significaba ser una solución SaaS, definiendo un conjunto más específico de barandillas que pudieran ayudar a las organizaciones a trazar su camino hacia delante.
Fue esta necesidad fundamental la que me hizo emprender un camino de varios años para definir mejor el panorama de la arquitectura SaaS. Lo que empezó con unas cuantas entradas en el blog fue seguido de un torrente de libros blancos, seminarios web, podcasts, vídeos de formación y presentaciones en conferencias. Por el camino, me di cuenta de que los conceptos y principios que defendía estaban calando en más entornos y se aplicaban más ampliamente. Esto me hizo pensar que tal vez había llegado el momento de escribir un libro que reuniera todos los elementos clave de esta orientación en una experiencia integral.
Con este libro, espero poder aportar más definición al debate sobre el SaaS, estableciendo un marco sobre cómo pensar en el SaaS y cómo conectar estos conceptos con las construcciones del mundo real. El objetivo es asegurarnos de que estamos de acuerdo con los principios fundamentales y, a continuación, ilustrar cómo se aplican esos principios en diferentes casos de uso y pilas tecnológicas. Al conectar estos conceptos con tecnologías específicas (Kubernetes, serverless, etc.), podrás ver cómo los matices de las tecnologías individuales pueden tener una influencia significativa en la huella global de tu arquitectura multiinquilino.
Por el camino, crearé una taxonomía clara de los elementos centrales de cualquier entorno SaaS, definiendo un vocabulario para SaaS que nos permita tener un enfoque más universal de cómo categorizar y describir las partes móviles de una arquitectura SaaS. Examinaré toda la gama de mecanismos específicos de la arquitectura SaaS, como el aislamiento de inquilinos, la incorporación, la jerarquización, la identidad, las métricas, la facturación y la partición de datos. Para cada una de estas áreas, veremos ejemplos de cómo podrían aplicarse en diferentes entornos.
El libro también estaría incompleto sin explorar los elementos operativos del SaaS. Como descubrirás, la arquitectura de los entornos SaaS está directamente determinada por los principales objetivos operativos de la empresa (agilidad, innovación, rentabilidad). Veremos esta fuerte correlación a lo largo del libro, esbozando las consideraciones operativas que influirán en la huella de tu entorno SaaS.
En general, considero que este libro representa un buen punto de partida para el debate sobre la arquitectura SaaS. Se propone crear una visión más clara de cómo definimos lo que significa ser SaaS, destacando principios, construcciones y estrategias clave que son fundamentales para dar forma a cómo abordarás la construcción de una arquitectura SaaS de buenas prácticas.
Un paisaje en evolución
Las primeras soluciones multiusuario en las que trabajé tenían una noción muy simple de lo que significaba ser SaaS. Estos entornos solían emplear un modelo en el que los clientes compartían un clúster informático y almacenaban los datos de cada cliente en una base de datos independiente. Sospecho que todavía hay muchos sistemas que utilizan este modelo hoy en día, especialmente en entornos en los que los equipos alojan y gestionan su propia infraestructura SaaS.
Ahora bien, cuando llegó la nube, aportó una nueva dimensión de posibilidades al panorama del SaaS. Los servicios gestionados, el escalado dinámico y la naturaleza de pago por uso de la nube dotaron a los equipos de SaaS de herramientas y mecanismos que se alineaban de forma natural con sus necesidades. Las organizaciones podían aprovechar todas las bondades de la nube para enriquecer el perfil de costes, funcionamiento y agilidad de sus entornos SaaS. En algunos casos, el atractivo de la nube era tan irresistible que algunas empresas equiparaban estar en la nube con ser SaaS (que no lo es).
Puedes imaginar cómo la aparición de la nube abrió un reino totalmente nuevo para los arquitectos de SaaS. Proporcionó a los arquitectos un conjunto mucho mayor de herramientas, servicios y mecanismos operativos que podían agilizar el desarrollo de sus entornos multiinquilino. La nube también permitió a los equipos de SaaS trasladar aún más complejidad operativa a la nube, reduciendo la fricción y la sobrecarga que conllevaba el apoyo y el funcionamiento de un negocio SaaS. También proporcionó mecanismos nativos que promovían la escala, la alta disponibilidad y la eficiencia operativa y de costes.
Este encaje natural entre el SaaS y la nube contribuyó significativamente al mayor atractivo general y a la rápida adopción del modelo de entrega SaaS. Las nuevas empresas de SaaS han podido aprovechar los puntos fuertes de la nube para acelerar el desarrollo de ofertas de SaaS, permitiéndoles trastocar los dominios y segmentos de mercado existentes. Las empresas de SaaS basadas en la nube podían moverse más rápido, conseguir mejores márgenes, captar nuevos mercados e innovar a un ritmo mucho más rápido. Esto, como puedes imaginar, motivó a las empresas de software existentes a acelerar su camino hacia el SaaS, algunas de las cuales consideraron que pasarse al SaaS era fundamental para su supervivencia. También influyó directamente en el comportamiento de los clientes de software, que empezaron a esperar y adoptar la naturaleza de baja fricción y centrada en el valor del modelo SaaS.
Toda esta actividad ha creado una avalancha de adopción de SaaS. También ha creado una importante necesidad de conocimientos y orientación adicionales sobre cómo aplicar estas construcciones de la nube en una arquitectura multiinquilino. La convergencia de estos factores -la necesidad de una orientación mucho más amplia y profunda sobre la arquitectura, el impulso general de la adopción del SaaS y la influencia de la nube- impulsó la demanda de una mayor claridad sobre cómo se diseñan, construyen y operan las soluciones SaaS.
Entonces, ¿qué significa esto para este libro? Lo principal es que el ámbito de las buenas prácticas del SaaS sigue siendo un blanco móvil. La rápida evolución de las empresas de SaaS y la aparición de nuevas tecnologías siguen introduciendo nuevas estrategias, mecanismos y constructos que pueden influir en la orientación futura. Es justo suponer que las buenas prácticas y estrategias del SaaS seguirán transformándose en función del cambiante panorama tecnológico.
¿Para quién es este libro?
Este libro está dirigido a equipos de constructores, arquitectos y operaciones que estén creando, migrando u optimizando soluciones SaaS. Puede que seas nuevo en SaaS y estés buscando los conceptos básicos que te permitan empezar con SaaS, o puede que ya estés inmerso en SaaS y estés buscando cómo aplicar los principios que aquí se describen para mejorar una solución existente. Verás que también he incluido operaciones en esta lista. Aunque partes importantes de este libro se centrarán más en los constructores y arquitectos, existe una clara necesidad de que los equipos de operaciones estén igualmente inmersos en la configuración de las compensaciones y estrategias que se utilizarán para definir la huella de tu experiencia as-a-service. También existe la correspondiente necesidad de que los constructores y arquitectos estén más inmersos en la experiencia de operaciones.
Empiezo intencionadamente estableciendo un conjunto claro de conceptos fundamentales que abarcan todo el libro. Incluso si tienes experiencia con el SaaS, te animo encarecidamente a que inviertas en empezar con estos conceptos fundacionales. Las ideas que se establecen en las primeras etapas del libro desafían algunas de las nociones clásicas de lo que significa ser SaaS, introduciendo terminología y mentalidades que influyen en cada aspecto de cómo diseñas y construyes un entorno SaaS. Los ejemplos que aparecen más adelante en el libro ilustran cómo se realizan y aplican estas opciones y patrones de diseño. Disponer de esta base y tener una buena alineación en torno a estos principios básicos influirá directamente en cómo enfocas la descomposición de los microservicios, el modelo de implementación de tu solución, el modelo de identidad que adoptas, etc. Lo que quiero decir es que, a medida que te adentres en los detalles de la implementación, verás una fuerte conexión entre los principios básicos y las estrategias de implementación subyacentes que puedas adoptar. Basarse en un conjunto común de principios rectores te permitirá a ti y a tus equipos aplicar un conjunto común de valores en todo el diseño, desarrollo y funcionamiento de tu entorno SaaS.
También hay un nivel en el que este contenido sobre SaaS tendrá valor para los líderes y las partes interesadas del SaaS. Aunque pueden estar menos interesados en los detalles técnicos, es probable que se apoyen en los elementos fundamentales del libro para refinar y cristalizar su visión del SaaS. La adopción del SaaS conlleva consideraciones culturales, métricas y dinámicas de equipo, y el éxito de la estrategia SaaS de tu organización dependerá en gran medida de que los líderes estén arraigados en un conjunto común de valores. Éste suele ser uno de los aspectos que más se pasan por alto a la hora de crear un negocio SaaS de primera categoría. Por las mismas razones, puedes imaginar cómo los propietarios de productos y otras personas relacionadas con la visión del SaaS extraerán valor de tener un firme conocimiento de estos principios fundamentales del SaaS.
Una base, no una Biblia
Los principios que trataré en este libro son el subproducto de mis experiencias de trabajo con un gran número de proveedores de SaaS, que abarcan una serie de dominios, experiencias de destino, industrias, etc. Este libro representa los temas, patrones y orientaciones que surgieron de esos proyectos. También he tenido la suerte de estar rodeado de equipos y personas que han ayudado a madurar esta visión.
Sin embargo, es importante señalar que este libro no pretende ser la biblia de facto de todo lo relacionado con el SaaS. Las estrategias y patrones para construir arquitecturas SaaS que aquí se tratan se crearon como punto de partida para aportar más claridad y definición al universo del diseño y la arquitectura multiempresa. En muchos aspectos, me he visto a mí mismo llenando un vacío, encontrando una forma de describir y caracterizar mejor la naturaleza de las soluciones SaaS, sabiendo que pueden existir estrategias alternativas o que podrían surgir en el futuro.
Mi esperanza es que esto dé más visibilidad a estos conceptos, atrayendo a más constructores y arquitectos a un debate más amplio que alinee mejor a otros en torno a estos principios.
Nota
Gran parte de mi experiencia en el ámbito del SaaS se debe a mi trabajo directo y a mi experiencia con la pila de servicios y herramientas de AWS. Esto significa que, a medida que nos adentremos en los detalles, gravitaré de forma natural hacia las herramientas y estrategias de AWS. Sin embargo, la mayoría de los principios y estrategias no son exclusivos de la pila de AWS. De hecho, deberían adaptarse bien a la mayoría de los entornos. También debo señalar que las estrategias y principios que trataré representan mis propias perspectivas, opiniones y puntos de vista. Gran parte de lo que exploraremos está ciertamente influenciado por los conocimientos y prácticas que he ido desarrollando durante mi tiempo en AWS. Sin embargo, lo que finalmente aterrice en este libro no debe considerarse una guía avalada por AWS.
Lo que no hay en este libro
SaaS es un tema amplio que tiene muchos hilos conductores. Si echas un vistazo al índice de este libro, verás que cubro una parte importante del universo SaaS, explorando un espectro bastante amplio de perspectivas de diseño, desarrollo e implementación, incluidos los temas empresariales. De hecho, verás ejemplo tras ejemplo en los que hago hincapié en la conexión entre las estrategias empresariales y tecnológicas del SaaS. Dejo claro que los constructores y arquitectos deben tener un gran interés en utilizar los parámetros empresariales del SaaS para dar forma a la huella de su solución.
Aunque estos elementos empresariales son una parte esencial de la historia del SaaS, también notarás que he evitado intencionadamente profundizar en aspectos específicos del espacio empresarial. Hay libros enteros que exploran las ventas de SaaS, el marketing, la salida al mercado, el modelado de negocio, el mapeo del viaje, las métricas, etcétera. Para mí, estos temas son independientes y se aplican de forma más general al ámbito del SaaS. Aunque tengo una exposición moderada a estas áreas, creo que es mejor tratarlas como temas independientes. Desde luego, sugiero que las organizaciones se familiaricen con los conceptos de SaaS como parte de la creación de un negocio SaaS sólido; simplemente, no los trataré aquí.
También vale la pena señalar que este libro no pretende incluir todas las permutaciones del SaaS. Hay muchas soluciones comerciales de empresa a consumidor (B2C) en las que la gente piensa cuando piensa en SaaS. Aunque puede que sean las más familiares para el ciudadano de a pie, también están diseñadas y construidas en torno a un modelo que, para la mayoría, es atípico. La mayoría de los creadores de SaaS no intentan dar soporte a millones de usuarios. Por lo general, los entornos B2C emplearán sus propias estrategias de diseño únicas que a menudo están hiperoptimizadas en torno a un conjunto especializado de retos de escalado. Por el contrario, una empresa de SaaS de empresa a empresa (B2B) que da soporte a cientos o miles de empresas probablemente adopte un enfoque diferente en cuanto al diseño y la arquitectura de su entorno multiinquilino. Creo que el espacio B2C es interesante, y creo que los conceptos de B2C se solaparán bastante con el conjunto de principios básicos que trataré. Al mismo tiempo, también debo reconocer que hay áreas en las que las estrategias B2B y B2C pueden divergir significativamente. Ofrecer a los inquilinos una infraestructura dedicada, por ejemplo, es una opción completamente válida en un entorno B2B. Es poco probable que ese mismo enfoque sea viable en la mayoría de los entornos B2C.
Convenciones utilizadas en este libro
En este libro se utilizan las siguientes convenciones tipográficas:
- Cursiva
-
Indica nuevos términos, URL, direcciones de correo electrónico, nombres de archivo y extensiones de archivo.
Constant width
-
Se utiliza en los listados de programas, así como dentro de los párrafos para referirse a elementos del programa como nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.
Nota
Este elemento significa una nota general.
Utilizar ejemplos de código
Los ejemplos de código de los capítulos 10 y 11 están disponibles para su descarga en https://oreil.ly/saas-ch10-code y https://oreil.ly/saas-ch11-code, respectivamente. También se proporcionan enlaces en esos capítulos.
Si tienes una pregunta técnica o un problema al utilizar los ejemplos de código, envía un correo electrónico a support@oreilly.com.
Este libro está aquí para ayudarte a hacer tu trabajo. En general, si se ofrece código de ejemplo con este libro, puedes utilizarlo en tus programas y documentación. No es necesario que te pongas en contacto con nosotros para pedirnos permiso, a menos que estés reproduciendo una parte importante del código. Por ejemplo, escribir un programa que utilice varios trozos de código de este libro no requiere permiso. Vender o distribuir ejemplos de los libros de O'Reilly sí requiere permiso. Responder a una pregunta citando este libro y el código de ejemplo no requiere permiso. Incorporar una cantidad significativa de código de ejemplo de este libro en la documentación de tu producto sí requiere permiso.
Agradecemos la atribución, pero en general no la exigimos. Una atribución suele incluir el título, el autor, la editorial y el ISBN. Por ejemplo "Building Multi-Tenant SaaS Architectures por Tod Golding (O'Reilly). Copyright 2024 Tod Golding, 978-1-098-14064-9".
Si crees que el uso que haces de los ejemplos de código no se ajusta al uso legítimo o al permiso concedido anteriormente, no dudes en ponerte en contacto con nosotros en permissions@oreilly.com.
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 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 https://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-889-8969 (en Estados Unidos o Canadá)
- 707-827-7019 (internacional o local)
- 707-829-0104 (fax)
- support@oreilly.com
- https://www.oreilly.com/about/contact.html
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/bldg-multitenant-saas.
Para obtener noticias e información sobre nuestros libros y cursos, visita https://oreilly.com.
Encuéntranos en LinkedIn: https://linkedin.com/company/oreilly-media
Míranos en YouTube: https://youtube.com/oreillymedia
Agradecimientos
He tenido la suerte de estar rodeado, influenciado, apoyado e inspirado por un gran número de personas que han contribuido directa e indirectamente a la creación de este libro. El mejor lugar para empezar es probablemente el principio, remontándome a mis primeros días en AWS, cuando era el nuevo arquitecto de soluciones SaaS contratado para intentar definir y dar forma a una visión de lo que significaba crear ofertas SaaS en la nube. Es en esta época cuando tuve la suerte de ser guiado por Matt Yanchyshyn, que me empujó a profundizar, moverme rápido y ofrecer resultados. Matt tiene la habilidad de pedir mucho, darte espacio para operar e inspirarte a pensar a lo grande. Sus primeros ánimos me encaminaron por esta senda y no estoy seguro de cómo o si habría hecho los primeros progresos que hice sin sus sabias palabras.
Mi capacidad para profundizar y desarrollar mis conocimientos sobre SaaS también ha estado directamente relacionada con las experiencias que he tenido trabajando con empresas de SaaS. Poder entrar en la sala con organizaciones y profundizar en sus soluciones SaaS me expuso a una amplia gama de industrias, dominios, casos empresariales y escenarios de adopción. Los datos, patrones y código que surgieron de estos compromisos fueron y siguen siendo impagables. También he tenido la suerte de estar rodeado de un equipo increíble de arquitectos de SaaS y líderes empresariales que han desempeñado un papel clave en el avance del estado de SaaS y me han ayudado a reevaluar continuamente las estrategias y patrones de buenas prácticas. Hay demasiados para mencionarlos aquí, pero me gustaría destacar a Craig Wicks, Seth Fox, Emily Tyack y Michael Schmidt por su liderazgo y colaboración desde el principio. Adrian De Luca también fue una fuente constante de inspiración, proporcionando orientación y aliento continuos.
Escribir un libro también depende en gran medida de un equipo de colaboradores entre bastidores que recorren este camino contigo. El equipo de O'Reilly ha sido increíble en todas las fases de la creación de este libro. En el centro de gran parte de mis interacciones cotidianas con O'Reilly estaba Melissa Potter. Melissa fue clave en cada parte de la evolución del libro, ayudándome a navegar por el proceso, revisando mis primeros borradores, respondiendo a preguntas y estando siempre ahí con palabras alentadoras de orientación. Louise Corrigan, de O'Reilly, también estuvo ahí desde el principio, guiándome durante las primeras fases de la estructura del libro y apoyándome en decisiones clave a lo largo de todo el proceso. También quiero dar las gracias a los revisores técnicos del libro, Anubhav Sharma, Russell Miles y Toby Buckley. Gracias por invertir vuestro tiempo y compartir vuestras opiniones. Vuestras perspectivas me ayudaron a perfeccionar esta historia e hicieron de éste un libro mejor.
Por supuesto, en el centro de cada viaje que emprendo está mi familia. Aunque nunca han entendido del todo qué es lo que hago, siempre han estado a mi lado animándome a lo largo del camino. Mi mujer, Janine, me ha apoyado en todo lo que he hecho, y este esfuerzo no ha sido una excepción. Sus palabras de ánimo siempre me facilitan seguir adelante. Luego están mis hijos, Chelsea y Ryan. Aunque ya son mayores y siguen sus propios caminos, siguen encontrando formas de alegrarme el día y recordarme lo afortunado que soy.
Get Construir arquitecturas SaaS multi-inquilino now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.