Hoy decimos

Resolvemos tus problemas - Conversá con nosotros

lunes, 30 de septiembre de 2013

Tecnología de contenedores en Linux

La tecnología de virtualización vía containers en Linux está tomando por sorpresa a muchos, mostrando una mucho mejor relación costo/beneficio para deployments en nubes públicas y privadas, que el actual uso de hipervisores completos para virtualizar servidores.

Los contenedores no son tecnología nueva, de hecho la implementación de contenedores en Linux todavía tiene algunos puntos flacos respecto de las tecnologías de contenedores de los unices AIX y HP-UX (bueno. OpenVZ no).

La clave es que los contenedores y su manejo optimizado de recursos de hardware se perfilan, para muchos casos de uso, mucho mejor para el uso en infraestructura virtual que el resto de las técnicas de virtualización usadas por ESX, Hyper-V, KVM, Xen, etc.

Las nubes públicas basadas en Linux (Rackspace, HP Cloud, Amazon, etc.), tienen una ventaja clave aquí: podrían implementar contenedores sobre sus infraestructura con mínimo esfuerzo, porque ya corren sus máquinas virtuales sobre Linux (y los contenedores Linux necesitan un sistema operativo Linux de host, corriendo sobre el hardware físico).

Docker no hace más que mejorar las perspectivas a corto plazo

viernes, 27 de septiembre de 2013

Howto: Cómo crear un mercado IT desde cero, en Corrientes

Este artículo iba a ser un howto en toda la regla, paso a paso, un procedimiento ordenado para bootstrapear un nuevo mercado de tecnología informática en la Ciudad de Corrientes, en cambio, recordando lo aprendido de los viejos emprendedores, les voy a contar una historia y el "cómo" es algo que van a tener que descubrir, "tarea para la cabeza, no para la casa" como decía una vieja profesora de Producción que tuve en los 90'.

Sigue siendo un howto, solo que para verlo, tenés que poder aprender de la experiencia.


Hay nuevos mercados de IT sin explotar en Corrientes, varios, ahora
Aunque no lo parezca a la vista para los que son relativamente nuevos en la industria IT local, el concepto de trabajar con nuevos mercados no es para nada extraño a la industria IT de Corrientes.

En los relativamente pocos años que trabajé y emprendí en la industria IT local pude participar muy de cerca: presenciar la propulsión, promoción, despegue y asentamiento de varios nuevos mercados para la industria informática de la región y en la ciudad de Corrientes en particular.


Entiendo la reluctancia a creer que "no hay posibilidad de que haya nuevos mercados de industria informática en la ciudad de Corrientes", ya que existe una coyuntura actual tal en la que la muchos de los profesionales y gente del ambiente IT, incluso empresarios IT, han trabajado durante años en la coyuntura actual, con pocas novedades respecto de años anteriores, y no han visto y/o participado de la aparición de nuevos mercados de informática en Corrientes.

La mayoría no emprendió o no pudo emprender más que brevemente*, llegando a "confirmar" que "no hay mercado para vender informática en Ctes.", y continuan su carrera profesional en IT como empleados y/o como empleados/emprendedores en negocios no IT en la región. Tengo la convicción de que tales "confirmaciones" fueron conclusiones apresuradas y deberían haber intentado emprender de nuevo. Pero no es una convicción sin fundamento.

*Yo mismo estuve en esa situación en algún momento y estuve totalmente convencido de la imposibilidad de emprender de vuelta en la industria informática de Corrientes.


El motor real de los nuevos mercados de informática en Corrientes
Hay un hecho afortunado para todos los actores de la industria IT correntina: la capacidad de emprender, de hacer empresa en la industria informática, no tiene que ver ni está limitada en modo alguno por el nivel de conocimiento y experiencia técnica en informática del emprendedor, por muy alto que sea dicho nivel y por mucha experiencia que tenga la persona en la industria informática.

Parece contraintuitivo :-), parecería ser una desventaja, no lo es. En realidad se constituyó - varias veces ya - en una ventaja y un factor que maximiza la oportunidad de éxito, es decir, "funciona" y muy bien.

De hecho, la creación de los últimos nuevos grandes mercados - masivos y altamente rentables - en la industria informática de la Ciudad de Corrientes tuvo una participación mínima de los profesionales de sistemas y en cambio fue impulsada y sostenida mayormente por personas autodidactas en informática, no profesionales, que eran a lo sumo estudiantes universitarios de sistemas, pero estos últimos inclusive siempre fueron una minoría - naturalmente, dada la escasa cantidad de estudiantes universitarios de carreras de sistemas en la ciudad de Corrientes - de entre los actores principales que movilizaron la economía de la ciudad hasta constituir cada uno de los mercados que voy a mencionar a continuación.

¿Cuáles fueron esos mercados nuevos?


A principios de los 90'
El negocio de los institutos de computación


Cerca de 1989 yo estaba aprendiendo a armar - "conectar" - computadoras desktop en uno de esos institutos, que eran en la práctica, "escuelas de hacking de hardware de escritorio", y en muchos lugares, lo mejor se aprendía al terminar las clases de DOS, compartiendo diskettes, y teníamos entre los pocos riesgos de ese entonces, al Stoned.

Los institutos fueron apareciendo de a poco, primero uno, luego dos, y al cabo de 3 años había al menos 7 en una ciudad donde casi nadie tenía una PC de escritorio en su casa, y muy pocos la tenían en el trabajo. De todos modos, la demanda fue muy alta durante años y sostuvo la buena rentabilidad de muchos institutos.

Eventualmente, las PCs baratas y el acceso a Internet hogareño erosionó la base de clientes de los institutos y solo quedaron unos pocos, que habían diversificado sus cursos a otras temáticas y/o que tenían suficientes contactos para vender regularmente capacitaciones masivas a entes estatales o privados.

Fue el primer mercado IT de Corrientes, nacido desde prácticamente cero en el que tuve algún nivel de participación: en 1987 había varias academias para aprender a escribir a máquina (la mecánica, las Olivetti, etc.), y tal vez uno o dos institutos de computación, un tanto avejentados; dos años después los institutos estaban abriendo sucursales por todas las ciudades del interior y cada instituto tenía al menos dos sedes en la ciudad Capital.


A finales de los 90'
El negocio de los cibercafés

(y la propulsión de mercados de productos y servicios complementarios: ventas de componentes de PC, ventas mobiliario, alquileres, nuevos puestos de trabajo, etc.).


La adopción de Internet iba lenta en Corrientes, las facturas telefónicas a pagar por navegar por Internet + el precio de suscribirse eran muy caras para el promedio de sueldos pagados en la ciudad de Corrientes; algo similar pasaba con los precios de las computadoras necesarias para navegar. Así entré en un cibercafé por primera vez en 1995.


A finales de los años 90' se dió el surgimiento de al menos 4 importante comercios de informática que hoy todavía persisten en la ciudad, que inicialmente se dedicaron a la instalación y mantenimiento de cibercafés.

Era en gral. un mercado nuevo, grande y sin explotar, decenas de cibercafés por toda la ciudad funcionaban mantenidos desde lo técnico y a duras penas por los empleados que los atendían y por algunos reluctantes incluso, técnicos que recorrían "cibers" todo el día, desde la mañana temprano hasta bien entrada la madrugada, reparando PCs, limpiando virus, reinstalando sistemas operativos y software.

No era raro ver que un cibercafé del barrio permanecía abierto toda la noche, una vez por semana, fuera del fin de semana, ya que en ese momento venía el técnico y se encargaba de "preparar" las máquinas para el exceso de carga del fin de semana: con uso intensivo en juegos en línea, sesiones interminables de navegación y prácticamente solo 6 horas de descanso en 72 horas de uso contínuo, tres días, de viernes a domingo.

Desde lo personal participé personalmente, colaborando con los emprendedores aunque no como socio, en el despegue de tres cibercafés que tuvieron un nivel de éxito muy alto, el último inclusive con éxito sustancial, obvio resultado del nivel de refinamiento de las diferentes metodologías de comercialización aprendidas en las experiencias anteriores, así como del refinamiento en el manejo de las tecnologías más útiles para implementar en un cibercafé (que por cierto propulsaban la automatización casi extrema, dejando libres decenas de horas/hombre tanto para los técnicos - ahorrando costos de mantenimiento - como para los empleados, que podían dedicarse a tareas secundarias a la "gestión constante" de las máquinas) - que hoy son estándares, pero en ese momento eran 100% artesanales.


A finales de los 90'
Mercado de servicios de desarrollo de aplicaciones a medida basadas en Visual Basic
(hoy evolucionado a provisión de software enlatado, como productos)


