Entrevista a Pancho Pérez de OCTI.io

Esta semana entrevistamos a Pancho Pérez, fundador de OCTI.io una plataforma que permite crear tu propio sitio web en WordPress, de forma fácil y rápida. Pancho nos habla de cómo surgió el proyecto y todas las tecnologías de las que hacen uso. Una entrevista con mucha chicha tecnológica para conocer de cerca el proyecto de OCTI.io

1. ¿Qué es OCTI.io?

OCTI significa One Click to Install, es la solución perfecta para empezar a crear una página web en WordPress, nosotros nos encargamos de instalar el WordPress, Theme, Plugins, Contenido demo y todo preconfigurado. Permitiendo al usuario en menos de 2 minutos tener todo lo necesario para empezar su proyecto web. Donde además, cada sitio creado dentro de OCTI tiene su propio SFTP y BD ofreciendo total libertad para cambiar o instalar lo que el proyecto necesite, sin ningún límite. Todo dentro Amazon Cloud Hosting.

2. ¿Cómo surgió la idea?

Fue una necesidad interna. Empezamos el desarrollo de una herramienta para lanzar sitios más rápidamente, poderlos copiar, cambiar dominios, etc.. sin tener que ir a la consola del servidor o recurrir al lento FTP. Cuando le añadimos la interface web para hacer todo esto, nos dimos cuenta de que podía ser una aplicación que utilice cualquier agencia / desarrollador, o incluso un usuario final.

3. ¿OCti.io es para usuarios finales?

El servicio de instalación de páginas web con WordPress con Hosting incluido está enfocado a usuario final, cualquier persona sin conocimiento alguno en como comprar un dominio, contratar un hosting o instalar WordPress puede empezar su sitio en OCTI.

4. ¿Que ventajas ofrece OCTI.io a desarrolladores o agencias?

Una vez creado el sitio OCTI.io ofrece herramientas que hacen de el trabajo mas fácil, incluyendo la opción de Stages (pre-producción) del sitio Live (producción) con un Click, asi mismo la opción de hacer un Backup completo con un click tanto de un Stage como de un Live.

Es decir, OCTI.io además de facilitar la creación de un sitio web también ofrece un entorno profesional para desarrolladores o agencias, permitiéndo así poder controlar de forma segura los cambios o actualizaciones que todo proyecto web necesita

5. ¿Qué ventajas presenta OCTI.io frente al desarrollo directo de un WordPress?

Básicamente la facilidad de gestión usando Snapshots, lo importante es que OCTI.io sigue siendo desarrrollo directo sobre WordPress, no alteramos el WordPress ni lo forzamos a trabajar de una forma determinada. No requiere de ningún plugin, ni setting especial. Los desarrolladores tienen total libertad igual o mejor que en un hosting tradicional. La ventaja está en que pueden hacer N copias rápidamente, cambiar dominios y desplegar su sitio en cloud con un click. Cloud de verdad, con autoscaling, balanceadores, etc. Esto hace que las webs hosteadas en OCTI no necesiten ningún plugin de cache. Y si quieres refrescar el cache del varnish basta con visitar el frontend estando logeado, ¡así de fácil! Nuestra tecnología es a nivel de servidor, por lo que el desarrollador puede hacer lo que quiera en su WordPress.

6. ¿Cuáles son los sectores que más demandan la creación a través de OCTI.io?

Páginas presenciales o corporativas de pequeña-mediana empresa. Consultores Web especializados más en contenido que en desarrollo. Dentro del mundo WordPress existe un perfil conocido como “ensambladores” quiere decir que no programan pero saben cómo construir una página web usando Themes y Plugins, para este último sector OCTI es la mejor solución sin lugar a dudas.

7. Cuéntanos el stack tecnológico de OCTI.io: lenguaje de programación, base de datos e integraciones con otras plataformas.

Es un montaje complejo, tiene muchas partes. Utilizamos Varnish para el cache, Nginx para el trafico SSL (con spdy), Apache con mpm_event para “ejecutar” los WordPress junto con php-fpm. Esto en la parte “frontal” donde se sirven las webs. Lógicamente utilizamos MySQL como servidor de base de datos. Luego en el back-end utilizamos docker con distintas imágenes para distintas soluciones. Uno para los servidores web, otro para los snapshots. Los snapshots están gestionados con demonios que construimos en Python y los API se gestionan con Python también con Django. Se utiliza colas de mensajes para comunicar todos los servidores con gearman.

Gracias a este stack podemos soportar cualquier aplicación desarrollada sobre PHP/MySQL.

