AWS es mejor que tú

Hoy vamos a hablar de un tema interesante y extenso que se puede resumir en la frase “AWS es mejor que tú”. Aunque siendo un poco menos contundentes, realmente vamos a ver por qué es buena idea utilizar servicios gestionados de AWS en vez de desarrollar soluciones propias.

Es un tema complejo, que requiere mucha crítica interna y además requiere un cambio de mentalidad bastante grande. Dada la complejidad del tema, hemos decidido dividir este artículo en varios post. En este primer post, abordaremos la cuestión desde un punto de vista más general, y más adelante nos sumergiremos en ejemplos específicos de servicios gestionados a nivel técnico, explorando sus ventajas y considerando qué se necesitaría para implementar soluciones similares de forma independiente.

¿Qué es un servicio gestionado?

Son servicios en los que AWS se encarga de diversas tareas operativas esenciales, como configuración, mantenimiento, escalabilidad, disponibilidad y seguridad del servicio. Este enfoque libera a los usuarios de la responsabilidad directa de gestionar la infraestructura subyacente, una tarea que recae en el usuario en servicios que generamos nosotros mismos, como en el modelo IaaS (Infraestructura como Servicio).

Para tener una comprensión más clara, aquí están las definiciones de los modelos de servicios que existen en la nube:

• IaaS (Infraestructura como Servicio): proporciona una infraestructura virtualizada a través de internet, donde los usuarios son responsables de la gestión de la capa de aplicación, el sistema operativo, las aplicaciones y los datos.
• PaaS (Plataforma como Servicio): ofrece una plataforma completa de desarrollo y ejecución, con AWS encargándose de la infraestructura subyacente. Los usuarios se centran en el desarrollo de aplicaciones sin preocuparse por la gestión de la infraestructura.
• SaaS (Software como Servicio): proporciona aplicaciones de software completas a través de internet. Los usuarios acceden a estas aplicaciones sin necesidad de instalación ni mantenimiento, ya que todo está gestionado por AWS.
• FaaS (Funciones como Servicio): permite ejecutar funciones individuales de código en respuesta a eventos específicos sin la necesidad de gestionar servidores. Este modelo se centra en la ejecución de código específico, sin preocuparse por la infraestructura.

En resumen, un servicio gestionado en AWS abstrae la gestión operativa de la infraestructura, permitiendo a los usuarios concentrarse en el desarrollo de aplicaciones y servicios sin la carga de la administración directa de la infraestructura.

La escala de AWS

A la hora de evaluar los servicios gestionados de AWS, una de las primeras cosas que debemos comprender es la escala de AWS.

Aunque cada vez es menos común, todavía muchas personas perciben a AWS como un gigante en el mundo del comercio electrónico en lugar de considerarlo como uno de los gigantes tecnológicos más grandes del mundo.

Es común creer que tenemos más experiencia en el campo de TI que AWS y que poseemos un sólido conocimiento en el ámbito On-Premises que AWS no tiene. Sin embargo, AWS fue fundado en 2002, lo que significa que ya lleva 21 años en funcionamiento, y lanzó sus primeros servicios de Cloud Computing puros (S3 y EC2) hace 17 años.

La magnitud de la infraestructura que AWS gestiona es impresionante y ha experimentado un crecimiento extraordinario. En 2014, se estimaba que AWS manejaba 1.4 millones de servidores físicos distribuidos en 11 regiones y 28 zonas de disponibilidad. Sin embargo, al comparar esta cifra con las 33 regiones y 105 zonas de disponibilidad actuales, la escala de AWS se vuelve aún más impactante.

Además, al hablar de una Zona de Disponibilidad (AZ), es importante recordar que en realidad una sola AZ puede albergar múltiples centros de datos. En una región recién lanzada, como la región de España, lo más común es que tengamos un solo centro de datos por AZ, junto con 2 centros de tránsito donde se alojan las interconexiones con Internet y otras regiones de AWS mediante múltiples proveedores.

Sin embargo, en regiones más consolidadas, podemos contar con un mayor número de centros de datos. Por ejemplo, en eu-west-1, la región de Irlanda, se estima que hay más de 10 centros de procesamiento de datos (CPDs), mientras que en us-east-1 (con 6 zonas de disponibilidad) se estima que hay más de 70 CPDs.

El propio esquema de una sola región es bastante impresionante en comparación con la infraestructura habitual de los diferentes CPDs que podemos encontrar.

Además, AWS diseña y fabrica sus propios chipsets, su propio hardware para networking, sus propios protocolos, su propia virtualización y sus propios procesadores.

Motivos para usar un servicio gestionado de AWS.

Ahora que hemos profundizado un poco más en el contexto de AWS, examinemos las razones clave por las que es altamente recomendable optar por los servicios gestionados de AWS.

La infraestructura no es bonita

