MICROSERVICES: THE

FOUNDATION OF TOMORROW’S
ENTERPRISE APPLICATIONS
June 2020

COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.

 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

TABLE OF CONTENTS

3 Microservices 101: A guide to micros-

ervice architecture
6 Survey: Microservices worth the hype
8 How to plan a microservices
implementation
11 SOA versus microservices:
How are they different?
14 Best practices for securing
microservices
18 Australian neobank Xinja is mastering
integration through microservices
21 8 ways to make sure you really need
microservices
23 8 speed bumps that may slow down the
microservices and container express
26 How to avoid turning microservices into
distributed spaghetti code

2
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

MICROSERVICES 101: A GUIDE TO MICROSERVICE

ARCHITECTURE
Microservices have revolutionized how technology is delivered and used at large and
small companies. Here’s an overview on how a microservice architecture can be useful
to your organization.
BY: PATRICK GRAY/TECHREPUBLIC CONTRIBUTOR

The idea behind microservices and a microservices archi-

tecture is relatively simple: Hide all the complexities of
hardware, operating systems, and different development
toolkits behind a standard ‘service’ that is available on a
network.

Perhaps the simplest way to illustrate this is with

an example. If you click this link, you’ll access
Zippopotamus, an open project microservice that
provides information about US Zip Codes (roughly
equivalent to postal codes outside the United States). Like most microservices, the result is returned over an
application programming interface (API) in a standard format called JavaScript Object Notation (JSON) that’s
relatively easy for humans and various programming languages to interpret. What’s interesting is that you don’t
need to know anything about how this individual microservice works. It could be running on a massive super-
computer, or a room full of people who furiously open books and quickly type results; all that complexity is
hidden, and irrelevant to the person or program using the microservice.

If you consider the implication of this, what technical folks call an ‘abstraction layer’, the power of micro-
services quickly becomes apparent. If the providers of this microservice completely change the hardware,
programming language, or physical location of their data center, the user of that service is completely
unaffected as long as it continues to return the expected results in the same format. For an internal software
application, you no longer have to worry about the painstaking and expensive work of rewriting interfaces and
complex connections between systems if they are delivered by microservices. If you have a set of standardized
order management microservices, it doesn’t matter if your order management infrastructure is on a mainframe
running a COBOL application on Monday and a modern ERP system on Tuesday: the microservice should still
deliver the same results, and that change will be seamless to any other application that uses that service.

3
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

HOW TO TAKE A MICROSERVICES APPROACH TO

APPLICATION DEVELOPMENT
Microservices can be leveraged either as a consumer, or a provider. In the zip code microservice example
above, you became a consumer of that service by clicking the link and seeing the response data. Zippopotam.us
is the provider of the service and maintains the infrastructure that delivered the zip code information, and also
publishes documentation on how to use the microservice.

Consuming microservices is probably the easiest

way start using them in your organization’s software
For an internal software application,
architecture, as there are thousands available that
you no longer have to worry about can do anything from delivering random dad jokes,
the painstaking and expensive work to providing the location of nearby hospitals, to
of rewriting interfaces and complex tracking packages. Most modern consumer appli-
connections between systems if cations, and increasingly business applications as
they are delivered by microservices. well, are little more than a user interface and some
high-level logic that manages the interaction among
multiple microservices to accomplish a task. Many
of these different services require registration or ‘keys’, and some require payment past a certain point, but the
costs are usually tiny versus building and maintaining your own code, and the ‘free tier’ are often more than
sufficient for a software developer to experiment and learn.

As your developer teams increase their understanding of consuming and building microservices, they’ll start to
identify key services that your company can deliver, either internally or externally. For example, you might create
an internal microservice that provides customer information that can be used by your call center, shipping applica-
tions, and customer support teams. You might consider a public microservice that provides product information,
order status, or other functionality that allows third parties to use your products or services in applications they
create, or lets partners easily connect with your back-end infrastructure quickly and easily.

Integration tools like MuleSoft, Boomi, Jitterbit, or other tools often called ‘ESBs’ (Enterprise Service Buses)
can help speed up the process of creating microservices for your systems.

AVOID THESE COMMON MISTAKES WHEN USING A

MICROSERVICES APPROACH TO SOFTWARE DEVELOPMENT
Perhaps the biggest pitfall of microservices is forgetting about the ‘micro’ part of the equation. It can be
tempting to create an individual service that performs dozens of tasks and acts more as a handoff between

4
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

legacy systems than a service that performs a discrete task. When you create these ‘monsterservices’ they’re
generally only useful in a limited number of applications, versus small, generalized services that can be used in
dozens of places.

If you must create a complex, multi-stage service, start by creating simple services that you can combine.
There’s no shame in an individual service that calls multiple services to perform its job, and by creating smaller
building blocks, you’ll ultimately have more reusable and scalable options in the long run.

The other common pitfall is creating services that are designed for a single application. For example, if I need
a tracking number for an order, it might be tempting to create an Order Tracking Number microservice that
takes in an order number and returns the tracking number. Better to create an Order Data microservice that
provides general information about the order, including the tracking number, that can be used in multiple
applications.

ADOPTING MICROSERVICES AS PART OF YOUR

TECHNOLOGY STACK
Businesses of all sizes should consider using microservices rather than custom code when available. In fact,
microservices have leveled the technology playing field to a large extent. Small businesses were once at a severe
disadvantage to the ‘big guys’ that could afford large data centers and the staff to run them. Now, organizations
of 1 or 100,000 people can access the same Amazon and Google APIs and leverage the assets of these tech
giants. For smaller businesses, microservices can serve as a ‘force multiplier’ in that they allow you to quickly
build complex applications by using services that someone else builds and maintains. Thousands of startups
have even combined existing services creatively, or built services to fill a specific niche, and turned them into a
business.

