Es incuestionable que las transacciones electrónicas generan grandes eficiencias económicas con respecto a los pagos en metálico. Se llevan años hablando del fin del papel moneda, puede que en la próxima década desaparezcan hasta las tarjetas de crédito. Ahora nuevos autores como David Wolman defienden la conveniencia de eliminar el metálico calificándolo como la riqueza de los pobres excluidos del sistema bancario. No obstante, prohibir el uso de papel moneda es una descomunal burrada y voy a exponer dos muy buenas razones para justificar tan tajante afirmación.

Para empezar la prohibición se presenta bajo el argumento de reducir el fraude fiscal, por aquello de que hagas lo que hagas en la vida siempre tiene que parecer que lo haces por una buena causa, y como en lo relativo al pago de impuestos la posición de la ciudadanía parece ser la de “yo tuerto si tu ciego”, pues bienvenidas sean todas las medidas fiscalizadoras aunque al final al único que acaben fiscalizando sea a uno mismo. Se supone que se perseguirá, para empezar, el fraude fiscal en las empresas/empresarios –los malos-malotes de siempre– pero ¿realmente sirve para algo prohibir los pagos en efectivo entre empresas para reducir el fraude? No, en absoluto. Cuando una transacción comercial se hace en dinero negro no se declara nada a Hacienda, NADA, se hace en billetes de 500 “Bin Laden” sin factura y la forma de pago es irrelevante a efectos de control de fraude porque oficialmente la operación no existe. La bolsa de fraude fiscal en ca$h está en los autónomos y PyMEs que venden productos y servicios a particulares sin declarar los ingresos. Es por eso que se creó la fiscalidad por módulos dado que resulta imposible en la práctica saber cuánto ingresa y gasta un bar, un dentista, o, en general, un autónomo que trabaja para personas que no pueden presentar facturas para recuperar IVA. De modo que, nuevamente, a los que exprimiría el fin del papel moneda no es a los de arriba sino a los de en medio.

Pero lo más importante es que la eliminación del papel moneda permitiría imponer de facto intereses negativos en la cuentas bancarias. Todos sabemos que durante los últimos 80 años la fórmula mágica para dinamizar la economía ha sido estimular el consumo. Para estimular el consumo hay que aumentar el gasto y, por consiguiente, reducir el ahorro. Fue así de hecho como funcionábamos las PyMEs entre 1996 y 2006. Dado que ahorrar es carísimo para una empresa (30% impuesto de sociedades) pues se reinvertía todo y si se necesitaba dinero era fácil obtenerlo prestado a un tipo de interés muy bajo. Es decir, endeudarse era más mucho barato que ahorrar, y, lógicamente, sólo los muy estúpidos –o muy visionarios– ahorraban. ¿De dónde se podría sacar dinero ahora para volver a “dinamizar” la economía? Fácil: forzando a la gente a gastar los ahorros que tenga. ¿Cómo? Haciendo que lo ahorrado en una cuenta corriente cueste dinero. El problema es que para evitar el pago de intereses negativos existiría la opción de sacar el dinero del banco y guardarlo en el siempre socorrido calcetín. La solución: eliminar el papel moneda para que el dinero esté siempre en un lugar donde el Estado pueda trincarlo fácil y rápidamente cuando quiera. O, alternativamente, obligar a que sea gastado, o no, en la forma en que consideren oportuna unos más que cuestionables gestores económicos.

Por último, vale la pena notar que fiscalizar toda la economía sumergida mejoraría las cuentas, pero sólo las cuentas de las administraciones públicas, no las cuentas de las empresas ni de las familias.

Robot readable world vía How robots see the world (Martin LaMonica, c|net).

La pregunta que pretendo responder en este post es ¿Debe alguien que no es programador profundo preocuparse por las tecnologías NoSQL?.

