Nmedia - Fotolia
Monolith to microservices case study proves maintainability matters
See how microservices have changed one retail rewards tech company's development team makeup as it worked to leave monolithic apps behind.
Most monolith to microservices examples start off with developers yearning for more application stability during frequent code updates, or the ability to scale without resource compromises, or a route out of dependency hell.
But Scott Bassin, engineering director at Ibotta Inc., a Denver-based mobile shopping rewards provider, also wanted to attract and retain the best developers, which he couldn't do with a monolithic application architecture.
New developers struggled to comprehend a whole application to develop features or improvements for it. "The monolith was hard to get into engineers' heads," Bassin said. With microservices, engineers can focus on one independent functional component of the application: "[Microservices] future-proof the app for the skilled workforce," he said.
See how this monolith to microservices case study worked out for Ibotta, and what lessons other application developers and digitally focused companies can learn from their migration.
Microservices vs. monoliths
Microservices are generally language-independent, so an organization can stick with whatever modern code language the staff already uses, such as Java or Python. Developers must adjust their perspective on application architecture to make the migration to microservices. "Developers need to understand how the architecture impacts how [they] build good software," said Jason Bloomberg, president at analysis firm Intellyx in Suffolk, Va.
Developers in independent teams can work concurrently on an application with a microservices architecture, but they must understand the context of their project within the broad architecture. Microservices are grouped by business domains for the core values they provide, Bloomberg explained. Microservices that share a business domain are tightly coupled to provide related tasks and functionality within applications. To compose an application, these domains form loosely coupled relationships. Organizations considering a migration to microservices should model the existing application architecture to this domain-based setup.
Microservices case study
A decoupled, business-driven microservices architecture lets engineers know exactly what problem to focus on, Bassin said. He added that the microservices architecture drives development in his team at Ibotta to a degree he didn't anticipate when the migration began. Microservices push what he calls slowness factors, such as scaling limitations and dependencies, out of application features.
Organizations that move from monolith to microservices address technical debt, especially in large enterprises, said Brandon Carroll, director of transformation, DevOps and cloud services at IT services provider TEKsystems Inc. in Hanover, Md. Developers aren't required to manage code in place with microservices as they do with monolithic apps. They can quickly release code to a container rather than deploy a whole app update. Enterprises can reduce total cycle times and deploy releases faster with independent microservices because they no longer manage thousands of lines of dependent code.
Ibotta's team turned to microservices development with the addition of its 30th engineer, but Bassin said if he could go back to day one, he would have started the migration to microservices sooner. He advises other software teams look at Ibotta as a case study and lift core functionality out of a monolithic application more proactively than his team did.
Ibotta's developers still work with a monolith in tandem with microservices, and that's not an unusual scenario, Bloomberg said. Microservices solve some problems with additional flexibility and new business capabilities, even when the big, old software architecture refuses to die. Modularized applications are patterns that date back to the advent of object-oriented programming and then service-oriented architecture, but there's no magic formula.
Microservices migration advice: Hire to disrupt
Microservices are a technological change driven by people, the Ibotta monolith to microservices case study shows.
Hiring managers should seek team members that advance the organization's digital roadmap -- you don't pick up microservices developers to maintain the status quo, Bloomberg said. "You're [hiring them] to get a software-based capability that will change the nature of your business."
Carroll exhorted company leaders to engage with this effort. Hire great talent, but don't stop there. Shepherd existing staff through the cultural and skills changes to work with microservices, and invest in tooling to create and support modern apps.