Antes de que fuera estándar, habitual y un hecho dado, el que una radio FM, un diario, tuviera un sitio web donde publicar noticias, no había nada de eso, no había acceso a Internet en la mayoría de los hogares e inclusive empresas en la ciudad de Corrientes, sin embargo ya había una cantidad suficiente de computadoras instaladas, tal que - junto a otros factores - permitió la aparición de un importante mercado local de desarrollo de software a medida.

El software que se vendía masivamente tenía que ver con la ahora vieja escuela de creación de aplicaciones rich-client, principalmente basadas en Visual Basic 5, la metodología y técnicas de venta fueron mayormente rudimentarias, no porque los productos - muchos, aunque no todos - no fueran de buen nivel técnico, sino porque los actores económicos tenían poca experiencia en el negocio de la venta de softwar.

Eran literalmente todos nuevos actores (compradores, vendedores, productores, etc.), ya que las pocas empresas locales de informática de ese momento en la ciudad se dedicaban a negocios "más grandes" que vender software Visual Basic a medida...y muchas perdieron ese tren y ya no están más presentes en el mercado.

Este mercado se agotó parcialmente luego de que los jugadores más previsores del mercado se constituyeran en proveedores de productos, software ya desarrollado, con cero tiempo de desarrollo y entrega inmediata, vs. los demás oferentes del mercado, que seguían intentando vender el servicio de desarrollo a medida de software (costoso en recursos, caro en precio, etc.), que finalmente ya está prácticamente desaparecido en la ciudad.


A principios del 2000'
Mercado de servicio de desarrollo de aplicaciones a medida basadas en PHP
(hoy evolucionado a provisión de software enlatado, como productos, principalmente CMS)


En los primeros años de la década del 2000, en Corrientes Capital estaba empezando a popularizarse el uso del lenguaje PHP, y la aparición de los primeros CMS, manejadores de contenido estaba por revolucionar el mercado de venta de software a medida en la ciudad (y también en toda la región NEA).

Volviendo a PHP, unos pocos participantes empezaron a crear el mercado, en principio - todavía inclusive - fogueados por la financiación de diversos interesados en aprovechar la nueva plataforma web, Internet para masificar aún más distintos tipos de campañas de marketing dirigido, en principio, muy relacionados con la actividad política, pero que luego fueron sencillamente plataformas de marketing dirigido en general, participando de campañas de publicidad dirigida prácticamente todo el espectro de posibles oferentes en la ciudad (partidos políticos, organizaciones no gubernamentales, variopintos sectores del estado provincial, municipal, inclusive nacional, comercios en gral., nuevos comercios, etc.etc.).

Claro, que con semejante nivel de participación de actores económicos diversos y capaces de suficiente nivel de financiamiento, los sitios de noticias web se multiplicaron en poco tiempo, al igual que los desarrolladores PHP independientes dedicados a satisfacer la incesante demanda de CMS para ser utilizados como plataformas de marketing dirigido.

También es obvio que la presencia de cibercafés y clientes contados por miles por día en ellos, por toda la ciudad de Corrientes ayudó a foguear el mercado de sitios web de noticias como plataformas de marketing dirigido.

En lo personal en esta época tuve la oportunidad de colaborar, aportar ideas - desde la "etapa de garage" - en la creación, consolidación y estabilización de una de las empresas con mayor experiencia en desarrollo PHP de la ciudad, muy conocida en la actualidad.


Década del 2000'
Revival de los institutos de computación en Corrientes


A principios de la década, junto con mi socio Carlos Pace y Andy Acevedo, dictamos los primeros cursos sobre Linux en la ciudad de Corrientes (en la FACENA - UNNE),  en su momento estuve seguro de que fue "el primero de la ciudad", hoy ya no tanto, porque había mucha gente arrancando con la idea de dictar cursos de Linux en la ciudad, al mismo tiempo.
La demanda fue pervasiva, y hubo que duplicar los horarios disponibles, nuevas ediciones de los cursos fueron dictadas en años subsiguientes, un par las volví a dictar yo, y se sumaron nuevos dictantes.

Los cursos y trainings de Linux se dispararon en varios institutos en la ciudad y se produjo un boom moderado de cursos de Linux. Pero fue creciendo con el paso de los años, y hacia finales del 2006, 2007, ya había cursos de Linux e institutos con mucho éxito comercial dictándolos en la ciudad.

Luego de algún tiempo la demanda de training Linux en Corrientes bajó bastante, cuando se dió la percepción de que Linux no añadía demasiado a las posibilidades de conseguir empleo de los autodidactas y profesionales de la informática en la ciudad. Proposición que se reveló últimamente como falsa, dado que un conocimiento importante de Linux es la llave que abre las puertas al trabajo en desarrollo PHP a nivel profesional e internacional inclusive.



Finales de la década del 2000'
Otros mercados nuevos en Corrientes


No es tan evidente, pero en los últimos años de la década la ciudad y el ambiente relacionado con la informática en Corrientes asistió a la aparición de varios nuevos mercados locales de venta de productos y servicios informáticos, solo que no fueron tan masivos como los ocurridos previamente, mencionados arriba. Algunos fueron muy rentables solo por un par de años, y los emprendedores lograron capitalizar sus emprendimientos de tal modo que hoy se dedican a la venta de productos y servicios IT más tradicionales (por esto es que no es tan evidente que sus empresas nacieron gracias a la explotación de nuevos mercados).

También tuve en un par de estos casos la oportunidad de colaborar con varios de los emprendedores en la ciudad, que lograron finalmente llevar adelante sus visiones de negocio en IT.

Por ejemplo: training de seguridad informática, software con características de geolocalización, servicios de intermediación de hosting, etc.

Y muchas más, ya que algunos nuevos mercados fueron mercados de nicho, específicamente asociados a determinados tipos de organizaciones y clientes (y a proveedores locales fuertermente especializados también), una actividad que si bien fue rentable para los actores, no fue demasiado pública y ni siquiera fue demasiado conocida en los círculos más amplios de personas relacionadas con la industria IT en Corrientes.

Tip: Mercados en boga ahora mismo en la ciudad de Corrientes: 
  • Training de informática a distancia vía Internet
  • Desarrollo mobile orientado a mercado locales (NO a clientes en Internet)

La dificultad para "ver" los nuevos mercados IT potenciales en Ctes.
La principal dificultad es que los ámbitos de operación de las empresas IT de Corrientes están fuertemente separados, y la articulación entre empresas es puramente circunstancial, casi nula en la mayoría de las empresas.

Un verdadero ecosistema de empresas IT, con importantes nexos B2B, dejaría "ver" a los empresarios muchas oportunidades fuera de su propio ámbito de negocios IT actual, pero como están totalmente focalizados en un solo ámbito de operaciones, se llega a tomar por veraz e irrefutable la idea de que "no hay plata en IT en Corrientes para hacer otra cosa aparte de X" (X = lo que sea que estén vendiendo), hecho que como se puede aprender de la historia reciente, es en realidad, una falacia.

Muchas veces el nivel de falta de información, gracias a una exitosa disciplina de discreción, hace que dos grandes emprendedores IT correntinos vayan a encontrarse en el mismo lugar, al mismo tiempo, sin saber que tienen un par sentado justo a su lado.


Empresas IT y no IT constituídas hoy en Corrientes y su origen
Es evidente que en la actualidad que muchas de las empresas relacionadas con la informática, hardware y software, existentes hoy en la ciudad de Corrientes tuvieron su capitalización inicial de origen en las escaladas de demanda surgida de la creación / aparición de nuevos mercados de industria informática en la ciudad en años anteriores.

Obviamente, un cierto número importante de inversiones y empresas no relacionadas con la informática en la ciudad de Corrientes tuvo el origen de sus capitales iniciales en la explotación de los mercados antes mencionados, capitales que fueron apropiadamente invertidos maximizando la diversificación de inversiones ("no poner todos los huevos en la misma canasta"), así tenemos que muchos empresarios de la ciudad que hoy se dedican a otros negocios (Maxikioscos, Minimercados, Inmuebles, Remises, etc.), en principio fueron importantes empresarios de la industria IT correntina.

Claro, eso nos lleva a otra idea interesante: muchos viejos emprendedores IT que salieron del negocio IT - volcándose a nuevos negocios e inversiones en el emprendedorismo, aunque continuaran trabajando en IT - en algún momento en los últimos 20 años, conocen muy bien la ciudad y cómo funcionan el mercado IT de Corrientes, así que de vez en cuando, al presentarse una oportunidad de mercado, vuelven a "aparecer", y en general nadie se acuerda de que ya estuvieron, varias veces, para alegría de los muchachos de marketing, que puede fabricar una presentación de mercado desde cero vs. la dificultad de plantear un "comeback".

jueves, 26 de septiembre de 2013

El primer pivoteo de Libres Consultores

Hoy completé el primer deployment del hipervisor múltiple, tengo un artículo en preparación explicando la idea en detalle, pero hoy quiero hablar del primer pivoteo de Libres Consultores.