Si tienes una base de datos con menos de cien millones de registros o un sitio web con menos de un millón de visitas al día, probablemente no necesitas preocuparte en absoluto ni siquiera por saber lo que es NoSQL. No obstante, la cantidad de información disponible está creciendo tan rápido que es fácil que en los próximos años muchas empresas alcancen los límites de las bases de datos relacionales. Y ya hoy por hoy es imposible concebir servicios de alto tráfico como Twitter sin tecnologías NoSQL.

La falta de escalabilidad puede visualizarse mediante las gráficas que muestran cómo se deteriora inexorablemente el rendimiento de un sistema relacional no distribuido cuando aumenta el número de usuarios. El problema técnico es que debido a su arquitectura intrínseca las bases de datos relacionales no se pueden distribuir de forma sencilla sobre varias máquinas. Existen algunas implementaciones comerciales de bases de datos paralelas pero son demasiado caras como infraestructura software de un sitio web y además una de las cosas que demostró Google es que las aplicaciones “big data” deben correr sobre pequeños servidores baratos. En 1998 Altavista utilizaba 20 máquinas DEC con multiprocesadores Alpha de 64 bits dotadas de un total de 130Gb de RAM y 500Gb de disco para indexar toda la web de entonces y atender 13 millones de consultas al día. Pero la infraestructura de Altavista fue incapaz de seguir el crecimiento de la web al ritmo que lo hacían los nodos clónicos de Google basados en MySQL. Y hoy en día Facebook tiene más de 2.000 servidores basados en MySQL.

Fuente: NoSQL Scalability and Performance (Couchbase).

Para empezar a entender los fundamentos relevantes de las tecnologías NoSQL hagamos un poco de historia. Las primeras tecnologías NoSQL son realmente anteriores a las bases de datos relacionales y se utilizaban porque ofrecían mejor rendimiento a costa de menos funcionalidades y la carencia del poder expresivo del lenguaje SQL. Una de las más veteranas, Berkely DB era uno de los soportes de almacenamiento de MySQL alternativo a InnoDB y MyISAM hasta que que MySQL le retiró el soporte el 2006. Incluso ahora varios sistemas de almacenamiento distribuido no relacional siguen usando Berkeley DB como back-end para la persistencia de datos. Berkeley DB es en esencia muy sencillo, se le proporciona una clave (típicamente en forma de cadena de texto) y un objeto binario y Berkeley DB almacena el objeto siendo luego posible recuperarlo dada su clave. También es posible crear claves alternativas o índices con duplicados para los objetos y recuperar los objetos ordenados por dichos índices. Berkeley DB no es cliente servidor, su código funciona dentro del espacio de direcciones de la aplicación que lo usa, lo cual aumenta su velocidad de respuesta pero también hace que sea inútil “tal cual” como sistema distribuido ya que la aplicación cliente debe estar en la misma máquina que los archivos de Berkeley DB para que sea posible garantizar la integridad de las transacciones.

Los sistemas de almacenamiento no relacional proporcionaban una solución para algunas aplicaciones que requerían un rendimiento en lectura y escritura de datos que los SGBDR no podían alcanzar, pero fue de las diferentes necesidades y retos técnicos con los que que se fueron topando los sitios como Facebook o LinkedIn de donde surgieron realmente las primeras aplicaciones open source de almacenamiento distribuido. Los portales se encontraban con problemas de escalabildiad y los ISPs con problemas para dimensionar y prededir el comportamiento de las bases de datos relacionales. Un serio obstáculo para ofrecer bases de datos relacionales en modalidad de software como servicio es que es muy fácil escribir consultas SQL que saturen por completo el servidor durante segundos, minutos o incluso horas.

Las aplicaciones NoSQL –o NewSQL o hasta N★SQL como algunos se refieren a ellas– pueden dividirse en seis grupos:

1. Sistemas “BigTable”: Son básicamente una forma de repartir las filas y columnas clásicas de una tabla en diferentes servidores. Muchas de sus ideas están derivadas de Google Big Table y Amazon Dynamo. Las opciones Open Source más populares son Cassandra, HBase, Hypertable. Y como servicio puede utilizarse Amazon SimpleDB.

