Creo que los comentarios e inquietudes expuestas por Luís y Lluís se merecían un nuevo post.  Nos hemos sentado Albert y yo, un par de vasos de Coca-cola y este es el resultado:

Web Services e interoperabilidad… ese gran dilema. No creas que no hemos hablado de ello. Si una cosa está clara es que los web Services fueron definidos para solucionar la interoperabilidad. Y después de mucho darle vueltas, creemos que Axis cubre nuestras expectativas. Así, como funcionalidad, se puede desplegar el framework como web service. Esto nos permite conectarnos a un framework remotamente a través de una interface web (pudiendo administrar o requerir ejecuciones).

Como dice Luís "…no es un problema atacar un SW implementado en Java desde un cliente .Net, Python o Symbian C++.." . Yo incluso creo que cosas sencillas y un poco complicadas, que realmente por mi justa experiencia creo que cubrimos el 90% de las necesidades de todos nuestros clientes potenciales. Pero ya puestos a pedir, y espero que no me cobres por ello , conoces alguna tecnología que te cubra todo el abanico de posibilidades?

La API de aplicaciones (ya hablaremos más adelante de que lenguajes soportaremos) permitirá la representación en objetos para su manipulación,  que en última instancia se traduciran a mensajes xml a enviar al FW (a través del puerto nativo). Por lo tanto destacar que tanto los mensajes que llegan a través del web service como en socket son equivalentes.

Lo que se comentaba sobre la API REST, quizás no me he explicado bien. Es justamente lo que tenemos :). Un servidor web + AXIS + XML. Todo y eso, creemos que no debemos olvidar tener un soporte clásico de sockets, porque como dices tu en otras palabras, no se puede pedir todo en esta vida y menos a los web Services.

Ligero, si, ligero, ligero, ligero. Por suerte, el diseño de nuestra arquitectura requiere de un módulo ligero en cada nodo de la red (El middleware) pero nos podemos permitir el lujo de decidir que FW exponen sus servicios en forma de web services, que es la parte central (que no centralizada) de nuestra arquitectura.

Los beneficios que nos aportaba tener sockets y SOA era mayor a los perjuicios de no hacerlo. Encima, está montado de tal forma que se reaprovecha gran parte del código en las dos interfaces (Que en el fondo es una pero con dos puertos de entrada).

La liberación de código está planificada para finales del mes siguiente (si todo va según lo planificado). Como comentábamos en el post del KICK OFF, de entrada no liberaremos el framework.

Sin más me despido. Gracias por vuestros comentarios :)

Creo que de entre todas las cosas que estamos desarrollando en ThinkInGrid la más importante se encuentra en la pasarela de entrada (API) a nuestra arquitectura basada en la comunicación por mensajes XML y donde esperamos que empresas de todo el mundo programen sus aplicaciones.

Como conseguir llegar a ser lo suficientemente específicos para que nuestra arquitectura sea sencilla de usar y como llegar a ser lo suficientemente abiertos para no limitar las mentes perturbadas (En las  que me incluyo) a la hora de diseñar una nueva aplicación.

Llegados a este punto y como si de un hijo se tratara actualmente estamos trabajando en ello. Es por eso que hoy quiero mostraros un par de pinceladas sobre la decisión tomada sobre el acceso a la API.

La decisión… no cerrarnos a un solo tipo de acceso. Es por ello que hemos preparado un entorno que permitirá trabajar con web services o con el sistema tradicional de sockets (Habilitando un puerto para dicho proposito). Por supuesto…a gusto del consumidor.

Sobre la primera, el motivo es claro, subirnos al carro de las nuevas arquitecturas SOA, facilitar la comunicación entre máquinas en una red y ofrecer al desarrollador la posibilidad de brindarle las ventajas que proporciona dicha tecnología. Para ello,  mediante un servidor de aplicaciones (Tomcat, WebLogic, etc.), nuestro framework y Axis ofrecemos la posibilidad de interactuar fácilmente con toda la arquitectura grid que pueda tener un dominio o grupo de dominios determinado. Como ejemplo de uso y que nos servirá para accelerar implantaciones en cliente estamos desarrollando un entorno web para el mantenimiento de dominios Grid.

Los sockets, para los nostálgicos, para los que prefieren seguir realizando comunicaciones entre máquinas sin depender de un servidor web, o simplemente para los que por necesidad de entorno precisan de esta comunicación.