https://en.wikipedia.org/wiki/Lean_Startup#Pivot
Resulta que el enfoque inicial de LC fue trabajar vendiendo consultoría en soluciones informáticas, todavía lo hacemos, pero el scope de ventas esperado inicialmente no lo alcanzamos, entonces decidimos pivotar hacia una idea nueva, y ese camino nos llevó hacia el desarrollo de productos basados en tecnología IT.

El primer enfoque no funcionó en principio porque el mercado de consultoría para infraestructura informática de nivel empresarial es relativamente chico en Corrientes, Capital (explícitamente aclaro: no estoy expresando que el mismo mercado sea chico en el NEA en gral.).

Los proveedores de consultoría de la ciudad están asentados hace tiempo y con una cartera de clientes bastante estable, y tienen una capacidad efectiva para proveer todos los servicios de consultoría sobre infraestructura que pudieran requerir esos clientes, desde la menor escala a la mayor escala de las infraestructuras existentes en la ciudad.

Por ende el mercado de consultoría si bien no está "cerrado" explícitamente de ninguna manera, en la práctica sí lo está; claro que la competencia esperable ante potenciales nuevos clientes es intensa, y entre otras cosas, la capacidad de provisión de servicios y el prestigio ganado a lo largo de años de óptimo rendimiento comercial y profesional juega a muy favor de los jugadores establecidos.

Así que en la práctica el primer producto mínimo viable ofrecido por Libres Consultores justamente resultó en un fallo y hubo que pivotear, reorientando la estrategia empresarial hacia mercados menos cerrados, de hecho, nuevos mercados locales, sin explotar aún.

Link

Pivoting in a Lean Startup

http://matthewmamet.com/2010/07/pivoting-in-a-lean-startup/

martes, 24 de septiembre de 2013

Precios baratos y nuevos mercados

En algún momento comenté que los productos de Libres Consultores van a ser relativamente muy baratos, aunque sea alta la calidad del software, de sus componentes y del mismo producto final. Uno de los factores principales determinantes de los precios es que usamos software opensource para el desarrollo de los productos.

El precio además está determinado otros parámetros y en el caso de los productos de LC, ellos se alinean a favor de precios relativamente muy baratos respecto de lo que está acostumbrado el mercado a pagar.

Mencioné "relativamente" porque la estimación de que los precios van a ser baratos no se está haciendo contra productos que se estén vendiendo hoy en Corrientes (no voy a arriesgar a asegurar lo mismo de Resistencia, pero es bastante posible que sea así también allí). Como expliqué someramente en uno de los primeros posteos de este blog, Libres Consultores tiene como misión desarrollar un mercado nuevo.

Como el mercado objetivo actualmente no existe*, de momento no hay ni un solo vendedor ofreciendo, vendiendo nada a nadie, a ninguno de los potenciales clientes de Libres Consultores. De hecho, según los estudios de mercado que estuvimos haciendo los últimos meses, las chances se dan a favor de que cerca del 100% de los potenciales clientes de LC no están usando ahora mismo ningún tipo de producto similar a los que está desarrollando LC.

* Por cierto, que el mercado no exista en el presente no implica que no se pueda realizar previsiones fundadas sobre cómo se estructuraría al poco tiempo de surgir.

Alguno se puede llegar a preguntar cómo es que nadie le está vendiendo nada siendo que las empresas IT de la zona están ávidas y muy capacitadas para realizar tal trabajo, bueno, de momento esa información es parte del capital logístico de LC. Para solventar esa deuda interna de inteligencia logística, sugiero emprender cabales estudios de mercado.


Algo que comentamos antes es que parte de la base de la logística de producto de LC es trabajar con bienes complementarios: al poder integrar un bien que es complementario a otros ya existentes, y al combinar ese evento con una estrategia se potenciaría una fuerte integración con sus complementos (que ya están en el mercado y vendiéndose a buen ritmo, por cierto), y si se logra retroalimentar el fenómeno de modo apropiado, no solo se dispararía la demanda de productos de LC, sino también la de los bienes complementarios, graciosamente elevando el grado de informatización global en la ciudad de Corrientes.

Mercado nuevo
Crear un nuevo mercado no es tan interesante ni revolucionario como puede parecer al ojo inexperto en negocios, al contrario, para el negociante promedio suele ser mucho más interesante desde varios puntos de vista intentar entrar en un mercado ya existente.

Aún así, los mercados nuevos se crean constantemente, simplemente se da que en IT, habiendo una aparente sobre-oferta de productos y servicios, muchos consideran - sin haber realizado estudios de mercado - que no hay nada nuevo que ofertar. Sin embargo, tal como es constantemente demostrado por los nuevos productos que salen al mercado, esa apreciación no es correcta.

Productos nuevos* que sirven de ejemplo: WhatsApp, Tumblr, etc.

* Ambos ejemplos me sirven para hacer distinguir al lector entre "nuevos productos" vs. "nuevas ideas" o mejor aún, vs. "ideas complementamente nuevas y originales"
Como ven, se puede construir un producto nuevo sin recurrir a ideas radicalmente revolucionarias, lo hizo Google en los 90' (pero ya había ideas muy parecidas en Altavista y Yahoo), lo hizo Mercado Libre poco después (eBay y Amazon ya existían hace tiempo). Etc.

Me resultó curioso leer que Jeff Bezos creó Amazon en parte porque tenía culpa por no haber participado desde antes en el boom de negocios de Internet, ya que en estos días, mientras delineaba ideas, estrategias, infraestructura técnica, logística, me pasaba algo parecido por la cabeza, "Tenía que haber empezado antes", en fin, más allá del éxito o no - que lo buscaremos a conciencia por cierto - trabajar en Libres ya empezó a devolver satisfacciones.

lunes, 23 de septiembre de 2013

Semana movida y 7x1


La anterior fue una semana movida en Libres y aunque nos divertimos mucho en lo que estuvimos haciendo, no hubo mucho tiempo para escribir, así que lo hago ahora.

Se buildearon varios servers de prueba para los diferentes productos, estuvimos trabajando junto con los early adopters para poner en producción los prototipos avanzados, varias arquitecturas en las que estábamos trabajando tuvieron una mejora drástica o directamente ya están en su versión final.

También estuvimos con los early-adopters estudiando casos de uso, o mejor explicado, casos de "no uso", contextos donde los productos de Libres Consultores no serían aplicables inmediatamente. Nos contactamos ya con una comunidad importante de usuarios, especialistas en uno de los componentes más importantes de uno de los productos en desarrollo de Libres.

Otras cosas que estuvimos viendo fue cómo se ajustarían los productos de LC a los que ya existen en el mercado, ya que son complementarios de ellos.

Así que hoy tenemos 7x1, siete artículos en uno, así ya vamos introduciendo el importantísimo concepto de bundles al blog de Libres Consultores.

  • Servers de Testing
  • Arquitecturas 
  • Gestión de proyectos flexible
  • Early Adopters
  • Componente actualizado
  • Colaborando con la comunidad
  • Innovación incremental y productos complementarios

Servers de Testing
Un alto grado de automatización va a estar ubicado en los productos de LC en sí, pero por el momento en la infraestructura de building y testing, hay que trabajar con servidores completos, a la vieja escuela, levantar los Linux, cargarlos con el software necesario y montar sobre ellos los productos.

En la teoría parece fácil "levantar servers de prueba", pero cuando se trabaja en equipo, los servers de prueba no pueden ser gestionados localmente, por ejemplo, usando máquinas virtuales locales (Vagrant, VirtualBox, KVM, etc.), más que para probar muy limitados aspectos de los productos, a lo sumo características en la que el miembro del equipo esté trabajando personalmente.

En los servers de testing principales es adonde va a parar el "código" final, todo lo necesario para ir perfilando los productos de cara al prototipo funcional avanzado.

En este contexto se vuelve muy fácil, pero muy fácil, entender la obsesión por las infraestructuras de nube (Openstack), y el software de configuration management (Chef, Puppet, SaltStack, Ansible, Rundeck, etc.), de los ingenieros de infraestructura de grandes empresas que deployan constantemente nuevo código (Continuous Delivery & Improvement): así es cómo se permiten poder crear y destruir rápidamente decenas de servidores de testing y producción nuevos diaria, semanal, mensualmente, dedicando un número de horas que quede en un total siempre de 2 cifras.


Arquitecturas
En varias ocasiones, en intercambios en Internet, me ví explicando qué era, para qué servía una arquitectura en infraestructura, que la idea es similar, pero diferente de lo que es arquitectura de software en el marco de la ingeniería de software. Por supuesto que las nociones de arquitectura de software se aplican totalmente en arquitectura de infraestructuras, simplemente se prescinde o se adapta algunas nociones que están muy especializadas en la gestión de lenguajes, código fuente y desarrollo en gral.