2. Sistemas “Atributo-Valor”: Son los sistemas de funcionalidad más sencilla, en los cuales simplemente se recupera un objeto binario (BLOB) a partir de una clave. Los sistemas atributo-valor no distribuidos como Berkeley DB o Redis suelen usarse como software base de otras aplicaciones, bien para la capa de persistencia bien para la implementación de caches. Entre los sistemas atributo valor distribuidos podemos destacar Voldemort y Riak este último incorporando también algunas ideas inspiradas en Dynamo. Los sistemas atributo-valor no son muy prácticos para almacenar datos estructurados, se suelen utilizar para almacenar y recuperar objetos cuya estructura interna es opaca a la aplicación cliente, por ejemplo, el almacenamiento de imágenes que usa Tumblr está basado en el servicio atributo-valor de Amazon S3. Además de Amazon S3, en modalidad de software como servicio de tuplas atributo-valor también está disponible Azure Table Storage de Microsoft.

3. Almacenes de documentos: Los documentos que manejan estos sistemas son un conjunto de datos identificados por etiquetas, internamente pueden ser documentos JSON o de otro tipo que se recuperan mediante claves primarias. También suelen disponer de funcionalidades para combinar documentos al estilo de las JOINs de SQL. Los dos productos Open Source más populares son CouchDB y Mongo DB.

4. Grafos: Para representar información estructurada en forma de red aparecieron aplicaciones como Neo4j o Infinite Graph.

5. Índices “full-text”: Se trata de sistemas orientados a crear índices de texto no estructurado. El producto Open Source más popular es Apache Lucene sobre el que se han construido otros productos como Bobo, Zoie o Solr.

6. Almacenes de documentos XML: Se trata de un almacén especialmente diseñado para almacenar documentos XML. Proporcionan XPath como lenguaje de consulta. Un producto popular es BaseX.

Disponibilidad de mano de obra cualificada en tecnologías NoSQL.

Para que una nueva solución tecnológica sea viable no es suficiente con que sea técnicamente conveniente, además es necesario que sea posible encontrar en el mercado de trabajo a un preico asequible a profesionales capaces de manejar la nueva tecnología. Los gráficos que se vienen a continuación muestran que NoSQL es un fenómeno originario del Área de la Bahía que se ha ido extendiendo a diferentes velocidades según el producto y que es aún relativamente poco conocido entre los programadores. En el estudio realizado por el Instituto de Analíticas Avanzadas de la Universidad de Carolina del Norte sobre el que están basados algunos de los datos del Grupo 451 se encontraron 366.084 miembros de LinkedIn con “MySQL” en su perfil frente a sólo 9.079 con “Hadoop” lo cual –extrapolado– implicaría que menos del 2,5% de los programadores tienen actualmente algún conocimiento de NoSQL. Sin embargo, las cifras de otros productos como Cassandra o Redis muestran que en Europa y particularmente en España existe una clara tendencia hacia la adquisición de competencias técnicas NoSQL.

Distribución geográfica de los miembros de LinkedIn con diversas tecnologías en su perfil

MySQL	Hadoop
HBase	Couchbase
Cassandra	Riak
MongoDB	Redis

Fuente: Too much information

Conclusiones y Recomendaciones.

1ª) Mantener en el radar las tecnologías NoSQL. Puede que no sean necesarias mañana mismo, pero con la explosión de datos que se avecina puede que sí lo sean pasado mañana.

2ª) No usar tecnologías NoSQL para problemas que pueden resolverse con SGBDR tradicionales. Algunos programadores son adictos a las novedades y les encanta instalarse cosas. Puede que Erlang sea un fantástico lenguaje de programación concurrente pero ello no implica que CouchDB sea una solución mágica sólo por estar escrita en él.

