PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download.

Microservices

by James G. Barr

Copyright 2022, Faulkner Information Services. All
Rights Reserved.

Docid: 00021069

Publication Date: 2204

Report Type: TUTORIAL

Preview

Microservices is an approach to application development in which a large
application is built using a suite of small modular services. Each module
(or microservice) supports a specific business goal and communicates with
other modules through a simple, well-defined interface.

Report Contents:

• Executive Summary
• Microservices Basics
• SOA and Microservices
• Microservices and Security
• Recommendations
• References
• Web Links
• Related Reports

Executive Summary

[return to top of this
report]

Microservices is an approach to application development in which a large
application is built using a suite of small modular services. Each module
(or microservice) supports a specific business goal and communicates with
other modules through a simple, well-defined interface.¹

In a microservices architecture, each service runs a unique process and
usually manages its own database.

According to the US National Institute of Standards and Technology
(NIST), the notion of microservices is not new. The concept has been
explored using web services and in operating systems based on microkernels
such as:

• Mach microkernel
• GNU Hurd
• Web services architecture

The microservices approach, however, structures services according to
different criteria. Ideally, microservices:

• Should implement individual business (or mission) capabilities
• Have independent refresh cycles
• Be relatively easy to replace
• Be programming language agnostic

In short, each microservice should make economic and management sense on
its own.

At the same time, microservices may rely on one another, which supports
a well-defined form of modular development.²

As a new application development methodology, most experts recommend
experimenting with microservices on new applications, rather than trying
to retrofit established legacy apps.

Importantly, analyst Claus Jepsen reminds developers that “the
underlying microservices infrastructure doesn’t need to be built from
scratch. By using a microservices platform, application teams can
encapsulate a customer or business scenario in an application separate
from the enterprise system to meet customer demands today.”³

Offering a de facto proof of concept, one prominent adopter of
microservices is Amazon. According to analyst Michiel Mulders, “Amazon has
multiple services running:

• “One service accepts orders.
• “One service generates a list of recommended items to buy.
• “One is a simple authentication service.”⁴

Microservices Basics

[return to top of this
report]

Analyst Martin Fowler and James Lewis were instrumental in advancing the
concept of microservices, writing in a 2014 article:

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

In terms of classical programming constructs, microservices are somewhat
analogous to program subroutines, each performing a particular function
and each accessible through a specific interface. Unlike a subroutine,
however, which is integrated into a larger, monolithic program or
executable (a program which must be recompiled when the subroutine
changes), a microservice is built and maintained independently, enabling a
degree a autonomy highly desired by today’s cloud-oriented development
teams.

As Fowler and Lewis observe, “Monolithic applications can be successful,
but increasingly people are feeling frustrations with them – especially as
more applications are being deployed to the cloud. Change cycles are tied
together – a change made to a small part of the application, requires the
entire monolith to be rebuilt and deployed. Over time it’s often hard to
keep a good modular structure, making it harder to keep changes that ought
to only affect one module within that module. Scaling requires scaling of
the entire application rather than parts of it that require greater
resource.

“These frustrations have led to the microservice architectural style:
building applications as suites of services. As well as the fact that
services are independently deployable and scalable, each service also
provides a firm module boundary, even allowing for different services to
be written in different programming languages. They can also be managed by
different teams.”⁶

Monolithic Vs. Microservices

As illustrated by NIST, Figures 1 and 2 reveal in a simple flowchart form
the implementation of an online shopping application. Figure 1 represents
a classic monolithic architecture; Figure 2 represents a microservices
architecture.

Figure 1. Online Shopping Application – Monolithic Architecture

Source: NIST⁷

Figure 2. Online Shopping Application – Microservices Architecture

Source: NIST⁸

Advantages and Disadvantages

According to analyst Brandon Butler⁹, a microservices
architecture provides developers with both advantages and disadvantages,
as outlined in Table 1.

A “Growing Disillusionment”

While the advantages of a microservices architecture would seem to
objectively outweigh the disadvantages, Gartner reports a “growing
disillusionment” with microservices, as measured by a social media
analytics study.

As the firm’s Anne Thomas observes, “The two issues that trip up software
engineering teams are complexity and cultural disruption.

“The complexity comes up because microservices must be rigorously
independent to attain the architectural benefits, and developers must
adopt new patterns and abide by numerous architectural constraints to
ensure that the microservices are actually independent.

“As for the cultural disruption, success depends on changing team
structures, improving distributed computing skills, and using mature agile
and DevOps practices.”¹⁴

Amazon and Microsoft Support