Las arquitecturas que estuvimos definiendo son aquellas básicas para la implementación de determinados componentes, en la práctica, esos componentes son productos internos en Libres, y cada uno sigue el mismo ciclo de desarrollo y definición que los productos públicos, simplemente que no se van a vender directamente, sino que los vamos a usar internamente en Libres (para integrarlos en los productos y/o en los procesos de la empresa).

Una forma muy básica de definir la arquitectura es ver qué se necesita hacer, ver los requerimientos, márgenes de tolerancia deseables, etc.etc. Luego se define qué componentes de software se va a usar para gestionar esos requerimientos (y si hace falta desarrollarlos o no, por ejemplo), y luego vemos qué capacidades puntuales del software elegido son las que se va a implementar en la arquitectura; si se determina que las capacidades no cubren los requerimientos, se vuelve - con ese feedback - a las etapas anteriores, inclusive llegando a revisar la definición de requerimientos. Recordemos aquí que Waterfall es tabú en Libres Consultores y no hay etapas de nada que no sean revisables, reajustables, especial y específicamente si se cuenta con feedback (nueva información), que permita - si es que no exige - re-optimizar (*dentro de parámetros - económicos, de tiempo, de recursos en gral. - razonables), el trabajo ya hecho.

* Determinar qué son parámetros razonables está totalmente alineado con el skillset que brinda la experiencia y la capacitación "dura" en IT. Muchas veces se llega a la conclusión - con la experiencia dada - que el camino más corto entre A y B, para la gestión de proyectos de infraestructura, no es ni por lejos una "línea recta". 

Gestión de proyectos flexible
Lo anterior es un clara alusión a la futilidad patente para la gestión de proyectos de tecnología de la información (IT), de muchas metodologías de gestión de proyectos que no incluyen diversos factores de contexto en la planificación, hiperfocalizándose en la tecnología (servidores, fibras ópticas, tiempo que se tarda en instalar el server en el rack, etc.), olvidando las personas y su entorno, los que son en realidad factores que tienden - contínua, constantemente - a afectar la planificación realizada sobre la "tecnología pura".

Ejemplos de importantes "Factores de contexto": estado de salud promedio de los parientes y familia cercana de los miembros del equipo, eventos importantes personales próximos para los miembros del equipo y su familia cercana, tiempo que se tarda en llegar efectivamente - de verdad - al nivel de expertise necesario en la administración de un software para poder configurarlo apropiada, acertadamente para los escenarios y requerimientos complejos planteados, si los miembros del equipo se mueven en colectivo o en auto propio, si está lloviendo muy de seguido y las reuniones de equipo se realizan lejos de los lugares de residencia de los miembros, etc.

Si no vas a por los factores de contexto, los factores de contexto de seguro van a por tu proyecto y su probablemente aséptica e irreal planificación.

Early Adopters
Los early adopters son colaboradores de LC, validadores de las ideas del producto mínimo, son quienes están usando la implementación más básica de la idea, tosca inclusive, de lo que va a ser el producto final, sumamente más refinado que las versiones que los early adopters están usando ahora mismo.

Las métricas obtenidas de los early adopters son la información más importante de Libres Consultores de momento, en especial aquellas que validan determinadas ideas de diseño de los productos, por ende es difícil dar muchos detalles.

Componente actualizado
Uno de los componentes clave de un producto de LC ha sido beneficiado recientemente por una actualización masiva incremental ("incremental" es el mejor tipo de actualización que puede recibir un software que ya funciona muy bien, por cierto), justo en estos días. Lo bueno de todo es aunque ya se trata de una versión avanzada del software - hace tiempo ya dejó la versión 1.0 - y tienen una fortaleza probada en escenarios empresariales muy exigentes, en el tiempo restante hasta que LC libere la versión inicial de su propio producto, incluyendo este componente, el producto va a ser beneficiado con la experiencia de los early adopters del software recién actualizado mencionado, y aquellos que van a actualizarse a la nueva versión.

Colaborando con la comunidad
No está de más mencionar que también vamos a contar - y a generar! - con los meta-datos importantes que siempre son lentamente liberados en el primer par de meses luego de una nueva versión mayor de un software complejo: tutoriales, fixes, howto's avanzados, howto's especializados creados por los mismos desarrolladores/implementadores del software, etc.etc.

Hace unos días justamente me puse en contacto con un ingeniero que está usando en producción este software (componente del producto de Libres), en una implementación avanzada y personalizada para un escenario, un caso de uso muy similar al caso de uso modelo del producto de Libres; ya se hicieron las presentaciones y estaremos colaborando conjuntamente en los meses venideros intercambiando material técnico importante al respecto, casualmente, esta misma semana pasada, recibí de su parte un "batch" importante de "metadatos" que son de suma utilidad para el producto de Libres y devolví un feedback con algunos datos que extrapolamos de nuestras propias implementaciones de testing.

Innovación incremental y productos complementarios
El caso de Google y su emprendimiento para crear un producto que genere un mercado nuevo, nos sirve para ejemplificar el trabajo que estamos haciendo hoy en LC sin contar qué es lo que estamos armando (todavía no se puede en esta etapa*).

*Google puede comentar en público cuál es el proyecto en el que está trabajando porque tiene el crédito ganado en proyectos anteriores llevados adelante con éxito, lo que es un importante capital en marketing y lo están gastando un poco al hacer público un proyecto ambicioso que todavía no se concretó en tecnología que no sea prototipos que no pueden ser llevados a producción masiva, ni venderse al público, por cierto.

En Libres Consultores ya tenemos prototipos funcionales de los productos, sin embargo, (todavía), no tenemos el crédito necesario para dar a conocer los conceptos en la instancia en que no están listos para producción masiva ni venta al público, en cambio, es preferible llegar a generar el(los) producto completo (algo que tampoco está demasiado lejos), y recién en esa instancia, hacer públicos los conceptos.

Lo que, como dije anteriormente, no impide que podamos comentar cómo estamos trabajando en LC.


Google está desarrollando automóviles que no necesitan conductores para poder usarse.

http://en.wikipedia.org/wiki/Google_driverless_car

La tecnología base para lograrlo ya está creada (algunos prototipos recientes usan Ubuntu como sistema operativo), pero faltaba que alguien emprendiera en la idea de integrar esa tecnología avanzada dispersa en una función singular, práctica (y rentable): un auto que pueda usarse sin necesidad de conducirlo.

La tecnología que va a vender Google se basaría principalmente en que ya existe un producto base sobre el cual se podría llegar a instalar el hardware y software necesario para lograr un driverless_car, esto es clave, ya que Google difílmente pueda llegar a construir sus propias fábricas de automóviles e integrar ellos mismos la tecnología en fábrica, sí en cambio se podría ver cómo poder vender kits de la tecnología para poder instalarlos en vehículos (tal como se puede instalar unos parlantes en el baúl de un auto hoy en día, por ejemplo), sino directamente kits que requieran instalación especializada con licencias de instalador, lo que según se lee en la red, tal vez sea lo más probable que ocurra (es parecido a la instalación de tanques de gas natural y lo necesario para adaptar su uso en motores que de fábrica funcionan con otro combustible).

Es decir, el probable futuro producto de Google va a ser - tal vez - un bien complementario de un automóvil.

Las tecnologías complementarias, los bienes complementarios son clave en la creación de nuevos productos, ya que aceleran en gran medida la adopción de un nuevo producto, por el simple concepto de la innovación incremental.

Un extracto explicando la noción:

"La innovación en los negocios se consigue de diferentes maneras. Pueden ser desarrolladas por modificaciones realizadas en la práctica del trabajo, por intercambios y combinaciones de experiencia profesional y de muchas otras formas. Las innovaciones más radicales y revolucionarias suelen provenir de I&D mientras que las más incrementales suelen emerger de la práctica, pero existen excepciones a cualquiera de estas dos tendencias."


El artículo de abajo, justamente, cita a Google como una de las empresas que mejor aplica el concepto de innovación incremental para sus productos.

"Innovación Disruptiva (Radical) e Innovación Incremental."
http://www.eoi.es/blogs/juanadoricelcepeda/2012/03/09/innovacion-disruptiva-radical-e-innovacion-incremental/

viernes, 20 de septiembre de 2013

Optimizar para ahorrar recursos y reutilizarlos

Por medio de la implementación de herramientas de análisis y registro de datos de rendimiento, como Ganglia por ejemplo, y al cabo de un tiempo de recolectar datos se puede estudiar qué tantos recursos informáticos de los disponibles son consumidos efectivamente por las aplicaciones y servicios en uso en la infraestructura. 

En base a ello se puede delinear una estrategia y un plan de acción para optimizar el uso de los recursos informáticos de la organización.

