Microservices-Based Software Architecture and

Approaches
Kapil Bakshi
Cisco Systems, Inc.
13635 Dulles Technology Drive
Herndon, VA 20171
703 484 2057
kabakshi@cisco.com

Abstract—In the last few years, a revised software architecture large, complex, monolithic applications. In a monolithic
style has been developed to design new software applications. approach, applications are decomposed into layered
This architecture style is particularly suited for use cases in the architectures such as model view controllers. However,
aerospace industry, from an independently deployable applications are still optimized with regard to the level of
software service. The microservices architectural style
functions that each of the applications are responsible for,
develops a single application as a suite of small services, each
running in its own process and communicating with therefore making them large and complex to manage. A
lightweight mechanisms. These services are built around monolithic application is an application where all of the
business and mission capabilities and independently logic runs in a single app server. Typical monolithic
deployable by fully automated machinery. With microservices, applications are large and built by multiple teams, requiring
some types of applications become easier to build and maintain careful orchestration of deployment for every change. They
when they are broken down into smaller, composable pieces usually have a large application code base, which often
that work together. Each component is then developed challenges new developers as they join a large project team.
separately, and the application is then simply the sum of its This then requires a significant amount of time to become
constituent components. This is in contrast to a traditional,
"monolithic" application which is all developed in one piece.
familiar with the code base. With monolithic applications,
This paper will discuss, several aspects of microservices-based even a small change might have a large ripple effect with
architecture, including several potential use cases for the regard to regression testing. Monolithic applications require
aerospace industry. The characteristics of microservice-based a built up history of a large suite of regression tests. This
architecture such as componentization, organization, endpoints adds to testing time cycles and also to the number of testers
and messaging mechanisms. The technical implementation of required, but missions and businesses want their teams to be
microservices by reviewing containerization, services able to respond to new requirements. Microservices allows
communication and related architectural components. Specific for more frequent delivery and faster delivery times. This
open source projects and components that can be utilized to enables application owners to receive quicker feedback and
build microservices-based architecture. A sample set of use
cases.
make adjustments to their requirements. Large monolithic
applications often have a large business scope and many
TABLE OF CONTENTS infrastructure touch points. Any change to the application
could result in multiple reviews and approvals, thus
1. INTRODUCTION ....................................................... 1
resulting in increased deployment cycle times. By adopting
2. ELEMENTS OF MICROSERVICES ............................ 1
a microservices architectural style with a single platform
enables service management teams to more easily support
3. MICROSERVICES ARCHITECTURE ......................... 5

multiple product and service teams. Efficiencies can be
4. SAMPLE AEROSPACE USE CASES .......................... 7
realized by automating deployment, logging, and
5. SUMMARY ................................................................ 7
monitoring practices across multiple microservices project
REFERENCES ............................................................... 8
teams. Hence, there is a strong impetus to review a new
BIOGRAPHY ................................................................. 8
architectural style for software applications.

1. INTRODUCTION 2. ELEMENTS OF MICROSERVICES

Today, there are several trends that are forcing application Microservices Defined
architectures to evolve. End users and missions expect a Microservices are small, autonomous services that work
rich, interactive and dynamic experience via the next together. [1] The key here is small and autonomous.
generation of clients, including mobile devices. Next Microservices is an architecture style, in which large
generation applications must be highly scalable, highly complex software applications are composed of one or more
available and be able to interface with cloud environments. services. Microservices can be deployed independently of
Organizations often want to frequently roll out updates on a one another and are loosely coupled and each of these
regular basis. Consequently, it is no longer adequate to microservices focuses on completing one task only.
develop simple, monolithic web applications that serve up Microservices support multiple clients in a typical
HTML to desktop browsers. Over the years, most enterprise architecture. Additionally, there are several factors to be
software applications have been designed and developed as considered in a typical Microservices based application,
978-1-5090-1613-6/17/$31.00 ©2017 IEEE

