Are microservices right for you?

Nov 22, 2017 12:00:00 PM / by Matt Ledger

  Matt Ledger

The Internet is splintering. What used to be a World Wide Web, where every web application was accessed via a browser, is fast becoming a World of Apps, in which service providers do their best to funnel users into a silo of individual app offerings and keep them there.

To create this World of Apps, more and more service providers have turned away from the monolithic application structures of old. Monolithic apps, in which every single service your app provides is locked together in the same set of servers and databases, simply aren’t fast enough or agile enough to keep up with the way users connect with technology today, as well as their demands for innovation.

Enter microservices. In this post, we’ll explore what microservice architecture is and how it can help you solve the innovation problem.

What Is a Microservice?

Instead of monolithic applications, companies as diverse as Netflix, Target, Google, and WordPress are turning to microservices. Microservice architecture splits formerly monolithic applications into separate services designed to perform one particular function. These services connect when they need to, but are otherwise siloed.

To see this in action, consider the following example. Before microservices, a typical application structure might have looked like this:

monolith-architecture-example-thriftly

Notice that every request a user makes of the application eventually goes to the same place, regardless of whether the request needs to access one function or several. This may work well in an application’s infancy, when scaling the application by copying it from one server to another and then another is enough to handle increased traffic. But as applications continue to grow, and especially as application traffic continues to increase, monolithic architecture becomes untenable. Scaling the application by copying it over wholesale to separate servers each time traffic increases becomes expensive, and load balancing can only account for so much.

In addition, it becomes difficult for developers to update your application, as each piece depends on the other. Any modification, including everything from framework overhauls to implementing a minor new feature, requires complete application knowledge and a significant investment in redeployment.

At this point, it might be worth breaking your monolith out into a series of microservices. Here’s what an application running on microservice infrastructure looks like:

microservices-architecture-thriftly

With microservices, requests are routed only to the particular pieces of an application that a user needs, splintering traffic and opening your app up for innovation. These services are deployed, scaled, and run separately but can connect when they need to, allowing you to build different subsets of your application that use (and carry traffic for) only a particular set of features.

How Microservices Allow Increased Innovation

While microservices solve monoliths’ traffic problem, their true benefit is the increased potential for innovation they provide. We talked earlier about how monolithic apps are difficult to update, since updating one part of the app could easily break another part or require other developers to finish their own updates before you can redeploy.

With microservices, you can assign one developer or team to each service and, since each of those services is deployed separately, that team can deliver updates and new features on demand. Breaking your monolith into manageable chunks of code allows developers to iterate quickly, allowing you to truly take advantage of agile development techniques. As users continue to demand more and more application updates, the increased iterative ability microservices provide will become even more of a boon.

At the same time, breaking your application into microservices allows both your own and outside developers to build on your app in innovative ways. By making your microservices easily accessible via APIs, you allow developers to easily mix and match your services to create new mobile applications, integrate their own app with pieces of yours, and create interesting connections that would not have been possible using monolithic architecture.

It’s worth noting that there are some drawbacks to microservice architecture. For example, splitting your application into several different parts can complicate overall app testing, and maintaining several disparate development teams requires increased cross-team communication. But for large applications, the innovative benefits of microservice architecture far exceed the potential drawbacks.

Conclusion

If you provide an enterprise application, microservice architecture is the way forward. Splitting your mammoth monolith into several smaller services allows you to better handle ever-increasing traffic and gives developers the room to truly iterate and innovate on your product. A good first step towards implementing microservice infrastructure is to look for pieces of your application that are easy to splinter off into their own service. Then, transform those pieces into APIs and set them up behind an API gateway. You can then experiment with iterating on and connecting to those services before diving wholesale into microservice architecture.

Need help creating fast, flexible APIs to use in microservice architecture?
Thriftly allows you to quickly split and call separate pieces of your application,
making microservice architecture easy.

New call-to-action

Topics: Microservices, Thriftly

Matt Ledger

Written by Matt Ledger

Matt is a former journalist and current blogger who loves technology and learning new things. He’s been writing in the software industry for nearly five years, having recently landed at Mertech.