Componentes ociosos
En casi cualquier organización, no es una sorpresa que mucha de la información recolectada llegue a mostrar que en el día a día de la utilización de recursos solo hay unos pocos componentes que hacen un uso intensivo de la infraestructura informática. El resto de los componentes de la infraestructura permanecen ociosos en general.

Esta noción no es nueva, justamente fue parte de la idea en la creación de servicios de nube como AWS, donde la empresa determinó que la infraestructura típica estaba la mayor parte del tiempo ociosa, sin carga significativa, sin realizar ningún trabajo relevante. Los servicios de nube nacieron - internamente al principio - para optimizar el consumo de recursos y lograr disminuir o suprimir los tiempos ociosos para dedicar más horas - todas las horas idealmente - a consumir lucrativamente los recursos tan costosamente adquiridos para la infraestructura.

En menor escala, hablando de infraestructuras chicas, medianas, por ejemplo de 2, 4, 16, 256 servidores físicos (y su correspondiente colección de recursos complementarios: networking, storage, espacio físico, previsión de presupuesto para actualización / renovación / expansión, etc.), inclusive si son parte de una infraestructura virtual, es típico que ocurra que hay importantes períodos de tiempo en los cuales la infraestructura permanece ociosa, básicamente todo el hardware está "arrancado", el software "corriendo", pero ningún proceso ni usuario están usando los servicios que ellos brindan. Lo que es un claro desperdicio de recursos.

Hotspots
Estudiando la información global producida por herramientas como Ganglia, Splunk, Logwatch y otros analizadores similares de consumo y uso de recursos y servicios, se puede "ver" claramente que muchos recursos implementados globalmente en la infraestructura como "muy resilientes" (con altos niveles de redundancia, alta disponibilidad, etc.), en realidad no necesitarían tan altos niveles de prestaciones tan costosas de adquirir y poseer (es decir no solo hablamos aquí en términos de costos monetarios, sino de TCO), focalizándose - en la práctica, en la realidad - la necesidad de gran resiliencia y disponibilidad de recursos en unas pocas áreas específicas (hotspots, "puntos calientes") de la infraestructura: por ejemplo, en servidores físicos/virtuales puntuales (y recursos complementarios), en servicios específicos, en determinadas franjas horarias. Ni más ni menos.

Es decir, quitando los hotspots, el resto de la infraestructura fue altamente "fortificado" sin una necesidad organizacional real y esos recursos ya adquiridos se están malgastando.

El hardware comprado está allí, el software también, pero nadie los va a utilizar a una escala que no sea mucho - o muchísimo - menor en comparación a los "puntos calientes" (hotpots), de la infraestructura.

Recursos de IT netos
Dado un apropiado estudio de la información histórica de performance de la infraestructura, podríamos localizar los "puntos calientes" de la infraestructura, focalizar allí el fortalecimiento de la provisión de recursos y optimizar - disminuir en gral. - dicha "fortaleza" en otras áreas de la infraestructura donde no es igualmente necesaria.

Los recursos que no se dispensen y que se ahorran al focalizarse en los hotspots pueden luego ser dedicados exactamente al mismo destino que antes hubieran tenido: actualización / renovación / expansión de la infraestructura, pero con una pertinencia neta en grado sumo mayor respecto de lo que antes hubiera significado y/o requerido un incremento bruto de recursos de infraestructura a añadir a lo ya existente.

Conclusiones
La infraestructura de tecnologías de la información típica desperdicia consistentemente grandes cantidades de recursos escasos y/o costosos de adquirir (hardware, software, presupuesto, caras horas / hombre de administradores, necesarias para la administración, gestión, configuración, etc.).

De una infraestructura típica - y con fundamento técnico analítico sólido, basado en datos concretos obtenidos de mediciones pertinentes y/o al menos con estimaciones bien fundadas en alguna previa correcta captura información de performance - se puede "extraer" típicamente suficientes recursos, tal que liberados de su uso anterior, permiten ampliar la capacidad de provisión de servicios de la infraestructura en porcentajes muy importantes, sin que para ello sea indispensable recurrir a nuevas adquisiciones.

Típicamente los recursos liberados para reutilizarse pueden representar tan poco como un humilde 10% hasta grandes porcentajes del total en uso en la infraestructura previo a las optimizaciones.

En 2012 justamente tuve la oportunidad de elevar - muy excepcionalmente - un 200% el ratio de utilización de recursos en una infraestructura; el cual dispuso luego del doble de recursos de infraestructura que tenía antes de la optimización. Es importante considerar que la optimización no solo liberó recursos técnicos, sino también determinada cantidad de horas/hombre que se volvieron disponibles para dedicar a implementar nuevos servicios y optimizar aún más la infraestructura (ya incurriendo así en prácticas de mejora contínua).


Links:

Ganglia Offers New Monitoring System Possibilities (April 2007)
http://www.ibmsystemsmag.com/aix/administrator/performance/Ganglia-Offers-New-Monitoring-System-Possibilities/?page=4

Whole Power Server + Virtual Server Monitoring - Part 5 via Ganglia (May 2011)
https://www.ibm.com/developerworks/community/blogs/aixpert/entry/whole_power_server_virtual_server_monitoring_part_5_via_ganglia116?lang=en

Monitoring Systems and POWER5/6 LPARs with Ganglia (April 2012)
http://www.slideserve.com/linus/monitoring-systems-and-power5

domingo, 15 de septiembre de 2013

Los "Nuevos" modelos de negocios IT

Siguiendo las ideas planteadas por el gráfico al pie de este artículo, los productos y servicios de Google, Facebook, Linkedin, Microsoft (Skype, Outlook), Mercado Libre, GitHub, Groupon, Ebay, y otros cientos más, muy exitosos, apuntan exactamente a: 

1) "No Sueñes" con Productos/Servicios de: 
    • Excelente Calidad, 
    • Rápidos, y
    • Gratuitos.
2) "Utopía" (en gral. para monetizar lo primero), con Productos / Servicios de:
    • Excelente Calidad, 
    • Rápidos, y 
    • Baratos.


Just saying..

sábado, 14 de septiembre de 2013

La misión de Libres Consultores: Software y Hardware de Infraestructura muy barato, simultáneamente


La mayoría de las organizaciones que intentan avanzar en la informatización de sus procesos encuentran un problema mayor al momento de iniciar sus proyectos: los costos.

Costos de Hardware y Software muy altos
El elevado costo económico de implementar una infraestructura informática de nivel empresarial es una variable que no deja de estar presente en ningún prospecto de proyecto de informatización, sin importar el contexto organizativo ni la magnitud del objetivo final del proyecto de informatización.

El alto costo del hardware de infraestructura es una barrera inicial demasiado importante para el avance de la informatización en las organizaciones. El otro alto costo de adquisición - y utilización - es el del software propietario, que también crea una barrera clara para el progreso de la informatización en las organizaciones.

Es claro que para potenciar la informatización de organizaciones hace falta disminuir exponencialmente ambos costos, el del software y el del hardware de infraestructura, simultáneamente.


Hardware de infraestructura muy barato
Ahora mismo, en Libres Consultores estamos trabajando para crear productos que permitan llevar adelante esa visión. Es clave el que no solo estemos trabajando sobre el software empresarial, claramente apoyados en el universo de billones de líneas de código y software opensource, sino también en el hardware.

Una parte muy importante de la Investigación & Desarrollo (I+D), que estamos llevando adelante en LC consiste en análisis detallados de las funcionalidades precisas que una organización extrae del hardware de infraestructura.

Una noción precisa y exacta del ratio de utilización real y efectivo del hardware de infraestructura permite medir cuánto se utilizará, para qué, en qué condiciones, cuanto más potencia hará falta a futuro para escalar ordenadamente cuando los requerimientos organizacionales lo demanden, etc.

Esas métricas clave, entre muchas otras, permiten dimensionar la potencia de hardware necesaria, la realmente necesaria e indispensable, "al milímetro", evitando al cliente gastar de más.


Software de infraestructura muy barato*
*La expresión completa de la idea sería "software de infraestructura muy barato de adquirir, implementar y utilizar".

El otro pie en el que se apoya LC para disminuir exponencialmente los costos de adquisición de infraestructura informática - de hardware y de software - es el software opensource.

El software opensource tiene un costo de adquisición cero (0), así que el precio de venta habitual es cero (0), solo se cobra servicios profesionales, no el software en sí. Sin embargo lo anterior es la menor de las ventajas del software opensource en infraestructuras informáticas de nivel empresarial:

El software opensource que corre sobre sistemas operativos Linux tiene requerimientos de hardware - para muchos casos de uso, tremendamente habituales en organizaciones - muchísimo menores que los requerimientos del software propietario típico para exactamente los mismos escenarios y usos.

