The architecture of Cheerz services
September 2013, in the chaos of a small coworking space of Paris, 11th arrondissement, after a few weeks of work, our first microservice was born. 🐣
Since then, this baby microservice has grown, and plenty of others services have popped up at Cheerz. This article is a short overview of how we have split our different services.
Microservices
I won’t go into the details of the microservice philosophy, that has already been detailed in billions of articles on the web. But to quote Martin Fowler:
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
Some people seem to argue about the appellation “microservices” for services depending on their size (and not miniservices, macroservices nor whateverservices). But more than a debate on naming, what actually matters to us is that:
- Services are independent: isolated codebases, isolated databases, independent deployment, and resilient to others failures.
- Communication between them is technology-agnostic, like with HTTP APIs. This way, each microservice can implement its own stack, depending on its needs.
- Size of projects remain small enough so that the development/testing/deployment cycle remains as short as possible
Cheerz Architecture
Cheerz architecture mainly relies on 6 main services :
- E-business
- Factory management
- Photo management
- Customer support
- Monitoring
- Events
During the last 5 years, others services were born that we then decided to take down (often with a bit of nostalgia and sadness). Most of the time, when we decided to stop a microservice, it was to instead use existing tools, despite their drawbacks, to not lose focus on our core business.
Something that I find worth to note, is that while speaking to other startups that have adopted microservices and have approximately the same size (15 to 100 people), most of them also have around 6 services. Is it a magic number of microservices? Question to be followed.
Service #1 - The E-Business core
Because we are an e-business company, it would seem quite logic that we start by the core of our e-business!
The e-business core is the back-end application that supports everything about our product catalog, our users, and all the actions they make on our website or apps: This is the main API with which all our consumer-facing apps have to deal with.
Many times, we have considered splitting this service to split the logic of the catalog from the logic of user interactions. However, if we think this split would be great for code isolation and would allow us to have a more specific infrastructure for each, so far, we could not see a solution that would compensate all the drawbacks it would also bring, especially about data sharing between these new microservices. Indeed, in some use cases, splitting services can induce complexity.
Service #2 - The factory service
Since we have always believed that mastering the production of our orders is key to deliver quality products and quickly to our customer, factory has been one of our top investments. This service has been the first one to be created, out of the main application, back in 2013.
Right now, this is the service in charge of :
- Providing the interface with which factory operators scan products they ship
- Allowing grouping of orders to reduce the number of parcels we ship
- Generating machine-specific files, with cutting marks, enhanced color profiles, and all the needed printing informations, based on the machine on which the product will be printed
- Being a gateway to all the carriers APIs (DHL, Colissimo, TNT, Laposte, etc.)
- Handling all the paperwork for the different carriers
- Allowing stock management
Service #3 - Customer Support
Being able to answer quickly and efficiently to our customers is a hard task, but nevertheless one of the most important ones for us. This is why we decided to create this service.
Every Customer Support member has a private Chrome Extension that converts every email or order number on Zendesk, into a link that points to this service. Once arrived on this service, our Customer Support members can perform quickly all the main actions needed when communicating with our customers, like:
- Manage emails (subscription to newsletters, re-send confirmation email, etc.).
- Find information about the state of the order (printing, shipping, etc.), and eventually take actions (reprint, cancel, etc.).
- Troubleshoot something that happened during the order, and open a ticket for another department.
Service #4 - The events
After a while, Cheerz became a quite sustainable company, with a strong production facility, and the tools to be efficient with our factory and in with our customers.
We then decided to broaden our activities by launching Cheerz Live, a branch of Cheerz that animates events with an amazing photo booth that we have created.
However, administrating those events, dealing with the machines availability, and especially configuring the booths for each event was very time consuming. This is why we have developed the events service that allows us to:
- Configure the booths remotely and easily
- Follow the project cycle for each event
- Configure galleries after the events, where users can see their photos (and download, share, etc.)
Service #5 - The Monitoring
Once you got many services arises the question of “how you will monitor all of them easily”, ie: in a same place. This is why we have developed a very simple tool that gathers and caches information from a lot of different places and then displays it on dashboards that everyone in the company can access: one dashboard for developers, one for marketing, one for customer support, one for the factory, etc.
This allows us to give real-time updates to all people from Cheerz to metrics like:
- State of our workers queues (number of workers in progress, stales, etc.)
- Errors & error rates traced by TrackJS and NewRelic
- Sales of the day, week, month, and real-time progress of our objective (%)
- Analysis of pages from tools like Google PageSpeed Insights or Search Console
- Conversion rates of our last app versions
- Datas about servers states and deployments
Et voilà! We have other small services, but we won’t go into details about them right now.
The risks
Microservices have drawbacks. Without going deeper in the overhead it can introduce if your team is not mature enough, we had to re-implement small pieces of configuration on each project, like user authentication, or some boilerplate that we didn’t feel like it should be put in a common module.
I have seen many debates about microservices. At which stage should we start thinking about it, partially, strictly, not at all? From what we have experienced, like in general in software engineering, there is no universal architecture for all problems. It’s all about granularity!
Depending on the size of your engineering team, the nature of your problems, the maturity of your team, you could consider having one monolith or thousands of services. Especially, our ability to succeed with microservices depends on the pain you have to spawn and monitor new services, and thus on the stack you rely on: Creating a new service could require to have a database, thus it means you have to monitor it, replicate it, have backups, etc, and unwinding it can be endless if your stack does not provide you automations for all of that.
The good parts
However, all in all, we clearly see the benefits we have gained by keeping separated services for our main problem domains.
- Onboarding of newcomers has been much easier because of relatively small and isolated codebases.
- Team work is more fluid, with less collisions in the codebases. No more weird side effects between different problem domains.
- We have been able to test upgrades of frameworks (or whole new frameworks or languages) on less critical services, to have a smooth migration and learning.
- When trying to scale, it has been way much easier for us to maintain high availability on our different services, that have very different resources needs.
- It has allowed us to keep the development/test/deployment cycle very short, and to deploy dozens of time per day with great confidence.
If you want to tell us your story of microservices and architecture, join us, or just have a coffee, contact us!
