DestacadosEstrategia DigitalMicroserviciosRetail y DistribuciónTecnologías Ecommerce

Cuándo elegir microservicios para construir tu e-commerce

6 Mins de lectura

Descubre cómo podemos ayudarte a reducir el tiempo de desarrollo de aplicaciones.

Desde del área de e-commerce de Hiberus Digital llevamos años construyendo soluciones para distintos clientes y con distintas tecnologías. Desde los más modestos a los grandes retailers hemos vivido grandes transformaciones y las tendencias tecnológicas y necesidades del momento han hecho que seamos reflexivos cuando aconsejamos implantar un nuevo e-commerce, ya sea adaptando una plataforma comercial, una plataforma de la casa o realizando un producto totalmente a medida.

Se puede decir que el momento actual corre bajo el paradigma de los microservicios, aunque antes de adentrarnos en qué base tecnológica debemos usar para construir nuestro e-commerce deberíamos conocer el abanico de posibilidades disponibles en el mercado y ver cuáles son nuestras necesidades concretas para no errar en la elección.

Como veremos a continuación, la complejidad del proyecto y la inversión a realizar va muy unida a otros factores como tamaño, tráfico soportado y un largo etcétera que marcará la estrategia que vamos a utilizar.

Una vez hayamos estudiado las funcionalidades que necesitamos debemos adoptar la primera gran decisión técnica de si debemos construir una arquitectura propia a media o si por el contrario vamos a utilizar algún producto comercial estándar. Esta decisión nos ligará en los próximos años a una filosofía de trabajo o nos atará a las vicisitudes de éxito de un determinado producto.

Necesidades tecnológicas según el tipo de e-commerce

En nuestra clasificación inicial y si nos fijamos en las estadísticas de uso distinguiremos 3 grupos:

Retailers de tamaño más básico y/o que están explorando una idea inicial de negocio.

Requieren una inversión menor y el time to market debería ser de semanas.

En este caso la recomendación es usar una plataforma ya construida y ceñirnos al modelo de venta estándar de ese producto. Estamos hablando de plataformas tipo Shopify (un “eCommerce as a Service”) , WooComerce (extensión de WordPress) o Prestashop.

Retailers de tamaño medio.

Y que, en muchas ocasiones, ya tienen detrás un modelo físico ya consolidado.

La inversión es ya más importante y a nivel técnico debemos tener ya en cuenta los sistemas con los que nos tenemos que integrar, estrategia omnicanal, lo complejo del propio modelo de negocio y otros muchos factores.

El tráfico soportado no suele ser un factor importante hasta que llegan las épocas de venta especial (rebajas, black Friday…) donde de repente nos acordamos que no lo habíamos tenido suficientemente en cuenta.

Si lo que vas a construir crees que va a tener un largo recorrido quizás ya deberías plantearte al menos tener una solución a medida.

En cuanto al time to market, y aunque depende mucho de la solución seleccionada, estaríamos hablando 3-4 meses para una solución mínima inicial.

Otro factor importante que deberíamos tener en cuenta es el mantenimiento y extensión de la plataforma. Nuestra recomendación es ir o bien a una plataforma estándar tipo Magento Open Source, basado en PHP, o construir sobre nuestra solución ecommerce llamada Hermes y que está basada en Java.

Grandes Retailers con un tráfico muy elevado.

Trasformar sus complejos canales de venta hacia una solución orientada a plataforma de Retail.

La inversión es ya muy importante, y las expectativas de beneficio esperado también lo son. La estrategia en muchos casos aplica a varios países.

Factores como el dimensionamiento de catálogos ya muy extensos, tráfico soportado, cantidad de sistemas a integrar, logística, medios de pago, complejidad del propio modelo de negocio y otros muchos, hacen que la decisión que tomemos marque el éxito o fracaso incluso del propio negocio en sí.

Una experiencia de navegación negativa hace que la repercusión en redes sociales y medios de comunicación ponga en riesgo la propia imagen de marca.

El time to market es este caso es muy variable y podemos irnos a muchos meses. En la mayoría de las ocasiones ya existe una plataforma que se va a sustituir.

La recomendación a nivel general en esto casos es utilizar grandes plataformas como Magento Enterprise, SAP Commerce Cloud o Salesforce Commerce Cloud o hacer un desarrollo completo a medida.

En general, si se requiere integrar un elevado número de sistemas legacy o accesos de terceros y el modelo de negocio no encaja al con el estándar de una plataforma, nuestra clara recomendación es un desarrollo a medida…. Bienvenido al nuevo paradigma de los microservicios. En nuestro artículo sobre «De una arquitectura tradicional a microservicios» ya hablamos de cómo migrar de una arquitectura tradicional a otra de microservicios basados en eventos. En esta ocasión vamos a centrarnos en microservicios para el mundo e-commerce.

