Migrating to a Microservices Architecture: How We Helped HyreCar Get it Done

California-based SaaS company, HyreCar, was growing rapidly and needed resources to help the business scale. The company needed an augmented team with experienced developers.

Sharing is caring!

by Julian Alessandro


But the HyreCar team had some less-than-ideal past experiences with outsourcing software development and were worried about:

  • Time zone differences

  • Language barriers

  • A siloed approach to development

That’s when they got in touch with NaNLABS.

“Some of HyreCar's team members, especially the legal team, had worked with some of our existing and former clients,” said Matias Alvarez, Co-founder and Senior Engineer Manager at NaNLABS. “They put us in touch with Ken Grimes, the CTO, and we started discussing their needs and what they were trying to achieve.”

With NaNLABS on board, HyreCar was able to successfully migrate from a monolithic architecture to a microservice oriented one and improve velocity while still keeping their current operations up and running.

In this case study, you’ll find out how NaNLABS augmented the HyreCar development team to support the migration.

Table of contents

Ready to build your own custom software with a team that cares about you and your processes? We’re not code monkeys, we care about you.

Who is HyreCar? 

HyreCar is a company dedicated to building a 2-sided car sharing marketplace that connects car owners to individuals looking for on-demand car rentals for services like Lyft or Uber. 

The marketplace was created to leverage technology and establish a presence in automotive asset sharing. Drivers and vehicle owners alike can utilize the platform to take advantage of new opportunities.

After signing up, the renter finds their desired car and submits an application. After their background check and application are approved, they can meet the car owner, pick up the car, and start earning.

On the other side of the marketplace, car owners sign up, respond to driver requests, verify their car documents, and hand off the keys.

HyreCar’s solution allows for fleet scalability, and satisfies the fluctuating demand for transportation across the United States.

The brief: Improve team velocity and solve architectural issues

Before partnering with NaNLABS, HyreCar was growing rapidly and struggling to find in-house development talent that fit the criteria for this project. At the same time, the team was making a conscious choice to move away from legacy architecture.

“We were experiencing a lot of expansion and growth… and there were a lot of projects and products that we wanted to roll out,” says Vanessa Ganaden, Product Manager at HyreCar. “So there was just this need to get more resources to help us with that.”

That’s when NaNLABS was asked to step in and help improve the velocity of the HyreCar development team and help deliver all the necessary updates and new features.

But because of previous unsatisfactory experiences with team augmentation, the client was feeling a bit apprehensive about a new collaboration. The HyreCar team had 3 main worries: 

  • Time zone differences 

  • Strong language barriers

  • A siloed approach to development 

In the past, these issues caused other dev shops to struggle with consistently producing viable and valuable products. That’s where our extensive experience with team augmentation and Agile software development came into play. 

The objective: Migrate to a microservice oriented architecture

Once HyreCar partnered with NaNLABS, we got straight to work. Our goal was to support the team with migrating to a new architecture and help them meet milestone deadlines.

After assessing HyreCar’s workflows and resources, we started by augmenting the team responsible for the company's fleet management application development and maintenance. 

The integration was a seamless process, despite the 4 hour time difference between the two teams. Daily meetings were held at pacific mornings and backlog grooming sessions, retros, and planning meetings during noon. 

All interactions with the HyreCar team were concentrated in 4 hours, leaving available time blocks for our team at NaNLABS during the mornings to focus on their duties beyond meetings and rituals. 

Through this approach, we were able to increase the client’s production velocity and help them migrate from a monolithic architecture to a microservice oriented architecture.

What is microservice architecture?  

Microservice architecture is a decentralized architecture style where the entire application is broken down into several single-purpose, individual web services. Each individual service then implements a single business capability within a defined context.

This architecture makes it possible to build applications as a collection of small autonomous services, which allows for continuous integration and iteration, and optimizes development. This aligns microservice oriented architecture with Agile software development and shortens the software development lifecycle. 

Microservice architecture is often considered to be a natural evolution of service oriented architecture (SOA), which was developed as a response to traditional, monolithic, approaches to developing software. 

Monolith architecture vs. microservice architecture

Monolith architecture is less complex than microservice architecture, and allows for easy deployment and maintenance. 

However, this is the software equivalent to putting all your eggs in one basket.For example,if new features need to be developed, the entire platform might need to be compiled and tested. And if one component, like a sign-in feature, fails then the entire server will be down.

Because in this traditional architecture pattern, all the components of the software, and those associated with them, are interconnected, tightly coupled, and kept on one server. This dependency creates a single point of failure. However, microservice architecture takes a decentralized approach enabling better high availability (HA) of the system.

When building microservice architecture, the application is broken down into more fine-grained and tiny services which function independently of each other, and are handled by smaller teams of experts. These microservices communicate with each other independently through APIs (or Message Queues) and are connected to their own database.

As an example, let’s imagine a marketplace web application. This platform’s services will include:

  • A storefront user interface

  • User authentication and login 

  • Catalog

  • Cart management

  • Chat

  • Payments

  • Order management

