Los Instant Server son un servicio de Acens, que forma parte del grupo Telefónica, para entrar en el mercado del que ahora mismo es líder Amazon EC2.

Sin embargo, aunque el servicio que ofrecen los Instant Servers es como si volviéramos unos cuantos años al pasado con Amazon EC2, los Instant Servers tienen unos puntos fuertes muy interesantes.

Desde el punto de vista de imagen corporativa

Para alguien que no sabe de que va el Cloud (tu jefe o tu cliente) la sugerencia de dejar en manos de Amazon (que para ellos venden libros) la infraestructura de la empresa le parecerá una locura y hará que encima pierdas su respeto. Pero oye, si le proponemos exactamente lo mismo con Telefónica (una de las mayores empresas de telecomunicaciones del mundo con infraestructura propia y redes propias) en vez de con Amazon a lo mejor la cosa cambia. Es triste pero es así.

No tengo dudas de que Amazon EC2 ofrece muchas más y mejores funcionalidades que los Instant Servers, pero la imagen de marca que tiene Telefónica hace que en la carrera de los 100 metros los Instant Servers salgan 50 metros por delante para muchas personas.

Desde el punto de vista de precios

Por ejemplo Amazon EC2 cobra por tráfico desde el primer byte mientras en Instant Servers te regalan los primeros 20TB.

A nosotros, un servicio que se nos llevaba bastante más de 100€/mes con Amazon EC2 se nos está llevando 36€/mes con los Instant Servers por el tema del tráfico.

Pero la elasticidad no es tan elástica ya que cobran los servidores por tramos de 1 hora. Es decir, que si tienes un servidor encendido un minuto te cobran la hora entera.

A la hora de comparar precios no es suficiente con ver el precio/hora sino también saber que uso le vamos a dar para saber si nos va a salir más barato o más caro.

Desde el punto de vista técnico

Comparándolo con Amazon EC2 podríamos decir que es como si nos volviéramos unos cuantos años al pasado. La cantidad de cosas que puedes hacer con Instant Servers es mucho menor que con Amazon EC2 y no existen conceptos como el de elasticIP o servicios como RDS o los balanceadores gestionados.

Tampoco se pueden ejecutar scripts para hacer despliegues automáticos desde la interfaz web de Amazon por lo que la instalación y configuración de servicios como puppet o chef en el momento de la creación del servidor hay que hacerla por ssh. Esto no supone un gran problema pero es otra cosa más que no se puede hacer.

La gestión de usuarios en los Instant Servers es muy simplona. Sólo puedes entrar con un usuario y las claves RSA que subes o que te bajas de la página web para la conexión por ssh te dan acceso a todas las máquinas que tengas bajo esa cuenta, es decir, que la gestión de acceso de personal a las máquinas de forma individual se hace un pelín difícil por no decir imposible.

Un punto a favor de los Instant Servers es la sencillez de gestión de redes privadas en el cloud. En Instant Servers te creas una LAN privada y enganchas todos tus servidores a ella por lo que la gestión de accesos por esa LAN se hace más sencilla. En Amazon EC2 tenemos el servicio de VPC que nos permite gestionar varias VLANs. Si no utilizas VPC al crear el servidor te dan una IP privada y una pública. La IP privada comparte LAN con el resto de servidores del mundo por lo que tienes que restringir el acceso por medio de políticas.

En cualquier caso, todas las cosas que no se pueden hacer con los Instant Servers ni siquiera se echarán de menos por un usuario que todavía esté empezando a usar servicios en cloud dinámicos.

Acceso al API

Telefónica/Acens ofrece una interfaz vía línea de comandos y una interfaz rest a la que hacer peticiones.

Acceso al API por línea de comandos

La documentación oficial se refiere a la última versión que no funciona bien en este momento así que para instalarse la versión 6.5 gestionando máquinas en el nodo de Madrid ejecutamos:

npm install smartdc@6.5 –g
sdc-setup https://api-mad.instantservers.es

Configuramos las variables de entorno, por ejemplo:

export SDC_CLI_KEY_ID=clave-ssh (nombre de tu clave)
export SDC_CLI_URL=https://api-mad.instantservers.es
export SDC_CLI_ACCOUNT=usuario_de_acceso
export SDC_CLI_IDENTITY=/root/.ssh/id_rsa

Acceso al API utilizando un cliente rest

En la página de documentación vienen todas las llamadas que podemos hacer al API para la gestión de las máquinas.

Podemos acceder al API utilizando cualquier cosa que haga de cliente rest. Por ejemplo para crear un servidor con curl tendríamos que poner algo como:

