I’ve heard I can use any language for each microservice, is that correct?

Sure. You can use any language for a microservice in the same manner that you can run a marathon in high heels. It’s possible, but it doesn’t mean it’s effective. The microservices architecture introduces a lot of operational overhead, adding onto that a diverse technology stack can exponentially increase that overhead. In this post, I’ll share our journey from multi-lingual microservices to a uniform technology stack, and the reasoning that informed our decision to make the switch.

Before…

When we started building out our architecture about 2 years ago, our primary goal was to build a stable, reliable, flexible and scalable platform that can support our fast growing business, while enabling speed to market and reducing costs. Our secondary goal, was to leverage this platform to support the continuous learning and development of our developers, for each of the technology stacks that Andela officially supports.

So we embarked on a journey to implement a Microservice Architecture. After all, microservices promise better fault isolation (reliability), increased autonomy of individual development teams (speed to market), scalability and re-usability. And let’s not forget, code for different services can be written in different languages! Killing two birds with one stone! With microservices, we could build a reliable platform to scale the business while leveraging the diversity in programming languages to continuously level up our developers in those stacks. We built our first iteration of microservices with a stack that looks something like this:

As you can imagine, we soon ran into multiple challenges:

• Code Reuse
  Re-using code across microservices implemented in different languages became a challenge. Anytime we needed to reuse a particular functionality, we’d abstract it into a library that we’d then implement in each of the languages. This process was very time consuming, and slowed the team down from delivering features fast.
• Context Switch
  Implementing a feature that cuts across multiple services required our developers to context switch between using one language to another. This also contributed to slow delivery.
• Developer Rampup
  The stack mix made it hard for new developers joining the team to get up to speed. They had to understand our business, architecture, and codebase. Additionally, depending on their programming background they needed to level up on 4 different programming languages! Ridiculous right!?
• Reliability
  While kafka is a very powerful distributed streaming platform, we simply did not have the knowledge/experience nor resources to properly setup and manage our own instance. Additionally, the amount of flexibility and scalability provided by kafka was not even needed given the business requirements, a clear case of over-engineering. This led to instability in our systems as kafka was the central message broker between the services, whenever it went down, it rendered all our applications unusable.

After…

The stack mix was clearly impeding in our ability to deliver business value quickly, and was the source of much frustration from both stakeholders, and the engineering/product teams. How do we improve things? Where do we begin? We went back to the drawing board! If we were to start the project from scratch today, how would we architect it? How do we evolve the current architecture to that ideal architecture? Should we scrap microservices all together? Those were some of the questions we attempted to answer. We also conducted a SWOT Analysis of our processes and technology stack.

After much discussions and deliberations, we decided to reduce and standardize our technology stack to the following:

• Frontend: React
• Backend: Node.js / Mali, Sequelize, Jest
• Database: Postgres
• Message Broker: Google Cloud PubSub

Our technology choices were informed by various factors such as business requirements (present & future), and cost of migrating to a new stack from current stack. Also, we wanted a leaner stack that would enable enforcing standards across our services, re-using code, reducing the amount of time spent ramping up new developers, and ultimately speeding up development.

Over the course of 6 months, we’ve been able to standardize over 80% of our services, reduce the average cycle time of development tasks by about 88%, and consistently achieved 99% reliability. In retrospect, I believe we made the right decision and feel confident we’ve put ourselves in the best position to start delivering more value to the business. To be clear, in no way am I suggesting that anyone implementing the microservices architecture should do so in a single language. But rather, it is probably wise to have a default language you use, and the decision to introduce a new language should be a deliberate one that solves for a specific need.

Thanks to Mohini Ufeli, Nadayar Enegesi, and Ebun Omoni for helping edit this article.