3ª) Ser consciente de la Paradoja de la Elección. Están apareciendo tantos sistemas alternativos sin que haya (por ahora) ninguno claramente dominante que puede ser difícil elegir el más idóneo entre ellos a medio-largo plazo.

4ª) Buscar talento y no tecnología. Para enfrentarse a los retos del Big Data, buscar personas con talento que tengan conocimientos técnicos y de negocio, no tecnologías presuntamente milagrosas.

Fuente: Seth’s Blog

Leí esta broma en el FB de Lisset. Circula por Internet. No he podido encontrar la fuente original.

Compartiremos tus datos personales con empresas, organizaciones o personas físicas ajenas a Google si consideramos de buena fe que existe una necesidad razonable de acceder a dichos datos o utilizarlos, conservarlos o revelarlos para:

• cumplir cualquier requisito previsto en la legislación o normativa aplicable o atender cualquier requerimiento de un órgano administrativo o judicial,
• cumplir lo previsto en las condiciones de servicio vigentes, incluida la investigación de posibles infracciones”

Es decir, que si cualquier gobierno quiere saber cualquier cosa sobre ti, Google colaborará.

Para empezar creo que el error más frecuente es asignar un precio al producto que está de alguna manera relacionado con lo que cuesta fabricarlo, o con las cifras de clientes y precios que se ven bonitas en el business plan. Idealmente debería haber dos equipos en una empresa, el de las personas que se dedican a fabricar el producto sin tener ni idea de cuánto podría valer en el mercado, y el equipo de personas dedicadas a hallar el valor de mercado y explotarlo sin saber en absoluto de costes de producción, y en una segunda ronda, si resulta que los resultados de ambos estudios de costes y beneficios son compatibles, entonces y sólo entonces hay que lanzar el producto al mercado.

Los productos hay que venderlos por el valor que percibe el cliente que tienen, no por el coste de producción más un margen o cualquier otro método de estudio de mercado. El valor que percibe el cliente no es el valor real del software. El software tiene valores diferentes para clientes diferentes dependiendo de su poder de compra. Incluso para el mismo cliente el mismo software puede tener valores muy diferentes dependiendo del momento del tiempo. Hubo unos años durante la primera burbuja de Internet en los cuales cualquier producto que prometiera servir para “ganar la web” se vendía más caro que el oro. La teoría económica dice que los clientes perciben el valor usando puntos de referencia, como los precios del software de la competencia, o incluso el precio de otros productos de tu mismo catálogo que ya conocen bien. En la realidad es mucho más lucrativo vender a los clientes que tienen dinero y están asustados. Normalmente dicha situación se produce durante las burbujas, cuando amordazan al responsable de compras y lo encierran en el sótano.

Para obtener el máximo beneficio económico con la venta de un producto, en teoría, hay que usar una curva de demanda junto con una segmentación adecuada de clientes. Hay una buena explicación de ambas cosas en el artículo Camels and Rubber Duckies de Joel Spolsky (2004). En resumen, la curva de demanda indica cuántos clientes comprarían el producto a un precio dado. Además, la segmentación, es una técnica complementaria para cobrar más al cliente que más puede pagar y ofrecer ofertas a los de menor poder adquisitivo, para de ese modo exprimir hasta el último céntimo de todos ellos. La segmentación aplicada al software suele traducirse en versionado, estilo Windows Home vs. Windows Business o a una variante que a mi me gusta aún más: el core wrapping.

Un buen versionado incrementará el beneficio, aunque llevado a extremos, como el que explica Spolsky en su artículo, puede llevar a productos cuyo precio oficial es imposible de obtener por ninguna parte dado que la estrategia comercial del fabricante es realmente y únicamente meterle el rejón que pueda a quien pueda. Ya he comentado en posts anteriores que gran parte del negocio del software va precisamente de trincar y tirar. Lo cual me conduce a otro error común, la falta de percepción del valor actual neto de una venta. El software que da dinero no está pensado para que el cliente lo pague una vez y lo use para siempre, esta pensado para que lo pague una vez y otra y otra y otra y lo siga pagando y pagando y pagando… El software no son sólo bytes sino que incluye muchas otras cosas como mantenimiento evolutivo, soporte a incidencias, etc. Aunque tampoco hay que caer en el error de pensar que el software es sólo servicios y soporte que fue el que hizo a muchos fabricantes Open Source volver al modelo de licencias.