¿Que creéis vosotros? En ThinkInGrid creemos que no podíamos descartar ninguna de las dos opciones y es por eso que hemos dedicado nuestro tiempo a implementar las dos posibilidades. Por ejemplo, Albert está acabando unos scripts muy chulos con el ANT para facilitar la carga del framework.

Y eso es todo lo que os puedo contar… seguimos en contacto.

JuanLuis, de Tecnorantes, me hace llegar el famoso meme. Supongo que tendrá más interés si en vez de personalizarlo lo corporativizo:

• Quise registrar la empresa en los idus de marzo y teniendo como notario a Jose Luis Perales. Llamadme fetichista :)
• Al principio pensamos ofrecer consultoría sobre Grid en Globus. Afortunadamente Sergio dijo un día una frase que pasará a la historia de la computación: "tardamos menos empezando de cero que parcheando".
• En el pasado escribimos varios bisnisplans. Me he jurado no volver a escribir nada parecido (o quizá sí, pero sin cifras). Si alguien está interesado en invertir en nosotros le va a tocar redactarlo.
• Pensé en bautizar los nombres de red con actrices (Angelina, Kim, Sharon y Monica). Sergio ganó el sorteo y tenemos a directores de cine (Tarantino, Allen, Coppola y Wilder).
• La empresa se gestó a base de carajillos y martinis en el Polipuaj de la UPC. Supongo que muchas más habrán nacido en el mismo lugar. Debe ser lo más parecido al Buck’s que hay por aquí cerca.

Otros startuperos que no han pasado por este lance son: David, Ángel y Albert.

En la próxima F1, Alonso ganará las carreras para McLaren, pero muchas más carreras serán corridas antes para posibilitar que su infraestructura, su coche, llegue a las óptimas condiciones que posibilitan al fenómeno asturiano hacer efectivo su potencial. Muchas más incluso de las que correrá el excelente probador del equipo, Pedro de la Rosa. La mayor parte, sin duda, se correrá en los simuladores del equipo Mclaren. Correr una prueba real en la F1 real es caro y limitado por el tiempo disponible; un buen puñado de opciones han de ser pre-seleccionadas para que los probadores determinen la óptima. Estos simuladores son usados en el desarrollo de todos los componentes del monoplaza, así como las pruebas sobre diferentes estrategias.

Con el Grid pasa exactamente lo mismo. Desplegar el middleware de Grid en la infraestructura real es caro en recursos y en tiempo. Realizar mediciones es complicado y muchas veces poco fiable. Las pruebas de prototipo deben de minimizarse, como mucho a un pequeño conjunto de candidatas pre-seleccionadas. La investigación especulativa es prácticamente inabordable a nivel de prototipo. Pero las buenas ideas nacen de buenas especulaciones. Para poder validarlas con un mínimo de fiabilidad, en Thinkingrid hemos completado un nuevo hito: el desarrollo de nuestro simulador de Grid. Incorpora el estado del arte de modelos de alto nivel del Grid, principalmente extraído de las publicaciones deSimGrid. La novedad más importante que aporta nuestro simulador es que está desarrollado sobre Repast, una plataforma de simulación especialmente diseñada para la investigación en sistemas multiagente. Damos las gracias a ambos proyectos por proporcionarnos herramientas tan útiles. Y la pregunta clave, ¿para qué vamos a usar este simulador?

Tenemos dos objetivos principales:

1) Testear y validar estrategias inteligentes de gestión de recursos y meta-scheduling en el Grid.

En el Grid tradicional, Grid-enabled HPC (High Performance Computing), las tareas son distribuidas mediante colas en los recursos y ejecutadas según disponibilidad. Si una tarea tiene problemas, se cancela y se vuelve a lanzar en el mismo u otro nodo. El tipo de aplicaciones que corren en HPC Grid Computing son de “machacar” gran numero de datos, del tipo Biotecnología. Física o análisis financiero. Las tareas son independientes y el costo de hacer un re-scheduling es despreciable comparado con el tamaño global de la tarea.

El middleware y Framework de Thinkingrid permiten extender el Grid a todo tipo de dispositivos. Esto abre el abanico de aplicaciones al Grid transaccional, donde las tareas no son independientes y no es válida la cancelación y el re-scheduling sin más, dado que puede afectar a otras tareas. Es preciso manejar con precisión y flexibilidad el scheduling y balanceo de las diferentes tareas en el Grid.