Larger businesses should consider an investment in microservices as a way to ease their dependency on propri-
etary and legacy systems. By providing internal microservices, they’re no longer dependent on a particular
hardware or software vendor and can upgrade components of their infrastructure without affecting large
swaths of applications. Additionally, using microservices allows for legacy data and systems to power creative
new tools. With the right microservices, you can quickly develop a mobile app that securely and easily access
data formerly locked in a mainframe. Microservices also can reduce the dependency on IT for new tools and
applications. If marketing wants to launch a new product catalog and you have a microservice, they’re no longer
dependent on IT to write interfaces or provide scarce resources.

Microservices can seem complex and confusing, causing too many IT leaders to regard them as a nice idea that
they’ll explore ‘eventually’. As you’ve seen above, they can be as simple as clicking a link.

5
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

SURVEY: MICROSERVICES WORTH THE HYPE

73% of survey respondents integrated microservices into their application process.
BY: MELANIE WOLKOFF WACHSMAN/TECHREPUBLIC

Microservices touts many benefits including faster,

more scalable, and more flexible application devel-
opment for organizations.

Does it actually live up to its promises? This past

March-April TechRepublic Premium surveyed 477
professionals to find out.

Microservices is certainly on the radar of most

respondents. The vast majority of survey takers
(96%) were either very or somewhat familiar with
the concept of microservices. Further, 73% have
IMAGE: GETTY IMAGES/ISTOCKPHOTO
already integrated microservices into their appli-
cation process. Of those respondents who have yet to incorporate microservices, 63% are considering it.

According to respondents, the top benefits of integrating microservices ranged from faster deployment of
services (69%), and flexibility to respond to changing conditions (61%), to the ability to quickly scale up new
features into larger applications (56%), more standardization of services (42%), and reduced technical debt
(33%).

A large number of survey respondents use REST (88%), Agile (80%) Web APIs (77%), and DevOps (75%),
or a combination of the above. While containers (67%) and cloud services (66%) also ranked high. At 1%,
COBRA, was the least used, according to survey respondents.

Lack of proper skillsets and unfamiliarity with microservices, as well as too many legacy systems, and lack of
corporate support round out the most popular reasons why companies have not integrated microservices into
their applications.

The infographic on the next page contains selected details from the research. To read more findings, plus
analysis, download the full report: Research: Microservices bring faster application delivery and greater flexi-
bility to enterprise (available for TechRepublic Premium subscribers).

6
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

7
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

HOW TO PLAN A MICROSERVICES

IMPLEMENTATION
Placing key services at your company behind an “abstraction layer” will have lasting
benefits. Here are some considerations for implementing microservices at your
organization.
BY: PATRICK GRAY/TECHREPUBLIC CONTRIBUTOR

Back in the early days of enterprise technology,

which was when I last did any significant appli-
cation development work, it would take weeks
to design and build even relatively simple appli-
cations. If you were lucky, someone else in the
organization or a vendor had a code library or
two that you could acquire and compile into
your application. This required deep technical
knowledge of the underlying code.

If you’ve done any recent development work --

and I strongly encourage IT leaders to occasionally IMAGE: ISTOCK.COM/RUFANA RAHIMOVA

do a ‘Hello world’-type application to understand

modern tools -- you’ve probably been amazed that most of the work is around integrating various services.
These services can be accessed over public networks, and use standards like JavaScript Object Notation (JSON)
to exchange information in a way that anything from a mobile app to an enterprise application can process.
Developers no longer need to understand any of the underlying complexities of how the service works,
allowing amazing functionality with minimal complexity.

The possibilities become obvious rather quickly. Complex integrations are the ‘black hole’ that derails many
well-intentioned development projects, so if they can become simplified and de-risked then custom apps that
create unique advantages for your company are no longer an option of last resort. This, of course, requires
that your internal systems have a microservices layer that allows key functionality from company systems to be
delivered through standardized services.

While this may seem like a daunting task, these standardized interfaces would be designed to accomplish a
single, discrete task, hence the ‘micro’ in microservice. In traditional systems design, you might pass data to
another application that ‘takes over’ the remainder of the transaction. In a microservice environment, the

8
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

application acts like a conductor, coordinating a function by asking hundreds of different services to perform a
discrete task that’s independent of the larger transaction.

THE MAGIC OF MICROSERVICES

Amazon is perhaps the best example of scaling
microservices across the organization. While it
seems a distant memory, 15 years ago you would Amazon is perhaps the best
have been laughed out of the room for suggesting example of scaling microservices
Amazon would become a dominant IT services across the organization.
provider. The now-unquestioned dominance of
Amazon Web Services (AWS) started with a simple
mandate that every computing service Amazon used internally be created as a microservice.

Amazon quickly realized that with all of its systems providing simple, common, and stable microservices,
other parts of the company, and ultimately the public at large, could use these services quickly to create their
own applications. Amazon, and later AWS customers around the world, were freed from the vagaries of
version upgrades, system changes, and code updates, since they could always depend on a service producing a
consistent result, irrespective of the technology used to provide that result.

TRANSITIONING TO MICROSERVICES
For starters, duplicate Amazon’s move and mandate that all new software projects be delivered through micro-
services. If that’s too challenging, it may be easier to start more simply. Probably the best place to do that
is when acquiring new software or platforms. This is easy when buying cloud software as a service, as most
providers deliver a suite of prebuilt microservices to interact with the data and business logic.

