What is a Microservice? What You Need to Know

Microservices are small, independently-running applications that perform a single function for a larger application or IT infrastructure. By loosely connecting a number of them together, developers create a pluggable architecture that facilitates the process of updating, upgrading, and scaling the application in response to changing requirements.

Compared to a traditional monolithic application, microservices-based applications offer enterprises greater agility and scalability when they need to upgrade their products or business systems to stay competitive. 

If you’re considering this architectural style for your enterprise – or if you just want to learn more about microservices – this introductory guide will teach you the following:

Generate a full-featured,documented, and secure REST API in minutes.

Sign up for our free 14 day hosted trial to learn how.

Generate your No Code REST API now

What Are Microservices?

There’s no better way to introduce microservices than by quoting James Lewes and Martin Fowler, who helped to popularize this architectural style with their authoritative piece, “Microservices”:

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

In Other Words...

Because the individual microservices that comprise a microservices architecture run autonomously, the process of adding and removing functionality within the architecture is painless compared to a traditional monolithic application where the services that comprise the monolith are difficult to untangle. 

At first, monolithic application developers can bolt new chunks of code on top of existing code, but in many cases, the monolith will eventually grow too complex to upgrade without refactoring the entire program. As a part of the refactoring process, developers may choose to break the monolith into its component functions (microservices) and build a microservices application. By redesigning the monolith as a “cluster” of loosely-connected, modular microservices, developers can avoid challenges and delays when upgrading the application in the future. 

Related Reading: Microservices vs. Web Services

Features of Microservices

Microservices generally have the following attributes:

• A microservices architecture exists as a cluster of loosely-connected, pluggable, and autonomous components. 

• Each microservice carries out a well-defined function – or satisfies a specific business need – for the larger application or IT infrastructure.

• Each one runs autonomously without dependency or knowledge of the other microservices or the larger application. 

• Because they run independently and are only loosely connected to the architecture, developers can add, remove, or upgrade them more quickly and easily without affecting the larger ecosystem.

• The microservices that comprise an application can be written in different programming languages and run on different platforms. Microservices could be running in the cloud, on-premises, or a mix of both. 

• Using an advanced iPaaS tool like DreamFactory, enterprises can add them to any IT infrastructure. 

• Cloud-based SaaS microservices can update automatically after rollout so businesses immediately benefit from the latest versions and security updates. 

In this section, we’ve answered frequently asked questions about how microservices work. This FAQ should give you a general understanding without getting too technical: 

1. How do they achieve independent operation? 

They consist of more than just code modules and libraries. They contain everything they need to run, and nothing more, packaged as a single, autonomous unit of execution. 

2. Are they “aware” of the other microservices? 

Microservices don’t generally know about or acknowledge the existence of the other microservices that make up the application.

3. How do they connect and communicate? 

They integrate with other microservices and applications through language and platform-agnostic APIs (Application Programming Interfaces). 

4. How do APIs work with these? 

You can expose APIs for microservices as REST endpoints, WebHooks, or invoke them via lightweight messaging protocols like RabbitMQ. The most common approach involves an HTTP/REST API with JSON. 

5. Are REST API connections stable for microservices? 

The relative decoupling of microservices data connections reduces the chances of a single service causing a failure cascade that interferes with the operation of the entire system. Loose connections help avoid synchronous and blocking-calls from disrupting system performance.

6. Where do you run them? 

Most developers agree that containerized environments are ideal for running microservices. While it’s possible to run microservices on a virtual machine, containers serve as a lighter-weight, faster, and more cost-effective way to virtualize a runtime environment for microservices.

Here’s how we explained this in the guide, “What Are Containerized Microservices”:

“Containers achieve operating system virtualization by “containing” only what’s required by an application for autonomous operation – executables, code, libraries, and files – then packaging it as a single unit of execution. From the perspective of the containerized microservice, it has its own file system, RAM, CPU, storage, and access to specified system resources. It doesn’t even know it’s in a container."

“Integration occurs by answering calls through a kernel or container orchestration tool.”

Most developers build these on Linux using Docker. Other tools for containers include Mesos Containerizer, containerd, LXC Linux Containers, and OpenVZ. 

How do you manage and control resources for different ones? 

When running a container-based microservices architecture, developers use container orchestration tools to manage and control the distribution of server resources to different containers based on the needs of each of them. 

