Sometimes it pays to be small, fast, and agile; it certainly did in the story of David when he confronted Goliath. As David showed, agility and speed is a winning combination, and it’s a particularly important combination in business and technology today. We’ve seen the shift to smaller, faster, and more agile processors, computers, and components for years. But processors and hardware components aren’t the only technologies getting smaller, faster, and more agile. Meet microservices, AKA the microservice architecture—the David to traditional, Goliath-esque, monolithic application development.
The microservices approach to app development isn’t entirely new. However, it is becoming more common—in part, thanks to the growing popularity of the cloud and containers.
So, just what is the microservice architecture? It’s an application development approach. Instead of developing an entire application as one big codebase, which might take months and require new hardware, microservices breaks an application down into small, modular services. Each service is an individual codebase that performs a specific process. Those processes all work together to deliver the actual application.
A few of the better-known enterprises that have migrated to a microservices approach include Amazon, eBay, Groupon, Netflix, and Uber.
How Microservices Form a Complete Application
The most common mechanisms to get individual microservices to work as parts of an application are API endpoints (usually REST APIs accessed via HTTP) or a messaging broker, such as RabbitMQ. The only dependency one microservice typically has on another is that the API used for each microservice be compatible or that each microservice use the same message broker.
Another tool is needed to orchestrate different microservices to run the applications. Containers, such as Docker or Kurbernetes, can be used. A cluster manager, such as Apache Mesos can be used. Or an orchestration solution, such as OpenStack Heat, can be used. Microsoft Azure Service Fabric provides an option for managing microservices within an Azure implementation.
The Benefits of Microservices
Where traditional application development follows the waterfall model of sequential, non-iterative development, microservices can follow an agile development methodology. That’s because each microservice can be developed separately, but simultaneously, with each team or developer solving a small piece of the overall puzzle instead of the entire puzzle. Microservices can even be written in different programming languages and can use different storage methods. Similarly, rather than upgrading the entire app, the development team might only have to upgrade an individual module. And to scale an app, only the microservice that needs scaling has to be distributed and replicated, rather than the entire application.
Individual microservices can also be used for, or shared with, other apps. This can help increase return on investment (ROI) and make it faster to develop apps that make use of existing microservices. Microservices are often available as existing open-source modules, so dev teams don’t have to develop from the ground up. They can simply customize an existing open-source microservice, or they can use it as is.
Once developed, microservices are deployed separately. This can increase an application’s resilience. If one microservice fails, a new one can be deployed quickly or automatically without affecting the rest of the app. And because microservices are small, replicating them is fast, easy, and less processor intensive than replicating complete applications.
Is There a Downside to Microservices?
While microservices offer many advantages, they are not meant for all apps or for all organizations. Adopting a microservices approach requires the skill, commitment, know-how, and collaboration to change the way an organization thinks and operates. Someone has to have a vision of how all the modules work together to create an end goal. Teams have to collaborate in order to ensure overall application effectiveness. Services have to be developed with failure as a possibility; if a service fails, what will happen, and how will it cascade to the rest of the services? Preferably, a service should be developed so its failure does not cascade to other services, but that takes planning. It also takes continuous real-time monitoring, which needs to be built into the service and overall application.
The use of APIs also requires that remote calls be made, which is more expensive than in-process calls. To compensate, remote APIs have to be coarser-grained. Ironically, courser grained APIs are the opposite of microservices, because they use larger components with fewer lines of code, which can be awkward to use and harder to modify. Again, planning is the key; it’s not that the planning is more intensive than for traditional, monolithic application development, it just falls into different areas.
What’s Next for Microservices?
Whether or not microservices will completely replace traditional, monolithic application development remains a mystery. Chances are that it won’t anytime soon. The disadvantages pose barriers to smaller companies with smaller teams. The paradigm shift is also a barrier for some individuals, teams, and organizations.
For those willing and able to adapt, microservices is an exciting frontier—one we’ll be watching. We hope you’ll watch with us. Stay in the conversation by following us and our growing communities on LinkedIn and Twitter.