1
called 12-factor app, which will be reviewed in following componentizing their own software is by breaking down
section. into services, which are components who communicate with
a mechanism such as a web service request, or remote
Microservices Compared procedure call. The primary reason for using services as
Microservices is an independent unit of work, which is components (rather than libraries) is that services are
small enough to stand on its own in terms of functions. independently deployable. An application, which consists of
There must be zero coordination for the deployment with multiple libraries in a single process (perhaps a change to
other microservices. Loose coupling enables frequent and any single component), results in having to redeploy the
rapid deployments of applications, therefore, getting much- entire application. However, if that application is
needed features and capabilities to the consumers. An decomposed into multiple services, many single service
example of such comparison is portrayed in Table 1. changes will be required for that service to be redeployed.
Another reason for using services as components is a more
Microservices need to be built using the programming explicit component interface. Most languages do not have a
language that makes the most sense for the final outcome. good mechanism for defining; therefore, componentization
They are composed together to form a complex application with interfaces makes sense for microservices architecture.
and do not need to be written using the same programming
language. In some cases, Java may be the correct language, Monolithic application development efforts leverage the
and in others it might be Python. Communication with project model, where the goal is to deliver software, which
microservices is through language-neutral APIs, typically a is then considered to be complete on delivery. On
Hypertext Transfer Protocol (HTTP)-based resource completion, the software is handed over to a maintenance
Application Program Interface (API) such as REST. organization and the project team then moves to a new
project. The microservice approach leverages the
Continuous Development and Continuous Integration
(CI/CD) process where software is continuously developed
and features are also added. This process is constantly
integrated with a development, test, staging and production
environment.

Monolithic approaches require an intelligent communication

system for application layers, for example, Enterprise
Service Bus (ESB), where ESB products often include
sophisticated facilities for message routing, choreography,
transformation, and applying business rules. [2]

Microservices take an alternative approach: smart endpoints

and dumb pipes. [3] Applications built from microservices
decoupled their own logic, receiving a request, applying
logic as appropriate, and producing a response. This
Table 1: Comparing Monolithic and Microservice communication is done using simple RESTish protocols
Architecture. [2] rather than complex protocols such as WS or BPEL or
orchestration by a central tool. Additionally, the common
Characteristics of Microservices use is messaging over a lightweight message bus. The
infrastructure chosen is typically dumb simple
There are several characteristics that need to be considered implementations such as RabbitMQ or ZeroMQ, which
in a microservices architecture. We will review and provide a reliable asynchronous fabric. The intelligence still
enumerate this below. exist in the endpoints that are producing and consuming
messages in the services.
Microservices need to be designed around business
capabilities. This approach takes a broad-stack Microservices with CI/CD require infrastructure automation
implementation of software for that business area, including techniques. In this model, teams automate deployment to
user-interface, persistent storage, and any external each new environment. Another area where development
collaborations. As a result, teams are cross-functional, with teams use infrastructure automation is for managing
a full range of skills required for the development: user- microservices in production.
experience, database, and project management. [3]
Since microservices are designed as service components,
The above characteristics imply that one has to follow the applications need to be designed so that they can tolerate the
componentized model for services. Hence, a component is a failure of services. Any service call could fail due to
unit of software that is independently replaceable and unavailability of the infrastructure. This is a disadvantage
upgradeable. [3] Microservice architectures can use compared to a monolithic design as it introduces additional
traditional libraries, but their primary way of complexity. The consequence is that microservice teams are
2
aware of how service failures affect the end-user experience. 12-Factor Application Method and Microservices
Netflix's Simian Army induces failures of services,
A common methodology, called the 12-Factor App
including datacenter processes during the working day to
methodology, has emerged with the purpose of providing an
test both the application's resilience and monitoring. [3]
outline for building well-structured and scalable
Services can fail at any time, therefore, it is important to
applications with the microservices approach. The
detect failures quickly and automatically restore service.
application deployment process can be complicated and
Microservice applications put a lot of emphasis on real-time
extensive. Virtualization, networking, and setting up
monitoring of the application, checking both architectural
runtime environments are just a few of the challenges
elements (such as how many requests per second is the
involved. The 12-Factor App methodology helps to create a
database receiving) and business relevant metrics (such as
framework for organizing the process in order to maintain a
how many orders per minute are received). Microservice
healthy and scalable application. [4] The following
teams would expect to see monitoring and logging
paragraphs explain how to meet the standards of the 12-
approached for each individual service such as dashboards
Factor App methodology, while addressing application
showing status and a variety of operational and business
infrastructure and deployment setup.
relevant metrics. Details on circuit breaker status, current
throughput and latency are other examples of this Codebase
characteristic.
A 12-Factor App has a version control system such as git. A
The microservices approach works well with copy of the revision-tracking database is known as a code
decentralization of logic and data. At an abstract level, the repository. A codebase is any single repository or in any set
application is divided into separate components. Another of repository that shares a root commit. [4] A 12-Factor App
way to consider decentralization is the Domain Driven requires one-to-one correlation between the codebase and
Design (DDD) notion of Bounded Context. [3] DDD the application. If there are multiple codebases, it is a
divides a complex domain into multiple bounded contexts distributed system with many applications. Each component
and maps out the relationships between them. This process in a distributed system is an application, and each can
is useful for both monolithic and microservice architectures, individually comply with 12-Factor. Multiple applications
but there is a natural correlation between service and context sharing the same code is a violation of 12-Factor. There is
boundaries that helps clarify, and as we describe in the only one codebase per application, but there will be many
section on business capabilities, reinforce the separations. deploys of the app. A deploy is a running instance of the
Microservices also decentralize data storage decisions. application. This is typically a production site and one or
While monolithic applications prefer a single-logical more staging sites.
database for persistant data, Microservices prefer letting
each service manage its own database, either different
instances of the same database technology, or entirely
different database systems, also called Polyglot Persistence.
One can use Polyglot Persistence in a monolith, but it
appears more frequently with microservices.

