If you could develop and deploy updates faster with less risk, wouldn’t you?
Speed, autonomy and safety of the pros behind working within a microservices framework, according to Haiping Chen, a software architect and 15-year engineering veteran.
“Microservices allow us to quickly respond to the needs of the different audiences our technology serves,” Chen said. “Each feature can be developed and deployed independently.”
Independence is one of the most essential reasons a company might find a microservices architecture beneficial, Chen said. Small and focused teams deploying microservices aren’t overly reliant on timelines or data systems from other areas of the business, and the architecture also means developers are given more individual ownership over their work.
At facilities maintenance platform SMS Assist, Chen said that a sense of autonomy — as well unit testing and a cloud-native infrastructure — allows developers to release products at an expedited rate.
“Before implementing microservices, we had a release cycle of two weeks,” Chen said. “Now we’re able to release new updates as soon as they’re ready.”
So how can teams best utilize microservices to simplify their tech? The following engineering leaders and teams walked Built In through best practices for keeping microservice architecture as it should be: small.
What are Microservices?
SMS Assist
Haiping Chen
SOFTWARE ARCHITECT
What resources did you use to build and support your microservices?
At SMS Assist, we implemented our microservices system with a cloud-native approach that ensures our service components can collaborate with other cloud-based solutions.
We applied domain-driven design as a method to abstract our business into different domains and aggregate the data via API management services. The services we use include open-source framework Istio to implement service mesh, Kafka as the messaging middleware, and Amazon Relational Database Service as the online transaction database. Our aggregation data flows into a data warehouse in an extract, transform, load process that includes batch and streaming processing. This setup provides our business intelligence team with a reliable data source presented in Tableau.
Microservices allow us to quickly respond to the needs of the different audiences our technology serves.”
How did you decide a microservices architecture was right for your business?
Our engineering team adopted a management concept based on service ownership; you build it, you own it. This approach motivates developers to take more care of the application and grants them a great deal of autonomy and decision-making power.
Microservices allow us to quickly respond to the needs of the different audiences our technology serves: customers, our network of service providers and the internal operations team. The architecture offers a flexible and scalable solution that positions our platform for the future.
Full unit and integration testing accelerates our release cycle. Before implementing microservices, we had a release cycle of two weeks. Now we’re able to release new updates as soon as they’re ready.
What are the pros and cons you’ve experienced implementing a microservices architecture?
A pro of working within a microservices framework is that it reduces risk because each feature can be developed and deployed independently. This aspect allowed us to release key products — such as a tool for onboarding new service providers — in separate release cycles from our regular two-week sprint. The services are also minimally dependent on each other and autonomous, meaning they internally control their own business logic.
A challenge to using microservices is that they are frequently more expensive than legacy monoliths. But we find value in the added agility for our team and the ability to accelerate product releases. Additionally, they require more collaboration in the vertical alignment because each team has to cover the whole product lifecycle. For us, that means each product we release needs dedicated UI, UX, front-end and back-end developers, a product owner and a quality assurance team member to ensure our standards for delivery are met. We prioritize maintaining a strong team of experts so we can continue to efficiently produce our technology.
Vericred
Dan Langevin
CO-FOUNDER AND CTO
How did you decide a microservices architecture was right for your business?
At Vericred, we determined that extricating our higher volume services and endpoints from our purpose-specific monoliths would increase scalability and flexibility of deployment by removing unnecessary entanglements that typically occur within monoliths.
We spent some time investigating available tooling before deciding on Lambda and API Gateway for services that have an external interface. We chose Step Functions, Lambda and SQS for services that run batch processes or event-based processes that don’t require a real-time response. Finally, we selected a handful of candidates to move into this architecture and build them out as proof of concepts.
What are the pros and cons you've experienced from implementing a microservices architecture?
We can distill our philosophy on microservices down to this: A microservice must provide a clear API and store its data independently of any other service. This means that two microservices should not rely on the same shared resource, like a database. If two microservices rely on the same shared data store, they are no longer a microservice but instead a more difficult-to-maintain version of a monolith.
By chaining services that each isolate data and provide an API, we can ensure that our microservices are, in fact, ‘micro.’”
A microservice should have a clear API specifying its inputs and outputs and it must own that contract definition. The systems that produce the inputs to that API should be tested such that that contract is fulfilled.
For example, we may have a microservice that processes a large file. The format of that file is the contract to the service’s API. Whatever system produces that file should be tested so that it fulfills our microservice’s API. Let’s say that our microservice processes that large file and sends API requests to ingest data from that file. It now becomes the producer of data that is consumed by a different microservice and no longer owns the contract — but must instead conform to the contract of the service that consumes its API requests. It should have unit tests to that effect.
By chaining services that each isolate data and provide an API, we can ensure that our microservices are, in fact, “micro.”
Tell us a bit about your team's microservices architecture.
Our team uses Ruby and Rust. We use Postgres, Elasticsearch, Redis and Athena/S3 as data stores, deployed on AWS and Heroku. The microservice architecture we employ is primarily Lambda, though we do have some smaller apps hosted on Heroku that could potentially be considered microservices.
This architecture works for us because it combines scalability and isolation of microservices for specific purposes with the ease of development and deployment that comes from purpose-specific monoliths.
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.
At Conga, 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
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.