8. ¿Cómo fue la primera versión de OCTI.io?

Empezamos haciendo un prototipo llamado WPand.me la idea era crear un marketplace para vender Themes usando nuestro sistema de One Click to Install, un objetivo muy ambisioso ya que competir con Themeforest requiere mucho trabajo e inversión. Con WP&me aprendimos el flujo de registro de usuarios y creación de sitios, aprendimos que usuario final tenía que tomar muchas decisiones antes de crear el sitio, esto hacía que muchos sean reacios a crearlo ya que una decisión simple como qué dominio usar o qué nombre le quieres dar al sitio ahuyentaba a personas que querían el WP instalado y luego pensar en esos cambios.

Por eso resolvimos todo a un click, registro y creación de sitio, las opciones de cambio de dominio lo movimos al panel interno facilitando así la entrada de nuevos usuarios. El cambio de dominio y proceso de adquisición de usuarios fue para abrirnos a otros CMSs y no limitar el tipo de productos a solo Themes ya que gracias a nuestra tecnología de Snapshots los desarrolladores o ensambladores pueden crear todo tipo de productos.

9. ¿Cuál ha sido el reto tecnológico más importante que os habéis encontrado hasta ahora?

Yo diría que son básicamente dos. Primero. Conseguir que PHP-FPM funcione bien, rápido y fluido leyendo los ficheros PHP desde NFS. Esto incluye los directorios temporales para las sesiones por nfs también, o no se mantendrían las sesiones al cambiar de nodo.

Segundo. Gestionar los snapshots (copias de cada instalación) cuando ocupan varios GB, y desplegarlos a una velocidad aceptable. Fue necesario hacer que los “workers” tengan tantos subprocesos como CPUs tenga el servidor y de ser posible, utilizar más de un servidor. Luego volver a unir todo para subir como un solo fichero a S3. Esto tiene su miga. (El libro de “Principios y algoritmos de concurrencia” de Ricardo Galli (creador de meneame.net) va de esto, y lo explica muy bien, ojalá lo hubiera publicado antes, cuando lo estaba desarrollando).

También nos dimos con otros muros como Varnish, o la gestión de los logs, que cuando las máquinas cambian constantemente (autoscaling) es necesario utilizar cosas como logstash, elastichsearch, kibana,.. y son millones de líneas por día. Son muchos retos.

10. ¿Cuál ha sido el mayor error tecnológico que habéis cometido?

Utilizar un balanceador propio en lugar de los de Amazon. Amazon ELB tiene soporte para un certificado digital. Por lo que no podíamos añadir varios sitios con SSL porque no había soporte SNI. Montamos un balanceador en NGINX. Y el día que publicamos la nueva web de un cliente grande, ese mismo día atacaron el sitio (DDoS; para estrenar la nueva web) y el servidor no pudo aguantar el ataque. Caído el balanceador, cayeron todos lo sitios, de todos los clientes. Fueron necesarias casi 2 horas para poner un equipo más potente (y mucho más caro).

Aprendida la lección. Ahora utilizamos los ELB con proxy_protocol (layer 4) y realizamos la negociación de los SSL con SNI en los nodos detrás del ELB con Nginx. Así puede crecer en caso de ataque o picos de tráfico. También quedó claro el excelente servicio de amazon a la hora de parar los ataques en Layer 4.

11. ¿Qué próximos hitos de desarrollo tenéis marcados?

¡Son muchos también!

A corto plazo queremos dar unas medidas de seguridad gestionables por el usuario, lo llamamos “secure mode”. Hará que sea imposible escribir en los ficheros PHP, incluso si entras por ftp. Cuando los sitios tengan esto activo, aunque haya un fallo en el CMS, el hacker no podrá escribir en los ficheros/carpetas. Así evitamos que dejen código infectado. Pero lo tenemos que sincronizar con las actualizaciones de seguridad de cada CMS. Aquí la dificultad.

El otro es implementar una consola SSH para que el cliente tenga acceso a wpcli, pero como son servidores cloud (móviles) tenemos que hacer esto en otra línea de servidores, donde cada sesión sea un docker aislado y guardar ese docker para que el usuario pueda acceder por SSH y continuar su trabajo. Una vez apagado el docker el SSH no es accesible.

También queremos dar la opción de descargar tu instalación en un docker, con todo, mysql, apache, etc.. de modo que tengas una copia exacta de tu sitio y puedas desarrollar en local.

Git/SVN auto deploy, esto ya lo tenemos dentro del API del software y lo usamos en nuestro interfaz interno pero queremos llevarlo al backend de OCTI.

Y un infinito etc...