The Microservice design stipulates that the application be

broken into several service components: governance and
management approaches also need to be considered. The
monolothic approach is a centralized governance, which
implies a tendency to standardize on single technology Figure 1. Code Base Repository [4]
platforms. This approach can be too restricting. By splitting
the monolith's components out into services, we have a Additionally, every developer has a copy of the app running
choice when building each of them in languages and styles. in their local development environment, each of which also
Development teams can code each service in the language qualifies as a deploy.
they are comfortable with — namely, Node.js, Python, Java
or C++. One can apply the same approach to database Dependencies
platforms. Teams that are building microservices prefer a
A 12-Factor App declares all dependencies; it never relies
different approach to standards. Rather than use a set of
on implicit existence of system-wide packages via a
defined standards, they prefer the idea of producing useful
dependency declaration manifest. An explicit dependency
tools that other developers can use to solve similar problems
specification is applied to both production and development.
to the ones they are facing. These tools are usually harvested
[4] The advantage of explicit dependency declaration is that
from implementations and shared with a wider group;
it simplifies setup for developers new to the application. The
sometimes, but not exclusively using an internal open
new developer can check out the codebase onto their
source model. Examples such as git and github have become
development machine, requiring only the language runtime
the de facto version control system of choice.
and dependency manager installed as prerequisites. They
will be able to set up everything needed to run the app’s

