Microservice Architecture for the Enterprise

HOW TO TAKE A DESIGN-BASED APPROACH TO MICROSERVICE ARCHITECTURE

For product information please visit our website at: broadcom.com
Copyright © 2021 Broadcom. All Rights Reserved. Broadcom, the pulse logo, Connecting everything, Symantec, and the Symantec logo, are among the trademarks of
Broadcom. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.

THAT ADDRESSES CULTURE, ORGANIZATION, METHODOLOGY AND TECHNOLOGY.

BC-XXXXEN August 2021

1 1
 What are microservices?
For the uninitiated, a microservice is up of capability-aligned microservices.
defined as an independently deployable This definition comes from the book
component of bounded scope that Microservice Architecture, published
In the pages that follow, we’ll supports interoperability through by O’Reilly.
cover how your organization can message-based communication.
What does this mean for businesses?
improve availability and system But, it’s not just about individual Rather than building monolithic
safety while speeding up and microservices—it’s about how applications that require long
scaling software delivery using microservices work together. From this development cycles and big releases,
a microservice architecture. perspective, we look at “microservice organizations are creating applications
architecture”—a style of engineering out of multiple, lightweight microservices
highly automated, evolvable software that facilitate smaller, more frequent
systems made changes and independent scalability.

2
 Why microservices in
the enterprise?
Companies like Amazon and Netflix popularized the use of microservices, and other
pioneers—such as Gilt (now part of HBC Digital) and SoundCloud—use them to build
While such companies are digital
massive scalability and decrease time between releases.
first, large enterprises with
legacy systems to support can Netflix started using a service-oriented approach to software engineering that we now
also benefit from a microservice call microservices over 10 years ago. In a 2006 interview, Amazon CTO, Werner Vogels,
architecture. And though the explained the benefits:
challenges—such as monolithic
“We can scale our operation independently, maintain unparalleled
systems, legacy technology, skills
gaps and cultural issues—might system availability and introduce new services quickly without the need
be great, the rewards can be far for massive reconfiguration.”
greater.
Gilt uses microservices to lessen dependencies between teams, allowing the company
to get code more quickly into production. SoundCloud, after expanding as a company,
progressed from using agile to continuous delivery to microservices to improve lead and
delivery times that it was accustomed to in its start up days.

3
 What are the challenges?
From an enterprise perspective, much of what we’re dealing with when introducing
microservices and trying to get advantages from microservices is the inevitability of
software complexity. And software complexity is certainly a subject that’s been studied
much longer than we’ve been talking about the buzz term “microservices.” Software
The difference between these is complexity goes back almost to the origins of software engineering.
that you’ll never get rid of the
Fred Brooks describes two types of complexity in his paper “No Silver Bullet: Essence and
essential complexity. In fact, Accident in Software Engineering”:
software solutions are a great
way to try to deal with essential • Essential complexity—The complexity of the software’s functional scope and the problems
it solves (e.g., correlating and analyzing large amounts of data in real time). There are some
complexity. On the other
problems we are trying to solve with software that are inherently complex and we can’t do
hand, accidental complexity is anything about it.
something that we would hope
to reduce as much as possible. • Accidental complexity—The complexity of the software’s implementation details (e.g., the
languages, processes and messages used to do the work). This is the complexity we create
in trying to solve the problem.

4
 How do we overcome the
challenges of building an
enterprise microservice
architecture?
What we see with microservices
is now, instead of the developers
building their code and having
to merge it with a monolithic
application, they can break things So, how do we deal with essential complexity? There’s a reason domain-driven design
down and work on the individual has become resurgent with the microservices movement. Domain-driven design, at a
high level, is a very effective way of modeling the systems which then map nicely into
microservices, eliminating a lot of
microservice architectures.
the accidental complexity. Their
job gets simpler and they can This is possible because the topology of the implemented system closely resembles the
just focus on building a service. model of the system’s “essence.” In other words, there’s a close resemblance between a
model of the essential complexity of a system and a model of a microservice architecture.
It makes microservice architecture an intuitive way of solving these essential complexity
problems.

On the other hand, accidental complexity in a microservice architecture can be minimized

through automation and distribution via continuous delivery tooling, cloud native
platforms, containers and APIs.

5
A Design-Based Approach to
Microservice Architecture
When looking at how to approach the introduction of microservices to an enterprise, taking a design-based
approach is very helpful. This approach can be broken down into five different steps of design:

1 2 3 4 5
Outcome design System design Service design Foundation design Organizational
Look at your goals and Examine how you identify Once you have a picture The previous steps have design
ask, “Why are you doing the scope of the system of what your domain is been very technology- Look at the organization
this?” It’s not enough to that you’re going to and what all its services agnostic. So now, you itself—the people side.
say: “Everybody’s on the be architecting.This is are going to be, look at need to look at the How do you make sure
microservice bandwagon, about decomposing the the design of all those underlying capabilities— that the culture and
let’s jump on too.” It’s domain. individual services to the technological tools methodologies you’re
important that you make sure they’re built in and platforms that using, and even the
understand the value the right way, so that they will be required to build organizational structure,
points you’re going after. can evolve and interact out the system best- match what you hope
in the correct way for the suited to the needs of to achieve?
system you want to build. your organization.

We’ll dig into these a little deeper in the pages that follow.
6
 1 Outcome Design: Define Goals
and Principles
STEP 1 is about defining measurable goals and developing associated principles. First, you
There are some key types of want to define where you are today and where you want to be. Ask:
microservice goals such as • How can we reduce our release cycles?
agility, composability, runtime
• How can we introduce more microservices?
and scalability. Out of these,
you can decide what are the • How can we retire or depreciate unused services that may be out there?
principles you want to use to Naturally, not everything can be concrete and measurable. Sometimes, it’s important
incent these behaviors. to define higher-level principles about the way things should be done to incent good
behavior. Defining these principles helps you build a common cause, which is very
important. We want this so that we can have alignment without having to have a lot of
coordination across the organization. So, these are constraints to help you with those
hard-to-measure goals.

7
 2 System Design: Choose an
Initial Scope Then Decompose
the Domain
Once you have the bounded
contexts, you can start to define Once you’ve defined your goals and principles, look at the best place to start working
services for your solution within. towards achieving them. In STEP 2, you want to first identify the target domain and
And once you’ve got a good start breaking that down into sub-domains in a bounded context—which are linguistic
map, you can start enumerating boundaries where everyone speaks the language. Then, start to define the interaction
between those bounded contexts within your domain.
the services that you want in
the organization. This is a process that’s helped through visual exercise. One approach is to use the domain-
driven design “Context Mapping” approach that breaks down a domain into its sub-
domains and bounded contexts. Since the accepted approach to understanding a system
is to focus on the relationship between its components, you need not go deeper than the
context map if you want a basic representation of a microservice system.

This context could be the decomposition of a monolithic application or the service interactions
of an initiative. The only way to coherently build a large organization’s system of microservices
is to do so piece by piece, context by context. Along the way, these contexts can be combined
to project the complete picture, if such a picture is even needed.

Related reading:
Designing a System of Microservices
8
 CONSUMER TASKS INTERFACE DEPENDENCIES

Consumer Queries Commands Event Event Service

• Task Subscriptions Publications • Task

QUALITIES LOGIC/RULES DATA

DESCRIPTION

3 Service Design: Design the

Services
In STEP 3, you want to take an outside-in approach. Start with:
You can expect the stages
• What are the interactions between services?
of system design and service
design to be quite iterative at • Who is going to want to consume my services and what are they going to consume?
first until things settle down and • What other services am I going to be dependent on?
the boundaries become clear. Then, you start to think about other external concerns like the quality of service, SLAs,
But, it’s important to remember the security situation and versioning—all the things that are going to affect the consuming
that the system design is going services as well as the services you depend on. These are going to be the most important
to be enterprise-wide at the factors in designing the service.
system maintainer level and the
From there, you should start to investigate the logic, the rules and finally, the data you
service design is going to be need. It’s a common mistake to start with the data and work outwards. That’s dangerous
much closer to the individual and it leads to tight coupling.
developers and the small
teams that will be building the
individual microservices.
Related reading:
The Microservice Design Canvas

9
 3 Service Design (cont’d): The
Importance of APIs
If you didn’t know anything about a system and you were only to look at the API definition
Another thing to think about for the services that live within the system, you would get a pretty good idea of what
when you’re designing the functional capability is in that system to the point where you could have business and
technical conversations, bridging that gap using the API definitions.
services is to dig into the APIs
because they’re extremely In addition, APIs are:
helpful and have a lot of value
• A living part of the system, unlike some documentation that lives outside the system and
when it comes to microservices. might be stale.
APIs provide a technological way
• A good way of bridging to service modelling through domain-driven design. As you go from
of expressing the capabilities of
domain to bounded context to the context map, think about your APIs as a helpful way to
your system.
map your system. It provides a way to understand the overall system of microservices, and it
contains the appropriate level of information so you can connect the dots.
• A place where you can enforce security policies, provide composition of services
for aggregation, universally monitor service levels and document services through
API definition languages, like OpenAPI. This is important because when you have a
microservice, you can no longer rely on something like an app server to provide all the
normalized information, such as logging and security.

