Microservices to support current approaches

‍

A big part of our evaluation consisted of the potential these ecommerce applications have to adopt, or be developed in accordance with microservice architecture. "Headless" ecommerce is a designation given to the new standard of developing ecommerce applications and environments. Previously, ecommerce applications were built using monolithic frameworks who could not be detached. It was difficult to find out the source of complex issues. Since the shift to "headless" ecommerce, we have been able to detach components and observe their performance in isolation and together in the whole framework(s). Headless ecommerce is the designation given to an ecommerce architecture that separates both the frontend and backend layers completely.

We use microservices to implement your headless ecommerce platform. A microservice architecture uses a set of separate, yet coupled, applications and services so that they collaborate in event-driven architecture. Each service implements their own designated function and communicate with each other using protocols such as HTTP/REST APIs or message queues. Each service is its own application and can be tested, deployed and released independently without system downtime.

Of course, microservices aren’t the holy grail, but another way of delivering reliable software. Due to its modular architecture, testing can be done relatively quickly and maintenance becomes feasible (especially when running upgrades). Below is a sample diagram of a rudimentary microservice architecture design. Some notable features include: 1) separate microservices representing functionality; 2) databases that connect to some microservices. Databases are independently connected to microservices to store data relevant to that functionality, this way it reduces dependencies to other databases. It also simplifies what is stored so that if it should fail, we would know which database could be affected. Another big plus of the encapsulation of the data storage is the scalability of microservice architectures, because data is spread to different storages and therefore easier to handle then one big database.

Meeting business needs

Business agility meets software agility: in this case, highly-compartmentalised pieces of functionality allow the system increasing flexibility and mobility. Microservices help to reinforce technical simplicity and allow software to be developed in a targeted way. The greater its simplicity, the more we can scale and address business agility. One needs to choose the scale at which they operate a microservice, and these are predominantly determined by the business need that those microservices fulfill. It is not recommended to be too granular if you don’t have to be.

‍

‍

Microservice architecture corresponds very well with a DevOPs organisational mentality. Development teams are able to size the functionality and deploy in container. By maximizing autonomy, development teams are able to address business needs that correspond to the piece of functionality they are responsible for. This allows them to become quicker and efficient in handling the work the business needs.

‍

Develop CI/CD to fulfill the microservice mandate

To achieve success with microservice continuous integration and continuous delivery (CI/CD)  will be essential. Without a functional CI/CD process, development agility will be difficult. There may be challenges implementing CI/CD for microservices if they are entangled with multiple code bases, or if they are too dependent on one another. The challenge is to create services that are independent insofar as they are able to be deployed without hindering other services.

A monolithic application relies on a single build pipeline. This means that deploying high-priority fixes (to be found, fixed, and tested) that must be deployed immediately will most likely delay the release of improvements and features. Overtime the application grows increasingly complex and its dependencies more tightly woven. Testing and deploying will also become increasingly complex and time consuming. On the other hand, microservices have the flexibility of being deployed independently. In a microservice environment, Team A has a direct pipeline to releasing directly to the quality environment and to production without the bug found in Team B to disturb it. Since we’ve detected that Team B is experiencing difficulties, Team B can isolate that bug without disturbing the production-readiness of Team A, C, and Ds features. By instituting an automated release pipeline, the chance for making mistakes during deployment will be minimised.

‍

‍