En otras palabras, con mucha menos potencia de hardware, se puede extraer y explotar las funcionalidades de software necesarias para la organización. Las mismas que para poder extraer y explotar desde el software propietario típico requerirían una potencia de hardware muy superior a la requerida por el software opensource corriendo sobre Linux.

Necesitar hardware más potente implica mayor precio a pagar para adquirirlo, en cambio, el hardware menos potente, pero igualmente útil y pertinente a para los requerimientos de una organización es mucho más barato de adquirir (y de reemplazar por cierto).


No es nuestro "primer rodeo"
No es una opinión ni una suposición el que se pueda reducir exponencialmente el costo de adquisición del hardware y software de infraestructura al mismo tiempo, al momento de su adquisición por parte de la organización, sino que fue nuestra experiencia en múltiples escenarios, en muy diferentes tipos de organizaciones, en numerosas ocasiones anteriores.

La combinación de los años de conocimiento íntimo de la cuestión y la vasta experiencia que llevamos mi socio Carlos Pace y yo a Libres Consultores respecto de:

  1. El diseño e implementación de soluciones basadas en software opensource en ambientes con altos requerimientos de características y funcionalidades, pero
  2. Con muy bajas potencias máximas en hardware de infraestructura en combinación claro, con 
  3. Disponibilidad de presupuestos de adquisición de hardware y software extremadamente bajos,

nos ha llevado a definir la misión de Libres Consultores:

Repetir esos éxitos en nuevas organizaciones, en las mismas circunstancias adversas.

lunes, 9 de septiembre de 2013

El producto no se vende ¿ahora qué hacemos?: Lean Startups

El artículo de la Wikipedia explicando qué es Lean Startup es excelente, no tengo grandes cosas que agregar. El único problema para entenderlo podría ser el que esté disponible únicamente en inglés.



El problema del producto que no se vende
Hay un problema básico con las startups, no importa el métododo que estén usando para capitalizarse, bootstrapping, inversiones, la combinación de ambos, etc.

El problema es que una gran idea para vender X producto o servicio a clientes puede resultar en que al final de cuentas al cliente no le interese comprar lo que la empresa vende, en realidad.

Es un problema de las empresas y la creación de productos en gral., pero es muy importante si la empresa en sí, su existencia, depende de que el produto/servicio creado - en el que la empresa ha invertido recursos importantes - se venda y se venda bien.


Los que leyeron sobre bootstrapping tal vez están pensando, "pero si ya vendiste el producto de a poco, probando primero venderlo a pocos clientes y luego a más clientes ¿cómo es que ahora no hay demanda?"

Bien, resulta que hacer bootstrapping para levantar una startup hasta convertirla en una empresa real tiene un efecto secundario: se parece mucho a montar una lean startup.

La solución para el producto que no se vende: Lean Startups


Validar
Cuenta la página de la Wikipedia, que cuando un entrepreneur que estaba pensando abrir un sitio de e-commerce para vender zapatos tenía una duda: ¿habría gente que estuviera dispuesta a comprar calzados por Internet? 

Así que agarró unos pesos y se fue a comprar varios pares de zapatillas, les sacó unas fotos, las subió a un blog y las empezó a ofertar (al mismo precio que las compró, detalle importante). Las zapatillas se vendieron, y el entrepreneur vió "validada" su idea de vender calzado vía Internet.


Producto Mínimo Viable
Como ven, no hay mucho diseño detrás abrir un blog y subir unas fotos y decir "esto se vende, preguntá y arreglamos", pero puede funcionar, ya ha funcionado, muchas veces.

Extrapolando un poco de metodología, para ideas más complejas, la noción es armar un producto / servicio vendible - en opinión del entrepreneur, que será validada si se vende - con los mínimos recursos posibles. Luego elegir hay que salir a validarlo (ver si se vende).


Mejora iterativa
Luego podrías tener tu producto validado y con un producto mínimo ya podés avanzar hasta tenerlo más definido (vieron lo del blog y las fotos: eso es un servicio "poco definido"), y preparalo para iterar.

¿Cómo? ¿No vamos a armar una línea / mecánica / procesos de producción para fabricar 50.000 unidades de ese producto bien definido? No, no al principio.

Se va armar un producto mejorado respecto del producto mínimo, identificando qué cosas lo hacen mejor a los ojos del cliente, en sucesivas diferentes versiones del producto, se va a ir incorporando las mejoras y quitando lo que no es útil a los fines de vender el producto.


Pivotar
Pero, en caso de que hubiera fallado la idea de vender los zapatos, ¿qué venía a continuación? ¿Qué pasa si el producto no se vende o se vende poco? ¿Cerramos la empresa? ¿Con toda la infraestructura montada y funcionando? ¿Con todo listo para generar un producto o servicio, pero con uno que no se vende?, No.

Pasa que hay que mejorarlo al producto, al servicio, así que se vuelve al diseño, se piensa de vuelta la idea, si hace falta incluso, una idea nueva.

La Wikipedia cuenta que a Groupon le pasó eso justamente, armaron la startup con una idea inicial, ser una plataforma para activismo en línea, y no se vendió, no generaba ingresos, no ganaban plata. Así que los entrepreneurs volvieron a pensar una idea, desde cero, razonablemente algo que pudieran armar usando la infraestructura que ya tenían montada. Así que levantaron un blog Wordpress y se pusieron a vender desde el blog pizzas con descuento del 20%, de la pizería que tenían en el primer piso del edificio donde estaba la oficina de la empresa. Se vendió bien la idea, y la implementaron como producto / servicio.


¿Quién usa esta metodología?
Muchos, por ejemplo, lo ves cuando alguna empresa crea una nueva golosina, un chocolate o una gaseosa nueva: primero la venden en muy pocos lugares, incluso solo en un par de ciudades y en pocos kioskos con cierto perfil (por ejemplo, que sean 24 hs. y estén cerca de zonas urbanas con vida nocturna activa los fines de semana). Luego de validar el producto, iterar, y pivotar si es necesario, se masifica la producción y probablemente termines conociendolo a través de una campaña de marketing masivo. En algunos casos, el producto se prueba rentable solo en ciertos mercados, y por ello - si se dan las cosas a nivel de producción - el producto se sigue fabricando, pero solo en cantidades limitadas. Por eso es que algunas cosas solamente las conseguís en determinados kioskos (los que están en los shoppings por ejemplo), o en determinados supermercados (los que están en barrios de clase media a media alta y no se consiguen en grandes hipermercados, por ej.). Etc.


Las soluciones que ofrece la metodología "Lean Startup" para los problemas típicos del modelo negocios startup tradicional son tan buenas, que al momento, lo que conocemos como "startup" casi siempre son lean startups, y ya muy pocos entrepreneurs trabajan para hacer una startup "tradicional" (idea, inversión/bootstrapping, crear el producto final, salir a vender).

Claro, Libres Consultores usa la metodología de Lean Startups customizada al contexto donde se desenvuelve, eso implica que hicimos una iteración sobre la base metodológica, mejorando las nociones de Lean Startup. Entiendo que puede parecer una afirmación demasiado optimista, sin embargo , es lo que hicimos, habrá más sobre eso en algún momento en el futuro, por el momento estamos (muy) ocupados llevando adelante la parte práctica de todo el cotarro (a pesar de escribir mucho sobre teoría).

domingo, 8 de septiembre de 2013

Cómo sería el bootstrapping en la práctica

En estos días, varias veces dije en voz alta que Libres Consultores (LC) está en modalidad startup y me estaba refiriendo a la definición técnica precisa, de BA (Business Administration), de cómo está funcionando LC ahora mismo.

Tengo varios links abiertos y estaba por empezar a leerlos para darle más background al artículo, pero resulta que la idea es muy simple.

Bootstrapping
Hacer "bootstrapping" de una startup es la forma de lograr crear/iniciar una empresa sin tener que gastar nada de plata, con cero inversión inicial.



El concepto en movimiento es este: armás un producto/servicio con los recursos a mano (*1), luego de ganar un poco de plata, reinvertís las ganancias en mejorar/ampliar la oferta de lo que vendas, y luego vas reiniciando el ciclo sucesivamente.

En algún momento la cartera de clientes y/o el flujo de caja va a ser suficiente para que no sea necesario reinvertir todas las ganancias, ya que toda la infraestructura (local, mesas, sillas, impresoras, costos de contador, abogado, escribano, etc.),necesaria para que la empresa pueda funcionar ya habrá sido adquirida/contratada mediante el bootstrapping (incluídos los clientes).

En ese momento de la startup, acá en Argentina, los clientes habituales, fijos, etc. y el flujo de caja que generan, el ingreso bruto será suficiente para: 

  • Constituir costos fijos mensuales (bimensuales, cuatrimestrales, semestrales, anuales, etc.), que permitirán pagar: alquiler, impuestos, insumos varios, empleados (!), servicios de terceros (escribano, etc.etc.), etc.
  • Replantear la planificación de reinserción total de ganancias (invirtiendo por ejemplo en guardar plata en un plazo fijo, para tener liquidez en caso de necesitar plata en efectivo en cantidades importantes)
  • Tener ganancias reales a distribuir entre los entrepreneurs (que serán varios en gral.)
  • Etc., entre otras cosas.