10
 4 Foundation Design: Identify
Needed Capabilities
Now it’s time to think about the required capabilities.
These could be technical capabilities or they could be
Mediation standards and guidelines you want to abide by. But, be
• Routing
Development • Service Discovery Security careful not to go so deep as to be restrictive to your
• Design Tools • Rate Limiting • Access Control
• Test Tools • Orchestration • Identity teams.
• API Discovery • Transcoding Management
• Container Creation • PKI To assist, use this capability model that outlines some of the
• IDEs main categories you may want to consider. Not to say every
Microservices microservice environment needs all these capabilities, but you
can use the model to think about the important capabilities you
need in your system.

If you’re focused on reducing development time, you may spend

Monitoring more time looking at design and development capabilities.
Deployment
• Container Orchestration • Logging Whereas if your focus is more on scalability and runtime
Hosting • Correlation
• CD Pipelines
• Container Hosting • Analytics
efficiency, you may be looking more deeply into security and
• Repositories
• IaaS/PaaS/FaaS • Anomaly Detection mediation and platform capabilities.
• Release Management • Data Management • Event Execution
• Storage

11
 5 Organizational Design: Align
the Organization, Culture
and Architecture
Now we get into the human side of
microservices: the organizational, On the methodological side, you’ll want to adopt agile practices. You want to be able to
cultural and methodological automate everything.
capabilities. When introducing
On the organizational side, you want to break down silos into teams that are cross-
something like continuous delivery,
functional—product owners and developers, and even business leads in the same team—so
it’s more than just a technology you can be more aligned with the business outcomes. There will still be the need for teams
tool introduction. It’s the whole that go across the organization and support those cross-functional teams, but rather than
process change that impacts dictating to those teams, it’s better to take a more incentive-based approach to teams
the way people do things. And where you’re enabling those teams and providing tools and services to them, to let them
it’s important to align your team function and fly on their own.
structure so you have cross- Finally, on the cultural side, if you have digital teams that are counterpoint to their IT
functional teams that can own teams, it’s time for a change. While change can be viewed as bad, which slows down
their services end-to-end. Also, releases, try thinking about becoming efficient at change and embracing it, so that you’re
you want to look at how you can doing more frequent, smaller changes, which are going to have less impact on the system
change culture. and are much easier to roll back if things do go wrong.

12
Move to Microservices and Accelerate
Your Digital Transformation
You want to deliver new innovations, release apps faster and take advantage of new opportunities, but legacy
applications and infrastructure are holding you back. Transition to a modern architecture by decomposing
monolithic applications into agile microservices—independently created, managed and scaled. Your business will
be able to act more quickly and developers will love the easy access to APIs that give them the freedom to focus
on customer experience.
Start With Microservice Strategy and Design A hardened API management solution is crucial in a microservices
architecture to manage domain-driven microservices and REST APIs
The API Academy, an educational site where you can learn about
as application backends, providing access to orchestrated data and
API strategy and design, as well as microservice architecture and
functionality from both new and legacy systems
the education enterprise architects need to build better APIs and
microservices, improve software delivery, and execute on broader
digital strategies. Orchestrate and Secure Microservices
The award-winning API Gateway and Microgateway enable
READ API ACADEMY MICROSERVICE BEST PRACTICES
architects and developers to manage discovery, orchestration
and transformation in a broad array of microservices deployment
Securing Microservices patterns. They are containerized and deployable in Docker® and
Many enterprises have started converting their monolithic and/or you’ll also be able to apply best-in-class OAuth security and
legacy applications into microservices to achieve: authentication to protect your business.

• Speed to market LEARN MORE ABOUT LAYER7 GATEWAYS

• Improve evolvability
• Scalability
• Enhance composability

13
Application
Architecture
Built for
Change
LEARN HOW LAYER7 CAN HELP YOU WITH YOUR
MICROSERVICE ARCHITECTURE.
PLEASE VISIT THE LAYER7 PRODUCT PAGE

For product information please visit our website at: broadcom.com

Copyright © 2021 Broadcom. All Rights Reserved. Broadcom, the pulse logo, Connecting everything, Symantec, and the Symantec logo, are among the trademarks of
Broadcom. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.
BC-XXXXEN August 2021

14 14