3
code with a deterministic build command. 12-Factor Apps database is misbehaving due to a hardware issue, the app’s
also do not depend on the implicit existence of any system administrator might spin up a new database server restored
tools. These tools may already exist on deployment and test from a recent backup.
systems, but there is no guarantee that they will exist on all
systems where the app may run. Build, Release and Run
A codebase is delivered to deployment through three stages
Config
— Build, Release and Run. First stage is Build, which
An app’s config typically changes from different converts a code repo into an executable bundle. Using a
deployment environments like staging, production, and version of the code at a commitment specified by the
development. The config could include resource handles to deployment process, the build stage gathers dependencies
databases, credentials to external services, host names, etc. and compiles binaries and assets. [4] Second stage is
12-Factor requires strict separation of config from code, as Release, which takes the build produced by the build stage
config varies across deployments, while code does not. [4] and combines it with the deploy’s current config. The
One approach to config is the use of config files, which are release contains both the build and the config and is ready
not checked into revision control. However, there is a for execution in the deployment environment. The third
tendency for config files to be scattered in different places stage is Run, which runs the app in the execution
and different formats, making it hard to see and manage all environment by launching some set of the applications
in one place. Another approach is to store config in against a selected release. A 12-Factor App uses a strict
environment variables. Env vars are easy to change between separation between the build, release, and run stages. Builds
deploys without changing any code. Yet, another approach, are initiated by the application’s developers whenever new
to config management is grouping. Sometimes apps batch code is deployed. Runtime execution happens automatically
configs into named groups (often called “environments”) in cases such as a server reboot or a crashed process being
named after specific deploys such as the development, test, restarted by the process manager. Hence, the run stages
and production environments. In a 12-Factor application, should be simple and constant, since there are problems that
env vars are granular controls, each disjointed to other env prevent an app from running. The build stage can be more
vars. This is a model that scales up smoothly as the app complex since errors are always in the foreground for
naturally expands into more deploys over its lifetime. developers who are managing the deployment.

Backing Services Process

A backing service is a service the application consumes over The application is executed in an environment as one or
the network as part of its normal operation. [4] Examples more processes. On one end of the continuum, the code is a
include datastores, messaging/queueing systems, SMTP stand-alone, and the execution environment is a developer’s
services for outbound email, and caching systems. This also local system with an installed language runtime. [4] On the
includes third-party and non-traditional (like cloud) other end of the spectrum, a production deployment of a
services. The code for a 12-Factor app makes no distinction sophisticated app may use many processes. 12-Factor
between local and third-party services. A deployment of the processes are stateless and share-nothing, hence any
12-Factor app should be able to swap out a local database persistent data needs to be in a backing service, typically a
(MySQL) with one managed by a third party (such as database. The memory space or file system of the process
Amazon S3) without any changes to the app’s code. Each can be used for a single-transaction cache; for example,
distinct backing service is a resource. For example, a downloading a large file, operations, and storing the results
MySQL database is a resource. of the operation in the database. The 12-Factor App assumes
that any data cached in memory or on disk will be
unavailable for job request. Some web-based systems rely
on caching user session data in memory of the process and
expect future requests from the same visitor to be routed to
the same process. Sticky sessions are a violation of 12-
Factor and should never be used or relied upon. Session
state data is a good candidate for a datastore that offers
time-expiration.

Port Binding
12-Factor Apps are sometimes executed inside a webserver
container and completely self-contained and do not rely on
Figure 2. Backing Services [4] runtime injection of a webserver into the execution
environment to create a web-facing service. [4] The web
The 12-Factor treats these databases as attached resources, app exports HTTP, as a service by binding to a port and
which implies loose coupling. Resources can be attached listening to requests coming in on that port. In a local
and detached to deploy at will. For example, if the app’s development environment, a service URL, for example,

