Archivo de la etiqueta: Toprural

Infraestructura de etece en la nube de Amazon

Publicado el por

Hace pocas semanas que hemos lanzado etece.es, tiempo para los que no tienen tiempo. En los próximos posts iré comentando algunos aspectos que creo que merece la pena compartir por si a alguien le puede ayudar. El primero que voy a abordar es el relacionado con la infraestructura y cómo lo hemos montado en la nube de Amazon.

Antecedentes
La primera vez que analicé a fondo la nube de Amazon como alternativa al hosting tradicional fue en 2008 cuando era CTO de Toprural. En aquel momento estábamos planificando un cambio de CPD y Amazon fue una de las alternativas que estudiamos. En aquella época, los servicios de Amazon se limitaban a EC2, S3 y muy poco más lo que suponía demasiadas limitaciones para lo que Toprural necesitaba. Finalmente y hasta hace bien poco, dejamos Toprural funcionando en máquinas propias en una huella contratada en un CPD de Madrid.
El segundo contacto serio con la nube de Amazon lo tuve en Planeo. Toda la infraestructura de Planeo se montó en Amazon, aunque fue el equipo de sistemas de Medianet quien montó todo en base a los requisitos que les transmitimos. En cualquier caso, me permitió conocer de primera mano muchos de los servicios que ofrecen actualmente.

Infraestructura para etece
Tenía bastante claro que Amazon nos ofrecía todos los servicios de infraestructura que vamos a necesitar, al menos en los primeros años, y que lo podíamos montar de manera fácil y rápida. Por ello nos pusimos manos a la obra y hemos montado la infraestructura de etece usando lo siguiente:

  • EC2 (máquinas virtuales) para los servidores web donde básicamente corren los Apache con PHP
  • Los EC2 de la web están detrás de un balanceador ELB que permite añadir y quitar de manera muy fácil, rápida y dinámica (si tienes tiempo de configurarlo) servidores web en función de la demanda (autoscaling).
  • Como base de datos usamos RDS, servicio de base de datos relacional que puede correr Oracle, SQL Server o MySQL, nuestra elección.
  • ElastiCache, el servicio de Memcache que ofrece Amazon, para la caché de aplicación y la gestión de las sesiones de Apache, permitiendo así la alta disponibilidad de los servidores web.
  • CloudFront, CDN de Amazon, que sirve el contenido estático por diferentes dominios. En nuestro caso usamos subdominios distintos para estilos, imágenes y scripts.
  • SES, servicio de envío de emails (se terminaron los dolores de cabeza para mantener un SMTP que envíe correctamente sin llegar a spam) para los emails transaccionales de la aplicación.
  • Route 53, el DNS de Amazon, necesario si quieres apuntar un dominio directamente a un CNAME. Los balanceadores no tienen IP fija y si no usas este servicio necesitaras un subdominio por delante de tu dominio, por ejemplo www.
  • CloudWatch en conjunción con SNS (servicio de notificaciones) para la monitorizacion y alertas de todos los servicios anteriormente indicados. Asociado a alertas puedes lanzar acciones como levantar o parar más instancias de las mismas máquinas.

Amazon tiene más servicios pero a nosotros con esto nos basta y nos sobra.
Entrar al detalle de cómo hemos montado todos y cada uno de los elementos llevaría mucho tiempo y no es el objetivo de este post. No obstante, es posible que aborde algún aspecto en concreto bajo petición de algún lector.

Pros
Llevar tu infraestructura a la nube de Amazon tiene muchas ventajas. Algunas de las más significativas para etece son:

  • Alta disponibilidad nativa en muchos de los servicios como SES, ElastiCache, RDS, etc…
  • Escalabilidad horizontal muy sencilla si has definido todo bien desde la base.
  • Pago por uso. Puedes tener una infraestructura muy potente y pagar muy poco si tienes poco tráfico.
  • Servicios en continua mejora y evolución. Amazon está apostando fuerte por sus servicios web y se nota.
  • Olvidarte por completo de algunos servicios que son comodity y que causaban muchos dolores de cabeza como SMTP, réplicas de base de datos, rotación de backups, etc…

