Una forma entretenida de entender los modelos de servicio cloud es haciendo un paralelismo con algo a lo que todos estamos acostumbrados y hacemos habitualmente: ir a hacer la compra.
Los proveedores de nube pública serían las grandes cadenas, cada una tiene sus cosas buenas y no tan buenas. Por ejemplo, unos se centran en tener una relación y trato con el cliente excepcional, otro priorizan la calidad de sus productos a todo lo demás y algunos prefieren estrategias diferenciales en precios.
Quien más y quien menos siempre acaba yendo a varios supermercados para satisfacer todas sus necesidades y, dentro de lo posible, se intenta crear unas rutas apropiadas de un supermercado a otro para que la integración de las compras sea lo más fluida posible.
Cualquier supermercado que se precie no vende un sólo producto, ni si quiera un conjunto de productos, todos cuentan con lineales y, normalmente, los lineales suelen ser parecidos en todos los supermercados a los que vamos. En ese sentido los supermercados cloud suelen definir los siguientes lineales:
- Computación
- Almacenamiento y bases de datos
- Redes
- Herramientas para desarrolladores
- Big data
- Inteligencia artificial
- Otros
Dentro de los lineales podemos encontrar una gran variedad de productos, algunos los podemos diferenciar por su calidad mientras que otros se diferencian por su precio. Además, en muchos de estos tipos de productos se pueden distinguir clases que hacen referencia al nivel o modelo de servicio.
Por ejemplo, si lo que queremos es un pizza tenemos varias opciones:
- Comprar todos los ingredientes, preparar la masa y los ingredientes y hornearla.
- Otra opción sería comprar directamente una pizza preparada en la opción de precocinados.
- Incluso, podremos pedir una porción en una sección del supermercado donde ofrecen servicio de restaurante.
La pregunta del millón suele ser siempre la misma, ¿cuál de la tres opciones anteriores es la mejor? Y siempre tendremos un depende “bastante molesto” como respuesta.
Es evidente que depende de muchos factores, pero es necesario mojarse de vez en cuando ante estas preguntas. Sin saber nada de un caso en concreto la mejor opción tiende a ser la tercera.
Quizás en ese momento solo estamos de paso por ese supermercado; quizás no tenemos un lugar apropiado con cocina y con todos los utensilios y herramientas adecuados o quizás no tenemos el conocimiento ni la ayuda para preparar adecuadamente la receta. En general (y partiendo de un escenario donde no sabemos más sobre el caso en concreto) la tercera opción tiene una probabilidad de éxito bastante alta frente a las otras. Hacemos uso de un servicio donde la responsabilidad la adquiere otra persona o entidad y satisfacemos nuestra necesidad.
En los otros casos la probabilidad de éxito es variable a muchos factores y la responsabilidad adquirida por nuestra parte es mucho mayor. No obstante, tiene ventajas frente a hacer uso de un servicio, por ejemplo, ese servicio puede salirnos más caro a largo plazo o que no cubra todas las necesidades que puedan surgir.
A todas estas opciones, y antes de olvidarnos de la metáfora del supermercado, hemos de sumarle un cuarto escenario donde queremos hacerlo todo. En este escenario no iríamos ni al supermercado a por provisiones, directamente nosotros seríamos los responsables de cultivar y recolectar apropiadamente los ingredientes necesarios para, en un tiempo determinado, por fin conseguir satisfacer nuestra necesidad.
Este último caso (y ya por fin hablando de nube) sería el famoso planteamiento On-prem, donde adquirimos una responsabilidad plena. Desde la adquisición y actualización de los servidores, hasta la conexión y el mantenimiento de las redes, así como de la seguridad y operación de los aplicativos que tengamos corriendo en nuestra infraestructura.
Como podemos observar, todo esto tiende a un término convergente, la responsabilidad, al que podemos extender con algo denominado “responsabilidad compartida” y que en resumen es el reparto que se realiza entre el usuario de nube pública y el proveedor de nube pública.
Antes de avanzar en el concepto de responsabilidad compartida, vamos a describir y mencionar algunos ejemplos de los distintos modelos de servicio.
El modelo de servicio IaaS (Infrastructure as a Service), se basa en alquilar capacidad de cómputo y de alojamiento de servicios, aplicaciones y trabajos en la nube. Esa capacidad de cómputo tiene muchas variables, configuraciones y tipos pero de forma simplificada se trata de alquilar un espacio en la nube pública donde podemos desplegar a priori cualquier tipo de servicio o aplicación que queramos. El nivel de restricciones de este nivel es el menor y por ello la responsabilidad asumida por el cliente de nube pública es la mayor.
Como referencia, mencionamos algunos ejemplos de servicios cloud en modelo IaaS:
- Elastic Compute Cloud (EC2) Instances de Amazon Web Services
- Compute Engine Instances de Google Cloud
- Azure Virtual Machines de Microsoft Azure
Éstos pueden describirse como servicios que nos permiten crear servidores virtuales localizados en uno (o varios) data centers y que permite a los usuarios de nube desplegar, gestionar y mantener un sistema operativo de su elección así como cualquier tipo de software compatible con dicho OS. Los parámetros a configurar más comunes son el ya mencionado sistema operativo, así como recursos de computación CPU/RAM, disco y configuración de red.
En el nivel PaaS (Platform as a Service) los servicios nos ofrecen un entorno de trabajo mucho más evolucionado (y acotado) que lo que podemos encontrar en el nivel de infraestructura. El objetivo principal es acercar lo máximo posible las necesidades de negocio con el desarrollo y los equipos IT y, de ese modo, reducir al máximo el time-to-market. En el nivel de plataforma comúnmente nos encontraremos entornos o sandbox ya predefinidos en los cuales basaremos nuestra solución. En este sentido es más restrictivo que el nivel de infraestructura y perdemos en flexibilidad.
Por otra parte la responsabilidad que adquiere el proveedor de nube es mucho mayor y por tanto, idealmente, no sería necesario contar con equipos de operaciones dedicados por lo que podríamos centrarnos en lo que realmente importa a nuestro negocio.
Dentro del sector PaaS han aparecido múltiples tecnologías en los últimos años que, a fin de cuentas, hacen referencia a distintos subniveles dentro del nivel de plataforma y están muy orientados al tipo de tecnología que usan. Por ejemplo, FaaS (que hace referencia a Function as a Service) es quizá el término más conocido y está relacionado con los servicios de computación serverless en los cuales el usuario de nube sólo sube el código de funciones idealmente isoladas y que realizan una una acción muy concreta. El término CaaS (Containers as a Service) es también común y hace referencia al tipo de formato de despliegue de nuestra aplicación, en este caso mediante contenedores.
Algunos servicios conocidos son los siguientes:
- AWS Lambda, AWS Fargate, AWS ECS (Elastic Container Service) o AWS Beanstalk
- Google Cloud Functions, Google Cloud Run o Google Cloud App Engine
- Azure Functions, Azure Container Instances o Azure App Service
El modelo SaaS recoge aquellos servicios o aplicaciones que de forma directa cubren las necesidades de negocio. Los ejemplos clásicos son los gestores de mail o en sentido amplio las “suites” de herramientas de trabajo como pueden ser Microsoft Office o Google Suite. Aunque estos ejemplos suelen ser los más comunes al mencionar servicios SaaS, también lo son aquellos más orientados a la parte técnica del catálogo de productos cloud, como por ejemplo: herramientas para desarrolladores (control de versiones de código, herramientas de CI/CD, …), APIs o servicios de inteligencia artificial (APIs de reconocimiento en imágenes, procesamiento de texto, …) o incluso servicios de monitorización y alertas de nuestras aplicaciones.
Al enfrentarnos a un caso de uso en particular o una necesidad de un cliente, las soluciones planteadas pueden ser infinitas y, en ese contexto, el nivel de servicio elegido para cada solución puede ser cualquiera de los anteriormente mencionados.
Sin un equipo y conocimiento adecuado, un planteamiento IaaS puede ser una “pesadilla” de la que podemos no darnos cuenta en una fase de ideación o diseño de una solución. Sin embargo, es importante recordar el siguiente principio: Ignorantia juris non excusat. El no conocer la responsabilidad adquirida mediante un planteamiento de este estilo no implica que no se esté adquiriendo. Todos los modelos tienen una responsabilidad inmediatamente trasladada al usuario de nube pública, por mucho que se desconozca este hecho.
Esto no va de asustar, pero sí de advertir de los posibles riesgos a los que nos podemos enfrentar al diseñar soluciones en distintos modelos de servicio, sobre todo en entornos de nube pública donde a veces podemos tener la extraña sensación de que la facilidad o dificultad de hacer uso de los distintos servicios es similar. Es más adelante, cuando el alcance o las especificaciones del proyecto cambian, cuando suele evidenciarse en mayor medida las diferencias entre los distintos modelos de servicio.
Si quieres conocer más sobre nube pública o necesitas ayuda en tu camino a la nube no dudes en ponerte en contacto, escríbenos porque en Keepler estaremos encantados de hacer de guía.
Imagen: unsplash | @hansonluu
Deja un comentario