Soy un apasionado de la infraestructura, me encanta saber cómo funciona un procesador a bajo nivel o detalles de los diferentes servicios, entender cómo funciona un EBS, pero reconozcámoslo, la infraestructura es fea, a la mayoría de la gente no le gusta y lo ve como un mal necesario para su negocio.

Es en este contexto donde los servicios gestionados entran en juego, liberándonos de la necesidad de lidiar con estos problemas. En un entorno de servicio gestionado, el mantenimiento de la infraestructura no recae en nosotros; se nos proporciona automáticamente, permitiéndonos enfocarnos en nuestro negocio en lugar de invertir tiempo y esfuerzo en mantener y mejorar la infraestructura.

Además, al considerar la escala de AWS, se vuelve evidente la ventaja de utilizar servicios gestionados. Están diseñados de manera que aprovechan todas las fortalezas de la infraestructura de AWS. Para comprender el impresionante nivel de alta disponibilidad que puede ofrecer un servicio gestionado de AWS, recomiendo la lectura del whitepaper AWS Fault Isolation Boundaries, donde AWS aborda temas cruciales como la separación del Data Plane y el Control Plane.

Además de la alta disponibilidad, los servicios gestionados, sobre todo en modelos SaaS son altamente escalables, de forma que rápidamente podamos escalar hasta límites inimaginables sin necesidad de provisionar más infraestructura por nuestro lado.

Diseñar infraestructura con estos niveles de disponibilidad y elasticidad es una tarea altamente compleja, y aquí es donde los servicios gestionados demuestran su valía al simplificar este proceso y ofrecer una solución eficiente y robusta.

No nos tenemos que preocupar por la seguridad

De la seguridad en AWS ya hemos hablado otras veces, pero lo realmente interesante en un modelo de servicios gestionados es que podemos delegar la responsabilidad de partes de la seguridad en AWS.

Probablemente, habréis visto la imagen del modelo de responsabilidad compartida de AWS, pero este modelo está basado en IaaS, mientras que los servicios gestionados son PaaS, SaaS o FaaS.

Esto significa que el modelo de responsabilidad compartida en un servicio gestionado es diferente, teniendo AWS más responsabilidades que en el gráfico anterior.

Por eso, cuando hablamos de seguridad me gusta usar más la imagen del CIS que indica el nivel de seguridad dependiendo de modelo de Cloud utilizado (IaaS, PaaS, SaaS o FaaS).

En el caso de los servicios gestionados, gran parte de la seguridad la gestionan los equipos de AWS, como el equipo de Ghostbusters, del que ya hemos hablado y que nos dio esta maravillosa sesión en el re:Invent hablado de cómo acometieron un evento de seguridad como Log4Shell.

Y podemos tomar como ejemplo precisamente el boletín de seguridad de AWS sobre Log4Shell, ya que AWS fue informándonos sobre cómo fue mitigando y solventando esta vulnerabilidad en todos sus servicios.

Un evento como Log4Shell fue bastante complicado de atajar y requirió un montón de trabajo y tiempo para solventarlo. En algunos casos, se tardó bastante tiempo en poder aplicar las medidas de seguridad adecuadas, mientras que los servicios gestionados atajaron el problema rápidamente y sin necesidad de que los clientes interviniesen.

No necesitamos reinventar la rueda

Una de las grandes ventajas de un servicio gestionado, es utilizar una solución válida que ya funciona, que está probada y en la que AWS nos da soporte.

Sé que repito mucho lo de la importancia de la escala, pero cuando AWS diseña un servicio gestionado, lo hace basándose en su experiencia y a la experiencia de sus clientes.

Es bastante habitual que un servicio gestionado mejore o incluso nazca gracias a los requerimientos de uno o varios clientes de AWS. Un servicio gestionado nace para solucionar problemas a multitud de clientes de AWS, esto es bastante importante porque AWS dedica mucho tiempo y recursos a generar los servicios gestionados, orientándolos a sus clientes.

No es necesario gastar tiempo de diseño y desarrollo en utilizar una solución funcional y que cubre nuestros casos de uso. Realmente, podemos dedicar todos este tiempo a mejorar nuestras soluciones en vez de generar soluciones ya existentes.

Cosas malas

Ahora vamos a ir al revés, vamos a explorar los motivos detrás de la elección de no utilizar servicios gestionados de AWS. Examinaremos estas razones para determinar si realmente tienen fundamentos sólidos o si requieren una reconsideración.

No sabemos qué estamos utilizando

Una de las grandes críticas que han tenido los servicios gestionados históricamente en AWS es que era muy cerrada de cara a dar visibilidad de cómo funcionaba un servicio gestionado y en qué software se basaba.

Esto ha ido cambiado en los últimos años y se ha dado más visibilidad a cómo funcionan estos servicios gestionados, hemos tenido charlas sobre cómo funcionan a bajo nivel diferentes servicios como Lambda, Fargate, DynamoDB, Aurora, etc. Esta visibilidad ha permitido conocer algo más sobre estos servicios gestionados y cómo funcionan

