Microservices for a Macro World

Architecting for the Future

At Kenzan, we often work with large, consumer-facing companies whose customers are demanding richer, more interactive, and friendlier experiences on all of their devices. As trends in software architecture evolve to adjust to these expectations, organizations need to create applications that are both highly available and highly scalable.

We’ve been building web applications with microservices for a while now and have found they’re easy to manage, can be scaled independently or across servers, and offer flexibility to quickly deliver features.

In this blog series, we’ll look at how you can architect for the future using microservices, some of the challenges you may face along the way, and strategies for mitigating these challenges.

What Are Microservices?

Microservices have been around for a few years, but you may not have encountered them yet.

In a traditional architecture, all functionality resides in a single, monolithic server-side application. This makes it easier for one developer to understand the whole system or run it locally, but it can quickly lead to issues as the application grows in size.

In a microservices architecture, functionality is distributed across small, self-contained, modular services that communicate with one another over the network.

What Are the Advantages?

Adopting a microservices architecture brings a lot of benefits — let’s check them out.

Up and Running Today

High availability and uptime are two big selling points for microservices. That’s because they allow for smaller components or services to be upgraded without risk of taking down an entire system.

Imagine a customer-facing application that has one monolith for all services, including account information, identity data, and login portals. Maintaining and deploying updates to just one of those services means you’re at risk of bringing down the entire application if there’s an issue. With microservices, if one service goes offline, the rest of the application doesn’t have to go down with it.

Scale to Meet the Future

The first thought that comes to mind when talking about scale is the amount of load a system can handle before falling down. But that’s not the only type of scale to consider when you’re building a microservice. When you’re dealing with big data, a microservices architecture lends itself to scale for velocity (number of active users on a given system) and for volume (how much data you have). With microservices, you can scale your applications just at the point of demand. You don’t have to scale everything together. For example, edge services that communicate directly with web clients often have higher load requirements than back end services, especially if caching strategies are used to reduce communication with the back end.

Microservices can also help scale your organization along with your application. Using microservices allows for distributing development teams more efficiently. Complex backend systems can be built faster by dividing workloads into multiple small teams, with each team responsible for a given set of microservices. Clear domain ownership means you always know which team to go to when there’s a problem with a microservice. Likewise, teams are empowered to operate and deploy independently at a delivery cadence that makes sense for them rather than coordinating large releases across many teams.

Every Service For Itself!

Let’s look at our imaginary monolithic application again. The many features of this application share resources like CPU, memory, network latency, and I/O, and as a result could easily overwhelm these resources, causing all the services to suffer. In a microservices architecture, many of these resources are isolated to the individual service and can be optimized more easily. Through containerization with frameworks like Docker, or serverless solutions like AWS Lambda and API Gateway, resource isolation is a much more cost-efficient practice in microservices. Services scale according to their own needs rather than to the needs of the busiest component.

Use of common protocols like HTTP, and standard interfaces like REST for communication with other services, allows microservices to be technology agnostic. Teams can choose to build microservices in the language they are most comfortable developing in. Having a microservice stack including both Node.js and Java applications is becoming more common. This lets organizations tap into a wider range of skillsets. (Choose technologies wisely, though, as some may not play nicely with other technologies in the microservice stack.)

What Are the Challenges?

Knowing why you should build a microservice is only half the battle. Knowing when to (or when not to) build one can be a trickier question. Every engagement is different, and there’s no one size fits all. Here are some of the key factors to consider:

• Infrastructure — Adopting a microservice stack can require a bit of scaffolding to get up and running. Considerations such as infrastructure requirements, deployment strategies, monitoring, and configuration management come into play when building a custom microservices solution. Platform-as-a-Service products like Amazon’s Elastic Beanstalk can reduce the time required to develop a microservice platform, and they streamline the process of developers deploying code.
• Code Compatibility — Microservices can suffer from code compatibility issues like monoliths can, but the single codebase nature of a monolith does allow code compatibility issues to be caught at compile time. In contrast, changing the interface of a microservice may go unnoticed until another microservice breaks after deployment. Maintaining API Contract Tests is a good way to ensure consistency of a microservice’s external API and avoid unintentional changes.
• Shared Libraries — There will be many microservices doing similar things, and it often becomes apparent to put common patterns into libraries to be shared with other teams. Sharing code with other teams is like sharing open source code on GitHub. The code must be useful enough to share and intended to accept contributions from other teams.
• Coding Practices — Many different teams working in siloed environments can result in vastly diverged coding practices. Whether or not this is an issue can be left to the discretion of the organization and their development culture, but establishing company-wide standards and periodic discussions of new patterns can help keep teams in sync.

Finally, microservices aren’t right for every application, like those with a limited scope, a small number of users, or a single data repository.

Conclusion

When applied to the right problems, microservices are a flexible solution that many companies are adopting to architect for the future. Given the complexities, you might decide to have an experienced guide on your journey.

In our next post, we’ll talk about how to put microservices to work to solve challenges now and prepare for future needs.

— — — — — — — — —

Check back in with us on our tech blog for the next microservices post.