Identify some simple use cases that show the benefit of microservices. For example, if you implement a cloud-
based sales platform, you might leverage microservices to capture data on your website and feed it into the
sales system. Or, you might quickly develop a mobile or web-based app in record time that performs a specific,
meaningful task and demonstrates that microservices make IT faster and more flexible. Rather than focusing
on the technology when pitching microservices, focus on the flexibility and speed it brings to IT, which have
long been the Achilles heel when delivering integrated applications.

USE THE ACCELERATORS

At a superficial level, it’s easy to convey the benefits of microservices. However, as you start to plan a transition
to microservices the proposition can seem daunting. Even small organizations have hundreds or thousands of

9
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

application components that could be made available via a microservice.

Thankfully, there are a variety of software platforms that provide an ‘integration layer’ which essentially
serves as a ‘translator’, integrating with your legacy tools in the technologies they understand and providing a
common, standards-based microservice on the other side. Tools like MuleSoft, Boomi, Jitterbit, and others can
quickly allow you to start capturing the benefits of microservices without wholesale updates to your existing
applications.

This provides a significant additional benefit. If you can create thoughtful microservices, replacing legacy appli-
cations simply requires changing some backend ‘plumbing’ without rebuilding the tools that depend on that
microservice.

Identify key IT services that power multiple applications and prioritize them for microservices. A shipping
company might start by building order status microservices, just as a retailer might start with inventory services.
It may also be tempting to create the ‘perfect’ microservice for each application, which accommodates every
potential scenario and permutation. This approach is a recipe for delayed rollouts and overcomplication. Seek
to keep the ‘micro’ in microservices by making each perform a discrete task. You can always combine multiple
services to perform more complex functions, just as you can expand functionality in future versions.

Finally, each service requires a published set of specifications that’s maintained on an ongoing basis. A compre-
hensive library of microservices that are not shared or well-documented accomplishes little. Remember that a
key benefit of microservices is that new applications can be built without complex IT projects and approvals,
so keeping your services updated and documented is critical for getting the benefit of these services.

There may also be some resistance by owners of the various services that will ultimately be made available via
a microservice architecture. With open services, individual teams give up some of their ‘gatekeeper’ role, which
can seem threatening. Ensure that you communicate that their span of control remains intact by preserving the
integrity of what happens ‘behind’ the microservice, and that the broader organization can rapidly benefit from
their work rather than having to wait for complex, one-off interfaces.

10
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

SOA VERSUS MICROSERVICES:

HOW ARE THEY DIFFERENT?
Microservices and service-oriented architecture are often compared, but the two frame-
works are quite different and have unique uses in enterprise environments.
BY: BRANDON VIGLIAROLO/TECHREPUBLIC CONTRIBUTOR

IT professionals and business leaders with an

interest in cloud services have probably heard
the term microservices, quite possibly in discus-
sions about service-oriented architecture (SOA).
There are good reasons why these evolving cloud
technologies are popular: Both can make an
organization and its cloud-hosted applications
more agile, less likely to suffer outages, faster to
update, and eliminate other problems associated
with monolithic architecture and software.

SOA and microservices can also exist side by side, IMAGE: GETTY IMAGES/ISTOCKPHOTO

but these frameworks are not the same thing. It’s

important to know the difference between them, and especially between microservices and monolithic archi-
tecture, which microservices stand in direct opposition to.

WHAT IS SERVICE-ORIENTED ARCHITECTURE?

SOA isn’t a new concept--in fact, sister site TechRepublic has been writing about it since at least 2003, and
the definition given back then still applies 17 years later: “In an SOA, the architect attempts to encapsulate the
delivery of a specific set of tasks within a single entity that accepts a service request and returns the results of
the work performed on its behalf or errors resulting from a failed attempt. The combination of these services,
along with guidance on how they can be combined to complete an application, makes up an SOA.”

SOA starts with an end result in mind and builds an entire enterprise architecture backward from there with
interoperability, reusability, and independence in mind. According to IBM, a well-constructed SOA uses
“common communication standards in such a way that they can be rapidly incorporated into new applications
without having to perform deep integration each time.”

11
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

In essence, SOA is a way of configuring an enterprise’s digital resources and data in such a way that it’s univer-
sally accessible to any potential business software that may need it--just add API.

WHAT ARE MICROSERVICES?

Software-oriented architecture is organizational
in scope and is more concerned with building a
Microservices and SOA have a core
bunch of services that can all talk to each other in
architecture similarity: Both rely on
order to deliver a business result independent of
the app that requests it. Shrink that idea down to containerized data. That’s where
an individual application, and you have the gist of the similarities end, though.
microservice architecture.

Microservices are single applications built out of a bunch of independent, containerized bits that don’t have
any direct bearing on the application as a whole. A single sub-service of a microservice architecture app can be
written in a completely separate language, updated independently of the main application, can be scaled at will,
and put individuals (or teams) in complete control.

Microservices are also ideal for cloud environments, where multiple containerized elements can be plugged into
an application without needing to consider their effect on a larger software product.

Contrast that to monolithic architecture, where each element of an application is built within the application
as a whole, and no part of a piece of software can be changed or scaled without having to consider the appli-
cation as a whole.

HOW DO MICROSERVICES AND SOA DIFFER?

There are a lot of similarities between microservice architecture and software-oriented architecture, but there
are several key differences that need to be understood to see how the two can work together, but still require
distinct approaches.