Listo, tenés la empresa creada, funcionando, "bootstrappeada" y fuera del loop (de reinversión total de ganancias), operando en modo estable (cumpliendo su misión, pagando costos, logrando ganancias).


Reinvirtiendo constantemente
La estrategia de reinversión total es viable en muy pocos casos, y normalmente cuando hay socios y mucho laburo atrás, mucho ingreso se termina distribuyendo sin reinvertirse al bootstrapping y las cosas van más lento que "listo".

La cantidad que se distribuye y la cantidad que se vuelve a volcar en el bootstrapping son la clave que hace que una startup despegue o tarde mucho, o quede estancada en alguna fase menor de sus planes (querías llegar a 1000 clientes en un año, y terminás con 40).

Inversores
En el punto en que decís "con XXX plata podríamos adelantar un año en 2 meses", es donde aparecen los inversores: tenés la estructura armada, funcionando, se autosostiene o tiene una fuerte tendencia a que lo va a hacer en breve, pero le falta capital para expandir operaciones, con lo que - hipotéticamente - llegaría rápido al punto de autosostenimiento y generación - "explosiva", "exponencial" gustan decir los socios de las startups - de ganancias.


En este punto, los inversores y los socios -actuales- de la startup podrían tener razón: con cierta inyección de capital, no solo van a llegar al autosostenimiento, sino a tener un buen nivel de ganancias, presumiblemente, suficientemente alto como para que la distribución de ganancias fuera de costos sea provechosa para los inversores y para los socios actuales de la startup (que van a empezar a ganar plata por fin). 

La contra es que los socios actuales van a ganar menos en porcentaje y - tal vez - controlen un poco menos la empresa (ceden control a los inversores, parcialmente); no todas son malas noticias: si empezás a ganar antes, tenés más acumulación de ganancias - aunque sea "cuotas" más chicas- que si esperás un año más (o más), para empezar a ganar plata. 

Diversión y  Garages
Es decir bootstrappear una empresa es armar una startup, y sirve de mucho leer y aprender de la experiencia de quienes armaron startups y llegaron a constituir una empresa efectivamente (bootstrappearon exitosamente).

Ok, más allá de las cuestiones financieras y el chitchat BA (Business Administration), está muy bueno intentar llevar adelante el proceso, buscar una idea, ir a un garage (aunque el garage sea metafórico, vía Skype), tratar de armar el producto, conseguir compradores, etc. 

Contrareloj
Es mucho mejor si no estás corriendo contra reloj, que es lo que pasa cuando tenés inversores: invierten a un plazo, te dan un tiempo para alcanzar rentabilidad (y ellos ganancias de su inversión), si no llegás a que la startup sea rentable en el plazo establecido, en algún lugar del documento que firmaste para adquirir el capital invertido ("adquirir" entendido como "para hacerlo tuyo y al mismo tiempo hacerte responsable de invertirlo en actividades X, Y, Z de la startup"), hay una clásula que dice que si no hay rentabilidad luego del plazo, las cosas se resuelven "ASÍ".

Y "ASI" suele ser que hay que devolver lo que quede de plata, vender (liquidar) mucho de lo que haya en *activos declarados de la startup (suelen estar declarados en el mismo documento), para intentar devolver el máximo posible al inversor. Eso suele implicar un impacto tan grande en la startup, que muchas directamente cierran las puertas luego no llegar a un plazo exigido para ser rentables.

* Activos: si en el documento figura que la propiedad intelectual de los productos, las marcas, etc. son activos liquidables, si no se cumple el plazo, el inversor termina como dueño legal de la startup, y se queda con todo el trabajo realizado por los entrepreneurs.


Los links que mencionaba al principio:

From Myspace’s Ashes, Silicon Start-Ups Rise

Who needs investors! Why many startups should bootstrap instead


Que les sea útil.

sábado, 7 de septiembre de 2013

El mito de las cosas completamente nuevas

Frase de:

"Good Entrepreneurs Create. Great Entrepreneurs Steal."

"The best entrepreneurs are some of the greatest thieves that the world has ever seen." 

"Los mejores emprendedores son algunos de los mejores ladrones que el mundo haya visto."


Que el título - y la frase - del artículo no te engañen, no es apología del delito sino la característica primaria de los artículos de negocios de la actualidad: mostrar agresividad verbal extrema para resaltar un mensaje simple, pero fuertemente.

En este caso el mensaje es este: REUTILIZA

No intentes reinventar la rueda! Hacerlo es un pérdida de tiempo y recursos colosal. En cambio aprende a estudiar código fuente ajeno, a aprender a distinguir los patrones - humanos, no los técnicos - que un coder ha volcado a un código fuente, de ese modo adquiriendo mayor entendimiento del código ajeno, más rápido.

No hace falta ir tan lejos como aprender ingeniería inversa, no en la actualidad al menos y no para la inmensa mayoría de productos IT innovadores que podrían crearse simplemente aprovechando la base de lo que ya existe como opensource y puede ser reutilizado y luego vendido, sin tener que pagar ningún costo a los creadores del software.

Es cierto que se recomienda (hazlo cuando puedas), contribuir de vuelta cuando sea posible, y muchas empresas lo hacen en cierto punto (luego de alcanzar el éxito económico), pero no es necesario si recién estás bootstrapeando tu startup y todavía no tienes ningún cash-flow o no tienes uno estable, mucho menos código para contribuir al software opensource que estás aprovechando para construir tus productos o servicios. 

En algún punto, lo harás, vas a retribuir, porque querrás hacerlo, sin que nadie te lo pida; como una forma de dar las gracias y/o como una forma de contribuir a que continúe tu propio - modelo de -negocio; así es como ha funcionado el ecosistema socioeconómico de generación y mejora contínua de software de código abierto, ya por casi 40 años (arrancando desde principios de los años 70'). Sin pausas y sin parar de mejorar.




Productos y Servicios Internos y Públicos

Hoy me metí a nuestro repositorio de información y terminé de armar las definiciones de producto así que ya podemos hacer un sales pitch (!), aunque no tenemos terminados los productos :-), cuestión que ya sabemos que no detiene a los vendedores IT en gral. (ni debería): publicitan (a diferencia de "ofertan" o "venden") productos que no están todavía disponibles y/o que van a estar disponibles en algún momento en el futuro, sin agenda específica para tal evento.


En este punto si estuvierámos trabajando con productos tradicionales, posiblemente tangibles, estaríamos hablando de que es momento de trabajar sobre la MPS


Sin embargo, no manejamos la misma cantidad de variables de producción que las necesarias de manejar para producir tangibles, por ejemplo:

- Costos, Estrategia, Previsiones varias para distribución: cerca de cero (0) a manejar, los productos no ocupan espacio físico significativo por lo que no hay necesidad de prever - por ej. - camiones, trenes, barcos ni containers como medios de transporte para los productos; 

- Costos, Estrategia, Previsiones varias para almanacenamiento: cero (0), este costo es nulo en la práctica por motivos relacionados con los bajísimos valores - completamente amortizados en nuestro caso - de los sistemas informáticos que los contienen - en su estado actual - al momento; etc. 

