What Are Microservices: An Easy Guide

As you’ve probably noticed, the term “Microservices” has been floating around in the software development industry for the last few years. While engineers are more than accustomed to this term, it still confuses many business owners due to the substantial lack of precise definition. All non-tech-savvy people are used to hear is that “Microservice Architecture” describes a more agile and faster way to design and develop software products as the sets of loosely-coupled services. We want to explore it a little bit deeper to help you navigate through this topic.

Quick introduction

Microservices architectural style means dividing an application into a suite of independently deployable fine-grained services. Microservices are technology agnostic. So you can build such services with pretty much any programming platform that allows you to operate within microservices ecosystems. However, the most commonly used languages in this field are Java, Go, Node.js, and .NET core. While a developer or an architect can start from here, for most CEOs, CTOs, and startup owners, this doesn’t say much.

The business people require crystal-clear details, that’s why we’re here explaining what microservices are and what they do. We won’t teach you how to develop a product rather present you with enough information on the specific common characteristics that microservices have in terms of organization around business capability, decentralized control, and automated deployment. Furthermore, we hope this material helps you to quickly decide if the microservices approach meets the goals of your project or company.

Software Development Lifecycle

It doesn’t matter if your project utilizes Waterfall or Agile development methodologies – it all starts with a software development lifecycle. During such a cycle, your team turns a project into an actual, released product. Since Agile is far more popular these days, let’s use it as a starting point for further discussion.

So, a typical Agile software development lifecycle consists of such stages as:

Analysis Phase/Requirements Gathering
Planning & Design
Development
Testing (Unit, regression, penetration, and so on)
Deploy & Release
Monitoring (User feedback)

If you’re following the Microservices architectural patterns, they significantly impact your product’s development lifecycle. Microservices affect the technology stack, the way you organize a team and its size, the development timeline, and the way your application goes into production. In a nutshell, microservices are software pieces, so they also follow your product’s software development lifecycle, with only some slight differences.

What Are Microservices? Part 1: Micro

Originally born in 2011, the term “Microservices” outlines a software development approach that tends to implement the best practices, principles, and architectural patterns for increasing the speed and efficiency of designing, developing, and managing complex software solutions at scale. Being technology agnostic, microservices present enormous engineering abilities on the most complicated projects as they do not require one single platform or programming language to be built. If your project uses numerous programming languages, you can be sure that you’ll find at least one among them that is suitable for creating microservices architecture. Let’s dive even deeper. The word Microservice itself consists of micro and services. The reasonable question would be – how big is one microservice? How many features should it include? The team of which size can build it? How many lines of code does it suppose to have? But there is no universal measure defining the ideal size of a single microservice. What is “big” or “small”? Who sets the benchmark? Nobody knows. The one thing we all know for sure, according to James Lewis and Martin Fowler, is that each microservice has to be designed to do one thing and do it well. Therefore, the “micro” part is about the scope of the service’s functionality itself, not the length of code or team size. Now let’s get down to a “service” part.

What Are Microservices? Part 2: Services

In Microservices architecture, each service is an independently deployable component/element of bounded code (engineers call it bounded context) built around a specific business capability. It also supports interoperability through message-based communication. Quite similar to Service-Oriented Architecture (SOA), yes. It brings to your product the same concepts of modularity and message-based communication that SOA follows.

How does it work? To create sophisticated enterprise software, you have to define the sub-domains of your primary business domain. Then you’ll be able to present each sub-domain as a separate microservice. For instance, you can split a large enterprise employee management application into a few smaller sub-domains – profile authorization, user management, communication portal, and so on.

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

James Lewis and Martin Fowler (2014)

James Lewis and Martin Fowler also wrote a book and various articles that list the common characteristics of Microservice architecture patterns without turning to a precise definition of the term.

Some of these characteristics are:

Componentization via smaller, independently deployable services
Services focus on business capabilities
Services are autonomously developed, messaging-enabled, and bounded by contexts
Microservices run independently, but they all rely on each other in the overall ecosystem
Decentralized governance system and data management
Automation – as much as possible
Products not projects are the end goal
Evolutionary Design
You can use different tech stack as long as it fits the project goals

Microservices’ Impact on the Development Lifecycle

So, when you manage to split a presumably monolithic app into smaller microservice components, you can concentrate on something smaller, more narrow-oriented. The smaller projects iterate much faster on all stages of the lifecycle, from requirements analysis to development and to release into production. Which significantly speeds up the product’s time to market.

Smaller projects also require a different way of team organization. Instead of trying to manage and connect several teams in different locations, you need only one small-sized squad, working closely together on the limited scope. Such a team will decompose your large app into small, highly-cohesive, autonomous, and loosely-coupled services that work together and communicate with each other efficiently, but will be deployed independently.

We’ve used to develop software ‘as one project results in one product or one app (one piece of software)’ at a time. This meant the longer lifecycles for complicated projects, where you could spend months or even years just gathering the requirements before the actual production. Microservices architecture, on the other hand, makes you more agile in all fields – with the developers, operational and QA teams, and other users.

Conclusions

Microservices are small, autonomously developed, independently deployable, self-contained pieces of business functionality that have own clear interfaces and focus on your business’ capability. Microservices are deployed in production at their own pace, on their own terms. The essential characteristic of this approach is that everything concentrates on being micro and bounded by context, while effectively exchanging messages to communicate within one ecosystem.

Microservices is the best choice when you need to solve the problem of a software system that is too big. Microservices architecture somewhat follows the Unix philosophy – do one thing and do it well. And here, unlike the monolithic architecture, a change of a single microservice within an app doesn’t require the redevelopment of the whole platform. Such industry giants as Amazon, Netflix, Twitter, eBay, PayPal, and others already benefit from moving onto a microservices architecture.