PactFlow: Self-Hosted vs SaaS

Hola de nuevo! Damos la bienvenida a la segunda entrega de la serie Rumbo a Pactflow Enterprise !

En esta ocasión, hablaremos de la clásica duda Self-Hosted vs SaaS: ¿qué opción se ajusta mejor a mis necesidades? ¿Tengo los conocimientos y recursos necesarios para alojar mi propia instancia de PactFlow? ¿A qué problemas me enfrentaré al elegir una u otra?

Spoiler: no hay una respuesta sencilla, ni una solución que funcione para todas las situaciones. Por ello, vamos a estructurar el artículo en diferentes puntos clave, y dentro de esos puntos, analizaremos las diferencias entre cada enfoque.

Intentemos resumir qué debemos tener en cuenta para responder con confianza a la pregunta: ¿SaaS o Self-Hosted para PactFlow Enterprise?

Una aclaración rápida

Antes de nada, creo que tiene sentido comenzar por el principio, con una definición de lo que en este artículo referimos como “Self-Hosted” y “SaaS”..

SaaS

El software como servicio (SaaS) es un modelo de distribución en el que el software se licencia por suscripción y se aloja en un centro de datos remoto. Puedes pensar en ello como "software bajo demanda".

Tendrás una instancia de PactFlow, accesible y privada para tu uso, alojada en los centros de datos de PactFlow/SmartBear.

Self-Hosted

Al seguir un modelo self-hosted, la instancia de PactFlow estará alojada en nuestra propia plataforma privada. Se basaría en ejecutar tu instancia privada de una aplicación donde toda la configuración relativa a servidores, redes, etc. es gestionada por ti mismo.

En este artículo, utilizaremos el término self-hosted para hablar de despliegues utilizando plataformas en la nube o in situ (on-premise)

Podríamos hacer uso de la versión on-premise de PactFlow Enterprise para desplegarla en una plataforma en la nube como AWS, Azure o Google Cloud. O podríamos ejecutar PactFlow en nuestras propias instalaciones, haciendo uso de nuestros propios centros de datos físicos para alojar el producto al completo. Si algún detalle aplica específicamente a on-premises o cloud, lo indicaremos.

Implantación

La primera y más obvia pregunta: ¿cómo de complejo sería poner en marcha una instancia de PactFlow?

Para el enfoque SaaS, el proceso es bastante sencillo. Una vez que creas una cuenta con PactFlow, el servicio estará listo y tendrás acceso a tu instancia casi al instante y desde cualquier lugar. PactFlow puede manejar la gestión de los usuarios, pero se recomienda como primer paso configurar el acceso SSO. Puedes delegar en Google o GitHub con una configuración bastante simple y directa o utilizar cualquier proveedor IdP SAML 2.0. Para esta última opción, recuerda que necesitarás coordinarte con el equipo de soporte, puedes encontrar más información aquí, en la documentación oficial de PactFlow.

Aparte de eso, solo tendrás que preocuparte por tu uso de PactFlow. Puedes olvidarte de cualquier tema relacionado con la gestión de la plataforma.

En el caso de la opción self-hosted, el proceso es mucho más largo y necesita de una planificación dedicada. Hará falta tener un equipo con experiencia en la plataforma que se va a utilizar para alojar PactFlow.

La arquitectura necesaría para alojar PactFlow no es precisamente complicada, pero tu equipo será responsable de desplegar, actualizar, mantener y dar soporte a la plataforma. El equipo deberá lidiar con la configuración del disaster recovery, backups, etc. y también tener conocimientos sobre PactFlow para trabajar en la configuración y en la corrección de errores. Aunque es mucho trabajo, también es cierto que tendrás mucho más control sobre tus datos.

****Para cualquiera de las dos situaciones, necesitarás contar con un equipo especializado en PactFlow y Contract Testing.****Con SaaS, evitarás todas las tareas relacionadas con el mantenimiento de la plataforma, pero tendrás que trabajar igualmente todas las integraciones y configuraciones requeridas para poder implantar el framework. Podemos decir que la única diferencia que encontrarás cuando optas por la opción self-hosted es que necesitarás un rol extra con conocimientos en plataforma de despliegue (AWS en el caso que utilizaremos aquí como ejemplo). Así que prepárate para contar con tu equipo con algunas personas expertas en Contract Testing 😜

Echemos un vistazo rápido a la arquitectura y los requisitos, para que puedas tener una idea de a qué te enfrentarías con un enfoque self-hosted.

Arquitectura

El siguiente diagrama refleja una arquitectura estándar para PactFlow, asumiendo que estamos desplegando usando los servicios de AWS con EKS y PostgreSQL RDS. Self-hosted, pero en la nube.

