Servicios, servicios, servicios... (y Amazon)

 Hace ya tiempo que el modelo de desarrollo orientado a servicios se ha convertido en algo popular.

Y no lo ha sido quizá por el convencimiento de los "programadores", sino por el empuje de las modas de las grandes tecnológicas (Amazon, google...)

Y eso tiene algo delicado, entender el modelo de servicios no es trivial, y mal entendido, puede generar más problmeas que beneficios.

Yo personamente, empecé a jugar con aplicaciones 100% distribuidas hace mucho, año 2000, aprox. (una pizarra de precios "peer-to-peer").

Esto fue un gran entrenamiento. No conocía en aquella época el celebérrimo CAP, sus discusiones y evoluciones posteriores.

Luego, lideré (por efecto "frente ruso") un proyecto en el que apliqué un modelo orientado a servicios y microservicios, realizado muchas tareas con pipelines de microservicios.

La experiencia fue un éxito rotundo y muy agradable.

Inicialmente no se entendía bien el modelo. Extrañaba que no funcionásemos con una bbdd sql para guardar "too"

Pero eso no fue "accidental", fue intencionado para evitar tentaciones, evitar que sea más fácil hacerlo mal que hacerlo bien. Ya conoces la ley del diablo...

"Si es más fácil hacerlo mal que hacerlo bien, terminarás haciéndolo mal en algún momento"
-- Devil

Desde entonces, he tratado de explicar y convender de las ventajas del modelo orientado a servicios. Y también de los riesgos, y de las tentaciones y...

Con un éxito... "realtivo" (es un eufemismo)

Pero claro, quién soy yo. Yo no soy un genio, una mente brillante, ni un gran comunicador, ni un gran programador...

En Amazon, que son mucho más listos, brillantes, que tienen genios... lo hicieron mucho mejor que yo.

Aquí está el comunicado que en su día publicaron en la compañía para "convencer" el modelo de desarrollo orientado a servicios.

 

Mucho mejor que los míos, más convincente...

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn't do this will be fired.

 

Que traducido sería...

1. Todos los equipos expondrán a partir de ahora sus datos y funcionalidad a través de interfaces de servicio.
2. Los equipos deben comunicarse entre sí a través de estas interfaces.
3. No se permitirá ninguna otra forma de comunicación entre procesos: nada de vinculación directa, ni lecturas directas del depósito de datos de otro equipo, ni modelo de memoria compartida, ni ninguna clase de puertas traseras: la única comunicación permitida será mediante llamadas a la interfaz de servicio a través de la red.
4. No importa qué tecnología utilicéis: HTTP, Corba, Pubsub, protocolos personalizados? da igual.
5. Todas las interfaces de servicio, sin excepción, deberán diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. Sin excepciones.
6. Cualquiera que no haga esto será despedido.

Mucho mejor, más claro y convincente que mis intentos.

Es curioso, que uno de los puntos peor entendidos, suele ser el de los datos.

He tenido muchas "conversaciones" tratando de explicar que eso es vital y no negociable. Pero Amazón, lo explica y "convence" mejor.

Amazón y yo entramos en el mundo del diseño orientado a servicios más o menos al mismo tiempo. Ellos lo explican mejor  ;-)

Aupa los sistemas diseñados con servicios y microservicios!!!

Ojo, tienen sus dificultades e inconvenientes, pero el balance es muy positivo, si lo entiendes bien, y te preparas para las dificultades.