Since the resource needs of fluctuate, container orchestration involves setting limits and triggers that automate the distribution of resources according to changing load requirements. Kubernetes is the most popular tool for container orchestration. Other popular container orchestration tools include Docker Swarm and Apache Mesos.

Use Cases

Here are some common use cases

Break Up Monolithic Applications with Microservices 

A monolithic application contains all of the code for each of the functions and services it performs. This isn’t a problem in the beginning, but as developers continue adding new functions on top of existing ones, the monolith can become an interdependent mess of spaghetti code. By dismantling the monolith can allow enterprises to increase their agility to implement upgrades faster and easier in the future.

Gradually Transform Monolithic Applications Without Risking Business Operations

Divvying up a monolithic application into its component microservices doesn’t have to happen all at once. Many enterprises choose to slowly re-platform their legacy applications by converting one function at a time into an independently-running microservice. This allows for a gradual transformation that doesn’t interrupt business operations or require a large upfront investment.

Quickly Add Business Intelligence, Forecasting, Machine Learning Analytics, AI Analytics, and Other Services to an IT Infrastructure

Many software as a service (SaaS) providers offer business intelligence, forecasting, analytics, and other services as microservices. These independently-running microservices pull information from your business system, apply ML and AI algorithms, and return valuable business intelligence insights. Other “add-on” ones like this include encryption and authentication services, communication services, and more. 

Build, Distribute, and Repurpose SaaS Apps

SaaS providers can use these to build brandable apps that organizations can quickly incorporate into their offerings. These could include microservices for flight search services, payment services, notification services, customer profile services, and more. Developers can then repurpose these across different channels. 

Rapidly Develop and Deploy a Minimum Value Product (MVP) 

Startups and development teams can zero in on the development of a Minimum Value Product (MVP) as a microservice that performs a valuable and specific function. They can offer this MVP as an add-on to other microservices architectures, or quickly create a microservices application around the MVP by adding pre-built microservices. This empowers development teams and startups to rapidly innovate new products and services in response to market demand. 

When Time to Market and Cost Savings Are Essential 

Development teams face stiff competition when bidding for application development jobs. By proposing a microservices architecture, development teams can offer more competitive deadlines and pricing. They can also provide prototypes more quickly to secure a contract. Also, enterprises may choose this architectural style when they need a rapid turnaround to stay competitive in their industries.

You’re Building an IoT Network

Microservices are ideal for creating an internet-of-things network that requires the integration of thousands – or millions – of IoT endpoints. IoT networks require massive horizontal scalability and large-volume data processing, something that only a cloud-based server and cloud-based microservices model is capable of handling.  

Pros and Cons of Microservices 

This section reviews the pros and cons of the microservices architectural style.

Pros of Microservices

Easy to Scale:

Since they run independently, developers can focus on scaling only the microservices that need it.

Platform and language agnostic:

Developers are free to program microservices in virtually any language and run them on any platform, then use an iPaaS (Integration Platform as a Service) tool to connect them. So, this allows developers to choose the most appropriate languages and platforms that match the needs of their team.

Improved application stability:

The failure of one is less likely to cause a cascading system failure. Even when microservices invoke other services synchronously, developers can stop failure cascades by implementing features like “circuit breaker” to prevent the calling service from using up system resources while waiting for an unresponsive service.

Better security and compliance:

Microservices only expose the data they need to share. This empowers developers to securely control access to financial, health, accounting, and other private information – which facilitates the process of complying with HIPAA, GDPR, and other standards.

Easier to organize development teams:

When building a microservices architecture, managers can divide the development of each microservice into smaller, more manageable chunks – to be completed by smaller, more manageable teams. These teams don’t have to wait for the other teams to finish a piece of code, and there is less worry about coding conflicts. Managers can also outsource the development of different microservices externally, or coopt prebuilt SaaS microservices to complete their applications. 

Faster, more flexible product development cycles:

The microservices architecture facilitates and speeds up the CI/CD/CD (continuous integration/continuous delivery/ continuous deployment) development cycle. This means that you can launch or deliver an application or individual microservice as soon as it offers use-value, and continue developing the application to roll out additional functions, services, and security updates over time. If the microservice is a cloud-based SaaS, developers can automatically update the application for all users as soon as new versions are available. 

Improved business agility:

They give enterprises more agility to experiment with different services and features without incurring significant business risks or exorbitant development costs.

Future-proof:

Development teams can prevent these applications from becoming obsolete by keeping them in a state of constant innovation. They can continually roll out updates without interrupting application performance. 

A DevOps-friendly architecture:

Since application tweaks and upgrades happen faster and easier, the microservices model supports a DevOps-friendly philosophy. Users offer feedback and requests, and quickly see their feedback implemented in the next upgrade.

Cons of Microservices

Connecting and integrating can be tedious:

Microservices rely on messaging and APIs to integrate their data with each other. Hand-coding APIs for each microservice can be tedious and costly. Fortunately, advanced iPaaS solutions like DreamFactory include automatic API generation features to create REST API from any database – in many cases turning an expensive, three-week coding job into a point-and-click process that developers can finish in minutes.

The challenge of refactoring a monolithic application:

Successfully dismantling and refactoring a monolithic application without affecting its external operation isn’t easy. Developers need to fully understand and identify all of the application’s components. They also need to realize the relationships that exist between them, how they operate, and how users interact with them. Developers and engineers also need to collaborate closely with users. This will ensure that any interface changes do not negatively impact application functionality. Without strict adherence to the DevOps or CI/CD/CD philosophy of application development, refactoring to microservices could end in failure.  

The challenge of deploying all microservices at once:

Dividing a monolithic application into its component parts and redesigning the application as a cluster of loosely connected microservices means that you’re dealing with a lot of different moving parts. Some of these parts will take longer to finalize than others. This makes it difficult to deploy all of them at the same time. This issue can become more serious when they are written in different languages and running on different platforms. 

Latency challenges require constant monitoring and tweaking:

Development teams need to keep a close eye on latency issues. They can do this by strategically controlling the distribution of system resources among the different microservices. This requires strategic container orchestration and workload placement, and some teams don’t have the necessary skills for this.

Examples of Microservices in the Real World

Here are two real world examples: 

Netflix

Netflix began the multi-year process of dismantling its monolithic application system in 2009 – before the term “microservices” had come to exist. After experiencing service outages caused by scaling challenges, Netflix started running its internal movie-coding system as an independent microservice on Amazon AWS cloud servers. 

Due to this, Netflix spent the next two years moving its customer-facing services to Amazon AWS.  Eventually they completed its microservices transition in 2012. The Netflix that customers know today is a platform comprised of hundreds of loosely connected microservices running on cloud servers.

eBay

eBay adopted this style of architecture in 2011 after facing tremendous scaling challenges and growth hurdles. At the time, the ecommerce website boasted 97 million active users, 75 billion daily database calls, 4 billion daily page views, and 250 billion daily search queries. Consequently, in order to handle these increasing demands on its servers – and continue rolling out quality, cutting-edge features – eBay diced up its monolithic application structure into a suite of connected microservices. 

Therefore, by dividing its functionality into a search engine and separately running applications and databases, eBay was able to accelerate its product development cycle. They were also able to increase developer productivity, and achieve a faster time to market. All while keeping its platform stable. 

Discover more examples of microservices.

Are They Right For Me?

Finally, you don’t have to break down your monolithic application if your current system operates smoothly and you’re not facing scaling challenges. However, if you want any of the following, you could be a good candidate:

• Overcome growing pains and scaling difficulties: Your monolithic application has become too inflexible to update. You’re facing scaling, system outages, and you want to bring your applications or IT infrastructure into the age of microservices and cloud computing.

• Faster time to market: You want to develop and release applications, updates, and new application features faster for more competitiveness in response to new business opportunities and challenges. 

• Business intelligence, ML, and AI: You need to integrate advanced business intelligence solutions for deeper, more competitive business insights, reporting, and analytics.

• IoT networks: You need to build an IoT network and your current infrastructure can’t offer the required horizontal scalability and can’t handle the massive data processing burden. 

Generate a full-featured,documented, and secure REST API in minutes.

Sign up for our free 14 day hosted trial to learn how.

Generate your No Code REST API now

Start Building Applications with DreamFactory Now!

Do you want to build a similar architecture? The DreamFactory iPaaS is a powerful, user-friendly Integration Platform as a Service platform that will rapidly connect and integrate these into your applications and IT infrastructures.

Related Articles:

What Are Containerized Microservices?, ESB vs Microservices: Understanding Key Differences, Designing Web-Scale Workloads with Microservices, MicroservicesDesigning Web-Scale Workloads with Microservices, Microservices Webinar Recap