Otra cosa que, en general, creo que no se debe hacer con una startup es seguir una estrategia de ofrecer el producto de más bajo coste para el cliente, a menos, claro está que la disrupción esté en el precio, lo cual no suele ser el caso. Hay emprendedores que creen que lanzar productos “low cost” es bueno porque ellos no tienen mucho dinero y echan en falta productos baratos que les resulten asequibles. Incluso hay inversores a quienes les gustan los productos low cost porque en una coyuntura económica desfavorable como la actual son los que tienen mejor salida al mercado o incluso los únicos con salida. Tengo, en general, una opinión desfavorable sobre el low cost por dos motivos: 1º) porque para cobrar poco hay que tener muchos clientes, invertir una burrada en marketing y dar un servicio pésimo, circunstancias ninguna de las tres que suelan darse en una startup; y 2º) porque vendiendo low cost se pierde la posibilidad de exprimir el jugo a la gama alta del mercado donde se concentran los clientes de mayor poder adquisitivo. Haciendo cualquier pequeño estudio de mercado es fácil comprobar que hay muchos productos por debajo de 1.000€/año y también bastantes, aunque no tantos, por encima de los 30.000€/año, pero la franja entre 1.000€ y 30.000€ (en EE.UU. entre 3.000$ y 75.000$) está prácticamente desierta porque los gastos comerciales de la venta B2B son tan elevados que impiden ofrecer ningún producto por debajo de varias decenas de miles la unidad. La venta a grandes corporaciones es todo un arte que merecería un post en si misma, pero en esta ocasión sólo me detendré en un aspecto concreto. Las grandes empresas cuentan con compradores expertos en negociar hasta el último centimo a la baja. He visto a lo largo de mi carrera muchos contratos que eran fabulosos en el volumen pero ridículos en los márgenes, sobre todo porque la comisión del comercial suele ir ligada a la cifra de venta y no al margen neto. Además, los sicarios de una mesa de compras son auténticos profesionales de las maniobras para pagar menos. Spolsky comenta la jugarreta de esperar al último día del trimestre, o del año, cuando saben que necesitas su compra para redondear tus cuentas y entonces pedir un descuento. Pero hay otras aún peores, como aplazar los plazos de pago sin previo aviso y de un plumazo, o incluso anunciar que compraran sólo a menor precio si se enteran de que dependes de ellos para sobrevivir, dejando al proveedor a margen cero en un estado de empresa zombie en la cual no quiebra pero tampoco obtiene ningún beneficio neto.

Por último, por las tendencias actuales, es inevitable comentar el caso del software como servicio. Ya he comentado con anterioridad que, en mi opinión, el cash flow del software como servicio es malo, y se necesita tener un bolsillo bastante más profundo de lo que parece a primera vista para soportar el tirón de lanzamiento de un SaaS. Pero, yendo a lo práctico, dos cosas a tener en cuenta: 1ª) en muchas empresas da lo mismo 29€/mes que 99€/mes de igual manera que no importa si un billete Madrid-Barcelona les cuesta 90€ o 200€ porque un software que no genera 60€/mes de valor o un viaje que no sirve para ganar +110€ no vale la pena hacerlo; y 2ª) pese a que el precio mensual pueda ser muy variable a veces no es lo mismo 600€ que 900€ porque 600 puede ser el límite de la tarjeta de crédito de la empresa exento de explicaciones detalladas a compras.

Más información: vale la pena leer el eBook gratuito Don’t just roll the dice the Neil Davidson si te encuentras en el proceso de ponerle precio a tu software.

