A Microservice Based Reference Architecture Model

in the Context of Enterprise Architecture

2 2 2
Yale yu ,, ,Haydn Silveira ,Max Sundaram
Xi'an Peihua University, Xi'an, 7lOl25, China
L
2. Infosys Australia, Melbourne, Australia
[email protected], haydn [email protected], max [email protected]
_ _

Abstract-In the service oriented, customer experience centric which automation logic is decomposed into smaller, distinct
and customer changing demand driven market environment, units of work". These units of work, known as 'services', are
leT is becoming the leading enabler and partner of the modern built around a set of well-defined principles, such as standard
enterprise business. More and more companies are transformed contract, discovery, loose coupling, autonomy, reusability,
into more or pure digital style and virtual organized enterprises composability, statelessness and abstraction [5]. Services that
that are enabled and supported by a group of business oriented
perform business functions are classified as business services
and microservice based applications and modules that are new to
e.g. address management service, while those that perform
most of the companies and enterprises, both business and
infrastructure functions are classified as infrastructure services
technical solution staff. This paper presents a microservice based
e.g. transaction management service, unless explicitly stated in
reference architecture model with clear understanding and
this context 'service' refers to a business service.
definition of the concept of microservice and key architectural
components and building blocks for implementing and managing SOA services are generic in function and have a great deal
enterprise microservices in the context of enterprise architecture. of reuse, as more consumers discover the service; each places
This reference architecture model can be used as the pragmatic additional demands on the service, both functional and non­
guidance for both business and IT professionals when they
functional. As additional features are added, the absence of an
develop the enterprise IT transformation architecture solutions
approach to evolve features while minimizing the need to
so that the API and microservice relevant technologies could be
ensure backward compatibility, means more testing is required
used properly at enterprise level without confusion. This paper
to ensure compatibility with existing consumers and existing
also highlights a set of key architectural issues and provides
features [2], over time architecture evolves into a collection of
corresponding recommendations when APls and microsevices
are leveraged within a company at enterprise level.
coarse-grained "monolithic" services. Change and release
management for these services is difficult as mUltiple
Keywords-service oriented architecture; microservice; API; consumers are impacted and changes must coordinated and
enterprise architecture; domain driven design; domain architecture; controlled.
API gateway; API platform
Enterprise service bus (ESB) is a common way to
implement SOA services in many organisations [2], using a
product from a software vendor like Oracle, IBM, etc.
I. Challenges and Issues with
Majority of these ESB products are based on an application
Enterprise IT container architecture and provide a set of infrastructure
services such session management, flow control, workload
The business organization needs to be able to respond to distribution, etc. Deploying a service to a container, includes
disruptions quickly, they need to bring agility to their IT both business service and all the associated infrastructure
systems and infrastructure, at the same time business also services irrespective of the requirement. Consequently, each
craves stability. The use of BiModal IT in the organization is container has a comes at the cost of greater runtime
one-step in the response to disruption; Gartner defines requirements in terms of memory and CPU and licensing. To
BiModal IT as "the practice of managing two separate, maximize efficiencies, developers then aggregate their
coherent modes of IT delivery, one focused on stability and services into a limited number of runtime containers, leading
the other on agility". The challenge facing organizations today
to further "coupling" between services. Scalability can be
is that while the traditional IT applications are satisfactory in
addressed by creating more instances of the containers, which
function, they are essentially not customer centric, and are
would provide a disproportionate increase in capacity, because
unable to keep up the fast changing demands of the consumer
of its containing instances of services that are unused.
platforms and the competition. This is in part due to its
organization culture, but another part is its enterprise Gartner's hype cycle for application architecture shows
application architecture. that microservices are at the peak of the hype cycle [7], the
tendency is to treat these technology trends as a cure-all for all
The challenge to create a component based distributed
IT problems, as maturity around the concept grows and there
architecture is addressed thru the application of "Service
is a clearer understanding of what the technology can and
Oriented Architecture" (SOA) which is defined "a model in
cannot do. To consider this observe the transition of SOA thru
978-1-4673-9613-4/16/$31.00 ©2016 IEEE