If built as a microservice application: 

  • The development and maintenance of each of these features will be handled by a small team 

  • User requests are directed through the API Gateway using a separate API

  • Every single service (payments, order management, etc) will be stored on an independent server

  • Different services will be connected to separate databases like AWS DynamoDB, RDS, etc.

Because of this, microservice architecture allows companies to scale more easily and quickly, and it shortens time to market, which were both goals of HyreCar.

This migration was the best route for HyreCar since it helped them speed up product development and reduce defects in production.

The challenge: Time crunches in a growing business

“[The biggest challenge was] transitioning from the old architecture to the new, while still running business normally, at a point in which HyreCar was scaling their operations,” says Martin. On top of that, the company’s frontend applications were using technology that was a bit outdated and needed to be updated. 

On the other hand, HyreCar’s current team application development had an unstable velocity which made it difficult to estimate the project timelines and make a roadmap. Meanwhile, failure to meet milestone deadlines was negatively impacting the business. 

Our teams needed to adjust to a significantly different way of working. That’s because the new architecture was heavy on concepts and practices like: 

  • Distributed systems

  • Event-driven architecture

  • Domain-driven design 

  • Functional programming

Applying these concepts meant changing the paradigms in which the software was being developed. So there was a learning curve for some team members as they got comfortable with this different approach, while still keeping HyreCar’s current operations up and running. 

The key was to remain open minded. Even though some of these methodologies and practices were new, the NaNLABS team was able to remain Agile, adjust, and learn. 

“When things seemed a bit off or we saw places where things could be done better, we said it, we didn't stay put,” says Martin. “We're not code-monkeys, we have an opinion and a goal of excellence, both for our clients but also for ourselves. We set the bar high, not because we have to, but because that’s who we are.”

Many developers, especially in the JavaScript and TypeScript communities, are used to the quick solutions observed in the startup world, and with developing MVPs and POCs. While this approach definitely brings results that allow for quick growth, the results can be unmaintainable and prone to code-rot if not attended properly.

Given that most developers come from an object oriented (OO) world, getting used to function programming (FP) had a pretty steep learning curve

“There’s no longer encapsulation of data and behavior, nor are there any variable assignments,” says Martin.”No side effects are allowed in FP, so the way you think of a solution changes.”

Domain-driven Design enables the discovery of a "universal" language that both technical and non-technical people can understand, which means that when the real world processes change, adapting the software to the change will be easier as well. 

“But most devs,” says Martin, “are used to analyzing a problem, modeling a solution, and putting that into production. It might be a great solution, but it will most likely be based on engineering concepts and abstractions rather than the real world structures and flows.”

The results: A long-lasting partner for microservice architecture

To overcome the challenges of this project, particularly the concerns at HyreCar around hiring external developers, it was vital that NaNLABS communicated well and became proactive members of the team.

That’s why our developers didn’t allow themselves to become siloed, working separately from HyreCar, but instead acted as any other engineer within the company. As a fully integrated team, they were able to make suggestions and improvements that helped ensure the success of the project.

Though HyreCar was already using tools like GraphQL, Redux, and Apollo, the NaNLABS team brought their own ideas to the table. For example, we made sure that React was updated to the latest version, and we brought AWS Amplify to simplify the deployment of test environments.

“[From an early stage,] the team were asking a lot of the right questions, giving pushback where necessary, and trying to better understand the product,” says Markus Rommel, Engineering Manager at HyreCar. “They came and gave us a level of stability and raised the bar for our expectations of committing code.”

Since completing the project, the NaNLABS team went from two developers in one Agile pod, to six developers and a minimum of two Quality Assurance team members covering a wide range of technologies in all of the development teams. 

That’s because NaNLABS’ developers are dedicated to helping your company do so much more than just resolve tickets. We’ll become an integrated part of your team, help you adopt Agile practices, offer creative solutions, and deliver high-quality software.

Ready to build your own custom software with a team that cares about you and your processes? We’re not code monkeys, we care about you

Frequently asked questions about microservice architecture

  • What is a microservice oriented architecture?

    Microservice oriented architecture, a fallout of agile and DevOps culture, is a type of application architecture where the entire application is broken down into several single-purpose, individual services. 

    Microservice architecture can be written in different programming languages, such as  TypeScript, Python or Java. Large companies like Zalando, eBay, Netflix, and Amazon use microservice architecture.

  • What are the pros and cons of microservice architecture?

    Some of the benefits of microservice architecture include

    • Independent development

    • Independant deployment 

    • Easy scalability 

    • More Agile and flexible 

    • Allows for continuous delivery 

    • Granular scaling

    • Enables fault isolation 

    Some cons of a microservice architecture are

    • Higher comparative cost 

    • More complex 

    • Higher security risks 

    • Difficult to manage a high amount of microservices

    • Complex communication

  • What is the difference between service oriented and microservice architecture?

    Service oriented architecture breaks down monolithic applications into smaller service modules. Microservice architecture breaks down the services into even smaller and more fine-grained components that function independently.

More articles to read

Previous blog post

Client Stories


From MVP to Enterprise Software Solution: How an Augmented Team Helped Amalgam Land Bigger Clients

Read the complete article

Next blog post



An Introduction to Test-driven Development in Agile

Read the complete article