You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 6 minutes
“There was no way to maintain that without a sledgehammer,” says Gus Fune, Chief Technology Officer at DivBrands.
How do you reverse engineer a monolithic e-commerce platform into a sleek microservices architecture? There are many schools of thought, like domain-driven design, the two pizza team, design-first, and Conway’s Law. Then there is Gus Fune, Chief Technology Officer at DivBrands, who is a fan of the FAFO approach, also known as “f**k around and find out.”
Another hip acronym is MACH, which stands for microservices, APIs, cloud-native, and headless, which emerged alongside the ecommerce boom as the building blocks for scalable, flexible digital experiences. Fune, a MACH Alliance Ambassador, has been steadily employing these engineering techniques for the past few years at DivBrands, a Swiss direct-to-consumer e-commerce company. His division oversees 40 decoupled microservices, each powering niche aspects of the online business.
Migrating to microservices was tough. The team encountered hiccups, broken databases, and complete overhauls. Nevertheless, the move has been well worth it, says Fune, having improved flexibility and even avoided lost sales during times of IT disruption.
From sledgehammers to emojis
When he first arrived at DivBrands in late 2021, Fune encountered a PHP monolith based on an old fork of WordPress. Their legacy stack was frozen in time, and any new change took considerable effort, delaying feature rollouts. “There was no way to maintain that without a sledgehammer,” he says.
Fune realized something had to change. Over a holiday break, he sketched out a proof of concept for rebuilding their ecommerce platform from scratch. Three or four rebuilds later, through outages and disappointing vendors, their microservices architecture began to take shape, all in a matter of a few months. “It was kind of like a blitzkrieg,” he says.
Throughout this process, MACH was essential, notes Fune, as the team built different modules, and each developer became the expert of the microservice they owned. Nowadays, each microservice has a cute name and emoji, like Orca 🐋 for their payment orchestration layer, or Owl 🦉for warehousing and logistics.
Decoupled microservices save revenue
Impressively, this separation of concerns style has saved the company from losing revenue. On one occasion, a mistake was made during a database update, effectively crashing a service that made the database inaccessible to other services.
Even though the database was inaccessible for nine hours, due to the decoupled design, customers could still place orders. When the service finally went back online, the system resumed processing them. The only noticeable impact on customers was a delay in receiving confirmation emails.
“Ten years ago, people said your campaign was a success if you got so much traffic that the server went down,” jokes Fune. Nowadays, that’s not celebrated, especially in online sales, where minor outages equate to abandoned carts. A decoupled backend, however, can help avoid disruptions. “It’s easier to maintain when things aren’t as intertwined.”
That said, homegrown microservices architectures are no small feat. “It’s inevitable, things will break,” says Fune. “You can’t make it foolproof.” However, you can avoid disruptions with a more flexible smart backend stack. “Can you make it fault-tolerant instead of fault-resistant?”
More like this
Tips on leading a microservices migration
Fune has learned a few things through this experience.
Trust your instincts. One of the hardest things about adopting microservices in practice is defining the scope of your services. For this, you might turn to Conway’s Law, which, in a nutshell, states that an organization’s systems and technologies will reflect its communication structures. This philosophy can impact domain-driven design, tech ownership, and communication channels. Fune has found Conway’s Law to be a helpful guiding principle, but beyond that, it’s about trusting your gut.
“To be honest, it really depends. Just start building, create a proof of concept, and see how it goes,” says Fune. Sometimes, you’ll find a Goldilocks middle ground that just feels right. “If something starts to become too big, we chop it down.”
Keep optimizing. “MACH in composable commerce is a process and a spectrum,” says Fune. Microservices design requires ongoing iteration, meaning you never really reach the finish line. For instance, he describes discovering an optimization that reduced payments-to-orders from 30 seconds to two seconds. Try to see the bigger picture and keep fine-tuning your environment.
Put faith in developers. As a leader, Fune uses a pretty hands-off approach. Teams are independent, and they don’t do live daily stand-ups. It’s good to intervene if someone is overpolishing, not testing property, or appears stuck. However, on the whole, nearly all collaboration occurs asynchronously. “We could work days without talking to each other,” he says.
To enable this agile way of working, developers are empowered with the tools they need to succeed. All developers can see their cloud statistics, error logs, and observability data, which gives them the full picture of the business.
Automate your infrastructure. “Try to automate the infrastructure layer, with infrastructure-as-code, Terraform, or Pulumi, as early as possible,” says Fune. If you don’t, microservices architecture becomes increasingly annoying to maintain. Investing in automation early on is totally worth the upfront cost.
Freshen up on DevOps. On that note, the best developers are pi-shaped professionals, who have a broad base of experience and deep specialization in two areas, like the two vertical “legs” of the π symbol. It’s helpful to have knowledge of programming and DevOps contexts, like hosting, container management, and site reliability principles. Freshening up on DevOps fundamentals will pay dividends, helping developers realize their full potential in the world of MACH.
An ongoing process
Looking to the future, Fune’s team is actively working on better documentation and incorporating more automation into their workflows. They’re specifically trying to replace manual tasks or spreadsheet-based processes, focusing their efforts where they’re already working, such as within Slack.
Another ongoing task is keeping costs under control. One drawback of introducing a microservices architecture is that it increases costs considerably, since modules run separately and must be networked together. However, Fune believes they make up these costs in indirect ways, by reducing redundant work, decreasing outages, and empowering developers to become experts in the modules they oversee. There’s also a lower maintenance overhead when things aren’t as intertwined. “The investment pays off in the end,” he says.
For instance, one way to avoid wasted resources is to avoid reinventing the wheel by focusing on reusability. “If we see one thing being used in more than one service, it becomes a library,” says Fune. “Build it once, and it becomes part of our toolset.”
The top benefit: flexibility
For e-commerce developers, it’s a race against the clock to get features ready in time for the end-of-year shopping season. This often means scaffolding, testing, and dismantling various services in preparation for a flood of requests. Fune finds solace in the fact that developing a customized microservices architecture has granted his team more flexibility.
“If you want to try something new and crazy, you’re not stuck in ‘oh, we can’t do this because our ERP doesn’t allow that,’” he says. Using a decoupled microservices approach, you can build it out easily and see what happens. “It helps retain that startup agility,” even nine years on.
