A Brief Introduction to Microservices and Containers

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 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.




Add Comment

Selling Items Online: Key Platforms and Sellers Tips
10 Things You Didn’t Know About Slalom Consulting CEO Brad Jackson
Ready, Set, Be an Agent for Change!
10 Things You Didn’t Know about Insight CEO Ken Lamneck
The 10 Best Credit Card Strategies for Married Couples
How the End of Net Neutrality Could Affect Your Finances
How to Get Health Insurance if You Missed the Enrollment Deadline
The Best Ways to Recover from Overspending on Holidays
Voice Interfaces are Finding Their Way into Businesses
The Top 20 Scientific Breakthroughs in History
Ice-Diving Drones Embark on Risky Antarctic Mission: But Why?
Nonprofit Technology Trends for 2018, and Beyond
The Top Five Wellness Retreats in the United States
The Top 20 Presidential Vacation Spots
The Top Five Luxury Hotels in Tel Aviv, Israel
The Top Five Hotels for Visiting Botswana
A Closer Look at the 2018 KTM X-Bow GT4 Racer
The Porsche Mission E: Everything We Know So Far
20 Things You Didn’t Know about McLaren
SSC North America Teases Tuatara Supercar
10 Things You Didn’t Know About Coggiola Watches
A Closer Look at the Armin Strom Mirrored Force Resonance
A Closer Look at the Urwerk UR-210 Dubai Edition
Five Watches That Made Serious Buzz in 2017