Vivimos en un mundo completamente digital. En nuestro día a día, utilizamos diversas aplicaciones para comunicarnos con nuestros amigos y familiares, para ver películas o series, escuchar música, aprender sobre aquello que nos motiva, o buscar un nuevo trabajo.
En el artículo de la semana pasada describimos las dificultades a las que se enfrentan los desarrolladores al trabajar con arquitecturas distribuidas o de microservicios, en muchas ocasiones, sin el conocimiento detallado necesario en las tecnologías de red subyacentes que hacen posible que las distintas piezas se comuniquen.
Las arquitecturas basadas en microservicios están cambiando la forma en la que, a día de hoy, diseñamos el software, lo que plantea nuevos retos en el desarrollo y la operación.
Estas arquitecturas están añadiendo una fuerte dependencia de la red en la lógica de negocio, incrementando el número de peligros potenciales, que crecen proporcionalmente a las conexiones o enlaces que se crean entre los servicios.
Cada vez más empresas se decantar por una arquitectura enfocada a microservicios. Y probablemente es porque los microservicios son el perfecto complemento para la tecnología SDN/SD-WAN: así, los módulos que componen las aplicaciones pueden implantarse en numerosos servidores o centros de datos.
Pero antes de continuar, definamos con precisión el concepto de microservicios.
Desde los inicios de la administración de sistemas, un dios ha sobrevolado las salas de servidores: el “uptime”. Nos indica el tiempo que llevaba encendido un servidor, lo cual indirectamente señalaba el tiempo transcurrido sin sufrir ningún problema que haya hecho necesario su reinicio. En los sistemas operativos siempre han existido comandos para indicar el uptime de un servidor, cifras que, a su vez, reflejaban el mérito de los administradores. Pero los dioses no son eternos; sus fieles acaban perdiendo la fe en ellos o simplemente son sustituidos por otros. Incluso al uptime le llegó su fin.