When it comes to building technology, growth often goes hand in hand with increased complexity. As a result, a software solution first created by a small team of agile developers can become more tangled as it grows, and there comes a point where no member of the growing team can really have a bird’s eye view of the whole project. The software’s architecture becomes monolithic – at times even inscrutable – and, by the same token, more difficult to manage and grow. Since October 2019, Etienne Lorthoy, Full-Stack & Performance Developer at Officevibe, has been at the head of an internal project which set out to tackle the sizable challenge that is rethinking their product’s monolithic architecture.
So how does he intend to go about simplifying Officevibe’s growth and evolution? By using a well-known strategy: divide and conquer. In software circles, this strategy finds its practical application in the concept of microservices architecture.
Share this article
The more the monolith grows, the more people get overwhelmed by it and the more they become fearful that their contribution will cause delays. This is where the rubber that is the notion of microservices meets the proverbial road: divide and conquer; divide to grow.
Full-Stack & Performance Developer at Officevibe, GSoft
The downsides of the classic approach
The inherent opacity of a monolithic software architecture makes a few core challenges to product development, innovation and management nearly impossible to escape. “As a developer,” explains Etienne, “I need to have a solid grasp of the entire monolith to make sure that the changes I make don’t compromise other aspects of the software.” So where does that leave us? Grappling with an increased risk of bugs and the considerable loss of time and resources required to correct them – resources that would, in better circumstances, be devoted to innovating the product. When working with a monolithic architecture, everything needs to be accounted for in advance and even the smallest mistake in forecasting can lead to significant setbacks. As a knock-on effect, the deployment time suffers and becomes a sizable obstacle to scalability. Basically: everything moves in slow motion and team members, fearful of making mistakes, become reticent to innovate.
For a large team like the one handling Officevibe, where no one person really holds a bird’s eye view of the project, the challenge is figuring out how to get the necessary information and know-how to the right teammate. If this information isn’t shared accurately, the spectre of costly bugs rears its ugly head once again, team leaders are tasked with managing the unmanageable, and colleagues become discouraged, making it difficult to keep them motivated to seek greener pastures.
Microservices: a pragmatic approach to the rescue
To stare down this challenge, the microservices approach decomposes the monolith into its constituent parts. Every element of the monolith is then transformed into a microservice, which itself exists in dialogue with other elements within a broader ecosystem of functionalities. “At Officevibe, we divide to conquer by making sure that each microservice is assigned a very specific problem to solve,” says Etienne.
This minimalist approach to software architecture allows the teams working on each microservice to shrink and thus reproduce the winning formula of a small, agile startup: creativity, innovation and control.
At the small scale of a microservice, circulating information and know-how among developers ceases to be a problem since everyone can easily understand the inner workings of the whole project. By the same token, the risk of bugs diminishes in tandem with the cost of correcting them. Deployment times are drastically reduced, and if an innovative feature fails to bear fruit, it’s easy to roll it back. Moreover, teams end up specializing and becoming experts in the domain assigned to their specific microservice. This expertise, in turn, feeds the quality of the work and, at scale, improves the quality of the whole microservices ecosystem.
Making the switch: the essential ingredients for a successful transition
Switching from a monolithic architecture to a microservices approach is a challenge all its own. Microservice architecture as a concept is a relatively new arrival on the software scene, so it’s no surprise that there are few practical guides for those looking to lead the way. At Officevibe, the shift has now been underway for about a year, but the approach’s adoption levels still don’t exceed 20%. “Our ambition is to reach 90% adoption in the next year,” says Etienne.
For those looking to make the switch, Etienne has two main pieces of advice:
First, both leaders as well as the team must have a solid understanding of the theory behind microservices architecture in order to avoid empty debates and to make sure that everyone has a good grasp of the variety of tools, approaches and alternatives at their disposal to tackle any given challenge. To that end, Etienne suggests these three books as required reading: Domain-Driven Design, Monolith to Microservices and Building Microservices.
Secondly, it’s crucial that the first iteration of the new structure be effective. “You have to find the smallest, simplest of projects for the first implementation,” advises Etienne. Apart from the technical challenge of the transition itself, one of the biggest remaining obstacles is adoption – it simply isn’t easy to get people to take on new habits, new ways of doing things and a whole new modus operandi. In order to promote a microservices-oriented culture, the first deployment shouldn’t exceed a few months. This first stab at the problem must also be simple to understand and easy to implement, not only to validate the tangible benefits of the new methodology, but also to make sure it is sufficiently intriguing and intelligible to convince an entire organization to question the status quo.
After all, as sociologist Daniel Bell so aptly put, “Technology, like art, is a soaring exercise of the human imagination.” But of course, before giving free rein to our innovative instincts and imagination, we must first understand the potential and scope of the tools at our disposal.
In this article
We recently talked products with Gibson Biddle, former VP of Product at Netflix, who we hosted for a series of events that included a workshop
Curious to join our dev teams?