Contras
No todo puede ser prefecto y existen algunos puntos que hay que considerar. La mayoría tienen que ver con detalles de algunos servicios pero no por eso dejan de ser contras:

  • No es barato. La nube de Amazon te da muchas cosas pero las pagas. No es prohibitivamente caro pero si algo más que otras alternativas como VPSs de algunas empresas.
  • El servicio de base de datos relacional con MySQL (no se si pasa con los otros SGBD) sólo funciona con timezone UTC sin posibilidad de cambio lo que te obliga a tenerlo en cuenta en tus aplicaciones.
  • Si vas con Amazon es para ir con todo y no quedarse a medias tintas. Es la maneja de usar todo su potencial.
  • Debes controlar la calidad de tus emails para mantenerte dentro de unos criterios que define Amazon si quieres usar SES.
  • La invalidación de contenido servido por CloudFront es muy lenta, es mejor usar versionado de los elementos y controlar tu mismo su invalidación.
  • La consola web está muy bien pero hay cosas que se tienen que hacer mediante el uso del API a través de la SDK como el autoscaling lo que supone, en algunos casos, invertir más tiempo del deseable para dejar todo muy fino.
  • No existe a día de hoy un servicio de almacenamiento compartido. Hay gente que usa S3 para este propósito pero el tiempo de acceso a los recursos lo desaconseja totalmente. Nosotros hemos montado un servidor que comparte su almacenamiento por NFS y mientas las máquinas con las que comparte estén en la misma región, el tráfico es gratuito.

Operativa
Como parte de nuestras tareas básicas de operaciones hacemos algunas preventivas que se podrían automatizar pero de momento no tenemos tiempo:

  • Tenemos siempre una imagen actualizada de cada tipo de máquina que usamos. Así levantar nuevas imágenes clon manualmente y escalar a demanda es casi inmediato, aunque es manual.
  • Guardamos snapshots de cada máquina después de cada cambio para poder recuperar el último punto bueno conocido y poder crear nuestras propias imágenes cuando necesitemos.
  • Monitorizamos mediante CloudWatch todos los parámetros importantes de cada servicio y asociamos alarmas a los más importantes.

Todavía nos queda mucho camino que recorrer pero creo que tenemos un buen punto de partida. Espero que estas líneas puedan ayudara alguien y por supuesto, estaré encantado de contestar las preguntas relacionadas con el tema, siempre que conozca la respuesta.

Mis errores como CTO en Toprural

Publicado el por

Tal y como hice en el post anterior donde repasé mis errores como CTO en BuyVIP, voy a repasar mis errores como CTO en Toprural, como parte de la serie de posts auto críticos que inicié con este post.

Me incorporé a Toprural en junio de 2008 después de dejar voluntariamente BuyVIP. Me encontré con un equipo técnico ya montado de 10 personas de los que 8 se dedicaban a desarrollo y que estaban repartidos en dos equipos: los que estaban desarrollando desde cero un nuevo Toprural en nueva tecnología y los que estaban manteniendo el antiguo Toprural. El foco era cumplir el plan de migración al nuevo Toprural (15 meses que terminaron siendo 18) junto con la implantación de un ERP (finalmente fue Microsoft Dynamics NAV) y el reciclaje del equipo encargado del mantenimiento del antiguo Toprural. No fue un aterrizaje fácil ya que una parte grande del equipo técnico no entendía la necesidad de un CTO, pensaban que no necesitaban jefe y lo peor, pensaban que la empresa dependía de ellos, lo que generaba un ambiente de ellos contra el mundo. Afortunadamente con el tiempo fueron entendiendo mejor la situación y se terminaron destapando las manzanas podridas del equipo. Allí me encontré a gente muy brillante técnicamente y alguno evolucionó de manera impresionante, siendo mi sustituto como CTO tras mi salida. A Paco le deseo lo mejor en su nueva etapa fuera de Toprural y espero que algún día podamos volver a trabajar juntos.
En esta nueva etapa me sentía muy a gusto y con la confianza de la dirección. Tanto François como Rafa creían en mi y en mi criterio y yo pude aprender mucho de ellos. Sin duda fueron buenos tiempos. Los principales errores que destaco de aquella época son:

  • No traerme a todo mi equipo de confianza. Creo que es esencial tener confianza ciega en las personas más importantes de tu equipo. En esta nueva aventura me acompañaron, algunos meses más tarde, dos de las personas de mi equipo de BuyVIP aunque una de ellas se volvió bastante pronto a BV tras no gustarle lo que allí encontró (incluso creo que yo mismo fui una de las cosas que no le gustó, aunque ya me conocía). Me costó demasiado tiempo sentirme alineado con mi equipo y eso nos impidió ir más rápido y mejor. Finalmente lo conseguí parcialmente al poder confiar plenamente en el trabajo que hacía el que fue mi sustituto.
  • No tener buen ojo con los fichajes. No todos los fichajes fueron malos ni mucho menos. Algunos fueron realmente buenos, pero unos cuantos fueron un error completo y lo peor fue que conseguí el efecto contrario al buscado: En lugar de alinearse conmigo, se alinearon con las manzanas podridas.
  • No despedir a quien debía cuando debía. Este punto suena muy duro y habrá gente que piense que soy un insensible o cosas similares pero nada más lejos de la realidad. El despido es un drama para todas las partes. Para la empresa porque tiene que prescindir de un profesional al que una vez quiso en el barco y que tiene que suplir con otra persona, con el trastorno que eso supone. Para el trabajador… Un palo muy duro. Aunque muchas veces es la mejor solución para todas las partes implicadas. El tema del despido requeriría un post aparte que escribiré cuando acabe esta serie. El caso es que debía haber limpiado la casa de manzanas podridas y haber dejado a los realmente buenos e implicados, fichando y renovando al equipo, aunque a corto plazo supusiera un retraso en loa planes. En estos casos te terminas dando cuenta que todo el tiempo que retrasas esta decisión es tiempo perdido.