First, there’s the issue of interoperability: Services in an SOA model are designed to report to various applica-
tions through APIs. The core concept is creating a single cooperative network architecture that is completely
platform agnostic.

That concept is antithetical to microservice architecture. According to IBM, a “microservices component that
is reused at runtime throughout an application results in dependencies that reduce agility and resilience.” In
the microservice world, it would even be preferable to duplicate code and accept data duplication to further

12
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

decouple microservice components. The goal is complete independence of each part of an app, not interoper-
ability between different ones.

This highlights another distinct difference between microservices and SOA: Data duplication. SOA’s purpose
is to eliminate any potential for duplication or fragmenting, whereas the chief goals of a microservices app are
speed and agility.

Microservices and SOA have a core architecture similarity: Both rely on containerized data. That’s where the
similarities end, though. In the case of SOA, the focus is on building a backend architecture that can deliver
information to any REST API that calls for it. For an application built on microservice architecture, the focus
is less on creating a universal backend and more on building a single application that is resilient and fast because
each of its subcomponents are entirely independent and don’t connect to each other in any common fashion.

How can you determine whether SOA or microservice architecture is better for your business?

Are you trying to build a single application or design an entire enterprise network? If it’s the former, you need
microservices; if it’s the latter, SOA is what you want.

Software-oriented architecture is an excellent way to think about building a new business network, or a way
to digitally transform an existing one suffering from fragmentation and compartmentalization. As its name
implies, it’s all about building a network designed around making it easier for software to access data when it’s
built and in the future.

Development teams or independent programmers who want to create apps that don’t rely on the fallibility of
an individual component should consider building their programs around microservices. It allows developers
to use the languages they’re comfortable with, eliminates IT’s struggles to update complex, interconnected
software, and lets products turn on a dime in a way that monolithic software could never hope to.

So, remember that microservices and SOA fill different needs and shouldn’t be confused with each other.

13
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

BEST PRACTICES FOR SECURING MICROSERVICES

BY: MATT ASAY/TECHREPUBLIC CONTRIBUTOR

The great promise of microservices is freedom.

Freedom to break up an application into distinct
services that are independently deployable. Freedom
to build these disparate services with different teams
using their preferred programming language, tooling,
database, and so on. In short, freedom for developers
to get stuff done with minimal bureaucracy.

Sounds great, right? A euphoric take on “Developers

of the world unite! You have nothing to lose but your
monolithic app chains!”

Except for the security part. It’s awesome that a micro-

services architecture breaks applications down into independent services, but this also means more complexity,
and more services to secure. If you have a database per service -- MongoDB here! Amazon Aurora for MySQL
there! Redis over there! -- you still have to manage them all. There are technology strategies to all of this but,
really, effective microservices security starts (and ends) with people.

Yep. Those jerks again.

PEOPLE ARE THE PROBLEM SOLUTION

The people issue starts with jobs. Or, rather, the fact that different people have different jobs, with different
priorities. A developer may be tasked with building an application as quickly as possible in order to catch up to
or leapfrog a competitor. Meanwhile, the security and operations teams are just trying to keep that application
from turning into a dumpster fire. In a world where developers build and everyone else is tasked with cleaning
up after them, security is always going to be a struggle, whether we’re talking about microservices or monolithic
applications.

However, as developers take on more responsibility for operating their code (DevOps) and securing it
(DevSecOps), it drives different behavior relative to “design, what kind of monitoring you have, what kind
of tooling, how you interface with that system,” according to Jason Chan, vice-president of Information
Security at Neflix, in his Future Stack 2015 presentation. As Chan spelled out, strong microservices security is

14
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

a function of three guiding principles, all of which are ultimately tuned to making life easy for developers and
security professionals: traceability and development, continuous security visibility, and compartmentalization.

TRACEABILITY
The best security happens without a lot of extra effort, which is why the first key to security is to build it into
your continuous delivery workflow. Many companies try to manually catalog their service components with
an application risk assessment, usually populated via survey questions sent to developers. Sound familiar? It
should. This is how most companies have handled security for eons.

But it doesn’t work. First, there’s an entire science to answering these questionnaires that enables the developer
to sidestep the questions without improving security. Even if they aren’t trying to get past the security folks,
it’s not always clear what the questions mean. In other words, these risk assessments may end up giving a
“false sense of security,” Chan pointed out, which is exactly the wrong approach to securing microservices (or
anything else).

Instead, he continued, “[D]on’t...create a bunch of new tools and new dashboards that people have to go to.
[D]on’t...interrupt their workflow.” Instead, integrate with the workflows and tooling those developers are
already using. Netflix, for example, has open-sourced its continuous delivery (CD) Spinnaker tool to give devel-
opers and operations/security folks a holistic, common view of an application and its component parts, but
there are plenty of others (Ansible, Jenkins, and so on).

It’s less important which tool you use, and more important how you use it.

It’s within the CD workflow that you insert tests, restrictions on which regions for deployment (and when).
Doing so not only automates delivery of services, but it also ensures auditability. A common technique for
ensuring a new service won’t introduce security (or other) problems is to launch a ‘canary workload’ -- a new
production workload launched to a limited set of users -- and if it looks good (doesn’t trigger any of the
automated security alerts, for example), the CD tool automatically rolls it into full production.

By working within the developers’ chosen workflow, and automating as much as possible, security teams can
keep the speed/agility benefits of microservices while still ensuring security checks are in place. Which leads to
a related principle: continuous security visibility.

CONTINUOUS SECURITY VISIBILITY