Por supuesto, esto es solo un ejemplo, podrías estar usando EC2 en lugar de EKS, o no estar utilizando AWS en absoluto y optar por Google Cloud, o Azure, o incluso evitar la nube y usar tu propio Openshift on-premise.

En nuestro diagrama de arquitectura, estamos reflejando el despliegue en una sola región, pero utilizando múltiples AZ (availability zones). Para implementar una buena estrategia de recuperación frente a desastres (disaster recovery), deberíamos al menos extender esta solución a dos regiones, replicando la misma arquitectura. PactFlow es una aplicación sin estado, así que al menos no tendrás que preocuparte sobre la configuración de sesiones persistentes (sticky sessions) o similares.

Cualquier equipo con experiencia en AWS puede crear una arquitectura similar con bastante rapidez.

Requisitos del sistema

Otro de los puntos clave a tener en cuenta antes de tomar una decisión: ¿qué tipo de infraestructura necesito para ejecutar PactFlow?

Los requisitos de PactFlow son bastante razonables, no es un producto con un consumo intensivo de recursos:

Si quieres profundizar más en este tema, siempre puedes revisar la documentación oficial de PactFlow

Ten en cuenta que estos serían los requisitos mínimos, pero vamos a necesitar escalar los recursos según el uso que hagamos de la herramienta. Y eso nos lleva al próximo tema a tratar en este artículo…

Escalabilidad

Al optar por SaaS, nos desharemos de toda la responsabilidad relacionada con la escalabilidad, recayendo sobre PactFlow/SmartBear. En función de la licencia adquirida, que está directamente relacionada con los usuarios activos previstos, se preparará la configuración de tu instancia. En conclusión, no tendrás que dedicar ni un minuto a pensar en esto.

Por otro lado, cuando se utiliza el enfoque de self-hosted, si serás responsable de la escalabilidad de la plataforma. PactFlow comparte una regla simple para hacer tus propios cálculos basándose en los usuarios activos.

1 unidad de procesado = 1 CPU, 256 MiB de memoria

1 unidad de base de datos = 1 CPU, 256 MiB de memoria, 1 GiB de almacenamiento (por semana), 25 escrituras/sg, 10 lecturas/sg

Por cada 500 usuarios activos*, deberías incrementar tu capacidad total de procesado en una unidad, y la capacidad del servidor de base de datos en una unidad. * Los usuarios activos se definen como un perfil que se conecta a PactFlow diariamente o que realiza commits de código que dispararían una build de CI integrada con PactFlow.

Pero, por supuesto, siempre será mejor monitorear la plataforma y escalar de manera dinámica.

Por suerte, los requerimientos de PactFlow no son muy elevados, lo que facilita mucho manejar la escalabilidad. De todas formas es un punto crucial y el equipo responsable debería ser siempre consciente del estado y necesidades de recursos de la plataforma. Puedes encontrar más información en la documentación oficial de PactFlow.

Costes y presupuesto

Tema controvertido y (¡oh sorpresa!) sin una respuesta clara. Cada enfoque tiene sus pros y contras, pero el más delicado es el relacionado con el equilibrio entre los costos de entrada y los costos a largo plazo.

SaaS tiene un costo de entrada más bajo. Es bastante obvio, seguirás un modelo de suscripción, y tendrás la plataforma disponible desde el primer pago. No es necesario gastar una gran cantidad de dinero por adelantado, aunque a cambio estarás pagando tu tarifa mensual o anual de forma continuada. Es una gran opción para mantener bajos los costes al principio.

Por otra parte, el enfoque self-hosted es costoso al inicio, necesitarás proporcionar la infraestructura, y cubrir todo el trabajo relativo a la configuración e implementación. Pero a largo plazo es donde empiezan a aparecer matices que hacen que dar una respuesta a la pregunta inicial de esta sección no sea tan sencillo.

Si hablamos de on-premise, los costos siempre van a ser más altos. No es solo el mantenimiento de la plataforma, sino también del hardware. No hay ninguna duda en este punto.

Pero la situación puede ser diferente si estás alojando tus servicios en la nube, especialmente si ya tienes un gran volumen de aplicaciones desplegadas. El precio por recurso mejora significativamente en función del número de recursos utilizados, haciendo que los costos relacionados con hardware/servidores disminuyan significativamente.

Por supuesto, aún necesitarás personal para mantener la plataforma, pero probablemente ya tengas un equipo de plataforma en este contexto (ten en cuenta aún así que esto supondría un sobrecosto operativo para el equipo, así que planifica en consecuencia).

La cuestión es que, en algunas situaciones, un self-hosted basado en la nube podría ser una opción más económica a largo plazo

Mantenimiento y actualización