Los componentes del framework permiten controlar dónde, cuándo y cómo se van a ejecutar las tareas en el Grid, así como la reacción ante eventuales complicaciones. La respuesta automática y escalable (en dimensiones tanto físicas como organizacionales) vendrá dado por el uso de técnicas de IA en el Grid. Para evaluar y optimizar las diferentes técnicas, el simulador es la pieza clave.

2) Grid a la carta

Un escenario bastante común para una empresa que desee mover su infraestructura de IT al Grid es la preocupación de saber de antemano cual será el efecto de esta re-organización. ¿Qué aumento de rendimiento voy a conseguir? ¿Cómo se va a hacer? ¿Cuánto tiempo va a tardar? Si se tuviera que hacer todas las pruebas a nivel del prototipo en la infraestructura de la empresa, la respuesta sería: “no lo sabemos seguro, solo podemos estimarlo… vamos a probar” para todas las cuestiones. Con un simulador validado la situación cambia: “Dime que infraestructura tienes ahora y  te diré que puedes conseguir y como lo puedes conseguir”. El grueso de las pruebas se llevan a cabo en el simulador, cambios y evoluciones se llevan al cabo en el simulador. El costo para la actual infraestructura de la empresa es 0, nada se interrumpe. Cuando se tiene claro lo que se quiere y cómo se quiere, simplemente se despliega la solución optimizada.

Resumiendo, tenemos una nueva herramienta que permitirá que tanto Sergio como yo mismo, que actualmente perseguimos nuestro doctorado en el área de de IA aplicada al Grid, incorporemos en el framework de ThinkinGrid el estado del arte (y mas allá!) de esta materia. Vamos a por la pole :)

Para quien tenga curiosidad en éste área y en el simulador en sí, mantendremos una sección detallada al respecto en la inminente web corporativa de Thinkingrid… stay tuned.

El placer que siento al sentarme con un abogado es únicamente superior al de atravesarme la mano con un clavo. Aún así, uno no escoge la sociedad en la que crece (y en ésta son cada vez más necesarios), por lo que la semana pasada nos reunimos con el nuestro.

(Inciso: De entre todos los que nos recomendaron, escogimos a Javier Prenafeta porque tenía un blog en el que escribía cosas coherentes. Una de las ventajas de iniciar conversaciones.)

Supongo que no me gustan los abogados porque demuestran lo inútil que son mis planteamientos en esta sociedad. Actuar de buena fe y "dar mi palabra" no es suficiente. Por ello, hubieron varios puntos de nuestra reunión que me chocaron bastante:

• Cláusulas de confidencialidad: Contratamos a gente con ilusión. Nos planteamos metas y seleccionamos a gente que nos pueda ayudar a alcanzarlas. Les damos libertad y la posibilidad de que desarrollen sus conocimientos. También, cómo es lógico, a final de mes el salario pactado. Y esperamos que el proyecto sea suficientemente interesante como para que se involucren completamente y se sientan cómodos en el equipo. ¿Cómo esperar que en una situación así te traicionen? Pues es bastante común, tanto que es habitual incluir en los contratos claúsulas de confidencialidad. Me choca mantener una relación habiendo plasmado por escrito cierta desconfianza desde el primer día.
• Avisos legales y registro de bbdd: Uno ha de tratar a sus clientes mejor de cómo le gustaría que le tratasen. No se plantea spammear, no se plantea vender datos a terceros… no se plantea nada que les pueda molestar. Pero ésto también es una excepción, por lo que existen la LOPD y la LSSI. Que, coercitivamente, se han de cumplir. En este caso me choca la desconfianza del Estado hacia mí. Sólo un imbécil cortoplacista molestaría a sus clientes. Por su culpa de perder tiempo en rellenar muiltitud de formularios.
• Licencias: Desde el primer momento tuvimos clara la fórmula mediante la que íbamos a ofrecer nuestros productos: si hay lucro con ellos danos una parte del pastel, y si no, disfrútalos con salud. Bastante sencilla, a la par que irrealizable. Si ya es complejo definir el "lucro", más sencillo resulta saltarse esa definición. Acabaremos licenciando mediante algún tipo de segmentación que de lejos no será tan perfecta como el planteamiento original.
• Patentes: De entrada, me cago en Bell, IBM y Microsoft. Algún día se ha de replantear completamente todo este sistema.

