Should you be using microservices in your app development?

While microservice application architecture dates back to 2011, enterprise IT tends to move relatively slowly when it comes to the adoption of new technologies. The concept and methodology has been refined in concert with the rise of cloud computing, and now microservices are a popular way to build, deploy, and most importantly scale applications.

Microservices can improve your agility, security, and resiliency, but they require a major adjustment to your development team’s workflow and the architecture of your application itself. Read on to learn the advantages of microservices and potential caveats for their use.

What is a microservice anyway?

Microservices evolved from service-oriented architecture and essentially break up different pieces of an application into individual modular services, each of which talks to one another and to the database(s), gateways, storage, and so forth.

Each service is tightly scoped and encapsulated, allowing it to be independently and constantly developed and helping to enable to concept of continuous delivery. With continuous delivery, small changes only require relevant services — one or a handful — to be rebuilt and redeployed. The services are each developed around their purpose or capability, like the UI systems, billing systems, or data processing.

Microservices can provide higher availability and more resilient applications due to their decentralized nature. A single failure therefore won’t necessarily bring down your entire app. You can even take down individual nodes or entire systems for maintenance while the remainder of your services run unaffected.

This also means testing and development cycles can be sped up, with new features or new applications potentially reaching the market faster as the entire app stack does not need to be overhauled and tested.

Scalability is a key advantage of microservices and part of why the 12 Factor App methodology for cloud-native applications makes microservices inherent to its design. Similarly to continuous development, each microservice can be individually scaled, rather than scaling or cloning the entire application.

The modularity of microservices goes beyond working on each component. Individual microservices can even use their own coding language, hardware, or add-on services while still working in concert with the rest of the overall application. You can also segregate sensitive data and impose stricter security protocol on individual components, leading to stronger security where it is most needed.

Downsides of microservices

Be sure to consider whether you have the agility and scalability built into your infrastructure to take advantage of microservices, as well as a skilled dev team well versed in DevOps. Microservices can be seriously disruptive and complex if your team isn’t prepared for them, leading to cost overruns and potentially scrapping entire apps to rebuild in a monolithic style.

Because there are more moving parts involved, the complex environment of a microservice-based application requires additional operational management effort. Without automation and collaboration channels and an ingrained DevOps culture, the sprawling nature of microservices could get away from your team.

You may also run into consistency issues – when a user interacts with the application, their node may not have received the latest updates or communications from other components. You must keep all microservice nodes in sync within the production environment.

Similarly, there can be latency stacks where one service must call one, or two, or three, or a dozen other services. Those remote calls can lead to serious delays as well as additional failure points.

Large enterprise IT environments probably have many monolith apps running at once, however, and are likely to have faced some of these downsides as they attempt to get those applications working in concert. Moving to microservices can actually help facilitate interaction between legacy infrastructure and a remote host, even if that remote host is monolithic.

The downsides of microservices, as illustrated by webcomic Turnoff.us.

How to get started with microservices

Do you really need to implement microservices? Are you struggling to scale or connect monolithic and legacy applications? The first step is to make sure your development team is ready for the shift in architecture as well as the move to agile / DevOps practices. Interview your data and storage admins to be sure they are ready to support microservices. Gather as much information on your existing environment as you can and take things slowly to start.

Begin by implementing Platform as a Service, containers, and/or virtual machine templates that enable the base architecture for microservices. Your system will have to be able to provision and scale on the fly. Add API gateways, monitoring systems, automation for deployment and testing. Design your system for maximum resiliency and plan for failure. Machine downtime and latency should be expected at some point.

If your team isn’t used to microservice style development, begin by using it only in new applications that require web-scale agility and scalability. If you don’t face those requirements, you probably don’t need microservices.