El futuro del hosting (y II)

Después de analizar el estado actual del hosting en el anterior post, paso a comentar qué herramientas tenemos y qué avances han ido apareciendo nos deberían ayudar a alcanzar a ese futuro utópico que tanto idealizamos. La realidad no es tan oscuro como parece por el tono algo pesimista con el que finalicé el artículo anterior. Tenemos un montón de herramientas que nos pueden ayudar. 🤗

 

Solicita una propuesta Cloud personalizada

 

 

Docker y contenedores

 

Ya he escrito en este blog acerca de algunos de los principales avances en el ámbito del hosting: Docker y Kubernetes. Son dos tecnologías que van de la mano y que en los últimos años han pegado muy fuerte y están haciéndonos la vida más fácil cada día. Por refrescar la memoria, Docker es un sistema para enjaular y aislar procesos que nos ayuda con los clásicos problemas de:

• «es que en mi equipo funciona»
• «es que yo estoy usando la última versión»
• «es que yo estoy usando una versión de hace 5 años»

Gracias a los contenedores podemos desplegar la misma versión en distintos sistemas, siempre que tengan soporte de Docker, ¡y eso es una maravilla! Puedes desarrollar en tu portátil Apple, probarlo en una Raspberry PI y ponerlo a funcionar en un servidor en el Cloud.

 

 

¿Que entra una persona nueva a tu equipo? Con un par de comandos puede tener ya el entorno de desarrollo funcionando en su ordenador. Adiós a los problemas de «es que para mi sistema operativo aún no está la versión 3.4 y la 2.8 tenía un bug que...».

Los contenedores nos contribuyen muchísimo a la hora de actualizar a nuevas versiones sin romper todo el sistema ya que no hace falta tirarnos a la piscina y actualizar todo haciendo complicada una vuelta a la versión anterior. Esto ayuda a usar software más moderno, con bugs más modernos con bugs corregidos y por lo tanto más seguro.

 

Repetibilidad: Kubernetes y los despliegues

 

Ha pasado mucho tiempo desde que las webs se subían por FTP y se firmaba como webmaster en los correos. Si bien hace 10 años podías hacer una web así, hoy en día se ha complicado un poco todo:

• Para instalar las dependencias usas algo tipo Composer, PIP, o NPM.
• Luego es posible que tengas que «transpilar» el código a javascript (que tu escribes en TypeScript, no JS directamente), y no te olvides de los CSS. Y de minificar todo al ponerlo en «prod».
• Ahora haz las migraciones en la BB.DD. y vacía la caché.
• Sube la versión nueva sin que la otra deje de funcionar.
• Y encima hazlo N veces ya que no tienes un único servidor con cPanel…

Pero… ¿no nos acabas de decir que Docker y los contenedores eran como cuando se inventó el pan de molde? Sí y no.

Si bien los contenedores nos han ayudado mucho y han resuelto muchos problemas, no han hecho que, por sí mismos, sea trivial desplegarlos y tenerlos en funcionamiento «de cara al público».

Hay que seguir gestionando logs, permisos de carpetas, contraseñas, reinicios, etc. ya que por sí sólo, el sistema de contenedores no trata de arreglar esos problemas (y mejor, por que ya tenemos a systemd tratando de arreglar todos los problemas del mundo).

Gracias a Kubernetes podemos disponemos del mismo lienzo en blanco en cualquier proveedor, si ya con Docker podíamos tener las mismas versiones, con Kubernetes nos aseguramos que los paths, las IPs (hasta cierto punto), las contraseñas o las bases de datos sea algo totalmente estándar dentro de nuestro despliegue.

¿Lo que comentaba en la primera entrada sobre tener tu desarrollo desplegado en un satélite? Ahora con Kubernetes ya hay gente haciéndolo. ¿El problema de desplegar nuevas versiones? Mediante los contenedores podemos hacer despliegues blue/green para evitar ese downtime.

Mediante los contenedores podemos tener contratado un clúster en el proveedor A y otro en el B, incluso tener algún equipo en nuestra oficina para ciertas tareas con los mínimos cambios entre ellos. Nosotros definimos la arquitectura y le pedimos al proveedor sólo los nodos de Kubernetes (que además por su propia naturaleza casi te obliga a que sean varios).

 

Solicita una propuesta personalizada de alojamiento

 

 

Fiabilidad: S3 y el almacenamiento de objetos

 

No os voy a engañar, esta parte la he metido un poco con calzador ya que es una de las cosas en la que he estado trabajando en los últimos meses y quería hablar de ella. 😉

Almacenar archivos siempre ha sido algo que en el mundo de TI nunca ha dejado de evolucionar. Desde las primeras tarjetas perforadas a los disco SSD de hoy en día ha pasado mucho tiempo pero seguimos teniendo un problema: tenemos que prever la capacidad total de datos que vamos a almacenar para montar nuestro sistema en consonancia, y por lo general, no es trivial ni en cuanto a tiempo ni a dinero el hacer ampliaciones sobre el mismo.

Para ello, cuando Amazon empezó a definir lo que es el Cloud, a parte de vender bestsellers, definió un tipo de almacenamiento de archivos basado en objetos para su servicio. Y lo hizo muy bien desde el principio:

• Los archivos dejan de serlo como tal dentro de un sistema de archivos como puede ser NTFS para pasar a ser «objetos» (de ahí el nombre). Así nos abstraemos del cómo se almacenan estos «objetos». Simplemente están ahí.

• No limitar el disco, pudiendo crecer todo lo que se necesite sin limitarnos a un tamaño inicial. No tenemos que contratar un espacio al inicio, si no que podemos añadir el que necesitemos sobre la marcha.
• En mi opinión, la última gran decisión fue la forma de interactuar con los archivos. Utilizar HTTPS para subir y descargar archivos fue una genialidad, nada de protocolos raros, módulos extraños en el Kernel o similares. Nuestro viejo conocido HTTP al rescate: ¿recuerdas lo que comentaba en el anterior post de un Internet interopeable?

Gracias al boom del Cloud y de los sistemas de AWS, muchos fabricantes y desarrolladores han sacado sistemas similares y compatibles, haciendo que «S3» pase a ser casi un estándar en vez de un producto. Y hoy en día disponemos de múltiples herramientas y librerías para utilizar sistemas de almacenamiento por objetos, haciendo trivial el almacenar una gran cantidad de archivos, tenerlos disponibles entre distintas plataformas (nada de tener que meter el WordPress en la red corporativa para poder acceder a ciertos documentos) y pudiendo crecer y disminuir en capacidad según el uso que estemos haciendo.

 

Sencillez: el futuro

 

Aquí es donde saco la bola de cristal. 🔮

Visto lo visto creo que vamos a seguir abstrayéndonos de los sistemas y nos va a dar bastante igual si estamos corriendo nuestros programas en tal o cual sistema operativo. De este modo, nos centraremos más en nuestro producto final, sea una web, un videojuego, un sistema de recogida de datos masivo o una tienda online.

Otra cosa que pienso que va a pasar es que vamos a tender a «recuperar nuestros datos». Gracias a tecnologías como Kubernetes podemos tener parte de la infraestructura corriendo en un Cloud público y parte en nuestras instalaciones (algo similar el edge computing). De esta forma, no dependemos sólo de un único proveedor grande con el que carecemos de visibilidad real de dónde están nuestros datos y nuestra información.

¿Sientes que trabajas en el futuro?

 

Solicita asesoramiento en Cloud para tu negocio