A few years back Michael Nygard said something that should resonate with anyone that has tried to secure
microservices: “An individual microservice fits in your head, but the interrelationships among them exceeds any
human’s ability. Automate your awareness.” If it were just one service, in other words, it would be fairly easy

15
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

to keep track of changes to it and secure the appli-

cation. But the whole promise of microservices
Guided by these three principles
is they may be self-contained yet their value arises
-- Traceability, Visibility, and
from their connections to other services.
Compartmentalization -- security
No matter how big your organization, you’re professionals can automate much
never going to have enough security resources to
of their security workload without
penetration test every application, or look at every
burdening developers.
line of code. Again, one of the cardinal virtues
of microservices is that they accelerate change
within and between applications. Going back to
those developer surveys, companies have historically tried to build spreadsheets with a score attached to each
application or service, but this has the problems mentioned above, as well as the difficulty (read: impossibility)
of keeping it up-to-date. If you have hundreds (or even dozens) of applications that change all the time, it’s
unwise to rely on people volunteering information in a timely or accurate fashion.

You need automation.

By employing service discovery tools (Netflix has its Penguin Shortbread application, but there are many other
options), you can gauge the riskiness of a particular service based on how many other services depend upon it
(the more services that depend on it, the higher its risk score), whether it’s exposed to external Internet traffic
(edge services get a higher risk score), and so on. This automated security risk assessment thus yields a stratifi-
cation of risk, allowing relatively scarce security people to focus their attention on the microservices with the
most exposure.

Which brings us to the final principle: compartmentalization.

COMPARTMENTALIZATION
This principle is critical for distributed systems, and the microservices that comprise them, for two reasons. The
first is that given that all security is likely to fail at some point, you want to limit the blast radius of that failure.
The second is about confidentiality: keeping data reserved only for those who need to know.

With a monolithic application, everything is lumped together. Developers struggle to iterate on monoliths
without breaking things in the process, and every break point introduces new security issues. According to
Chan, with monolithic applications “you have very sensitive systems that have a lot of inputs and outputs, [i.e.,]
attack surface. [Applications with a large] attack surface [can] be secured, [but] it’s more difficult to do it.” It’s
also harder to verify that things are working as they should.

16
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

In a microservices context, however, security can be better because the ‘blast radius’ isn’t the entire application,
it’s just the individual services. Many security-forward companies choose to further improve on this security
posture with a token vault, where sensitive data is stored. Tokens map to this sensitive data, and those tokens
can be passed around the application without the data itself moving. The token service calls crypto infra-
structure that sits between the sensitive data and the token, protecting the data. This approach allows you to
implement much finer-grained access control, Chan said, and it’s much easier to trace what’s going on.

PEOPLE-BASED SECURITY (DRIVEN BY MACHINES)

Guided by these three principles -- Traceability, Visibility, and Compartmentalization -- security professionals
can automate much of their security workload without burdening developers. Even better, as developers are
increasingly asked to secure their own applications, they become willing partners in this effort. Which brings
us back to people: if IT tries to secure microservices in the old way (spreadsheets, surveys, treating all applica-
tions/services more-or-less equally), the people partnership breaks down and security won’t work. But through
automation, people (and machines) partner to make microservices secure.

Disclosure: I work for AWS, but nothing herein relates directly or indirectly to my work there.

17
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

AUSTRALIAN NEOBANK XINJA IS MASTERING

INTEGRATION THROUGH MICROSERVICES
The bank has dubbed it as the ‘post-SOA architecture’.
BY: AIMEE CHANTHADAVONG/ZDNET

When Greg Steel first investigated what the archi-

tecture for Xinja was going to look like just over four
years ago, a few options were considered.

One of those, according to Steel, now CIO of the

Australian neobank, was to purchase an off-the-
shelf bank-in-a-box solution, such as Temenos or
Celeriti, that could have easily offered them every-
thing they needed: Core banking platform, customer
management platform, integration layers, channel layers, and the opportunity to customise those layers.

But as Steel puts it, it would have been “quite a conservative approach and it would have limited what we could
have done”.

“We would’ve built a great new credit union just like existing banks but we couldn’t have differentiated and
done our own things and added in our testability at each layer of that stack,” he told ZDNet.

At the same time, Xinja wanted to avoid going down the path of building an enterprise service bus (ESB)
service-orientated architecture (SOA), mainly because it came with “approaches of really having a centralised
type platform and centralised skillsets to be able to do those integrations that were the bottlenecks for every-
thing”, and it was also a typical approach for most financial services organisations.

What they opted for in the end was an event sourcing-based microservices architecture made up of a mix of
best-of-breed banking platforms -- including an SAP digital banking platform for its core banking platform --
and building their own integrations layers without an ESB.

“We needed to give ourselves the flexibility and freedom so we can innovate at every layer of our technology
stack,” Steel said.

“We’re architects, we believe in the principles that came out of that service-orientated architecture, so it’s kind
of what we call a post-SOA architecture where you’re dividing your banking landscape across the different
technical capabilities cleanly.

18
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

“Rather than buy an out-of-the-box platform and all those integration capabilities and hooking into all sorts of
legacy platforms and integration platforms, we decided to choose modern banking platforms, mostly born in
the cloud platforms, all integrated with great web services.

“Therefore, we could build our own microservices architecture to do that integration, which meant more
handcrafting of code than you would do with an ESB where you might use patents, frameworks, or templates.”

Steel conceded that while it was not the cheapest option nor was it the easiest at times, the pay-off has been
much higher.