Además los componentes (commodities) base de nuestros productos son relativamente pocos, y la producción se trata mayormente de tareas de definición de productos (hecho), testing de componentes (cada componente, al ser software opensource, ya fue individualmente extensiva e intensivamente testeado a un nivel - en la práctica - imposible de ser alcanzado por casi cualquier emprendedor/emprendimiento usando recursos limitados (especialmente si estás haciendo bootstrapping!), integración (en proceso y algunas tareas terminadas)..etc.


Tecnología Interna
Inclusive cuando el Integrador crea un producto para un nuevo mercado - al hablar de integración de componentes preexistentes, en este caso integración de sistemas - es natural crear nuevos productos y servicios ("Productos y Servicios Internos") que van a ser consumidos por los productos que se va a ofertar en el mercado abierto ("Productos y Servicios Públicos").

Uno de los principales motivos para llevar adelante una startup, como modelo de negocios, es la creación de nuevos mercados, con sus correspondientes productos y servicios que satisfarán la demanda proyectada. Sin embargo, al encarar la creación (integración en el caso de Libres Consultores), de nuevos productos y servicios, diferentes tecnologías y productos resultan creados como consecuencia natural de los requerimientos de los productos y servicios principales.

Esos productos y servicios resultantes pueden ser re-insertados en la planificación y replanteados directamente como potenciales productos viables para la comercialización directa. Matar dos pájaros de un tiro.

Amazon es el ejemplo clásico, AWS, la nube de Amazon, era originalmente un producto/servicio interno, consumido por sus sistemas principales (dedicados al e-commerce); que luego - en 2003 - fue replanteado como producto/servicio por sí mismo.


En el caso de Libres Consultores, al poco tiempo de estar trabajando ya tenemos dos productos y dos servicios "Internos", que ya son aptos - sin mayor desarrollo técnico - para la comercialización directa. De hecho los dos productos mencionados van a ser parte de la oferta de LC.

Etc.



Bibliografía recomendada: 

"Effective Methods for Software and Systems Integration"

Gracias por su tiempo

jueves, 5 de septiembre de 2013

Ingeniería de Confiabilidad para los productos de Libres

Estuve haciendo bastante SRE (Systems Reliability Engineering), para Libres en estos días (y voy a seguir haciéndolo en próximas iteraciones del ciclo de mejora contínua), pero muy poco de llevar esas nociones a código y configuraciones (vamos a volver a hacer eso hoy). Sin embargo es tiempo bien invertido.


Ingeniería de confiabilidad - RE - Reliability Engineering
Acá está la página de la Wikipedia para el tema en gral.


Links
Y dejo algunos links acá mismo, RE es un campo de trabajo muy requerido en el extranjero, no tanto en Argentina en gral.:

"What's the role of the reliability engineer?"

Site Reliability Engineers: “solving the most interesting problems”

Al 05/09/2013 tenemos:  972 results for Senior Reliability Engineer jobs 

Fijénse por ejemplo, lo que es la definición de búsqueda para un RE:

"..currently seeking a Reliability Engineer with a strong understanding of the fundamentals of Reliability Engineering, extensive experience/exposure in one or more engineering disciplines (mechanical design, electrical circuit design), and the mindset & desire to drive product development culture change and lead global Reliability Engineering/Design for Reliability initiatives."



Mi Plan

Bueno, como ven me focalicé en el plan de RE, a ver..

Fijénse estos párrafos, es el por qué un plan de SRE es necesario:

"A reliability program plan is essential for achieving high levels of reliability, testability, maintainability and the resulting system"

y

"A reliability program plan is used to document exactly what "best practices" (tasks, methods, tools, analyses and tests) are required for a particular (sub)system, as well as clarify customer requirements for reliability assessment"

Básicamente armás un marco dentro del cual tu sistema/s van a funcionar, pero bien, y el - método/procedimiento/s de - cómo vas a lograr mantenerlo funcionando así de bien.

La idea general es básica, por ejemplo, si vas a construir un puente, no solo construís el puente, sino tenés que pensar en cómo se va a mantener bien pintado, en condiciones óptimas luego de terminado. Allí vas a ver que hace falta interconstruir determinadas cosas en el puente: desde escaleras para los que van a auditar/mantener el puente, hasta ver los materiales y componentes que son reemplazables en diferentes etapas del ciclo de vida, y qué tan accesibles son para la gente a cargo del mantenimiento (si se consiguen, pueden comprar dentro de un radio de 100 a 1000 km. del puente, o dentro de un radio de 10.000 a 20.000 km), es una variable a considerar para elegir materiales y componentes a utilizar, siempre que todos cumplan los parámetros mínimos requeridos para su función, etc.etc.

Acá lo podés leer mejor:

"Availability and is developed early during system development and refined over the systems life-cycle."

y está bien definido qué es Disponibilidad:


Así también, usando el principio KISS, manteniendo todo simple, logramos evitar este inconveniente:

"In general, the amount of work required for an effective program for complex systems is large."


Lo que sigue, se refiere a lo que la filosofía Devops y sus filosofías de ingeniería asociadas plantean en gral: es mejor mantener un buen MTTR para el sistema que focalizarse totalmente minimizar los MTTF del sistema.

"A Reliability Program Plan may also be used to evaluate and improve Availability of a system by the strategy on focusing on increasing testability & maintainability and not on reliability. Improving maintainability is generally easier than reliability. "

Llegar a entender bien el párrafo siguiente es lo que permite diseñar productos y servicios perfectamente alineados con los recursos disponibles y con el escenario / mercado objetivo donde van a funcionar:

"Maintainability estimates (Repair rates) are also generally more accurate. However, because the uncertainties in the reliability estimates... 

...Testability of a system should also be addressed in the plan as this is the link between reliability and maintainability. The maintenance strategy can influence the reliability of a system (e.g. by preventive and/or predictive maintenance), although it can never bring it above the inherent reliability."

Listo, y la conclusión:

"The Reliability plan should clearly provide a strategy for availability control. Whether only Availability or also Cost of Ownership is more important depends on the use of the system."


Hay mucho más claro y faltan nociones adicionales y detalles prácticos importantes en los comentarios de arriba, así que como mínimo para hacer una introducción completa al tema, recomiendo leer la página completa sobre reliability engineering de la Wikipedia.

domingo, 1 de septiembre de 2013

Integración de componentes de software y un salto

Al trabajar con soft propietario, encontrar alguien que ya esté vendiendo un producto que vos ibas a vender es un GRAN problema. Cuando trabajás con soft opensource es al revés, encontrar alguien más que pensó lo mismo antes que vos es lo mejor que podía pasar :-D

Y tu capacidad de producción se multiplica instantáneamente y vas a encarar más tareas y terminarlas más rápido. 


Integrados Chinos
Hace unos años, tuve la oportunidad de escuchar una charla donde un entrepreneur en el negocio de vender hardware especializado nos contaba su aventura en la integración de componentes.

Resulta que una vez terminado su diseño - experimental - necesitaban - con sus socios - probarlo, y lo probaron con componentes locales, el diseño inicial fue exitoso y empezaron a producir en masa. Al cabo de unos meses y con buenas ventas, recibieron pedidos más grandes y se empezó a justificar el costo-beneficio de pagar en dólares el costo de comprar e integrar los componentes en China.

Así negociaron por teléfonos e Internet con un par de proveedores chinos para adquirir allá los componentes y lograron realizar la integración en una fábrica. El problema resultó en que al llegar los integrados, el desempeño bajo diferentes situaciones y exigencias no era ni el mínimo esperable del integrado anterior (local, argentino). Es decir, estaban en problemas. Así decidieron viajar - en una inversión arriesgada - y estudiar in-situ las circunstancias de integración y la calidad de los componentes.

Ya estando en China, lograron estudiar en pocos días los ratios de respuesta de diferentes componentes que necesitaban, cambiaron un proveedor, le pidieron algunos componentes más caros al otro y luego ajustaron algunos parámetros que usaba el integrador en la fábrica, vualá, un integrado con los mismos niveles de calidad que los que fabricaban en Argentina.


Integrados Correntinos
La morelaja de todo lo anterior es: lo mismo ocurre con los productos que son resultado de la integración de software (complejo).

Lo que resulta bien en algunas circunstancias, cuando se va a las pruebas no resulta tan bien, luego algún componente no tan bueno es detectado y se lo reemplaza, resultando en una integración que vuelve efectivo el trabajo del producto final (integrado, redundo).

Si el lector va siguiendo este blog supongo que habrá intuído que Libres Consultores está trabajando en el desarrollo de productos en base a la integración de componentes de software opensource.

Hasta hace unas horas estábamos trabajando simultáneamente en el estudio, customización y tareas previas de integración de al menos 15 componentes distintos, piezas de software. Cada una compleja y necesaria en un producto final, estrechamente integrado bajo requerimientos precisos.

Anoche, luego de una nueva iteración en la búsqueda de componentes opensource preexistentes logré localizar una solución opensource que integra perfectamente los 15 componentes necesarios para nuestro producto y brinda diversos opcionales interesantes.

Este macro-componente viene con un añadido de I+D (Investigación & Desarrollo), considerable: varios años de implementación y testing, pruebas en escenarios reales (completamente afines a nuestros propios casos de uso), etc. Es decir, la integración de los 15 componentes está funcionando muy bien, los detalles de integración están totalmente ajustados para que el macro-componente funcione óptimamente, solo o dentro de un sistema, de un producto, de mayor envergadura. Como el de Libres Consultores.

Por ende, el core de nuestro proyecto de desarrollo del producto ha dado un salto tremendo hacia adelante, no solo cuantitativo en tiempo ahorrado, sino en calidad (dado el alto nivel de testing pre-realizado en el macro-componente). La estimación más conservadora nos indica que adelantamos el trabajo al menos un par de meses (en un día).

A continuación, hoy por la tarde tuvimos una reunión con Carlos Pace, otro miembro del equipo de Libres Consultores, donde estuvimos ajustando ideas respecto de la futura - y cercana - integración del macro-componente a nuestro/s productos.

Tenemos camino por delante, pero es un gran salto que se dió hoy.