1856
Authorized licensed use limited to: The Technology Library. Downloaded on September 12,2024 at 14:52:19 UTC from IEEE Xplore. Restrictions apply.
the hype cycle from 2002-2010, organizations fear that they Applications expose interfaces that can be used by other
will be left behind and will be tempted to invest in applications to interact with are defined as "application
transforming the IT landscape using microservices programming interfaces" (API) [8]. These interfaces are often
architecture, invariably the expectation is high and based on based on their native programming languages and use custom
historical evidence, the corresponding disappointment will be protocols such as the remote function call (RFC) and ABAP
large too. programming for SAP Applications. A microservice should
provide interfaces for communications, it extends this
Microservices and API based reference architecture
definition to include the characteristic of being "technology­
presented in this paper seeks to address these challenges of
agnostic". Microservice API's are built using internet
agility, coarse-grained services, inter-operability and coupling.
communication protocols like HTTP, adhere to open standards
like REST and SOAP and use data exchange technologies like
II. Concept of Microservice and XML and JSON [6].
Microservices though independent, do not exist in silos,
API in context Enterprise they are part of the enterprise landscape and need to
Architecture participate in the enterprise business process. To do this it
depends on other enterprise components and invariably have
A Microservice is an application on its own to perform the other enterprise components that depend on it. Interfaces
functions required. It evolves independently and can choose provided by microservices should be "discoverable",
its own architecture, technology, platform, and can be consumer of the interfaces must be able to look up, fmd the
managed, deployed and scaled independently [1] with its own interfaces without having explicitly knowledge of the
release lifecycle and development methodology. This underlying technology implementation or location.
approach takes away the construct of the SOA and ESB and
the accompanying challenges, by making "smart endpoints" In an enterprise, several teams would require access to
and treating the intermediate layers as network resources create or enhance common functions like customer account. In
whose function is that of data transfer [6]. the absence of a clear understanding of the service, it is
difficult for microservices to be reused effectively.
A Microservice based architecture is defined as a Specifications must be defmed, maintained in an enterprise
"software architecture pattern" for development of distributed wide "shared repository" of all the microservices
applications, where the application is comprised of a number specifications. Additional information like status, ownership,
of smaller "independent" components; these components are can also be included.
small application in-themselves [1]. To put this in context,
consider an online ordering application for fixed line Independence is a key characteristic of microservices
telephone service. This application performs multiple architecture. To enable this characteristic a microservice
functions such as providing address validation, product should have "stewardship of the data" within its context, other
catalogue, customer credit check, etc. When using the microservice would allowed to read its data, however writes
microservice based architecture pattern, applications are would be performed thru that service. For e.g. a customer
created for address validation, customer credit check and account microservice would be the data steward for customer
online ordering, these application are cobbled together to accounts, other microservices can access read-only versions of
provide the ordering capability for the fixed line telephone customer account data. This allows the development team to
service. This approach to application development addresses take decision on what is the best suited data models,
the challenges of "monolithic" application and services. representation, persistence, etc. for the data assets they control,
without depending on an updates to the enterprise data models,
A microservice should be built around a subjective scope and freeing them from the overheads of enterprise governance
of "business-bounded context" and its concerns will apply to and release.
that functional context. This can be interpreted be mapped to
enterprise systems such as customer relationship management, A microservice normally comprises of three layers as a
payroll, etc or smaller functions within these systems such as typical 3-tiered application, consisting of an interface layer, a
customer account. A microservice should be "idenpendtly business logic layer and a data persistence layer, but within a
deployable". Each microservice has its own deployment much smaller bounded context. This sets a broad scope of the
architecture and would not share its resources like containers, technical capabilities that a microservice could possess,
caches, datastores with other enterprise software components. however not every microservice provide all capabilities, this
For e.g. where the microservice stores and retrieves would vary based on how the function provided is meant to be
information from a database, the database schema should be consumed. For example, a microservice used primarily by
part of the microservice. The scaling of one microservice is providers of API's would have communications interface
independent of other microservices, that is to say that layer, business logic and data persistence layers but not
microservices should be "loosely coupled". Increasing the necessarily have user interfaces.
capacity of a microservice, by moving its hosted target or by
increasing the number of instances, should not have any
impact on its consumers [6].

1857
Authorized licensed use limited to: The Technology Library. Downloaded on September 12,2024 at 14:52:19 UTC from IEEE Xplore. Restrictions apply.
 discussed above. This reference architecture model consists of
