The software products we use every day for both business and leisure are going through a quiet transition behind the scenes. A decade ago, it was the norm to build software as one, large, unified product — as a monolith. But in recent years, there has been more adoption of microservices, or microservice architecture, which constitutes a drastically different approach to building software.
What Are Microservices?
With a microservices, a type of service oriented architecture, software is built in smaller loosely coupled segments, rather than one large monolith. By segmenting key parts of a software, you can silo and decentralize a suite of software products that work independently, but they can also work in tandem when necessary. It also allows for smaller more focused teams that can work more independently. “Microservice architecture is an approach to developing a single application as a suite of small services, rather than as one large product,” he says. These individual services run in their own process and communicate with each other via lightweight mechanisms, often in the form of an HTTP resource API," says Jake Lumetta, CEO of Chicago based ButterCMS.
Microservice Pros and Cons
If you’re considering microservice architecture for your next project, here’s a summary of the pros and cons of microservices.
- Better Organization: Microservice architecture usually results in a more organized development environment. Everything has its place — but they keyword here is usually, as microservices can get just as messy as a monolith.
- Better Performance: Under the right circumstances, microservices can also have performance advantages depending on how they’re organized because it’s possible to isolate hot services and scale them independent of the rest of the app.
- Leaner, More Targeted Teams: With microservice architecture, a small team is often in charge of one or a small group of services, which can enhance agile and SCRUM development strategies.
- Easier to Scale: Microservices are highly scalable, and easy to use with containerization technology such as Docker. Plus, you can scale parts of your software product independently.
- Decoupled Services: Microservices are decoupled, which means they can be modified independently and can individually serve the purposes of different apps.
- Higher Overheads: Microservices typically take up their own virtual machines or containers, which can lead to higher overhead costs.
- Frequent Communication Needed: When apps get siloed, teams can sometimes follow suit. Thus, developers need to compensate by communicating frequently so that everybody understands the bigger picture.
The Difference Between Microservices and Monoliths
San Francisco, Calif.-based Dialpad’s Co-Founder and VP of Telephony, John Rector offers this befitting metaphor. “Microservices is an architecture design for building applications, particularly of the cloud/SaaS variety. I think the best way to understand the approach is by using an example, contrasting with the old monolithic approach,” Rector says.
He went on to describe how a startup phone service provider may launch using monolithic architecture.
“[Say an entrepreneur] in the phone service industry builds a prototype, where everything runs on his laptop: the database, the webserver, the telephony server — everything. VCs like the demo, so he takes the prototype and puts it on a cloud server. Eventually he signs a lot of customers, only to find out his server can handle just up to 1,000 users. So, he sets up nine more of those same servers, throws a load-balancer in front, and now he can handle 10,000 users. By this time he’s received some reliability complaints, so he sets up his servers with a hot standby for each one: if machine A crashes, there's a duplicate A' which is ready to start handling traffic. This is the old monolithic architecture: everything runs on one machine, and if you need to scale up, you duplicate the whole system with more machines,” he says.
The alternative, is a microservices architecture. In this new example, Rector explains how the entrepreneur resists the urge to lump everything on one laptop or server.
“The big difference [with the microservices approach] is that the database, the webserver and the telephony server talk to each other using APIs (basically, HTTP requests). At first they all run on the same machine, but when he adds more hardware, he pulls each type of server onto its own machine: one Dell box for the webserver, another for the database, and they talk to each other with HTTP,” Rector told CMSWire.
Eventually, Rector explains, the entrepreneur will gain too much traffic for that one webserver to handle, so he puts a load balancer just in front of the webserver, and adds more Dell boxes running that same webserver software. Then, “he can have 2 or 3 or 50 webservers handling his traffic, but the database still talks to it over exactly the same HTTP API. This is the microservices approach: little software components talk to each other via APIs, and you can build and scale them independently,” he says.
Microservices Examples From 3 Big Brands
An increasingly large amount of developers are choosing microservice architecture, including brands like Netflix, Facebook and Amazon. We also probed Rector, a former Google employee, about their take on microservice architecture: “[Building microservices] was 'the way we do things' at Google when I joined in 2006,” Rector says.
He went on to add, that the architecture is most useful for the sort of cloud, mobile and SaaS applications that are reaching into other industries now. "It's relatively less common in telephony companies, for example, since most predate the cloud,” he says. Here’s a closer look at how some of these big brands are leveraging microservices architecture to deliver experiences at scale.
Netflix, the movie and video streaming service, is one of many global brands that embraces microservices architecture. According to the Netflix Medium blog, the Netflix Content Platform Engineering team, “runs a number of business processes which are driven by asynchronous orchestration of tasks executing on microservices.”
Uber’s taxi-hailing app spans the globe, but it’s not built as one, gigantic monolith. Uber adopted microservice architecture and explained that, “this [microservice] design pattern enforces the development of small services dedicated to specific, well-encapsulated domain areas. Each service can be written in its own language or framework, and can have its own database or lack thereof.”
Coupon giant Groupon transitioned from monolithic architecture to microservices architecture back in late 2012. They migrated their U.S. web traffic from a monolithic Ruby on Rails application to a new Node.js stack with substantial results. After the move, Groupon reported that "page loads are significantly faster across the site [and] our development teams can develop and ship features faster and with fewer dependencies on other teams.”