Me marché de Toprural a finales de 2009 para montar tagUin. Después de pasar por dos empresas exitosas de Internet, no pude contener más el gusanillo emprendedor y decidí dar el salto, dejar un buen trabajo para montar un proyecto propio. Tuve la suerte de que muchos amigos e inversores apostaron por mi y por el proyecto, pero no estuvo exento de errores, aunque esta vez no fueron tanto técnicos o de gestión de equipos… pero eso lo cuento en el siguiente post.

Mis defectos y virtudes

Publicado el por

Voy a empezar a escribir una serie de posts bastante reflexivos, con una dosis fuerte de autocrítica y auto análisis que espero que sirvan a alguien para no cometer los mismos errores y de paso os animen a hacer el mismo ejercicio. Creo que es importante conocer nuestras fortalezas y debilidades para intentar corregir las segundas e impulsar las primeras. Como le decía a un gran amigo hace ya algunos años en tono jocoso: «lo primero es reconocer que eres un atraso de persona. A partir de ahí todo es construir».

Los posts que quiero escribir en esta serie son:

No van a ser posts demasiado largos ya que no tengo demasiado tiempo. Mi hijo ha cumplido un año hace pocos días y le dedico el poco tiempo libre que tengo. Por eso voy a escribir en ratos cortos e intentaré que los posts sean muy concentrados.
Me pongo a ello…

Qué hace falta para ser CTO

Publicado el por

En mi anterior post sobre equipo técnico en una startup, Luis Clemente me preguntaba sobre qué hace falta para llegar a ser CTO. Tal y como le contestaba a él en ese comentario, esa reflexión tiene contenido suficiente como para escribir un post y por ello aquí estoy reflexionando sobre, lo que bajo mi punto de vista, hace falta para llegar a ser CTO.

No quiero parecer que hago una descripción de mis aptitudes y cualidades profesionales, ya que alguna de las que mencionaré yo no las tengo, pero cuando me las encuentro en otros profesionales las aprecio mucho y creo que son importantes.

Formación

El primer punto que considero básico es la formación. No quiero decir que para ser CTO hace falta ser Ingeniero Informático o de Telecomunicaciones, pero si considero casi imprescindible tener una base técnica que nos permita entender y desarrollar nuestras funciones sin limitaciones.  Como CTO vamos a necesitar saber de desarrollo, sistemas, infraestructuras, etc… además de otros conocimientos más relacionados con gestión económica, estrategia y negociación, aunque estas últimas es más normal adquirirlas durante nuestra trayectoria profesional. No descuidéis vuestra formación en ningún momento ya que en nuestra profesión tenemos que estar en continuo aprendizaje.

Experiencia

Como decía mi abuela: «más sabe el diablo por viejo que por diablo». En el ámbito profesional muchas veces tenemos capacidad de resolver problemas o aportar soluciones cuando basamos nuestros criterios en experiencias anteriores de las que hemos aprendido qué funciona y qué no, aunque más veces aprendemos qué es lo que no funciona que al contrario. Por ello creo que un buen CTO suele ser un profesional con unos 10 años de experiencia.