“Building software is difficult to do but we found that it did mean that we were able to achieve outcomes in
integrating new capabilities so much more quickly than we’ve ever experienced,” he said.

He pointed to Xinja’s integration of Apply Pay as one example of where the decision to build its integration
stack with microservices was the right call.

“Most banks that have done Apple Pay in the last five years take about a year to do it. It’s a very big and very
complex project. You have a number of different suppliers involved, a number of integration points, and
Apple is also really anal with you about how things are going to be done,” Steel said.

“We were under great time pressure to get funding

and we couldn’t go out to potential funding sources
What they opted for in the end
and say ‘We’re a neobank but we can’t do Apple Pay or
was an event sourcing-based Google Pay,’ so we put ourselves under great pressure
microservices architecture made but we delivered from our first conversation with
up of a mix of best-of-breed Apple to customers in five weeks.
banking platforms -- including an
“The biggest reason we were able to do that was
SAP digital banking platform for
because we built this microservices integration archi-
its core banking platform -- and tecture. If we hadn’t, and were dependent on suppliers
building their own integrations to do the integration, and had to get suppliers working
layers without an ESB. with each other to jump through their hoops, it
would’ve taken us months and months.”

Despite Xinja’s own successes, Steel believes it will take time for others in the financial sector to warm up to
building an integration stack with microservices.

“There’s scepticism about building software. Everyone’s been burnt on software build. We’ve been burnt.
Software development is always a bit of a bottomless pit. I think it will always be the case and there’s always

19
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

going to be a move towards patent-based, code generation-based, software development delivery,” he said.

He added that unlike others, Xinja’s advantage is that it has been built in the cloud and is not weighed down by
legacy infrastructure.

“The cloud is hard for existing financial services … taking existing legacy platforms and bringing them into the
cloud is a lot harder,” he said.

“You wouldn’t try to build this architecture outside of the cloud … it’s not something you can go 50-50. You
really have to embrace those patents and embrace them properly. If you try and do a hybrid thing, such as a
customer mastering over here and Kafka for securing and messaging, you’re not really embracing the patent
and it’s not really going to work.”

But whether the existing model is sustainable to maintain in the long run, Steel is optimistic that emerging tools
and platforms will help ensure it is.

“Microservices is quite fine grain. You’ve got many smaller components, each of which is relatively simple in
their own right … when you’ve got a lot of fine-grain microservices, that can become a nightmare where you
start needing registries and keeping track of who’s talking to what, what the dependencies are -- that’s always a
problem, that’s the flip side of having something highly monolithic,” he said.

“If you’re going to have something that’s fine-grain distributed, there’s great tools evolving to deal with that.
We do an awful lot of automated testing which keeps us in check and makes maintenance and managing finer
grain components a lot easier.

“The other thing is when you’ve written code to do something like integrate with some third-party systems
… it probably takes you longer to get it working in the first place, but what you have at the end of the day is
java code, so you’ve actually removed a few potential layers of complexity and loss of knowledge and under-
standing. Instead, you’ve got code that’s quite well understood.”

20
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

8 WAYS TO MAKE SURE YOU REALLY NEED

MICROSERVICES
You may not even need microservices to manage your monolith. A tech transformation
expert offers some ways to test your readiness.
BY: JOE MCKENDRICK/ZDNET CONTRIBUTOR

Microservices -- today’s service oriented architecture

du jour -- are great, but not for everyone. There are
many situations where they may do more harm than
good.

That’s the word from Adam Drake, a technical

business transformation expert, who posted some
words of caution about microservices, warning of
increased operational overhead, performance issues,
and scalability problems.

Drake provides key steps in assessing an enterprise’s

need for microservices architecture. Once the first two
steps are taken, he urges, “then consider again whether
microservices are the right direction for your organization. Chances are, a lot of the issues you had previously
will simply disappear.”

1. Clean up the application. This includes ensuring that the system “has good automated tests and is using
the current versions of all libraries, frameworks, and languages,” Drake says.
2. Make use of APIs. “Refactor the application into clear modules with clear APIs,” Drake says. “Don’t
allow bits of the code to reach into the modules directly. All interaction should be via the APIs presented
by the module.”
3. Separate the services: Separate a module from its application, but keep it on the same host, says Drake.
“This starts to give you some of the usefulness of totally separate microservices, but with fewer of
the operations headaches,” says Drake. There will still be communications issues to contend with, but
without the accompanying challenges that will come up once the separate components are running across
distributed networks.

21
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

4. Move the separated module to a new host. “Now you’ll have to deal with the issues surrounding
communication over a network, but you will have bought yourself a little less coupling between the two
systems,” Drake says.
5. Separate storage capabilities. Finally, Drake says, “if possible, refactor the data storage system so that
the module on the other host now has total responsibility for storage of data within its context.”
6. Consider your organizational readiness. A microservices-savvy enterprise has teams who can
provision resources on a moment’s notice, with little or no outside assistance, Drake says. “If your
organization has only one or a few people in your entire dev team who can set up new services, virtual or
otherwise, you are not ready for microservices.”
7. Be ready to monitor. “If you don’t monitor the system and application performance of your monolith,
then you will have a miserable time with microservices,” says Drake. Key metrics include “system-level
metrics (such as CPU and RAM), application-level metrics (such as request latency per endpoint, or errors
per endpoint), and business-level metrics (such as transactions per second, or revenue per second) to
understand the performance of your systems.”
8. Be well-equipped for continuous integration and continuous deployment. Drake puts it
perspective: If the monolith is lacking a good CI/CD approach, then a microservices architecture is going
to be hundred times as challenging, “Imagine having 10 teams and 100 services, all of which require
manual integration testing and deployment. Now imagine the same manual work, but with only one
monolith. How many ways can things go wrong with 100 services? How many ways with one monolith?”