Si se tuviese en cuenta que se tardan años en crear una imagen y minutos en perderla, todo sería más sencillo. Y nosotros tendríamos más recursos y menos preocupaciones. Aunque visto el panorama, sólo un irresponsable saldría al mercado sin asesorarse.

Forget the original ABC of sales: "Always Be Closing" mantra. Replace it with "Always Be Collaborating". You might actually then like it.

Dharmesh Shah

We are getting ready for our leap towards public releases. What we expect to have just after Christmas is:

• Our open-source multiplatform middleware, along with the binaries for Windows, Mac, Unix/Linux and others such as PSP or Symbian S60; the documentation in Doxygen and the source code
• A developer portal in Track for the maintenance and improvement of the middleware
• A limited version of our framework interface available on the Web.
  
• Our corporative web, replacing the dull "visit our blog"
  

We are working hard in the middleware for this "kickoff". We are migrating it to as many platforms as possible, and working hard on the documentation, in and out of the code. Our goal is to get the grid community enrolled in this project.

Borja pointed out that there was not enough talking about how grid standards are being implemented in our middleware. In fact, the first release will not implement the standards, but we have specified, designed and implemented having OGSA and WSRF in mind. The papers about them have always occupied a main place in our desks. Therefore, we have planned to implement the wrapper - that will give the middleware support for the standards - before February 2007.

Last but not least, in this our first kickoff preview, here are the technological specifications of the middleware:

• Written in ISO C++
• Size of the binaries: varies, aprox. 400-500kb in Unix/Linux x86 - aprox. 55kb in PSP 1.5
• Four resource classes fully available in this release: shared memory, disk storage, process execution, MySQL database (their availability depends on the platform)
• Installation wizard for Windows, Preference Pane for Mac, configure + make scripts for Unix/Linux

In the next kickoff preview, we’ll talk about the inner design of the middleware. Stay tuned.

En Oxyfish han compuesto el villancico de estas navidades. Todo un acierto. Los seguidores de alarm:clock y TechCrunch entenderán el cambio.
Read the rest of this entry »

"Sorprendenos" es la cuenta de correo en la que recibimos las ofertas de empleo. Siempre he creído que el nombre era bastante explícito. Si fuese "rrhh" lo que uno esperaría recibir serían otras cosas. Así que intentaré remarcar brevemente lo que un startupero espera encontrar y lo que no.

Lo redacto pensando en nosotros, pero creo que es fácilmente extensible a otras startups.

Veamos: ME IMPORTA UN CARAJO TU CURRICULUM. No necesito saber donde naciste, ni tu DNI, ni tus notas del instituto, ni el nombre de la academia donde ibas a aprender inglés. Tampoco quiero una lista de los 10 lenguajes que tocaste brevemente en tu paso por la universidad. Ni por supuesto leer que te encanta practicar deportes de equipo o que tu mayor defecto es ser excesivamente responsable.

A las chicas que estudiaron psicología y que trabajan en RRHH de una gran multinacional ("seleccionando" sobre patrones de una plantilla) quizá les interese. Nosotros tenemos mucha prisa, así que vayamos al grano. Olvídate del currículum. Únicamente quiero que escribas sobre los siguientes temas:

• Tu trabajo: ¿Dónde trabajas actualmente? ¿Qué haces allí? ¿Por qué escogiste ese trabajo? ¿Qué has conseguido? ¿Por qué quieres dejarlo?
• Nosotros: Somos una startup. Así que explica por qué quieres dedicar los próximos meses de tu vida a trabajar mucho y cobrar poco (ya no :D).
• ¿En qué eres el puto amo?: Aprender VisualBasic por tu cuenta no suma. Tocar Eiffel en la facultad sólo te ha dado seis carácteres en un CV. Así que únicamente cita aquellas tecnologías sobre las que podrías escribir un libro. Si no hay ninguna, mejor no nos envíes nada. No tenemos tiempo ni recursos para formarte.
• ¿Qué puedes aportar?: Véndete. Véndete. Véndete.

Y más o menos esto es todo. Formatéalo como quieras. Si estás interesado en crecer con nosotros: sorprendenos##a##thinkingrid.com