Mi primer puesto de CTO fue en BuyVIP en el 2007 cuando tenía unos ocho años y medio de experiencia y aunque en aquel momento pensaba que estaba sobradamente preparado, ahora me doy cuenta que no me hubieran venido nada mal un par de años más de experiencia. Por el contrario al incorporarme en Toprural creo que tenía una madurez profesional mayor además de más experiencia y conocimiento y pude desempeñar algo mejor mis funciones, aunque quién mejor lo puede juzgar son mis jefes.

Por ello creo que no hay que tener prisa en llegar a un puesto de dirección. En varias ocasiones en mi carrera me he encontrado con buenísimos profesionales que han llegado a puestos de dirección demasiado pronto y no han tenido la madurez profesional suficiente como para asumir las responsabilidades del puesto y aceptar la presión y el stress de una forma natural, lo que en muchas ocasiones desembocó en un profesional quemado, que no hace bien su trabajo y que sufre un parón muy grande en su progresión profesional.

Buenos mentores

Ya que hemos empezado con los refranes, voy a usar uno más: «al que a buen árbol se arriba, buena sombra le cobija». Es decir busca siempre los mejores jefes posibles e intenta aprender de ellos. En este concepto creo que yo he tenido excelentes jefes y mentores de los que he aprendido y sigo aprendiendo mucho. Por mencionar algunos: Alejandro García y Paco Romero en Capgemini, José Luis Vallejo y Gustavo García en BuyVIP y François Derbaix y Rafael Pérez-Olivares en Toprural.

A todos ellos los identifique como profesionales con más experiencia que yo y con excelente aptitudes en algunas áreas. Lo que hice fue intentar siempre aprender el máximo de ellos en cada oportunidad que tuve e intentar que no se me pegaran algunos de sus defectos (todos tenemos defectos). Sin duda ellos tienen gran parte de culpa en mi perfil profesional.

Por el contrario me he encontrado con algunos profesionales que tienen un potencial enorme y un recorrido importante, pero que, o bien no han tenido buenos jefes y mentores, o bien no han aprendido de ellos lo que deberían. Esta circunstancia les lleva muchas veces a tener experiencias y ejemplos no demasiado buenos y a imitar esos comportamientos cuando están en una situación similar.

Sin duda es esencial tener buenos jefes y aprender el máximo posible de ellos.

Jugador de equipo

Bajo mi punto de vista el trabajo técnico es un trabajo en equipo y en gran medida nuestros resultados, éxitos o fracasos dependen del trabajo y rendimiento del equipo. Por ello creo que es importante ser jugador de equipo en fases previas a ser CTO y aprender a trabajar por y para el equipo. Eso nos llevará a tener una actitud hacia los compañeros muy buena que arrastraremos cuando lleguemos a ser CTO.

Una vez que hemos llegado y en nuestros primeros meses en ese puesto creo que es básico tomarlo con la mayor humildad posible tratando de seguir haciendo equipo, respetando y apoyando al máximo a los compañeros. Sin duda obtendremos mejor rendimiento de todos y mucho más cohesión y mejor ambiente de trabajo.

Orientación a resultados

Mi experiencia es que los puestos directivos son mayoritariamente orientados a resultados. Es decir, no nos van a medir por cuánto trabajamos si no por si obtenemos los resultados adecuados. Esta orientación es importante que se adquiera cuanto antes mejor en nuestra trayectoria profesional y aprendamos a trabajar por objetivos. Si estamos acostumbrados a trabajar nuestro horario y si el trabajo sale bien y si no pues también, sin duda tendremos experiencias muy traumáticas en nuestro camino hacia ser CTO.

Visión comercial y de negocio

En este punto voy a ser un poco polémico, pero creo que merece la pena. Es habitual encontrar profesionales del área técnica que no quieren saber nada del cliente, del negocio y de la estrategia. Si éstos llegan a ser CTO’s no creo que sean demasiado buenos en su trabajo ya que un puesto directivo requiere de una visión mucho más amplia que la técnica para entender los objetivos de la empresa y poder aportar con la tecnología para conseguirlos. Igual estos profesionales de los que hablo podrán ser excelentes arquitectos técnicos o algún otro puesto de alto nivel que sea simplemente técnico, pero para ser CTO hay que tener otra visión mucho más cercana al negocio y poder aportar a mejorar el negocio con la tecnología. Esta visión y orientación al negocio no se adquiere de un día para otro y es importante ir cultivándola durante nuestra carrera profesional. Si trabajáis en consultoría, no perdáis la oportunidad de participar en reuniones con clientes y en cualquier caso intentad siempre plantearos de qué manera ayuda vuestro trabajo al negocio de vuestra empresa.

 