Como podrás imaginar, el mantenimiento y la actualización cuando se opta por SaaS será responsabilidad exclusiva de SmartBear/PactFlow. Estos procesos deberían ser invisibles para ti como cliente. Para el mantenimiento y actualización de la plataforma, PactFlow seguirá el procedimiento clásico de establecer tiempos de inactividad planificados y notificar con suficiente tiempo de antelación.

En cuanto a la opción self-hosted, una vez más, tu equipo será el responsable de todo el mantenimiento y actualización de la plataforma y la aplicación. No solo necesitarás un equipo con experiencia en la plataforma utilizada para el despliegue, sino también con experiencia en PactFlow. El equipo de soporte deberá tener recursos para poder lidiar con cualquier tipo de problema relacionado con el producto.

La gestión de backups, o copias de seguridad, también estaría de tu lado. Pero es un proceso bastante sencillo, únicamente es necesario respaldar las instancias de PostgreSQL.

En nuestra experiencia, un enfoque que está funcionando bastante bien es crear un equipo dedicado especializado en PactFlow y Contract Testing. Este equipo será responsable del mantenimiento y la actualización, trabajando mano a mano con el equipo de plataforma. Siendo también el equipo responsable de la implementación de la metodología, la capacitación de equipos de desarrollo, el soporte y el seguimiento de las métricas de uso en toda la organización.

Puedes encontrar más información en este artículo oficial de PactFlow, o incluso ver en Youtube el video sobre el que charlamos sobre un caso real de implantación.

Soporte

El soporte de la plataforma no será una de tus preocupaciones cuando optes por utilizar la versión SaaS, toda la responsabilidad estaría del lado de SmartBear/PactFlow. Tendrás un canal de comunicación dedicado para notificar cualquier tipo de problema, aunque lo normal sería que no necesites usarlo demasiado.

La situación cambia bastante cuando decides alojar tu propia instancia de PactFlow en tu plataforma. El producto se distribuye como una imagen Docker, y eso da una enorme flexibilidad en términos de opciones sobre cómo ser desplegado. Esa flexibilidad viene con un precio, y el precio es que el equipo de PactFlow proporcionará soporte únicamente a temas relacionados con la aplicación, pero nada relacionado con las infraestructura o componentes externos que viven fuera de la imagen de docker.

Algunos ejemplos de temas que están cubiertos podrían ser problemas de configuración, interpretación de logs, y diagnóstico del comportamiento de la aplicación. Pero cosas como problemas de red, orquestación de despliegues, o herramientas de automatización de infraestructura están totalmente fuera del alcance. Por supuesto, el equipo de PactFlow hará todo lo posible para ayudar, pero sería imposible para ellos intentar cubrir todos los factores externos.

Puedes leer más sobre la política de soporte aquí.

Seguridad

Ahora nos toca adentrarnos en la que probablemente sea, junto a la relacionada con costes, la sección más controvertida del artículo.

Antes de saltar a la sección self-hosted, me gustaría dar mi punto de vista sobre el enfoque SaaS. Al contrario de lo que defiende la creencia popular, no tiene por qué ser (más) arriesgado almacenar tus datos en la nube.

Veamos algunos de los puntos más destacables sobre la plataforma SaaS de PactFlow::

• PactFlow SaaS está completamente alojado en la región ap-southeast-2 de AWS (Sídney, Australia), lo que significa que está protegido por todos los controles de seguridad del centro de datos de AWS.
• La plataforma principal utiliza diferentes servicios de AWS, todos ellos certificados con los más altos estándares de seguridad (EC2, Lambda, Cognito, Route53, S3...)
• La comunicación está cifrada en tránsito y en reposo, incluyendo el almacenamiento en S3 utilizando AES-256 (considerado suficiente para datos TOP SECRET por la NSA).
• La autenticación de dos factores es obligatoria para todos los usuarios, y las claves de acceso se rotan regularmente. Está disponible el acceso SSO SAML 2.0 y cada acción en la plataforma se registra en logs inmutables. Incluso hay herramientas de análisis que detectan cualquier actividad sospechosa, y auditorías de pruebas de penetración de terceros independientes.
• La plataforma completa cumple con las políticas de CIS IG 1 y se espera que obtenga la certificación SOC2 en el cuarto trimestre de 2023.

Si quieres tener más información sobre como implementan su seguridad puedes consultar esta sección de su web: Seguridad de PactFlow.

Así que sí, podemos asumir que el entorno SaaS de PactFlow es bastante seguro.

PERO... (siempre hay un pero...)

Siempre tendrás más control sobre tus datos en una configuración self-hosted.

Incluso si decides alojarlo en la nube, como hicimos en la sección de arquitectura, te asegurará que eres el único poseedor de toda la información en PactFlow.