To help ease the introduction of microservices, both Amazon [Amazon Web
Services (AWS)] and Microsoft [Microsoft Azure] offer clients facilities
for building and operating microservices architectures.

AWS App Mesh, for example, “makes it easy to monitor and control
microservices running on Amazon Web Services, [standardizing] how clients’
microservices communicate, giving [the clients] end-to-end visibility and
helping … ensure high-availability for [their] applications.”¹⁵

SOA and Microservices

[return to top of this
report]

For many, microservices represent the next generation implementation of
service oriented architecture (SOA).

A now standard development strategy, service oriented architecture is an
architectural framework that breaks down software elements and business
processes into standardized components that can be combined and reused
with minimal effort. This is accomplished via a layer of middleware that
enforces policies and rules for services, such as security, routing, and
workflow. In an SOA, all functions are defined as services; however, an
SOA only defines a service’s required parameters and results, not the
technology used to implement those results.

Dismissed by some developers as a more granular approach to SOA,
microservices, according to its advocates, offer:

• Greater scalability than SOA
• A faster, more flexible approach to managing changes¹⁶

Both elements are considered attractive – if not essential – in a cloud
computing environment.

Service oriented architecture and microservices share several
similarities and differences as highlighted in Table 2.

Source: NIST¹⁷

Microservices and Security

[return to top of this
report]

According to TechTarget, “Microservices architecture can
alleviate some security issues that arise with monolithic applications.
Microservices [simplify] security monitoring because the various parts of
an app are isolated. A security breach could happen in one section without
affecting other areas of the project.

“However, there are still challenges when securing microservices
applications, including:

• “More network areas are open to vulnerabilities.
• “Less overall consistency between app updates allows for more security
  breaches.
• “There’s a lack of control of third-party software.”¹⁸

To help mitigate any security risks, analyst Joydip Kanjilal recommends
“building security into [microservices] design” by pursuing a DevSecOps
software development model.¹⁹

DevSecOps refers to the union of development, security, and operations.
The intent is to integrate security design (such as incorporating
wide-scale data encryption) and security testing (like conducting
QA-administered functionality and performance exercises) into both
software development and operations. In effect, this builds security into
the entire software development lifecycle (SDLC).

Recommendations

[return to top of this
report]

Analyst Tom Hardin asserts that enterprises reluctant to employ
microservices will lose ground on their competitors.²⁰

This is not to suggest, however, that use of microservices should be
automatic. Analyst Tim Anderson reports that microservices expert Sam
Newman told a developer conference that “microservices should not be the
default choice.” Before decomposing a monolithic application into
microservices, developers should explore other options, such as:

• Locating and removing execution bottlenecks
• Transitioning the application to a modular structure
• Achieving scale by running multiple instances

In other words, “Do all the easy stuff first.”²¹

When pursuing a microservices architecture:

Create Small Teams to Build Microservices

Al Hilwa, program director for Application Development Software Research
at IDC, believes that microservice development teams should be small to
facilitate decision-making, accelerate innovation, and minimize costs.

“When building new systems, probably the key point is to recognize that a
single microservice should be built by a small team. The main pitch to an
exec is to build software incrementally using small teams, with each
building a coherent module with a published interface. The advantage is
that the independent modules can be evolved at a much faster pace
independently as long as the published [application programming interfaces
(APIs)] are managed in an organized way.”²²

Utilize Microservices for New Application Development

In addition to relying on small development teams, Hilwa suggests that
microservices initiatives should be limited, at least initially, to new
application development, rather than re-architecting an enterprise’s large
legacy apps.

“Traditional system architectures typically involve large, complex
database systems of record with elaborate normalized schemas. Factoring
such systems into smaller components with their own independent systems
requires a lot of database design work and effectively rewriting most of
the core application logic. This is generally cost- and time-prohibitive
in most cases.”²³

Fowler and Lewis present a possible hybrid approach to
microservices-oriented development. “One reasonable argument we’ve heard
is that you shouldn’t start with a microservices architecture. Instead
begin with a monolith, keep it modular, and split it into microservices
once the monolith becomes a problem. (Although this advice isn’t ideal,
since a good in-process interface is usually not a good service
interface.)”²⁴

Pursue a Holistic, Platform Approach to Microservices

MuleSoft recommends “a holistic, platform approach to microservices,
centered around API-led connectivity. Not only does API-led connectivity
create the integration component so crucial to the proper function of your
technology stack, it will allow developers inside and outside the central
IT team to create new solutions in a manageable, reusable, and governed
way, eliminating concerns of too many applications that the business
cannot control.”²⁵

Implement State-of-the-Art Microservices Security Strategies