4
http://localhost:5000/, is used to access the service exported Logs
app. In deployment, a routing layer handles routing requests
Logs provide a time-ordered status of processes and backing
from a public-facing hostname to the port-bound web
services of an application and are typically written to disk
processes. This is implemented by using dependency
files. A 12-Factor App should not attempt to write to or
declaration to add a webserver library to the app. This
manage logfiles. During local development, the developer
happens entirely in the user space, that is, within the app’s
views streams in the foreground of their terminal to observe
code. The contract with the execution environment is
the process behavior. [4] In staging or production deploys,
binding to a port to serve requests.
each process stream will be captured by the execution
Concurrency environment, collated together with all other streams from
the app, and routed to one or more final destinations for
In the 12-Factor App, processes are first-class citizens [4]. viewing and long-term archival. These archival destinations
Processes in the 12-Factor App are built on a unix process are not visible to or configurable by the application, and
model. Using this model, the developer can architect the instead, are completely managed by the execution
application to handle diverse workloads by assigning each environment.
type of work to a process type. For example, HTTP requests
may be handled by a web process, and background tasks Administration Process
handled by a worker process. This process model is a scale-
In a 12-Factor App, admin tasks should be run as a one-off
out approach. The share-nothing, partitioned process
process. Developers often utilize one-off administrative or
architecture provides a simple approach to concurrency. 12-
maintenance tasks for the app such as, database migrations,
Factor App processes should leverage the operating
console or to inspect the app’s models against the live
system’s process manager to manage task output streams
database. [4] One-off admin processes should be run in an
and handle user-initiated restarts and shutdowns.
identical environment as the regular long process of the app,
Disposability and against a release, using the same codebase and config.
The admin code must ship with the application code to
The 12-Factor Apps processes are disposable, as they can be avoid synchronization issues.
started or stopped easily and instantaneously. [4] This
enables fast, elastic scaling, rapid deployments of code and Additional Considered factors
configs. Short process startup time provides agility scaling
There could be additional factors to consider include
up and movement of process to different deployment setups.
Scaling services, via mechanisms like auto scaling and load
Typically, a process takes a few seconds to launch, until the
balancers. Also integration of desperate services with
process is available to receive requests or jobs.
external service also needs to be considered. Additionally,
Consequently, a proper process shutdown is done by
deugging techniques also need to be considered. Finally,
returning the current job to the work queue. A
security requirements would also need to be reviewed in the
recommended approach is to use a robust queueing backend
microservices architecture.
that returns jobs to the queue when clients disconnect or
time out. Processes should also be robust against sudden
death, in the case of a failure in the underlying hardware. A 3. MICROSERVICES ARCHITECTURE
12-Factor App is architected to handle unexpected, non- Microservices architecture consists of several components.
graceful terminations. These components work together to provide distributed
services that have been discussed in the previous sections.
Development and Production Parity The key components are as follows.
The gaps between development and production
environments are typically due to either time gap, as Containers
development releases code and operations deploy it, or a Containers have been in deployments for some time now in
tool gap between developers and operations team as they the form of Linux containers and several commercial
may use different tools. A 12-Factor App is designed for implementations (like Dockers). Linux containers are self-
continuous development with minimal gap in environments. contained execution environments with their own isolated
[4] Additionally, the 12-Factor App should use the same CPU, memory, block I/O, and network resources that share
backing services between development and production, even the kernel of the host-operating system. [5] The experience
when adapters abstract away any differences in backing is like a virtual machine, but without the weight and startup
services. Differences between backing services could mean overhead of a guest operating system.
incompatibilities, defeating the purpose of continuous
deployment. Adapters to different backing services are still Two key elements of containers are Linux cgroups
useful because they make porting to new backing services and namespace, the Linux kernel features that isolate
relatively simple. But all deploys of the app (developer containers and other processes running on the host. [5]
environments, staging, production) should be using the Linux namespaces, originally developed by IBM, wrap a set
same type and version of each of the backing services. of system resources and present them to a process to make it
look like they are dedicated to that process. Linux cgroups,

5
originally developed by Google, govern the isolation and packages and utilities necessary for a containerized
usage of system resources such as CPU and memory for a application to run.
group of processes. For example, if you have an application
that takes up a lot of CPU cycles and memory such as a Services Communication
scientific computing application, you can put the application In a monolithic application, components are invoked via
in a cgroup to limit its CPU and memory usage. function calls. In contrast, microservices-based services
Namespaces deal with resource isolation for a single interact using an Inter-Process Communication (IPC)
process, while cgroups manage resources for a group of mechanism. When selecting an IPC mechanism for a
processes. service, it is important to consider services interaction. One
dimension is whether the interaction is synchronous or
asynchronous. With synchronous interaction, the client
expects a timely response from the service and might even
block while it waits. With asynchronous interaction, the
client does not block while waiting for a response.
Additionally, there are other types of one-to-one interactions
— namely, request/response where a client makes a request
to a service and waits for a response. Notification occurs
where the client sends a request to a service, but no reply is
expected or sent. Request/async response is where a client
sends a request to a service, which replies asynchronously.
There are different types of one-to-many interactions:
Publish/subscribe, where client publishes a notification
message, which is consumed by zero or more interested
services; Publish/async responses, where a client publishes a
Figure 3. Container Architecture for Applications request message, and then waits a certain amount of time for
responses from interested services. Each service typically
Image-based containers package applications with uses a combination of these interaction styles. Let us review
individual runtime stacks, making the resultant containers the IPC mechanisms that a developer can implement in
independent from the host-operating system. Thus making it microservice architecture.
possible to run several instances of an application, each
developed for a different platform. [5] This is possible IPC Technologies
because the container run time and the application run time
are deployed in the form of an image. There are several IPC mechanisms that can be applied to
microservices. Services can use synchronous request/
response-based communication mechanisms such as HTTP-
based REST or Thrift. Alternatively, they can use
asynchronous, message-based communication mechanisms
such as Advanced Message Queuing Protocol (AMQP). [6]