Actualización: Un lector me ha comentado que leyó el post de cabo a rabo y al final se quedó pensando que sólo he mareado la perdiz divagando y no he explicado realmente nada de nada sobre qué hacer en la práctica después de todo. Pues bien, voy con La Receta Mágica:
- si es un software monousuario (sea lo que sea) pide 299€ (o dólares) por usuario y año
- si es un software para una PyME o un departamento de una gran empresa, pide 29.000€ el primer año y 6.000€ cada año siguiente
- si es un software para un ente público pide 49.000€ el primer año y 17.900€ cada año siguiente
- si es un software para una gran empresa, pide 199.000€ el primer año y 72.000€ cada año siguiente

De la mano de las aplicaciones móviles han llegado el fenómeno de la “appificación” y las tiendas de aplicaciones privativas.

Es indicativo de las tendencias que en el ßetabeers del 13 de enero (el evento de moda de los desarrolladores en España) las tres aplicaciones presentadas fuesen una app de música para móviles, una herramienta de marketing online basada en gamification, y un componente SaaS para ejecutar acciones de marketing y comercio electrónico. Google hace ya tiempo que lanzó “los APIs de tu vida“, pero, además, rediseñó el API de Google Maps (entre otros) en su versión 3 para adaptarlo al uso en móviles aún a costa de ir hacia atrás en algunas funcionalidades ofrecidas por la versión 2 del mismo API.

En el entorno empresarial, hay tres trendencias que creo que vale la pena observar: la integración contínua, PaaS y clouds híbridos.

La integración contínua se originó ya hace tiempo de la necesidad de automatizar los tediosos procesos de hacer builds de software y ejecutar pruebas de humo de manera repetitiva. Sin duda, la era del lanzamiento semestral, anual o plurianual de versiones, es historia, y ahora lo habitual es sacar una nueva vesión cada dos o tres semanas en sprints Scrum. Pero las herramientas como Jenkins se están usando también cada vez más para integrar datos mediante ETLs. Personalmente, opino que los web services nacieron muertos debido a lo complejo que resulta implementarlos, y han sido substituidos por servicios HTTP REST más sencillos. Las SOA ya estaban pasadas de moda en 2006 debido a que prometían, en principio, integrar aplicaciones heterogéneas pero resolvían sólo una parte del problema, el transporte de datos mediante un bus; dejando muchas herramientas sin cubrir la parte a menudo más compleja, que es la traducción semántica de los datos entre las aplicaciones. Los data mash ups como Denodo también tuvieron su hype pero tampoco parece que hayan acabado de cuajar del todo. Al final del día lo que la mayoría de las empresas necesitan son pequeños procesos que muevan datos de una aplicación a otra, que se puedan ejecutar y monitorizar fácilmente a diario y que resulten sencillos de mantener evolutivamente.

El PaaS (Platform as a Service) es una respuesta evolutiva a las devops. Desplegar aplicaciones se había convertido en tal carajal que empezaron a buscarse perfiles profesionales que tuviesen competencias tanto de desarrollador de software como de administrador de sistemas para que pudiese depositarse en la misma persona la responsabilidad de coordinar ambas tareas. Pero como siempre, las soluciones basadas en usar materia gris de calidad para resolver un problema son caras y difíciles, puesto que tal tipo de materia escasea. La idea del PaaS es que el programador pueda escribir su aplicación en un entorno de desarrollo que es completamente indistingible del entorno de producción –excepto por su escalabilidad– y, además, mover la aplicación de un entorno a otro de forma totalmente automatizada y sin riesgo de errores.

El PaaS puede apoyarse en los clouds híbridos, los cuales pueden serlo en dos sentidos: a) empezar con un cloud privado que luego se externaliza, o b) empezar con una infraestrutura externa tipo Z Cloud y luego traérsela “in-house” para abaratar costes y conocer con más exactitud la disponibilidad y calidad del servicio.