According to NIST, there are many challenges to be addressed in the
development and deployment of a microservices-based application. Network
security, reliability, and latency are critical factors since every
transaction will involve the transmission of messages across a network.
Further, the presence of multiple microservices exposes a large attack
surface.²⁶

Begin by consulting NIST Special Publication 800-204: “Security
Strategies for Microservices-based Application Systems,” which is
available from the NIST website. Other NIST publications of note include:

• SP 800-204A: “Building Secure Microservices-based Applications Using
  Service-Mesh Architecture”
• SP 800-204B: “Attribute-based Access Control for Microservices-based
  Applications using a Service Mesh”
• SP 800-204C: “Implementation of DevSecOps for a Microservices-based
  Application with Service Mesh”

References

[return to top of this
report]

¹ “Microservices.” TechTarget. January 27, 2017.

² Paul E. Black, Lee Badger, Barbara Guttman, and Elizabeth
Fong. NISTIR 8151: “Dramatically Reducing Software Vulnerabilities.” US
National Institute of Standards and Technology. November 2016:13.

³ Claus Jepsen. “Enabling the Enterprise Shift to
Microservices.” Forbes. December 10, 2018.

⁴ Michiel Mulders. “Understanding Microservices and Their
Impact on Companies.” Plutora. February 4, 2020.

⁵ Martin Fowler and James Lewis. “Microservices.” Martin
Fowler (blog). March 25, 2014.

⁶ Ibid.

⁷ Ramaswamy Chandramouli. NIST Special Publication 800-204:
“Security Strategies for Microservices-based Application Systems.” US
National Institute of Standards and Technology. August 2019:32.

⁸ Ibid.

⁹ Brandon Butler. “What You Need to Know About Microservices.”
IDG Communications. November 9, 2016.

¹⁰ “Microservice Architecture – Introduction, Challenges &
Best Practices.” GeeksforGeeks. October 20, 2021

¹¹ Ibid.

¹² Michiel Mulders. “Understanding Microservices and Their Impact
on Companies.” Plutora. February 4, 2020.

¹³ Ibid.

¹⁴ Laura Starita. “Should Your Team Be Using Microservice
Architectures?” Gartner, Inc. August 20, 2021.

¹⁵ “Overview of Amazon Web Services.” Amazon Web Services,
Inc. August 5, 2021:61.

¹⁶ “Microservices.” TechTarget. January 27, 2017.

¹⁷ Anil Karmel, Ramaswamy Chandramouli, and Michaela Iorga.
Draft NIST Special Publication 800-180: “NIST Definition of Microservices,
Application Containers and System Virtual Machines.” US National Institute
of Standards and Technology. February 2016:2.

¹⁸ “Microservices.” TechTarget. January 27, 2017.

¹⁹ Joydip Kanjilal. “8 Fundamental Microservices Security
Best Pactices.” TechTarget. September 28, 2021.

²⁰ Tom Hardin. “Microservices.” G2 Crowd, Inc. 2018.

²¹ Tim Anderson. “Microservices Guru Warns Devs That Trendy
Architecture Shouldn’t Be the Default for Every App, but ‘A Last Resort’.”
The Register. March 4, 2020.

²² Rob Marvin. “Microservices: What They Are and Why Your
Business Should Care.” Ziff Davis, LLC. September 16, 2016.

²³ Ibid.

²⁴ Martin Fowler and James Lewis. “Microservices.” Martin
Fowler (blog). March 25, 2014.

²⁵ “Best Practices for Microservices.” MuleSoft, Inc.
2017:23.

²⁶ Ramaswamy Chandramouli. NIST Special Publication 800-204:
“Security Strategies for Microservices-Based Application Systems.” US
National Institute of Standards and Technology. August 2019:vi.

Web Links

[return to top of this
report]

• Amazon Web Services: http://aws.amazon.com/
• Microsoft: http://www.microsoft.com/
• MuleSoft: http://www.mulesoft.com/
• US National Institute of Standards and Technology: http://www.nist.gov/

About the Author

[return to top of this
report]

James G. Barr is a leading business continuity analyst
and business writer with more than 40 years’ IT experience. A member of
“Who’s Who in Finance and Industry,” Mr. Barr has designed, developed, and
deployed business continuity plans for a number of Fortune 500 firms. He
is the author of several books, including How to Succeed in Business
BY Really Trying, a member of Faulkner’s Advisory Panel, and a
senior editor for Faulkner’s Security Management Practices.
Mr. Barr can be reached via e-mail at jgbarr@faulkner.com.

[return to top of this
report]