Hacia una estrategia orientada a microservicios

Estamos ya en la tesitura de un e-commerce de tamaño medio/grande y que viene con una dilatada experiencia con una plataforma comercial que ha funcionado razonablemente bien durante los últimos años.

El imparable auge de la venta online hace que aparezcan problemas de cada vez más difícil solución y ha llegado a un punto que nos replanteamos si seguir parcheando o hacer un cambio estratégico.

Si analizamos cuáles son las principales debilidades de un sistema tradicional, veremos que son bastante comunes:

  • Falta de escalabilidad para momentos de gran tráfico y venta.
  • El modelo de procesos en batch hace que seamos poco ágiles frente a nuestros competidores a la hora de modificar un precio o de lanzar una nueva promoción.
  • Estamos atados al roadmap de evolución que haya decidido el fabricante de nuestra actual plataforma ecommerce.
  • Incluso la infraestructura que tenemos es propietaria, y si incrementamos la mismas para los momentos punto tenemos que quedarnos con ella.
  • Una nueva versión de nuestro software para una pequeña modificación solicitada por negocio hace que tengamos que desplegar el software al completo y esto hace que el proceso sea lento y con tolerancia a fallos mayor.

Por el contrario, las arquitecturas basadas en microservicios se caracterizan por:

  • Altamente escalables. Nos posibilita de facto hacer sistemas autoescalables y poder usar incluso plataformas cloud para poder añadir mayor capacidad en momentos concretos y posteriormente volver a la situación inicial con la reducción de costes correspondiente.
  • Generar menos acoplamiento entre servicios. Lo microservicios permiten el uso incluso de diferentes tecnologías. La versatilidad de una plataforma cloud choca en muchas ocasiones con la cantidad de integración que tengas en tus propios sistemas para acabar escogiendo una estrategia on premise.
  • Arquitectura flexible. Es un modelo que no depende del tamaño de su arquitectura, es decir, se puede adaptar para sistemas de cualquier tamaño.
  • A la hora de hacer un despliegue, cada servicio se hace de forma independiente, ya no necesitamos desplegar todo el sistema, dejando que el resto funcione normalmente. Por el contrario, se requiere un mayor control de las versiones.
  • Nos permiten acercarnos al real time mediante arquitecturas event sourcing, conjugando el escalado de microservicios y la ingesta de flujos de datos de forma continua apoyada en plataformas como Apache Kafka.
  • Como todo no podía ser perfecto, debido a que los componentes están distribuidos, las pruebas globales serán más complejas y debería pensarse en automatizarlas con la máximas cobertura.

En la mayoría de las ocasiones ya existe una plataforma que se va a sustituir y debemos replicar funcionalidad que ha sido iterada durante años.

 

Aplicación de arquitectura de microservicios

 

Estrategia para migrar tu negocio digital a una nueva arquitectura sobre microservicios

Nos surge el dilema de cuál es la estrategia más conveniente para migrar a nuestra nueva arquitectura sobre microservicios:

  • Si hacemos un big bang ganaremos en time to market y en el coste final del proyecto. Por el contrario, también corremos más riesgos a la hora de la implantación.
  • Dividir por dominios la antigua plataforma e ir quirúrgicamente migrando esto módulos o dominios. En este caso coexistirán las dos plataformas durante este tiempo, lo que nos repercutirá en un mayor coste al duplicar el desarrollo/mantenimiento en ambas partes aunque minimizaremos en gran media el riesgo.

Otro tema para analizar es el uso de una plataforma de infraestructura cloud. Si la cantidad de integraciones que tengas en tus propios sistemas es alta puede que una mejor opción sea usar una estrategia on premise o plantearse ir eliminando también estos sistemas legacy que tanto nos hacen sufrir llevándolos a nuestra flamante arquitectura de microservicios.

Como conclusión, para determinar si la arquitectura de microservicios es adecuada para un proyecto, primero se debe evaluar convenientemente cuáles son nuestras necesidades.

En Hiberus tenemos una dilatada experiencia en tecnologías para E-Commerce como SAP Commerce, Magento o Salesforce Commerce, así como en plataformas de e-commerce basadas en microservicios. Si estás pensando en construir tu e-commerce B2C o B2B o migrar el actual, no dudes en contactar con nosotros.

 

 

¿Quieres más información sobre nuestra área de Microservicios?

Contacta con nuestro equipo de Microservicios

    3 posts

    Sobre el autor
    Service Manager Retail & Ecommerce
    Artículos
    Artículos relacionados

    1 Comentario

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    ¡No te pierdas nada!

    Te mantenemos al dia de tendencias y novedades sobre el futuro del trabajo, formas de hacer crecer tu negocio, liderazgo digital y muchas cosas más..

    Newsletter