In an asynchronous system, client makes a request to a

service by sending it a message. If the service replies, it
sends a separate message back to the client. Since the
communication is asynchronous, the client does not block
waiting for a reply. Instead, the client is written assuming
that the reply will not be received immediately. There are a
Figure 4. Image-Based Container large number of open source messaging systems to choose
from, including RabbitMQ, Apache Kafka, Apache
Figure 4 describes a typical image-based container. ActiveMQ.

A container is an active component in which an application When using a synchronous, request/response-based IPC
runs. Each container is based on an image that holds mechanism, a client sends a request to a service. The service
necessary configuration data. When a container is launched processes the request and sends back a response. In many
from an image, a writable layer is added on top of this clients, the thread that makes the request blocks while
image. An image is a static snapshot of the container’s waiting for a response. There are numerous protocols to
configuration and is a read-only layer. All changes are made choose from. Two popular protocols are REST and Thrift.
in a top-most writable layer and can be saved only by Let us first take a look at REST.
creating a new image. Each image depends on one or more
parent images. A Platform Image is an image that has no
parent. Platform images define the runtime environment,

6
Service Registry and Discovery example, imagine that a space flight experiences an
intermittent hydraulic fault code. The equipment health
In a microservices application, the set of running service
monitoring system performs a local analytics service and
instances changes dynamically, including network locations.
sends a notification message to the ground station where
Consequently, in order for a client to make a request to a
maintenance control personnel run the fault detail service.
service, it must use a service-discovery mechanism. A key
After identifying the likely problem, maintenance control
part of service discovery is the service registry. The service
orders a mitigation process. When the aircraft lands, the
registry is a database of available service instances. The
ground crew replaces the pressure transmitter during the
service registry provides a management API and a query
scheduled cleaning and refueling time. In this use case, the
API. Service instances are registered with and deregistered
microservices performed the predictive analytics locally and
from the service registry using the management API. The
only transmitted the notification to the ground crew.
query API is used by system components to discover
Consequently, the equipment health data can be locally
available service instances. There are two service-discovery
collected and then transferred to a core data center for batch
patterns: client-side discovery and service-side discovery. In
historical and trend services.
systems that leverage client-side service delivery,
clients query the service registry, select an available Manufacturing Visibility and Management
instance, and make a request. In systems that use server-side
discovery, clients make requests via a router, which queries A microservices-based architecture for manufacturing can
the service registry and forwards the request to an available provide aerospace production line information to
instance. There are two methods where service instances are manufacturing plant staff and improves factory efficiency.
registered with and deregistered from the service registry. For example, a plant manager on the production floor could
One method is for service instances to register themselves also use connected floor and visibility tools to access the
with the service registry, the self-registration. The other efficiency of each machine, view production from any
method is a system component to handle the registration and location, and reduce the time to decision and action. The
deregistration on behalf of the service. In deployment manufacturing facility and equipment assembly line can be
environments one needs to setup a service-discovery connected to a service that will collect real-time data on the
infrastructure using a service registry such as etcd and status of the plant. So, instead of managing a control room,
Apache Zookeeper. In other deployment environments, facilities managers and production personnel can have easy
service discovery is built in. For example, Kubernetes will access to real-time information and collaborate more
service instance-registration and deregistration. effectively. For example, if there is a quality control
problem on a production line, they can shut down the line
4. SAMPLE AEROSPACE USE CASES before it continues to create products where possibly all
products could be wasted. The benefits of this architecture
There are several aerospace-specific use cases that can be can extend beyond the enterprise to a wide range of
implemented by adopting a microservices-based approach suppliers and third-party providers of services,
and architecture. This section provides a selection of use consumables, and capital goods.
cases that could be leveraged by the aerospace industry, as
well as other industries. 5. SUMMARY
Mission Data Analytics Whether or not microservices architecture becomes the
preferred style of developers in the future, it clearly has
Data Analytics is traditionally real time, batch, and archived
strong benefits for designing and implementing
in nature. Technically, the solution involves accessing
applications. However, as with gaining adoption of any new
aerospace sensor data from a digital source. If the sensors
technology, there are a few challenges, for example,
are analog, there needs to be some component within the
incorrect requirements. If we start with requirements that are
architecture that converts the analog data to digital, for
wrong, it will not matter how fast we can develop, deploy,
example, with an Analog-to-Digital (AD) device in the
or scale a system. There is also a lack of frameworks to
field. The analytics services can be developed to perform
support this from an operational perspective. Additionally,
small tasks, which can collectively give the outcome of
substantial DevOps skills are required to keep microservices
mission. The key here is that different services can be
running and available. Finally, when breaking an existing
running on a variety of systems and invoked independently.
monolithic system into collaborating components, you are
For example, the edge analytics service can be run on a
introducing interfaces between them. Each interface requires
network edge device (like a router), and batch service on a
maintenance across releases, despite some capabilities
Hadoop cluster at the data center.
available using leading practices such as compatibility with
Equipment Health Monitoring earlier versions. In the future, we expect to see standards for
describing microservices. Currently, one can use any
The deployment of equipment health monitoring and technology to create a microservice, if it exposes JavaScript
predictive analytics technologies promises to deliver Object Notation (JSON) or Extensible Markup Language
benefits to aerospace and defense companies. Microservice (XML) over the HTTP to provide a REST API. Thus the
architecture can be implemented for this use case. For future of the microservices approach is promising and