Por otro lado, también ha existido un cambio en el propio naming de los servicios, priorizando qué soluciones utilizan por debajo en vez de tener Naming propios.

Un ejemplo sería el cambio de nombre del servicio de Amazon Kinesis Data Analytics a Managed Service for Apache Flink Studio.

Si bien es cierto que AWS no nos va a dar toda la información sobre estos servicios, este cambio de modelo permite tener más visibilidad sobre qué utilizamos y tener menos reticencias de cara a utilizar un servicio gestionado.

Las soluciones gestionadas tienen Vendor Lock-In

Por otro lado, esta opacidad que existía antes ha sido muy utilizada para hablar del temido Vendor Lock-In, del que ya hemos hablado otras veces, como en el post de Kubernetes o en un podcast específico sobre Cloud Lock In.

Aquí no me quiero extender mucho, pero reiterar que el Vendor Lock-In es algo que no podemos evitar, que va a existir en soluciones OpenSource o incluso en soluciones propias. Lo importante no es evitarlo, sino controlarlo y ser conscientes de cuando tenemos Vendor Lock-In, que nos aporta y cómo de complicado sería evitarlo.

En muchas ocasiones no utilizar una solución nativa y gestionada puede ser más problemático que el propio Vendor Lock-In. Incluso puede llegar a pasar que para evitar el Vendor Lock-In generemos una solución que también tenga Lock-In propio y que sea más perjudicial que haber optado por una solución gestionada.

El coste es superior

Habitualmente, un servicio gestionado a nivel de infraestructura es más caro que una solución puramente IaaS. Pero esto tiene muchas aristas.

Por un lado, tenemos que añadir el gasto de mantenimiento y evolución de un servicio propio, mientras que en un servicio gestionado este coste va incluido.

También tenemos que tener en cuenta la escalabilidad y alta disponibilidad de los servicios gestionados. De nada sirve comparar un servicio que no sea escalable o con menos disponibilidad que su homólogo gestionado.

Además de esto, los servicios gestionados, sobre todo modelos SaaS tienen un modelo de pago por uso, que es muy interesante en cuanto a gastos, ya que su coste va vinculado a su utilización y no tenemos necesidad de provisionar la infraestructura para empezar, podemos probar un servicio gestionado sin necesidad de realizar una fuerte inversión. Por otro lado, no requerimos sobre-provisionar para cubrir futuras demandas o incluso para mantener la alta disponibilidad.

Necesito utilizar funcionalidades que el servicio gestionado no tiene

Este es uno de los supuestos más complicados y comunes, ya que la mayoría de las veces requiere un ejercicio de autocrítica.

Los servicios gestionados están pensados para la gran mayoría de los clientes y siempre nos gusta pensar que somos un caso de uso único, pero no es así.

Normalmente, cuando analizamos un servicio gestionado y no cubre alguno de nuestros requerimientos, solemos descartarlo en vez de reflexionar.

Aquí tengo que ser sincero, ninguno somos tan especiales como pensamos y es más habitual que estemos pidiendo un requisito que realmente no necesitamos.

Por poner una similitud, a mí me encantan los coches y me encantaría tener un Ferrari SF90 Stradale. Pero seamos sinceros, teniendo en cuenta que teletrabajo casi todos los días (bendito Paradigma Everywhere), que utilizo el coche poco y que habitualmente es con mis hijos, quizás no sea el coche más adecuado, aunque sea un coche precioso.

Pues con los servicios gestionados pasa lo mismo. Todos queremos tener un Ferrari, pero no siempre es lo más adecuado y más si tenemos en cuenta el coste que tiene, por eso es importante reevaluar nuestros requisitos y ver si son reales.

Cuando un servicio gestionado no se adapta a nuestras necesidades, tenemos que ver si nuestras necesidades no son como la mayoría o si estamos sobredimensionando nuestras necesidades.

Conclusión

Mi recomendación es siempre utilizar un servicio gestionado y si es modelo SaaS, mejor. Es verdad que depende de cada solución, pero en la mayoría de casos un servicio gestionado nos va a dar una serie de ventajas que permitirán que nuestra solución sea mejor en todos los sentidos:

• Coste más bajo (Contando CapEx y OpEx).
• Mayor eficiencia.
• Menor tiempo de desarrollo.
• Mejor seguridad.
• Mayor escalabilidad.
• Mejor disponibilidad.
• Facilidad de mantenimiento.

Hay algo que no he comentado en el artículo hasta ahora y que es una crítica interna que tenemos muchos arquitectos e ingenieros y es que nos gustan las cosas complicadas, en vez de ir por el camino sencillo. Muchas veces pensamos que utilizar un servicio gestionado es demasiado sencillo y que no aportamos valor. Tendemos a buscar soluciones “mejores”, pero que realmente no aportan más y en vez de buscar una solución compleja, podemos dedicar ese tiempo a mejorar nuestra solución utilizando un servicio gestionado.