III. Microservice based Reference some key architectural components and building blocks,
Architecture Model and Key described below in detail, for implementing and managing
microservices in the context of enterprise architecture within
Building Blocks an organization.
In this paper, we present a microservice based reference
architecture model as following figure with clear
understanding and definition of the concept of microservice as
�� ob� n� evr.
M ��o� ��et-- -- -- -- -- �E�nt-e -��
r��eA
� pp �H �
-- -- -- -- -- - li�m�om""
Desiqn- TimeAPI Weorobles Microservices
Discovery Web-Browser MonitoringApplimtions
Mlcroservlce Consumer

Sensors SooS Applimtions

Develope API
Partner API
, - -------
Enterprise API
" ,
Gov nance

"lifecyde RetrieveMeii\

]
\

:
Management ,
r SessionManagement Aa:essContro/
AliI Specification
Security Auditing
u�, L Discovery l
Enterprise
API Proxy

APISped/imtion
API Realstry
Runtime
Forwarding and Routing Metering

�ore Con/iguratioo)
____-.-_______..-_____________..-

i API Provi er
d
A P
................................ .. / ����'.������l��� �
V
i r
d. .
� ..
API Provi er
d

�::.,,::! �p:;:: � unctiona(& (� � Interfac e layer rl Interface layer

rAPrPiiit er
Guides 'Technical J II
peCff1catlon
Enterprise ' I Business Losic layer Business Losiclayer

� - Enterprise Service

,
MIcroservIc:e Repository
II Persistencelayer II Persistence layer

DocumentManagement , API Data Converter

Wrapper
Mlcroservlce MIcroservIc:e

Logs
I

Metric5
Enterprise Service
Domain Information Model
.. (o To
',-------------------�� ····
gs ........ ............................................ · · · ·

Interface
Metrics
gs
Metrics

(.D.I!elate ', r>'/aitiframes SOAApplimtionl

.,.-------------
Collect
LEGEND
_ Outside Scope of Reference Model : �
: :8 Inform �I Enterprise

Visualize £rigs
Enterprise Monltorlna .. Traddna
_ LegacyApplimtionl
tj,!etrics I,partner Intearation
Scope of Reference Model
: �
I 0
=: Natify
Service Providers

_ Internal Component ,- ------------------------------------------- ,

Fig. 1. Microservice based Reference Architecture Model

by the business unit associated with billing processes and

A. Microservice Domain
activities.
When this microservice based architecture model is
applied at an enterprise level within an organization or A "microservice domain" also can be applied to enterprise
company, the resultant architecture of this application information management. In the case of the microservices
decomposition would consist of fine-grained building blocks, approach to information architecture is developer-centric, it
creating a proliferation of smaller applications or allows each microservice to have its own representation and
microservices. For example, the problem diagnostics function naming convention of common data entities like customer.
[3], is broken down into smaller blocks based on the various But this may not be able to scale at an enterprise with several
technology types, such as copper service diagnosis, fibre hundred microservices due to lack of a "common information
service testing, cable service diagnosis, etc., the flexibility model". In this case it will lead to the addition of mediation
afforded by a microservice means that each microservice can layers in microservices for semantic translations. As the
be built using different tools and technologies, scaled to an enterprise information model is too large and microservice
enterprise that generates complexity in management. information model is too fine, an information model should be
applied at an intermediate level of granularity. The
A "microservice domain" normally is a business logical "microservice domain" of enterprise information architecture
entity, that contains a collection of related microservices, its could provides this intermediate level where all microservices
purpose is to aid with managing the complexity associated within that logical domain would adhere to a "domain
with governing the problems related to proliferation of information model". The benefits of this would be multi-fold,
microservices, such as multiple data models, platform and for one it would increase interoperability within the domain as
technology proliferation, cross-dependencies to other all the microservices would speak the same language, it would
microservices, etc. The business functional domain would also provide consumers of the domains API's a common
serve as the boundary of the business logical container. It language for those functions, it also provides standards for
could be used to assign ownership from a business operations development of all microservices in that domain.
perspective, for example, microservices associated with
providing billing functions would be managed and governed

1858
Authorized licensed use limited to: The Technology Library. Downloaded on September 12,2024 at 14:52:19 UTC from IEEE Xplore. Restrictions apply.
B. Enterprise API Registry API, a mobile application developer to add "mobile user
The "discovery" requirements of the microservices are met verification" capability to their application thru the SMS API.
thru the use of the API registry service. Its purpose is to make These interfaces are supported as "public API's", agility and
the interfaces exposed by the microservice visible to simplicity are the key to these interfaces, they have simple
consumers of the services both within and outside the automated on-boarding processes and are characterised by the
enterprise. An "Enterprise API registry" is a shared use of industry standard security mechanisms like 'OAuth',
component across the enterprise, whose location must be well low degree of access, are subject to metering, usage throttling
known and accessible. Its information content is published in a and monetization.
standard format, information should be consistent and human
readable format, and must be access controlled. It must have D. Enterprise Microservice Repository
search and retrieval capabilities to allow users to look up The "enterprise microservice repository" would be a
details on available API specifications at design time. shared repository for storing information about microservices,
Additionally it must also provide information on the it provides information such as microservice lifecycle status,
operations provided by the API, its usage context and versions, business and development ownership, detailed
accessibility requirements such as security protocols. It can information like its purpose, how it achieves the purpose, tools,
also contain a runtime configuration of API destination URL, technologies, architecture, the service it provides, any API's it
thereby allowing the API proxy component to dynamically consumes, data persisted and queried, any specific non­
route API's to target URLs. It would also include the ability functional requirements. In the absence of well-defined
for API lifecycle management; it should provide a central repository standards, the enterprise must define its own
location for governance of the enterprise API portfolio. standard specification artefacts for microservices. This
representation like the microservice itself should be
C. API Proxy technology agnostic. In addition, this repository would also
The proxy or surrogate pattern has its origins in object­ contain supporting standards, guides and templates to be used
oriented programming as a GOF design pattern that is defined microservice design and specifications.
as "a placeholder for another object to control access". It
provides features such as providing protection to the E. Enterprise Service Wrapper
underlying resources, providing a known location for remote Most large enterprises have already invested in
resources, throttling, etc. To "de-couple" the microservice architectures like SOA and invariably have a significant part
from its consumers, this proxy pattern is applied at the of the core business logic and data on legacy software. A
microservice interface level, thru the "API proxy" component. transformation program to replace these will equivalent
Organizations will provide API's to a different consumers, microservices may not be forth coming in the short term. An
some of whom are within and others outside the enterprise. "enterpise service wrapper" component enables the access to
These microservices would differ by service level agreements these resources thru API technologies. It is an accessor
(SLA), security requirements, access levels, etc. The API's component that will hook into the enterprise resources like the
provided the proxy function can be grouped into three ESB and the legacy applications using Message Queuing, or
categories. SOAP or other technologies to expose services and make them
available as API's. It must also be able to perform
Enterprise API's: Consumers with the organization use the
transformation between to and from API data formats. A
"enterprise API's" within the organization, these would be
microservice like functional decomposition can be applied
characterised by lower security requirements, greater degree
when creating instances of this component, to align with the
of access, enterprise level SLA, unmetered and no throttling.
rest of the enterprise. This component is key in quickly
These API's would provide access to modify of core business
unlocking the core business capability for composition thru
entities and retr Partner API's: As a business grows, it partners . .
mlcroservlces.
with other businesses entities to provide it services or deliver
products, however a partner in one area can be a competitor in
another, and access must be restricted appropriately. As the F. Enterprise Monitoring and Tracking Manager
use of API's technology gains momentum, "partner API's" In any enterprise, operational intelligence is an important
can be used to integrate with partners outside the enterprise, decision-making tool and any analytics tool is highly
replacing traditional B2B integrations. "partner API's" would dependent on data. The fragmentation caused thru the
also be used in the scenarios where the services are hosted by deployment of microservices based architecture means there
providers outside the enterprise, such as services hosted on are multiple disparate sources of information based on
SaaS platforms. These will be characterised by greater security different implementations of microservices, each with a rather
thru the use of secure networks, greater deal of formality thru small subset of information. The enterprise monitoring and
negotiated and signed interface agreements, enterprise level tracking manager requires that all emitters (microservices and
SLA's, restricted access to a subset of API's.ieve protected other applications) publish standardized events (operational
information. and log events, metrics) which it would gather and store.
These emitters will include microservices and other enterprise
Public API's: As a provider of a service, a business could
applications. It would serve as a central collection of all events,
choose to provide its some of services to its developers as
on which various analytics operations can be performed, this
API's, enabling them to enhance their services. For example, a
store must store both current and historical data and can serve
telecommunications service provider can offer a SMS as a

1859
Authorized licensed use limited to: The Technology Library. Downloaded on September 12,2024 at 14:52:19 UTC from IEEE Xplore. Restrictions apply.
both business and operational intelligence functions. agreements of all these toolsets would be impossible at an
Operation teams can query the store for all events pertaining enterprise level. A "limited toolset" must be identified and
to a single transactions within a single microservices or across updated as required and all microservices must be developed
the entire lifecycle of the interaction. Basic events co-relation using the provided toolset at an enterprise level. The
can be used for real-time business activity monitoring. microservice based reference architecture model presented
reporting and dashboards must be supported for visualization. above could be used as the key reference to help both business
Event monitors could monitor the data streams for event types and IT professionals to assess and select the right technology
that require actions. and platforms for the implementation and management of the
enterprise microservices and APIs across the entire
organization.
IV. Key concerns and issues and
Recommendations V. Conclusions
From a business owner's perspective, the lines around This paper presents a microservice based reference
ownership of microservices are blurred. In an enterprise where architecture model with clear understanding and definition of
different lines of business pay for development and support of the concept of microservice and key architectural components
capabilities, it is conceivable that each create their own and building blocks for implementing and managing
architectures built around microservices. This may not be enterprise microservices in the context of enterprise
desirable from enterprise architecture perspective, as this leads architecture.
to duplication of across all areas of IT expenditure. A
governance structure or function can be created to govern the We believe that this reference architecture model can be
design and implementation of enterprise microservices across used as the pragmatic guidance for both business and IT
an organization, and a line of business can have complete professionals when they develop the enterprise IT
control over the microservices where business features are transformation architecture solutions so that the API and
significantly different to what exists in the microservice microservice relevant technologies could be used properly at
repository. enterprise level without confusion. This paper also highlights
a set of key architectural issues and provides corresponding
Microservices and API technologies are driven by the recommendations when APIs and microsevices are leveraged
emergence of the software and infrastructure available on the within a company at enterprise level.
Internet (Cloud). HTTP is one the foundational
communication protocol of the internet communications
architecture. Microservices and APIs' are built around the References
HTTP protocol for communication, which address many of
the interoperability concerns. However it does not provide the [I] Dmitry Namiot, Manfred Sneps-Sneppe. "On Microservices
guaranteed quality of service as expected of an enterprise Architecture" . International Journal of Open Information Technologies
communication system when a business function requires ISSN: 2307-8 162 vol. 2,no. 9, 20 14. p24-27

transaction management, atomicity, reliable delivery of [2] Mahmood,Zaigham. 'The Promise and Limitations of Service Oriented
messages, once-only delivery and broadcast event-driven Architecture'", INTERNATIONAL JOURNAL OF COMPUTERS Issue
3, Volume 1,2007,p76-77
actions. Further and more development efforts needs to be
[3] "Application Framework (TAM)'"
done around this area, with the potential to adapt some WS-*
https:llwww.tmforum.orgiBrowsable_HTML_Frameworx_RI5.0/mainI
for those enterprise level requirements.
[4] Chief Information Officer Council(200I) "A Practical Guide to Federal
A basic tenant of microservice based architecture is Enterprise Architecture'". Version 1.0

"choice of technology" when building microservices, this has [5] Erl, Thomas. "Service-Oriented Architecture: Concepts, Technology &
Design'",Prentice Hall/PearsonPTR,p32-37
great benefits from developers but not from enterprise
business perspective, as they are not tied into a specific stack [6] Newman,Sam. "Building Microservices'",O'Reilly Media,p4 10-420

or version of software. Considering the scenario where a few [7] Gartner, "Hype Cycle for Application Architecture'",2002, 2010, 20 15.

version of 100 microservices are built each with its own [8] API Architecture: The Big Picture for Building APls

unique set of toolset, tracking and managing license

1860
Authorized licensed use limited to: The Technology Library. Downloaded on September 12,2024 at 14:52:19 UTC from IEEE Xplore. Restrictions apply.