Microservices: The latest flavor

Microservices are the latest flavor of application architecture and development. Each of these small services (thus microservices) runs a unique process and is modular and independently deployable. They can then be combined through a relatively lightweight code set to perform whatever larger business function developers intend.

Microservices can been seen in contrast to traditional, monolithic architectures. For decades, applications were built as a single unit. The problem with this strategy is that the logic and code become interdependent. Any modifications can necessitate a myriad of other adjustments across what might be millions of lines of code, plus subsequent version control, testing, and roll-out.

With today’s “fail fast and fix it” business mindset, monolithic architecture often isn’t nimble enough to keep pace with market demands. Microservices can help and are becoming increasingly popular with IT pros responsible for creating enterprise and cloud-based applications.

A word that often comes up in relation to microservices is “containers.” Although related, containers and microservices are not the same thing. A microservice may run in a container, but it could also run as a virtual machine (VM). By the same token, a container needn’t be used for a microservice.

That being said, the two pair well together, as containers are a good way to develop and deploy microservices. Additionally, the tools and platforms designed to run containers are often well adapted to manage microservices-based applications.

We’ll take a quick look at both technologies in turn over the next few posts.

What are Microservices Again?

Martin Fowler is generally credited for defining microservices in a way that caught on in the industry. To quote his influential 2014 take on the topic:

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

Each microservice runs a distinct process, and it will probably manage its own database. It’s an inherently decentralized approach.

When would someone use them? Well, you might just want see Martin Fowler’s answer. Redhat also offers a hypothetical example of an umbrella company that goes something like this:

• The company wants salespeople to enter orders for umbrellas, so they create a microservice that does just that.
• They want to integrate a rainfall feature. They create a microservice that taps weather information so salespeople can encourage bigger orders in rainier places.
• They want an SMS alert feature when a sale is made.

Each of the requests is a relatively simple function, which would require few lines of code. They can then be tied together by a lightweight application that calls on the service when needed.

It’s important to realize that not every subroutine or component of a larger application is a microservice. For example, as this blog points out, Facebook has different groups of developers responsible for mobile, ads, chat, photos, and other elements that comprise what we would call “Facebook,” but that doesn’t make them microservices.

Microservices are being used more and more widely. Many of the big players, including Amazon, which experiences hundreds of millions of calls to given microservices from the mobile app, website, and elsewhere, made the transition to enable the flexibility their business models require.

Don’t You Mean SOA?

Ah, service-oriented architecture. SOA is an older term with many definitions. Microservices-oriented architecture probably fits many of them; it depends on who you ask. Many IT pros find it more helpful, however, to talk of microservices as a distinct strategy. As SmartBear explains:

“The typical SOA model, for example, usually has more dependent ESBs, with microservices using faster messaging mechanisms. SOA also focuses on imperative programming, whereas microservices architecture focuses on a responsive-actor programming style. Moreover, SOA models tend to have an outsized relational database, while microservices frequently use NoSQL or micro-SQL databases (which can be connected to conventional databases). But the real difference has to do with the architecture methods used to arrive at an integrated set of services in the first place.”

Like in so many other parts of IT, it can be the differences that matter most. Next up, we’ll talk about how microservices can make a difference in enterprise application development.