This week we spoke with John Oram, one of our Senior Software Engineers at Intlabs, to understand why building with microservices has enabled us at Intlabs to build a flexible and powerful system that is primed for growth.
Building for growth
Designing and building a system is a big job. Any Software Engineer worth their salt knows from previous experience that the choices you make early on will come either to haunt you (and your customers…) or empower you to move quickly later on down the line.
We know there are a lot of things to consider when deciding whether to build a monolith or build with microservices. Like,
- How fast do you need to get your system live?
- How much fundamental development do you expect will be required, after your MVP is live and being used by customers?
- How hard do you expect your interface needs to be?
Mike Anderson, CTO at Intlabs, chose to build ORIGIN with microservices rather than as a monolith system right from the start. He made this somewhat unconventional choice because firstly, he knew that ORIGIN would need to be a flexible system that enables clients to include or exclude functions based on their needs. As a premium enterprise data governance platform, ORIGIN needs to be able to look a little different for each of our clients. Secondly, Mike knew that because data governance regulations are in constant flux, ORIGIN needs to be easily adaptable as the data environment changes across jurisdictions.
The benefits of an early monolith aren't what they once were
According to John, Senior Software Developer at Intlabs, he always thought that the cost of building out the infrastructure to host the multiple services of a microservices-based system was too high for an early stage startup. Though he knew it would be valuable later on, he didn’t believe it would be worth the development effort out of the gate.
“To me, the right evolution of code and infrastructure was always to start with a modular monolithic architecture and then split it out into its own dedicated services once the complexity in a given module passed a certain threshold,” John explains. “Only once you graduate to building with microservices do you one, stop kicking the can of operational costs down the road, and two, actually build out the ability to quickly and easily deploy multiple small services (not an easy feat!).”
Microservices > a monolith
In our industry, technologies and programs have to be highly specialized and extremely capable. Systems have to be adaptable so that as customer needs and data governance laws change, ORIGIN can be a market-leading solution.
“With a monolith, you’ll get to proof of concept faster. That’s a good thing and it makes investors happy. Monoliths also allow you to start iterating on ideas sooner which is helpful for the business. But it comes with a really major downside,” John continues.
“Ultimately, monoliths – even modular ones – are less adaptable."
- John Oram, Senior Software Developer at Intlabs
“They require that everything within the system is written in the same language. That hinders the ability of any team member to quickly create a simple new functionality if the tooling and libraries exist in a different language outside the prescribed stack. And with things like Kubernetes and Helm Charts you can minimize the operational costs of building microservices in the way you configure the services.”
“I have seen first-hand a few growth-point startups begin to feel the pains of a monorepo monolith,” John continues. “In every single case, longevity concerns and efficiency become the primary drivers for the Dev team’s work. Anything that can make their work faster and their options better is just good business.”
We have a recent example of how our development team has been empowered by using microservices. Just a few months ago, one of our Junior Software Engineers, Ben Reichwein, was able to build a dedicated service to redact and modify a particular type of document. He was able to create this service based on an existing technology because the output did not have to be in a particular language. This functionality wasn’t readily available in any other language. He containerized his service, cloned and modified a few helm charts, and released it behind a feature flag in less time than anyone on the team thought possible.
"I hate to say it but Mike was right. He started building ORIGIN using microservices and we've already seen incredible dividends because of it." - John Oram, Senior Software Developer at Intlabs
Addressing the standard mono vs. micro repos question
With a system built using microservices, clients get to buy exactly what they need. Nothing more. But perhaps something more important that lies outside the usual view of the client is how things look behind the platform that they interact with.
If your system is a monolith, it’s also a monorepo. That means all your code lives in one repository. Microservices, on the other hand, give you the option of modular repos or a mono repo. That means you can have one repository per service or one repository with every service inside of it. And ultimately, the fascinating thing is that other than an isolated devops deployment controlling repository, this worked better than John expected. The services share the same developers, CI/CD tooling, and architectural approach so they can live together no problem. If one was deployed by Jenkins, the other by Github Actions, built by different teams, and deployed at different cadences, then they likely would be better suited to living in different repositories.
So, ultimately, contrary to John’s original suspicions, the choice between using a mono repo or micro repos is much less black and white. In this case, using mono repos simplifies the work of our developers at Intlabs so they can focus on building a better product.