7
applications would overtime migrate to this revised BIOGRAPHY
architecture.

REFERENCES
[1] Newman, S. (February 2015). Building Microservices.
USA: O’Reilly Media Inc.

[2] Daya, S., Duy, N., Eati, K., Ferreira, C., Glozic, D.,
Gucer, V., Gupta M., Joshi, S., Lampkin, V., Martins, M., Kapil Bakshi is a Distinguished
Narain, S., Vennam, R. (August 2015) Microservices Systems Engineer for Cisco Systems, Inc. He is
from Theory to Practice. IBM Redbook. responsible for leading and driving Analytics, data center
and cloud computing strategy and initiatives in the U.S.
[3] Fowler, M., Lewis, J. (March 2014). Microservices. public sector. Kapil has extensive experience in
http://www.martinfowler.com/articles/microservices.html strategizing, architecting, managing, and delivering data
#CharacteristicsOfAMicroserviceArchitecture center solutions. During his career he has held several
architectural, consulting, and managerial positions
[4] Wiggins, A. (Jan 2012). The twelve factor app. within the industry. Prior to Cisco, Kapil worked for Sun
https://12factor.net/concurrency Microsystems where he spent a decade working with the
U.S. Government and service provider customers. Prior
[5] Mouat, A. (December 2015). Using Dockers. USA: to Sun Microsystems, he worked for Hewlett-Packard and
O’Reilly Media, Inc. several government system integrators in consulting and
product development roles. Kapil is a native of
[6] Morris, K. (June 2016). Infrastructure as a Code. USA: Washington, D.C., and holds both a BS in electrical
O’Reilly Media, Inc. engineering and a BS in computer science from the
University of Maryland, College Park, as well as an MS
in computer engineering from Johns Hopkins University,
and an MBA from the University of Maryland, College
Park. He also holds U.S. patents for data center and
related solution sets.