From monolith to microservices: Why Credit Karma made the switch

Credit Karma, the personal finance technology company powering more than 100M members, migrated from monolith to microservices, which they say has vastly increased developer efficiency for its engineering team, which makes up more than half of Credit Karma’s 1000+ employee base.
We caught up with Nick Nance, VP of Engineering at Credit Karma, to chat about why they made the switch, and how the migration has transformed product development speed and efficiencies, resulting in major productivity gains. What's more - Nick says it's transformed engineering culture at Credit Karma, and many microservices are now regularly deployed.

ADM: What is likely the common tipping point for companies when deciding to make the move from monolith to microservices?  Are there instances in which you would suggest a company delay in making this migration or to remain operating via monolith?

Nance: The common impetus for companies making the migration from monolith to microservices is to operate more efficiently at scale. It’s common for startups to adopt monolithic architecture because monolith applications are easy and fast to deploy and manage, but as an application or team scales, the need to build and test new features becomes challenging. 

A monolith is one big autonomous unit, meaning all application functionality is defined in the same codebase, so if engineers want to make any changes or updates, no matter how small, they must completely recode and redeploy a new version of the application. As an application grows, engineers add and add to one codebase, and the bigger the codebase gets, the more fragile it becomes. The inability to scale independently eliminates autonomy and decreases velocity. 

Microservices isn’t the answer to all of the monolith’s downfalls, both software architectures have their pros and cons and the architecture solution depends on what growth phase an application or team is in. Companies need to fully understand the challenges that come with microservices before they make the migration decision.

ADM: What are the key points companies need to consider before making the migration? 

Nance:

Team structure: Take into consideration the size and plans for team structure. A complete migration is no easy task and involves several transitions. Team structure will change from one unit to smaller teams of 3-4 people, so make sure your team can successfully support this new format. 

Time: Set expectations across teams regarding the time and undertaking it takes to make the transition to microservices. It is a time-consuming and complex process, so overestimate the time needed to ensure deadlines are met and frustrations minimized. 

Operational Complexity: There is operational overhead with a microservices architecture, but building and operating services is much easier today than it used to be because of technologies and platforms like Kubernetes and Istio. 

• Infrastructure — Organizations should consider infrastructure creation and management tools
• Load scaling and balancing — Service meshes are starting to make this issue much more manageable 

ADM: What are the main benefits of moving to microservices and how does it improve product development speeds and efficiencies?

Nance: Although microservices comes with its complexities and challenges, the architecture does solve several technological and collaboration challenges, especially for more established projects with large development teams. Benefits of moving to a microservices architecture include: 

Independence: The most important characteristic of microservices, which allows for several other benefits, is its modular structure. Because code is broken into independent services, applications are easier to develop, test, deploy, update and maintain. 

Velocity: Services can be scaled independently of one another, reducing the time and cost that comes with having to scale entire applications. Teams can autonomously develop and deploy their own services. Various teams can simultaneously work on different components without having to coordinate with each other, and as a result, application delivery is faster. 

Security: In a world where data security is a highly important consideration in product development, you want to try and isolate that access, which is achieved with a microservices architecture. The services’ isolated structure makes it easier to defend.

Ownership: Microservices architecture allows development teams to own a product through its full lifetime. Not only does this give engineers more freedom to work autonomously, and therefore make decisions faster, but it gives them a sense of ownership, allowing them to take pride in their craftsmanship. 

ADM: What are the common challenges faced in the migration process and how can engineering teams best approach these challenges? 

Nance: Similar to how its independent structure is the underlying benefit of microservices architecture, complexity is the underlying challenge. Services may be easier to manage individually, but the overall application consists of more components and moving parts. Because these components are interconnected, they become more dependent on each other, which can create more potential for error. Microservices’ complex nature creates other challenges, including: 

Planning & Maintenance: Because the microservices in the application are dependent on each other, careful planning must come into play when deciding how to refactor the monolithic application. Rebuilding the application is a gradual process that requires maintaining the monolithic and microservices, so the challenge is maintaining the applications function while tearing it apart internally. 

Testing: Testing in a microservices environment is much more complex since each service has its own dependencies and requires verification for each service before testing begins. Not only does each microservice need to be tested separately, but also the APIs, so quality assurance teams must be smart on service communication channels to ensure seamless communication. 

Monitoring: Historically, monitoring microservices has been more complicated than monitoring the monolith but several new technologies have helped close the gap. Teams should implement tools to ensure monitoring can support scaling. Tools worth considering are tracing, APM and logging tools. 

ADM: Are there different ways to approach the migration process? Which approaches are most common and why? 

Nance: The only reasonable approach is an incremental one, which entails refactoring the monolithic application gradually. When prioritizing which modules to convert first, I suggest starting with the foundation of the data access layer and focus on the most dependent parts of the system. 

ADM: How should engineers approach API architectures when deciding which to use to expose services?

Nance: With a microservices architecture, you must decide how client applications will interact with services. Using an API Gateway brings value in terms of providing a common entry point for security reasons, the ability to perform protocol translation and API throttling, which allows you to control the way an API is used. Engineers will decide whether to use a REST or GraphQL API and if they choose to use GraphQL, they must use a GraphQL gateway.

About Nick Nance

Nick Nance is the VP of Engineering at Credit Karma. His experience spans from early-age startups to hypergrowth at large-scale engineering organizations. He’s passionate about creating software that drives value for Credit Karma and its 100 million members while leading Credit Karma’s growing team of engineers, who make up more than half of the company’s employee base.