22
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

8 SPEED BUMPS THAT MAY SLOW DOWN THE

MICROSERVICES AND CONTAINER EXPRESS
Containers and microservices are paving the way to DevOps. However, as with any
promising technology approach, they require management care and feeding.
BY: JOE MCKENDRICK/ZDNET CONTRIBUTOR

At the core of any DevOps initiative is the

judicious employment of containers and microser-
vices, which dramatically speed up and simplifying
the jobs of developers and operations teams alike.
While many of the tried-and-true rules of IT
management apply, containers and microservices
also add new considerations, and new ways of
doing things.

To explore many of the IT management concerns

that accompany successful container and micros-
ervice deployments, we turn to the observations of IMAGE: HUBSPOT

two seasoned experts in the field, Ashesh Badani,

VP and general manager of OpenShift for Red Hat, and Marc Wilczek, a highly regarded industry thought leader.

Badani, writing at The Enterprisers Project, observes that the ultimate goal of containers and microservices
-- and the DevOps they enable -- is agility. “Containers corral applications in a neat package, isolated from
the host system on which they run. Developers can easily move them around during experimentation, which
is a fundamental part of DevOps. Containers also prove helpful as you move quickly from development to
production environments.”

Developers are especially enthusiastic about microservices enabled by containers for a couple of reasons,
Wilczek explains in a post in CIO. “They enable developers to isolate functions eas­ily, which saves time and
effort, and increases overall productivity. Unlike monoliths, where even the tiniest change involves building and
deploying the whole application, each microservice deals with just one concern.”

As with any promising new technology or methodology, there are barriers to overcome, both organizational
and technological. Badini and Wilczek offer sage advice on overcoming the major speed bumps that may
flummox the move to a microservices and containerized architecture:

23
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

1. Organizational skills and readiness: Before any container of microservices effort can get underway,
people across the enterprise need to be on board with it, and ready to adapt their own mindsets. “IT
leaders driving cultural change need support from both the C-suite and evangelists in the smaller
teams,” says Badini, warning that all too often, “the easiest thing to do is just do nothing.” But today’s
hyper-competitive and hyper-fast economic environment demands the speed and agility containers and
microservices make possible. The good news, Badani adds, is “you don’t need all the resources or skills
of Facebook in order to make significant business change. Start experiments with smaller groups. As
you succeed and become more comfortable, expand out in terms of technology and talent. Encourage
people on your team to engage with their peers outside the company, to talk about technology and culture
challenges.”
2. Platform: Choice of platform is key to a container and microservices efforts. “A platform addresses
management, governance, and security concerns,” says Badani. “While there are plenty of open source
container tools to experiment with, an enterprise-grade container platform typically comprises dozens
of open source projects, including Kubernetes orchestration, security, networking, management, build
automation and continuous integration and deployment capabilities out of the box.”
3. Capacity and lifecycle management:
“Both containers and microservices can
easily be replaced and therefore tend to have
a relatively short lifespan” -- often measured
in days, says Wilczek. “The short lifespan
combined with the enormous density lead
to an unprecedented number of items that
require monitoring.” In addition, containers
need a lot of memory space. The challenge is
that “with their own operating environment
attached, images can easily reach a couple
IMAGE: HUBSPOT
of hundred megabytes in size,” Wilczek
says. He recommends ongoing lifecycle management practices -- “especially retiring old images to free up
shared resources and avoid capacity constraints.” An ability to quickly retire containers to free up memory
space requires a comprehensive lifecycle management effort.
4. Network layer: Wilczek cautions that networks -- or even virtualized network layers -- may prove to be
bottlenecks in the performance of microservices and containerized architectures, and thus require “close
monitoring in terms of performance, load balancing, and seamless interaction.”

24
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

5. Balancing legacy and cloud-native apps: Trade-offs between existing infrastructure and new, cloud-
borne applications may be a sticking point, but is normal, Badani explains. “Some CIOs still have
COBOL apps to support. Grappling with both old and new technologies, and making tradeoffs, is
normal. Some companies seek containers mostly to house cloud-native apps being created by application
development teams, including new work and revamps of existing apps. These apps are often microser-
vices-based. The goal is to break up an app into its underlying services, so teams can update the apps
independently.”
6. Monitoring: “Many traditional IT monitoring tools don’t provide visibility into the containers that make
up those microservices, leading to a gap somewhere between hosts and applications that is ultimately off
the radar,” Wilczek warns. “Organizations need to put one common monitoring in place comprising both
worlds and covering the entire IT stack - from the bottom to the top.”
7. Manageability. Organizations need to ensure that there are enough staff resources dedicated to
container and microservice deployment and management. “All too often, developers are tempted to add
new functionality by creating yet another microservice,” Wilczek says. “In no time, organizations find
themselves attempting to manage an army of containers and countless microservices competing for the
same IT infrastructure underneath.” He recommends employing “analytics tools that discover dupli-
cative services, and detect patterns in container be­havior and consumption to prioritize access to systems
resources.”
8. Security. “Because containers contain system specific libraries and dependencies, they’re more prone
to be affected by newly discovered security vulnerabilities,” Badani says, who recommends the use of
“trusted registries, image scanning, and management tools” that can help automatically identify and patch
container images.’

25
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

HOW TO AVOID TURNING MICROSERVICES INTO

