Hoy en día, la mayoría de las empresas ha migrado o está migrando al Cloud. Pero esto hace unos años no era así. Todos recordamos los tiempos en los que las aplicaciones eran ejecutadas en servidores en racks dentro de la misma empresa o en hostings de terceros virtualizados. Después llego el Cloud, que era básicamente una nueva palabra para definir exactamente lo mismo, pero con un montón de marketing detrás. No queremos decir que el Cloud no era la solución, pero el proceso de migrar al Cloud no podía resumirse en poner exactamente la misma aplicación que se tenía en servidores propios en los servidores de Amazon, Google, Azure o cualquier otro proveedor.

Migración de nuestra plataforma de ecommerce a una aplicación cloud native

Hace ya unos años, en Aktios tomamos la decisión estratégica de migrar nuestra plataforma de ecommerce al Cloud; lo hicimos abrazando la premisa de que no podíamos simplemente mover nuestra aplicación, sino que debíamos transformarla, evolucionando a una nueva arquitectura que usase todas las tecnologías y metodologías que pudieran ayudarnos a disponer de una aplicación más eficiente y a dar un mejor servicio a nuestros clientes.

Al cabo de los años, viendo los beneficios que nos ha aportado en muy diversos aspectos, tales como el rendimiento, la versatilidad, la reducción de los tiempos de desarrollo y la facilidad con la que pudimos lidiar con el crecimiento exponencial de accesos y pedidos durante el confinamiento por el COVID-19; podemos decir que tomamos la decisión acertada en un momento donde no era la opción más conservadora ni más cómoda.

Si alguien nos preguntara si estamos de acuerdo en que la innovación debe ser uno de los motores que impulsan una empresa, seguro que la respuesta sería Sí. En cambio, también es común escuchar en el sector la frase “Si no está roto, ¿por qué tocarlo?”. Porque en realidad en el día a día es muy difícil mantener un equilibrio entre innovación, coste y cumplimiento de las necesidades de los clientes.

Pilares sobre los que basamos nuestra arquitectura cloud

Tal como hemos comentado, para realizar el cambio de paradigma hacia el cloud pensamos en una evolución de la arquitectura; no solamente considerando cambiar el hosting “on premise” versus “on cloud”, sino que lo enfocamos de una forma más general implementando diversas estrategias que pasamos a comentar a continuación.

Domain Driven Design

A la hora de diseñar los servicios y aplicaciones, el equipo técnico y el equipo de negocio deben de trabajar codo con codo para definir el dominio de la aplicación. Es decir, identificar qué es lo que aporta valor en el núcleo del negocio y hacer que la aplicación esté lo más cercana posible al cliente, centrando toda la lógica de negocio en un solo lugar y dividida por contextos (por ejemplo: Surtido, Promociones, Clientes o Pedidos). Con esta metodología conseguimos que negocio y desarrollo hablen el mismo idioma. Adicionalmente, esta separación por contextos nos permite dividir en servicios y microservicios toda la lógica de negocio y ser así más flexibles para incorporar nuevas necesidades y para escalar de forma independiente las aplicaciones en función de su demanda, por ejemplo, no es lo mismo escalar el catálogo de compra que las llamadas para obtener mis listas.

API Headless E-commerce

Aprovechando la migración al cloud desarrollamos nuestra solución de e-commerce con una API totalmente Headless, es decir, toda la solución está desacoplada del frontal Web. Esta API fue creada con tres premisas en mente:

 

  • Tenía que ser fácil de usar por nuestros clientes.

  • Aportar un rendimiento óptimo.

  • Incorporar la seguridad por diseño.

 

Así, ofrecemos una API totalmente documentada usando OpenAPI, en la que todas las llamadas son “stateless” (es decir, independientes unas de otras), simplificamos los procesos de integración con terceros y reducimos el número necesario de consultas para realizar una acción.

Serverless

Una de las mejoras que aporta el cloud es la posibilidad de usar aplicaciones serverless. En realidad, la aplicación se sigue ejecutando en un servidor, pero no está encendido cuando la aplicación no lo requiere. Por tanto, estas aplicaciones “sin servidor” deben estar optimizadas para poder arrancar en milisegundos, realizar su función y apagarse inmediatamente después.

Con ello se reduce drásticamente el coste en aplicaciones que sirven contenido cada cierto tiempo y que no necesitan un servidor dedicado solo para ellas. En definitiva, reducimos costes de hosting y consumimos menos energía haciendo más sostenible nuestro trabajo.

Tecnologías y estándares OpenSource

La decisión de usar software Open-Source se justifica normalmente por la reducción de los costes de licencia y una menor dependencia de los proveedores. Pero esto no es lo único importante, el uso de herramientas Open-Source permite a las empresas usar soluciones que están en continua revisión y mejora e impulsadas por multitud de empresas tecnológicas. Además, siempre es posible colaborar con la comunidad proponiendo cambios y mejoras.

En el caso del stack tecnológico del Cloud usado para nuestra plataforma de e-commerce, la mayoría de las herramientas adoptadas como estándares son hoy en día Open-Source.

GitOps

Con GitOps realizamos todas las operaciones de despliegue y/o configuración de la infraestructura y de sus aplicaciones a través de ficheros en un repositorio Git. Esto nos permite simplificar la gestión de cambios aportando trazabilidad y la posibilidad de hacer rollbacks. Además, nos obligamos a que todo cambio a realizar en la solución deba ser aprobado mediante una revisión previa del código.

Nosotros usamos este flujo de trabajo, para la gestión de nuestros clústeres de kubernetes mediante Flux. Y nos aporta garantía de estabilidad y fiabilidad ante todos los cambios realizados.

Infraestructura como código (IaC)

En definitiva, el Cloud está en constante evolución, no debemos asumir que ir al Cloud es una meta como tal sino que lo debemos ver como una forma de enfocar nuestras decisiones de otra manera. Somos conscientes que en cuestión de meses las tendencias y las soluciones cambian y nuevos retos aparecen. Y para ello debemos estar preparados, evolucionando constantemente.

En nuestro caso la decisión de ir al Cloud nos obligó a restructurar no solo la arquitectura de nuestra solución, sino los procesos internos con los que nos organizamos. Pero, sobre todo, teniendo en cuenta el valor que somos capaces de aportar a nuestros clientes. Queríamos una plataforma de ecommerce más flexible, más fiable y robusta; más segura, con mejor rendimiento y todo ello ajustando más los costes.

La infraestructura como código, que podemos considerar una parte del concepto GitOps, es una forma de trabajar en la cual se gestiona la infraestructura (Servidores, Redes, CDN, Clusters, etcétera) directamente desde el código en vez de hacerlo de forma manual a través de la herramienta web del proveedor Cloud. En Aktios empleamos diversas herramientas que nos facilitan este enfoque de gestión de la infraestructura para asegurarnos de que siempre esté configurada de la misma forma independientemente del entorno o de la persona que la esté gestionando.

En Aktios no nos complicamos la vida con innovaciones tecnológicas si no van a aportar valor a nuestros clientes. Innovamos con sentido de negocio y de forma pragmática para ofrecer la mejor solución de ecommerce.

La pregunta que desde Aktios siempre nos hacemos es: ¿Cómo podemos ofrecer la mejor solución a nuestros clientes? La única respuesta es innovando continuamente, formándonos y aplicando todo aquello que realmente les aportar valor.

Si te ha gustado el artículo y quieres saber más... ¡Contacta con nosotros!
Contáctanos