curl -is -u access_user:access_password -H "Accept: application/json" -H "X-Api-Version: ~6.5" -d name=test -d package=g1_standard_1cpu_512mb -d dataset=sdc:sdc:centos-6:2.4.2 "https://api-eu-mad-1.instantservers.telefonica.com/my/machines

O si queremos acceder al API para crear, para y eliminar un servidor utilizando ruby tendremos que poner algo como esto tras instalar los paquetes ruby-rest-client y ruby-json. No olvides cambiar access_user y access_password por tus credenciales de acceso:

require "rest_client"
require "json"

# Crear una máquina CentOS 6.4 cuyo nombre es test
puts "Creando máquina virtual en acens"
response = RestClient.post "https://access_user:access_password@api-eu-mad-1.instantservers.telefonica.com/my/machines", {'name' => "test", 'package' => "g1_standard_1cpu_512mb", 'dataset' => "sdc:sdc:centos-6:2.4.2"},  {"Accept"=>"application/json", 'X-Api-Version' => '~6.5'}
test_machine=JSON.parse(response)

# Esperamos un rato a que se cree del todo
sleep 40

# Listar máquinas
response = RestClient.get("https://access_user:access_password@api-eu-mad-1.instantservers.telefonica.com/my/machines", {"Accept"=>"application/json", 'X-Api-Version' => '~6.5'})
result=JSON.parse(response)
puts result.inspect

# La paramos
puts "Parando máquina virtual en acens"
RestClient.post("https://access_user:access_password@api-eu-mad-1.instantservers.telefonica.com/my/machines/"+test_machine["id"], {'action' => "stop"},  {"Accept"=>"application/json", 'X-Api-Version' => '~6.5'})

# Esperamos otro rato a que se pare del todo
sleep 20

# Listar máquinas
response = RestClient.get("https://access_user:access_password@api-eu-mad-1.instantservers.telefonica.com/my/machines", {"Accept"=>"application/json", 'X-Api-Version' => '~6.5'})
result=JSON.parse(response)
puts result.inspect

# La borramos
puts "Destruyendo máquina virtual en acens"
RestClient.delete("https://access_user:access_password@api-eu-mad-1.instantservers.telefonica.com/my/machines/"+test_machine["id"],{"Accept"=>"application/json", 'X-Api-Version' => '~6.5'})

# Esperamos a que se destruya
sleep 30

# Listamos las máquinas para ver si tenemos alguna funcionando
# Listar máquinas
response = RestClient.get("https://access_user:access_password@api-eu-mad-1.instantservers.telefonica.com/my/machines", {"Accept"=>"application/json", 'X-Api-Version' => '~6.5'})
result=JSON.parse(response)
puts result.inspect

¡Cuidado! Esto es sólo un ejemplo sencillo. Habría que capturar excepciones en cada llamada y comprobar salidas por si en algún momento falla algo o intentamos hacer alguna tontería como crear dos máquinas con el mismo nombre porque ¡no se pueden crear dos máquinas con el mismo nombre!.

SmartOS vs Linux

Hasta que he empezado a utilizar Instant Servers ni siquiera había oído hablar de SmartOS y lo que he visto me ha gustado mucho. La apuesta que hacen es exactamente la misma que yo hacía hace tiempo sobre usar contenedores y KVM hace más de tres años pero utilizando como sistema operativo un derivado de Solaris en vez de Linux. Sólo por poder usar ZFS como sistema de archivos ya puede estar justificado el cambio y tras una instalación de prueba he visto que cambiando apt-get o yum por pki los paquetes se gestionan de forma similar sólo que, al igual que en Debian y Redhat, las rutas cambian. Para mi eso es un mal menor y lo iba a utilizar para el proyecto peeero ahora entramos en el tema de la imagen.

Tu dile a tu jefe o a un cliente que usas Linux que habrá oído hablar de él y sabrá que las cosas funcionan y que van a tener unos plazos aproximados de entrega. Ahora dile que vas a utilizar un sistema operativo que tiene pinta de ser mucho mejor pero que a lo mejor te lleva más tiempo terminar el proyecto por ese motivo y que luego para tener el mismo servicio en cualquier otro proveedor tendrá que cambiar de sistema operativo. ¿Hace falta que siga?

Como hay cosas que sólo funcionan en SmartOS como el autoescalado, a efectos prácticos será como no tenerlo. Hay que tener en cuenta que todas las características de los Instant Servers funcionan para SmartOS pero no para Linux.

Conclusión

Me parece un buen servicio, fácil de usar y más cercano al usuario clásico. Pero tienen que mejorar muchas cosas si quieren competir con Amazon EC2 y tienen que dar un mejor soporte para distribuciones basadas en Linux.