DISTRIBUTED SPAGHETTI CODE
The sheer convenience of building with serverless can lead developers to resurrect the
dreaded spaghetti code of monolithic architectures.
BY: MATT ASAY/TECHREPUBLIC CONTRIBUTOR

One of the coolest things serverless offerings

do is allow you to “mix and match programming
languages and frameworks like never before,” as
Gartner research director Raj Bala has said. This
means, as he suggested, you can write a Java appli-
cation that calls Python libraries, for example, using
a functions-as-a-service (serverless) platform.

So. Cool.

It may also mean, however, a new era of spaghetti IMAGE: MARIHA-KITCHEN, GETTY IMAGES/ISTOCKPHOTO

code (i.e., unstructured and difficult-to-maintain

code). Just because you’re moving on from monolithic code (bad!) doesn’t mean that you’re not replacing it
with “a distributed systems problem with implications for deployment, communication, monitoring, and so
on” (also bad!), as Johannes Staffans has written. As with more traditional software development, developing
easy-to-maintain microservices requires a thoughtful approach.

SPREADING THE MICROSERVICES LOVE

Bala is right to call out that one of the primary benefits of a serverless and “single-purpose microservices” is that
“You can use the right tool for the right job rather than being constrained to one language, one framework or
even one database.” This is immensely freeing for developers, because now instead of writing monolithic appli-
cations that likely have very low utilization with spiky workloads, they can build microservices tied to ephemeral
serverless functions. When the system is idle, it shuts down and costs nothing to run. Everyone wins.

This also can make maintaining code more straightforward. For monolithic applications, updating code can
present a major burden because of the difficulty inherent in covering all dependencies. As Ophir Gross has
noted, “Spaghetti code is full of checks to see what interface version is being used and to make sure that the
right code is executed. It’s often disorganized and usually results in higher maintenance efforts as changes in

26
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 MICROSERVICES: THE FOUNDATION OF TOMORROW’S ENTERPRISE APPLICATIONS

code affect functionality in areas that are challenging

to predict during development stages.”
It’s not, however, with its own
In a microservices-based approach, by contrast, “Code risks. Ironically, one of those
in a microservice is restricted to one function of the risks just might be the spaghetti
business and is thus easier to understand,” said Peter code that developers embrace
Eijgermans. Teams can operate independently of
microservices to escape.
each other, using their own preferred implementation
technologies and frameworks, among other things.

It’s not, however, with its own risks. Ironically, one of those risks just might be the spaghetti code that devel-
opers embrace microservices to escape.

DISTRIBUTED SPAGHETTI
Among other complications (debugging is more complex, the difficulties associated with APIs changing over
time and ensuring the services that consume the API are updated in a timely manner, etc.), one problem with
microservices is that developers may use them to build in a similar manner to their monolithic application days.
Eijgermans explained this problem:

People are often unaware that microservices really need to be independent. For example,
you often see that all kinds of services are being made but that one database is shared.
Another problem is that people program what they were used to doing in a monolith, making
the chain of synchronous calls between services (over the network !!!) much too long.
Neither is attention paid to spaghetti structure that can arise from all kinds of services that
use each other and services are tightly coupled.

The key to designing microservices is to properly “defin[e] their boundaries and how they communicate,”
according to Marko Anastasov. “A loosely coupled service contains related behavior in one place and knows
as little as possible about the rest of the system with which it collaborates.” Anastasov’s emphasis on “loose
coupling” is critical. You want services to communicate asynchronously with a limited number of endpoints
and no shared database.

Of course this doesn’t eliminate the potential for “Spaghetti Code 2.0.” The very power and convenience that
Bala calls out can lead to developers creating all sorts of API calls to serverless functions that can get unwieldy
fast. Still, ensuring loose coupling of services can help.

Disclosure: I work for AWS, but nothing herein relates directly or indirectly to my work there.

27
COPYRIGHT ©2020 CBS INTERACTIVE INC. ALL RIGHTS RESERVED.
 CREDITS
Editor In Chief ABOUT ZDNET
Bill Detwiler
ZDNet brings together the reach of global and the depth of
Editor In Chief, UK local, delivering 24/7 news coverage and analysis on the
Steve Ranger
trends, technologies, and opportunities that matter to IT
Associate Managing professionals and decision makers.
Editors
Teena Maddox ABOUT TECHREPUBLIC
Mary Weilage
TechRepublic is a digital publication and online community
Editor, Australia that empowers the people of business and technology. It
Chris Duckett provides analysis, tips, best practices, and case studies
aimed at helping leaders make better decisions about
Senior Writer
Veronica Combs technology.

Senior Reporter, UK DISCLAIMER

Owen Hughes
The information contained herein has been obtained
Editor from sources believed to be reliable. CBS Interactive Inc.
Melanie Wachsman disclaims all warranties as to the accuracy, completeness,
Staff Writer or adequacy of such information. CBS Interactive Inc. shall
R. Dallon Adams have no liability for errors, omissions, or inadequacies in
the information contained herein or for the interpretations
Associate Staff Writer
thereof. The reader assumes sole responsibility for the
Macy Bayern
selection of these materials to achieve its intended results.
Multimedia Producer The opinions expressed herein are subject to change
Derek Poore
without notice.
Staff Reporter
Karen Roby COVER IMAGE: ISTOCK

Copyright ©2020 by CBS Interactive Inc. All rights reserved. TechRepublic

and its logo are trademarks of CBS Interactive Inc. ZDNet and its logo are
trademarks of CBS Interactive Inc. All other product names or services
identified throughout this article are trademarks or registered trademarks of
their respective companies.