El cliente quiere ser dueño de sus datos y que los servicios digitales le faciliten diferentes problemáticas del día a día al menor coste posible o incluso gratis. Demandan rapidez, servicios de calidad e información en tiempo real para mejorar su calidad de vida.

Pero ¿ ¿Qué ocurre con nuestros empleados y servicios de gestión internos? Si ponemos al cliente en el centro de todos los servicios que prestamos (por aquello de la ansiada #omnicanalidad en el sector), toda la organización tiene que estar preparada para responder a este nuevo modelo.

La mayoría de #Retailers piensan que estos cambios solo le afectan a su "tienda online" y acaban haciendo un esfuerzo descomunal solo para este servicio que, en muchos casos, supone una inversión sin retorno porque este canal de venta supone un porcentaje muy pequeño respecto a la venta en tienda física. Para que la inversión tenga retorno, es imprescindible digitalizar la mayoría de los servicios que prestamos a los clientes, sean del canal que sean.

Para adaptarse a este nuevo paradigma, tanto las tecnologías como las plataformas Cloud han ido evolucionando para proporcionar un abanico de servicios que permitan a los diferentes sectores desplegar estos servicios para sus clientes, empleados, proveedores y/o colaboradores.

La cuestión es cuales elegir y como garantizar la seguridad, escalabilidad con unos costes reducidos, tanto en sistemas como personal especializado. Para esto nació el concepto de #Devops y los procesos de integración continúa (CI/CD).

Empezamos con la terminología técnica ¿ no te preocupes que las intentaremos "traducir" para aquellos no iniciados en ellas.

Devops y CI/CD (integración continua/entrega continua).

Simplificando mucho el concepto Devops, nace como un conjunto de prácticas para agrupar tareas de desarrollo con tareas de sistemas para agilizar la generación de nuevas versiones de nuestras aplicaciones. Todo programa desarrollado se almacena en algún sitio (código fuente). A partir del código fuente se generan los ejecutables, se realizan tests y los ejecutables son desplegados en los servidores para que sean usados por los usuarios tanto en un entorno de calidad como en producción.

A esto se le llama CI (continuous integration/integración continua) y CD (continuous delivery/entrega continua).

Para que podamos decir que tenemos Devops implantado, es necesario que estas tareas estén completamente automatizadas.

Desplegando #Microservicios, #Miniservicios, #Serverless, #Monolitos ...

Como continuación al concepto Devops, ahora veremos las modalidades principales de cómo son "entregadas/desplegadas" las aplicaciones a los usuarios como producto final del proceso Devops.

Una aplicación monolítica contiene todos los procesos principales en el mismo "paquete de aplicación/ejecutable". Suele incluir la interfaz de usuario, la lógica de negocio y la capa de acceso a la Base de Datos.

Los Microservicios son aplicaciones que normalmente contienen una única funcionalidad de un proceso de negocio, con interconexión con otros microservicios a través de una API. Contienen lógica de negocio y opcionalmente la capa de acceso a base de datos.

Los Miniservicios son aplicaciones que contienen diferentes funcionalidades para un mismo proceso de negocio. Pueden funcionar de manera independiente o tener interconexión con otros Mini/Microservicios a través de un API. Contienen lógica de negocio y opcionalmente la capa de acceso a base de datos.

Los servicios con arquitectura Serverless despliegan pequeñas funciones/procesos que se ejecutan para dar respuesta a un evento específico (por ejemplo, una petición a una URL concreta). Esto permite que el servicio se ejecute únicamente bajo demanda, sin necesidad que la aplicación esté consumiendo recursos mientras no se ejecuta. Según la plataforma Cloud utilizada, tampoco requiere administración de servidores.

Amazon, Netflix o Uber ya se equivocaron al elegir estas tecnologías. ¿Qué podemos aprender de ellos?

Unos de los principales defensores y pionero en la tecnología Serverless y Microservicios es Amazon.

Cuando construyeron Amazon Prime Video utilizaron la tecnología Serverless para dar servicio a los clientes. Cuando la demanda comenzó a crecer, se empezaron a formar cuellos de botella debido a la gran cantidad de tráfico y cambios de estado de las transacciones por segundo, que se traducía en un gran aumento de consumo de recursos. Esto les obligó a cambiar de una arquitectura Serverless a Miniservicios (muy cercana a monolítica, según quien lo interprete), reduciendo un 90% el coste de la plataforma. El informe resultante de sus ingenieros concluyó que tanto los Micro/Miniservicios como los Serverless funcionan a gran escala, pero es necesario analizar cada caso para establecer la tecnología más conveniente.

Algo parecido les pasó con Amazon Marketplace, que contiene miles de microservicios. Tuvieron que inventar dos reglas para intentar prevenir el caos:

·        La regla del "Equipo de dos pizzas". Un equipo responsable de un microservicio que no se pueda alimentar con dos pizzas, es demasiado grande. Un equipo inferior a 10 personas no necesita largas reuniones para estar sincronizados. Cada miembro del equipo sabe que hacer y todo el equipo será más productivo.

·        La regla del "usted lo crea, usted lo ejecuta". El equipo es totalmente responsable de los servicios que crean, desde la funcionalidad hasta el despliegue (proceso Devops completo).

Netflix tuvo una caída en 2008 que duró varios días. Pasaron de un modelo monolítico a Microservicios (unos 700), lo que les permitió aumentar la escalabilidad y minimizar los tiempos de desarrollo y puesta en producción en los diferentes países donde dan servicios.

El caso de Uber también fue de un entorno Monolítico a Micro/Miniservicios. En su caso no fue por un problema de escalabilidad como en los anteriores, sino en la capacidad de poner en el mercado nuevos servicios en el menor tiempo posible. Ésta fue la conclusión publicada por el grupo de ingenieros de Uber en su blog:

"Agregar nuevas funciones, corregir errores y resolver dudas técnicas se volvió extremadamente difícil. Se requería un conocimiento extremo de lo servicios antes de intentar un solo cambio. Solo los desarrolladores que llevaban mucho tiempo trabajando en Uber podían realizarlos".

Como conclusión, todos aprendieron de sus errores y tomaron nota para ser "prácticos". Se enfocaron más en el negocio y la productividad que en la propia tecnología.

Hay que dar en la diana o al menos acercarnos lo máximo posible. Debemos "centrar el tiro".

Llegados a este punto, todo el mundo entenderá que antes de plantear una solución integral hay que seleccionar dos grupos de herramientas. Las primeras nos tienen que permitir hacer el proceso de Devops (almacenar y controlar el código fuente y realizar su entrega/despliegue). Las otras son la(s) plataforma(s) Cloud/OnPremise que nos tienen que permitir ejecutar y monitorizar nuestras aplicaciones al menor coste y mayor escalabilidad posibles.

Todo esto antes de escribir la primera línea de código o incluso seleccionar el/los lenguajes de programación que vayamos a usar.

Los técnicos somos muy propensos a apostar rápidamente por una tecnología simplemente porque nos gusta o simplemente la hayamos usado en otro proyecto. Esto puede hacer que "perdamos el norte" y acabemos usando tecnologías para procesos para las que no nacieron. No todas las tecnologías son válidas para todos los procesos de negocio, por lo que debemos ser más selectivos y, sobre todo, prácticos.

Para ello, debemos evaluar unos "requisitos mínimos" para cada tecnología desde el punto de vista práctico y de negocio (time to market, equipos de trabajo disponibles, velocidad de cambio, etc.). Dentro de estos requisitos mínimos no podemos olvidar otras partes vitales, como pueden ser la monitorización de los servicios, escalabilidad y la seguridad.

Si algo hemos aprendido de los errores cometidos por Amazon, Netflix o Uber, es que hay que construir el software de manera que nos permita moldear los servicios de la manera más versátil y ágil posible. Para ello tenemos que aplicar un diseño #composable.

Aplicación en el sector del #Retail.

Composability. La clave está en la modularidad y crear un ecosistema "composable".

Divide y vencerás. En el sector #Retail hay unos procesos de negocio muy definidos, por lo tanto, es nuestro mejor punto de partida. Esta debe de ser nuestra base de construcción, independientemente de las tecnologías que vayamos a usar.

El primer paso es crear los módulos/librerías que contienen los procesos/reglas de negocio. Cada módulo debería de diferenciarse según su objetivo. Puede ser un módulo que proporcione experiencia de usuario a clientes (customer journeys), soporte de procesos de negocio completos o módulos que proporcionen datos a otros procesos/módulos/librerías.

El segundo paso es crear los "paquetes" con los que vamos a dar visibilidad a los servicios (por ejemplo, en formato #api), donde incluiremos uno o varios módulos/librerías en función de las necesidades de despliegue, seguridad y ámbito (servicio solo visible desde nuestra intranet o publicado en internet requiere diferente seguridad).

El tercer paso es crear las aplicaciones que contengan uno o varios paquetes. Esto nos permitirá crear aplicaciones en formato Micro/Miniservicio o un servicio Serverless con la(s) funcionalidad(es) que necesitemos. Si el caso lo requiere, incluso podemos crear una aplicación monolítica. Básicamente podremos adaptar lo que está previamente desarrollado a las diferentes estrategias de despliegue.

Esto nos permitirá cambiar la arquitectura en función de las necesidades, reutilizando toda la base construida.

Ya tenemos la receta, ahora solo nos falta "cocinar".

Para aplicar todo lo que llevamos visto hasta ahora, vamos a utilizar términos del mundo de la cocina para simplificar los mensajes.

Ya tenemos la receta, pero para obtener el plato final, podemos utilizar un robot de cocina o contratar a un Chef.

Contratar un chef (y ya no digo varios), puede ser una tarea complicada y cara porque es un perfil muy demandado. Además, tendrá especialidad en un tipo de cocina (tecnologías o sector en nuestro ámbito) que quizás no se adapte a nuestras necesidades. El plato resultante de la receta original puede no parecerse en nada a lo que esperábamos, con un tiempo de ejecución muy largo, o aún peor, con un coste imposible de pagar para nuestros clientes. Esto sin contar que requerirá un equipo de personas especializadas (subchef, auxiliares, pinches, etc.) y una cocina totalmente equipada con todo tipo de utensilios.

Todo se complica si además necesitamos cambiar la receta sobre la marcha, porque las necesidades del mercado lo exigen. Es probable que, en el transcurso de dos cambios seguidos en la receta, el chef nos tire una sartén a la cabeza.

Sin embargo, si utilizamos un robot de cocina obtendremos un resultado uniforme con unos costes estables, independientemente de los conocimientos de cocina de quien lo utilice. El cambio de receta se podrá realizar sobre la marcha, o utilizar un segundo robot de cocina con las mismas personas u otro grupo para probar la nueva receta antes de sacarla al mercado.

Volviendo al lenguaje tecnológico, el equipo del chef puede ser un grupo de técnicos que acabamos de incorporar. Este equipo tiene experiencia en el sector bancario, energía, telefonía o seguros y, por lo tanto, intentará aplicar lo que han conocido al sector Retail. Lo más probable es que el producto resultante llegue tarde, no se adapte a las necesidades del sector Retail y con unos costes imposibles de asumir.

El robot de cocina es una plataforma especializada en el sector #Retail, que nos proporcione todas las herramientas y software necesarios para que un equipo de personas, puedan adoptar las mejores prácticas que se puedan aplicar en el sector #Retail en el menor tiempo posible.

 

comerzzia omnichannel platform es tu receta. comerzzia cloud development platform, tu robot de cocina.

Hemos querido simplificar mucho esta guía y sobre todo "la receta", pero es necesario tener en cuenta todos los "ingredientes necesarios" y que estos sean de la mejor calidad.

#comerzzia #omnichannel #platform contiene todas las aplicaciones y procesos orientados a la venta multicanal para el sector #Retail. Dispone de un #Framework de desarrollo que permite crear nuevos procesos de negocio o modificar procesos existentes en la plataforma de manera ágil y sencilla, minimizando los tiempos de puesta en marcha de nuevos requisitos del mercado.

Este #Framework dispone de un "core" de desarrollo bien estructurado y definido. Son los servicios horizontales que proporcionarán los cimientos de los diferentes módulos.

·        Seguridad.

·        Trazabilidad.

·        Auditoría.

·        Flujos de estado configurables.

·        Internacionalización.

·        Internacionalización de procesos fiscales, documentos e impuestos.

·        Integraciones con terceros.

·        Alta capacidad de personalización.

·        Fácil de integrar con otras soluciones de software.

·        Multi-tenant (multi instancia y/o multi actividad de negocio).

·        Estándar OpenAPI para exponer los servicios vía API's totalmente documentados.

·        Distribución incremental de datos a tiendas (catálogo, promociones, configuración, etc.).

·        Tratamiento de las ventas de los diferentes canales y países casi en tiempo real.

·        Gestión de eventos, IoT, sistemas de tiempo real.

 

Para seleccionar las diferentes tecnologías usadas en el Framework, se han seguido una serie de buenas prácticas para alcanzar la mayor productividad en el menor tiempo posible (curva de aprendizaje del equipo), tanto en tiempo de desarrollo como de despliegue/entrega:

·        Todas las tecnologías seleccionadas son ampliamente usadas en el mundo empresarial, y en la mayoría de los casos, utilizadas como base de formación en el mundo Universitario o de Formación Profesional.

·        La construcción del software sigue un conjunto de buenas prácticas para garantizar el crecimiento estable de la solución, o la posibilidad de actualizar a las últimas versiones del software base de comerzzia.

·        Utilización de estándares.

·        Las aplicaciones/módulos resultantes son escalables y proporcionan alta disponibilidad y monitorización de forma ágil.

·        El despliegue se puede realizar en cualquier entorno Cloud (Amazon, Google, Azure, etc.) u OnPremise, sin necesidad de cambiar el software, de forma automática y controlada por los Gestores del Proyecto.

#comerzzia #cloud #development #platform proporciona un entorno #Devops totalmente operativo y preconfigurado. Permite gestionar el ciclo de vida de nuestras aplicaciones, desde la fase de desarrollo/construcción a su despliegue automatizado en los entornos de calidad y/o producción.

Con #comerzzia #cloud #platform podemos disponer de un entorno de calidad y/o de producción en cloud en cuestión de minutos, totalmente operativo, y preconectado con comerzzia cloud development platform. Contiene el "orquestador de servicios" que proporciona la estabilidad y escalabilidad necesaria para cada aplicación/servicio desplegado.

 

Publicación de nuestro compañero Antonio Martín Álvarez

Director de arquitectura en comerzzia

Vía Linkedin