How Microservices Architecture Helped These Teams Improve Product Functionality Across the Board

by Janey Zitomer
August 13, 2020

Before FirstBank decided to break the applications development department into specific delivery teams in 2017, developers felt like they were often stepping on each other’s toes. 

“There were inefficiencies due to contention for applications, services and data across projects,” IT Fellow John Brady said. “Breaking up into teams has allowed everyone to focus on improving their product independent from a larger, monolithic application.” 

Relying on a microservices architecture has not only helped keep the peace at the locally owned bank. It’s allowed their delivery teams to target a variety of consumers through small, manageable RESTful services, which teams can test and implement independently.

For similar reasons, Conga’s Alex Bonjour said his team has also shifted to a microservices-based approach. The senior manager of software engineering said that, while the technology has increased development complexity in the short term, it’s also given them a newfound ability to add functionality to one part of the system without fear that unrelated parts of the application will be impacted.

 

Conga
Conga

Senior Manager Alex Bonjour said his Broomfield-based team was attracted to the scaling properties of microservices because of the number of customers they can serve and the number of activities they can support. The ability to scale portions of a workflow without it affecting the entire application makes it possible for him and his team to build technology that handles higher loads at lower infrastructure cost.

 

Tell us a bit about your team’s microservices architecture. 

Our digital documents product pillar works with AWS Cloud and leverages several of their available services. We are shifting our infrastructure to be microservice focused, and our microservices are running on EKS, the AWS-managed Kubernetes service. Our microservices themselves are containers. Our code is written in mostly C# and Java, with a bit of Ruby. 

For cross-service communication, we rely on an API gateway, queues (AWS SQS) and topics (AWS SNS) depending on the situation. To facilitate sending large amounts of data between services, we use a Redis cache and an RDS instance at various points in our workflow.

 

How did you decide a microservices architecture was right for your business?

We value being responsive to customer requirements, which have evolved over time. This means adding a few more third-party integrations, adding a few more features and moving more data through the system. All of that is possible with our legacy architecture. Not all of it is easy.  

Microservice architecture gives us the ability to add functionality to one part of the system without fear that it will impact unrelated parts of the application. If we, for example, have a bug within an email system, we want to limit the potential impact to only that email system. Isolating the interaction between unrelated pieces of functionality allows us to keep critical systems up for our customers for longer periods of time.

Also, Colorado companies are moving toward adopting microservice architecture based on cloud systems. Working with this infrastructure allows us to make a clear investment in our staff through certification, training and hands-on experience.  

 

This complexity increase required learning about a new way to organize our work.’’

What are the pros and cons you’ve experienced from implementing a microservices architecture? 

The largest drawback is the increase in infrastructure complexity. Microservices have smaller, clear scopes. To oversimplify it, if you are building a single, large application, you can scale it by running more of them with a load balancer. Microservices give you many more knobs and configuration bits to control the behavior of different services, how they scale, what authentication they use and more. Some of the complexity from application development shifts into the infrastructure. This complexity increase required learning about a new way to organize our work.

The positive trade-off is that, in exchange for more infrastructure complexity, you gain clarity and simplicity in business logic. For example, Conga has been able to replace a brittle connection between two components with a series of components that leverage an API gateway, two microservices, two SQS queues, Amazon’s SNS and a Redis cache. The infrastructure is more complex, but the purpose of each piece in the system is clear, easy to communicate, easier to test and, therefore, easier to address should anything go wrong unexpectedly.

Teams can also own and understand several microservices without stepping on each other in source control and deployments. If the right solution is in a different language than the rest of the product, that is OK. Conga has current microservices running in Kubernetes written in C#, Java and Ruby. We have AWS Lambdas written in Node.js, Python and C#. Because each microservice is small enough and made with a well-defined interface, it is easier for developers to make changes and test those changes.

 

FirstBank
Firstbank

According to John Brady, IT fellow at FirstBank, breaking apart monolithic applications has allowed his team to gain certain efficiencies in their work. Those efficiencies include the ability for developers to make small, incremental improvements without stressing about other engineers simultaneously altering code or data.

 

Tell us a bit about your team’s microservices architecture. 

For more than five years, FirstBank has adopted RESTful services as our primary model for service development. Using RESTful services was an attempt to move away from monolithic applications. In the last few years, we have also moved away from project teams to delivery teams. Each delivery team owns its product and the applications, services, data and reporting that make up their product. The delivery teams are organized so that a single team can own the business functionality and data for a particular business function.

Within our delivery teams, we apply many of the principles of microservices. But because our delivery teams are not built around operational use of certain functionality, we have reduced the possibility of duplicated business functionality across teams. We strive to build small RESTful services within our delivery teams that can be tested and implemented independently. These services are designed to be consumer agnostic. Currently, we primarily use Java with Oracle as the database. We have also implemented Kafka to help communicate events across delivery teams while remaining loosely coupled.

 

With the delivery team approach, we have better defined what our teams own.’’  

How did you decide a microservices architecture was right for your business?

Before delivery teams, we had inefficiencies due to contention for applications, services and data across projects. Breaking up into teams that each own a set of business functionality has allowed everyone to focus on improving their product independent from a larger, monolithic application.

 

What are the pros and cons you’ve experienced from implementing a microservices architecture? 

The biggest challenge has been shifting from a project mindset to a team mindset. In the past, multiple teams made changes to the same code to get a project completed. With the delivery team approach, we have better defined what our teams own. 

As a result, only the delivery team that owns that product should make changes to the related applications, services and data. With this shift, developers have been able to make small, incremental improvements without any contention regarding altered code or data.

 

Jobs from companies in this blog

Colorado startup guides

LOCAL GUIDE
Best Companies to Work for in Denver & Boulder
LOCAL GUIDE
Coolest Tech Offices in Denver & Colorado Tech
LOCAL GUIDE
Best Perks at Colorado Tech Companies
LOCAL GUIDE
Women in Colorado Tech