• Podrás aprovechar los estándares de seguridad de la nube de AWS (o de cualquier otro proveedor) mientras mantienes el control total de tu información.
• Podrás hacer que PactFlow esté disponible únicamente para tu red privada, mejorando significativamente la seguridad, ya que no necesitaría estar expuesto a internet.
• No necesitarás abrir la comunicación desde tus pipelines añadiendo a tus allowlists la IP de PactFlow SaaS.

Estos tres puntos cobran aún mayor protagonismo si hablamos de un enfoque on-premise. La conectividad con tus propios servidores no podría ser más privada, y los datos se almacenarán en tu propio hardware. Pero ojo, ya que con este enfoque también estarás solo para toda la gestión de seguridad, y mantenerse al día con las últimas actualizaciones sobre seguridad es tan imprescindible como exigente.

Al final todo depende del contexto, muchos de nuestros clientes han optado por un enfoque de self-hosting debido principalmente a estos últimos matices. A pesar de que prácticamente todas las secciones anteriores favorecen al enfoque SaaS, la seguridad tiene un peso muy importante en algunas situaciones. Otro tema a tener en cuenta serían posibles restricciones sobre la región donde se almacenan sus datos, pero eso está ya relacionado con temas de regulaciones, no con aspectos técnico, y no es el objetivo de este artículo el adentrarnos ahí.

Composición del equipo

No teníamos en mente incluir esta sección, pero la vamos a incluir como bonus. Veamos un resumen rápido y sencillo de los roles que pensamos que necesitarás para la adopción del producto y la metodología. Para cualquiera de los dos enfoques, necesitarás un equipo experto en contract testing para ayudarte con el proceso. Si optas por self-hosted, ese equipo también debería incluir al menos a un experto en plataforma donde piensas alojar PactFlow, sería solo un rol más que para adoptar el enfoque SaaS.

Un equipo estándar de adopción de Contract Testing podría estar compuesto por los siguientes roles:

• Arquitecto de Soluciones: Se encargaría del despliegue y mantenimiento del producto, por lo que necesitarías un experto en la plataforma que va a alojar PactFlow. Y no solo la plataforma (AWS/Google Cloud/Azure/OpenShift) sino también las tecnologías que la van a rodear, que podrían ser por ejemplo Kubernetes, Terraform, Istio, CertManager o cualquier otro componente utilizado para la orquestación. Este perfil sería solo necesario en un enfoque self-hosted.
• ****SME (Subject matter expert): Rol que posee una comprensión detallada y exhaustiva sobre Contract Testing y PactFlow. Actuará como líder del equipo técnico y del grupo de práctica. Debería ser un perfil con buenas habilidades de comunicación y experiencia en gestión de equipos.
• DevOps: Para el desarrollo del CI/CD y la integración de los webhooks. Especializado en la implementación de pipelines con la herramienta corporativa de automatización (Jenkins, Bamboo, GitHub Actions…).
• Ingenieros: Al cargo del proceso de desarrollo (y adopción) del contract testing. Necesitan tener un sólido conocimiento sobre cómo implementar los tests, utilizando los lenguajes de tu stack y, a ser posible, buenas habilidades comunicativas para transferir conocimiento a los miembros del resto equipos.

Como podrás imaginar, ya hemos recorrido este camino unas cuantas veces... tenemos la experiencia para ayudarte con todos los roles clave necesarios para un enfoque self-hosted o SaaS, así que no dudes en contactarnos si estás interesado en comenzar este viaje. Estaremos encantados de ayudar 😊

Conclusión

Si me preguntas a mí, diría que todo se puede reducir a una combinación de las siguientes preguntas clave:

• Seguridad y cumplimiento de regulaciones específicas.
• Control sobre tus datos.
• Madurez de la plataforma en la nube y compromiso con la metodología.

Las dos primeras, relacionadas con la seguridad, las regulaciones y el control sobre los datos, son las más críticas. En algunas industrias es prácticamente innegociable y la opción self-hosted es obligatoria.

Pero si este no es el caso, y podemos evaluar ambas opciones, entonces deberíamos calcular los costos de alojar el producto y lo que yo llamaría "compromiso" con la metodología.

Comenzar con el enfoque SaaS será más asequible, pero a largo plazo, la opción self-hosted puede ser más beneficiosa en algunas situaciones específicas.

Tabla resumen

¡Hasta pronto!

Como siempre, no dudes en contactarnos para cualquier comentario o pregunta, nos encantaría conocer tus opiniones sobre los contenidos compartidos. ¡Y mantente atento/a a más actualizaciones en nuestra serie ‘Rumbo a Pactflow Enterprise’!