Creo que no me dejo ninguno de los atributos que creo necesarios para llegar a ser CTO. Como siempre me encantará conocer vuestra opinión y si consideráis que me falta algún atributo, no dudéis en comentarlo.

Días en los que volvemos la vista atrás

Publicado el por

Con el ritmo diario que llevamos, es bastante raro que volvamos la vista atrás y nos paremos a pensar dónde estábamos hace algún tiempo. Uno de esos días en los que lo alguna vez lo hacemos es en fechas señaladas como cumpleaños o navidades. Pues bien hoy, 2 de julio, es mi cumpleaños y un buen momento para volver la vista y ver cómo han cambiado las cosas en los últimos años, meses o incluso semanas.

2007, un año apasionante en BuyVIP

Tal día como hoy hace tres años estaba trabajando en BuyVIP. Me había incorporado hacía algunos meses el proyecto en el que, por aquel momento, no éramos más de 12 o 15 personas. Eran momento de mucho trabajo en una start-up que crecía día y día y por aquellas fechas se estaba negociando una ampliación de capital que a la postre se acabó firmando con 3i.

A mi todos los conceptos de valoración pre-money, dilución, etc… me sonaban un poco a chino, pero estaba viendo desde dentro cómo vive una compañía en los momentos previos del cierre de una ronda de esas dimensiones. Por aquella época veía lejos el emprender por mi cuenta aunque la idea ya rondaba mi cabeza.

2008, un año de cambios. Nace en mi cabeza tagUin

El 2 de julio de 2008 estaba trabajando en Toprural. Hacía poco más de quince días que me había incorporado, después de salir de BuyVIP tras varios meses de mucho trabajo y stress. Para mi fue un cambio importante, salir de una empresa que iba a un ritmo vertiginoso, pero sin tener afianzados los procesos básicos de negocio, e incorporarme a una .com con 8 años de vida en aquel momento (hace poco han celebrado sus 10 años, felicidades!!!), con un negocio muy rodado, con un equipo de primera línea y un proyecto de migrar la web y el backoffice por delante que me motivaba mucho.

Todavía no había nacido la idea de tagUin, ya que lo hizo entre octubre y noviembre de aquel año, aunque la idea de emprender cada vez tomaba más fuerza en mi cabeza. Creo que vivir tan de cerca y desde una posición de dirección privilegiada lo que supone emprender con éxito (François Derbaix es un gran ejemplo de emprendedor de éxito) me impulsó todavía más. Mi background como CTO había evolucionado mucho en el último año y creo que en Toprural pude aportar bastante más a nivel de estrategia y dirección de lo que aporté en BuyVIP. Sin duda la experiencia es un grado.

2009, el principio del fin

Hace exactamente un año todavía trabajaba en Toprural, aunque ya sabía que quedaba poco para dar el salto. tagUin ya había nacido, llevábamos casi cinco meses trabajando en la primera beta de la web en fines de semana y noches y emprender por cuenta propia estaba cerca. François ya conocía el proyecto y ya habíamos hecho un plan de transición para que pudiera salir de Toprural sin perjudicar demasiado a la empresa a la vez que fuera bueno para mi. François ha sido una de las personas que más me ha ayudado (junto con José Luis Vallejo) en la fase previa a emprender con sus consejos, ayudas, comprensión y apoyo, tanto personal como económico. Todavía hoy me da pena haber salido de Toprural, pero la «llamada de la selva» había llegado y no podía ignorarla. Emprender estaba muy cerca.

Un año muy intenso

Desde el 2 de julio de 2009 hasta el día de hoy (2 de julio de 2010) he pasado por vivencias muy intensas. Hemos creado tagUin, hemos conseguido capital semilla, he dejado mi trabajo por cuenta ajena para dedicarme full-time a tagUin, hemos intentado ejecutar el plan de negocio con más o menos éxito y de nuevo estamos buscando capital para hacer una nueva ampliación de capital.

Ahora sin que tengo claros los conceptos de valoración pre-money y dilución. Ahora si que entiendo lo difícil que es encontrar financiación. Ahora ya se lo que es emprender. Ahora soy un año más viejo…