2021: ManoMano IT Odyssey - Part II
Architecture Spaceship
After Antoine told us about the Dawn of ManoMano IT, I will continue the exploration of ManoMano IT story by getting into our Architecture Spaceship. I am Laurent and joined ManoMano mid-2019 as a Solution Architect Captain.
2018 was the year when we began to structure our IT organization, adapting to new business challenges: from a startup to a scaleup company. Before 2018, we launched our DIY marketplace in all the 5 current countries. We wanted to launch new services for our marketplace sellers (such as fulfilment) and our customers (like ManoMano PRO for B2B). We knew that we could not enrich our legacy application with these new services: we had to develop new pieces of code or interconnect SaaS solutions.
To do that, we had to rethink our architecture: how to escape from the monolith pattern?
In 2011, microservice architecture appeared and we decided to embrace it. So microservices ran with legacy applications and we decoupled them thanks to asynchronous communications by introducing a broker.
The second step was to improve code industrialization by introducing templating and bundles on common technical features, such as security, data access, and observability.
The third step was related to difficulties of recruiting and future increases of traffic and volume, so we decided to invest in new languages such as Java and Node.JS.
The last step was to begin, and not to reinvent, the wheel, by introducing new functional or technical components as PaaS or SaaS. “Make or Buy” was the new question we asked before starting a new project (see also ManoMano’s “make or buy” decision grid).
After a failed attempt in 2018, we began to set up in 2019 a Solution Archinaut team so that they may help feature teams to better design distributed services and to interconnect SaaS solutions. At ManoMano, we support trial and error practice. Why did we fail in 2018? We tried to promote technical leads or software architects without building a solution architecture mindset and community. So we started to recruit a community leader with a background in Solution Architecture (your faithful writer) and then solution architects related to business domains and feature teams (one architect per ca. 3 domains).
When a new solution architect arrives in ManoMano, their first objectives are to be legitimate for technical teams: engineering managers, IT leads, developers, ops. They must understand how the legacy code has been designed and implemented: architecture and design (anti-)patterns. Then they will work closely with product teams (domain experts, product directors, product managers) so that they may help feature teams to implement new services. A solution architect firstly acts as a coach to allow all contributors to speak the same language, aka the famous DDD ubiquitous language. Then they use diagrams and maps to allow teams to design scenarios, target solutions and to make informed choices.
In 2019, we started to revamp the way we build marketplace web pages: from server side with PHP Symfony to front side SPA with React and Rest API. As we are a marketplace, SEO is compulsory; we then introduced SSR (Server Side Rendering) software architecture. It was really challenging to preserve display performance (CDN issues, progressive - micro-frontend per micro-frontend - migration thanks to our A/B test homemade tool) and cost containment on server resources. On the other side of the Mo(o)nolith (Back Office for Manos and Manas), we decided to virtually split end-user access through roles (RBAC). It will then help us to ease the rebuilding of new dedicated BO per persona based on SPA architecture too.
APIzation of our ecosystem was the 2020 big project to enable us to have a better system decoupling and monolith escaping strategy (sanctuarization of monolith through API endpoints). The side effect was to provide ready-to-use endpoints for the first native apps of ManoMano (ManoMano PRO app launched in October 2020).
Developing new frontends (React or native app) requires to rely on backend microservice API. Sometimes we have to aggregate API calls or to filter API answers in order to improve performance due to specific UX or latency constraints. So we introduced yet another bloody acronym: BFF pattern for Backend For Frontend which is implemented through API gateway and front microservices.
In 2019, we also carried out an alien mission to explore new infrastructure capacities for our IT ecosystem.
But this story will be a part of another post!
