BROUGHT TO YOU IN PARTNERSHIP WITH

CONTENTS

Managing öö Overview

öö Microservices and FinTech: A Use

Case

Microservices
ö ö Microservices Benefits and
Requirements

ö ö How to Manage Microservices

ö ö DevOps + Microservices

ö ö Conclusion

WRITTEN BY ARIFF KASSAM

CHIEF TECHNOLOGY OFFICER, NUODB

environment and a customer base that demands innovation and rapid

Overview
The promise of microservices is the ability to increase developer agility delivery and, therefore, benefit greatly from the adoption of microser-

by breaking the application into smaller, more manageable components vices. Industries that require services to always be available, reliable,

with clear interfaces. As a result, making changes to a microservice and responsively scalable based on real-time demand benefit from a

requires less coordination between components and less testing. These move to microservices.

smaller components significantly improve the agility, scalability, and

availability of applications, which offers significant benefits to devel- Microservices and FinTech: A Use Case
Financial organizations have been facing significant competition and
opers as they seek to deploy new application features rapidly to meet
disruption due to the introduction, and now expectation, of technol-
customer demands.
ogy that allows end users to rapidly make mobile payments, transfer
While unquestionably adding to agility, microservices aren't for every ap-
plication. When starting with microservices, it's important to remember
that it's not something you can adopt in a vacuum. Microservices require
significant development and delivery skills, including security built in
and automated at every layer of development, a mature DevOps environ-
ment, and a high degree of standardization and automation using tech-
nology such as containers and Kubernetes for container orchestration.

While microservices can be used in any industry, right now it makes the
most sense to adopt them in organizations that use Agile development
methodologies and need to make changes to customer facing applica-
tions quickly. Highly regulated industries and those that use Waterfall
development methodologies and have less frequent software releases,
such as healthcare, government, oil and gas, and manufacturing, may
not benefit from a move to microservices architectures. Other indus-
tries, such as financial services, already have an agile development

1
Your microservices are portable,
flexible, and scalable.

Is your database?

Learn why NuoDB is the database to build your future on:

www.nuodb.com/financial-services

NuoDB’s cloud-native distributed SQL database helps enterprise

organizations overcome the complex challenges faced when trying to
move enterprise-grade, transactional applications to the cloud.

Learn more at nuodb.com.

 MANAGING MICROSERVICES

money, make or request loans, conduct fundraising, and access wealth occurred and what caused it without logging and monitoring tools. Due
management tools. FinTech, or financial technology, encompasses any to the fact that microservices break an application into many smaller
type of technology in financial services, from mobile payment apps to components, logging generates a lot of data, so it's helpful to choose
cryptocurrency. tools that help you parse or visualize the results. Prometheus is an open
source application used for event monitoring and learning.
FinTech originally referred to technology applied to financial institutions'
back-end systems, but today includes many more consumer-focused CONTINUOUS INTEGRATION (CI)/CONTINUOUS DELIVERY (CD)
applications, including smartphone apps to manage funds and make There are many continuous integration build systems available that pro-
payments, trade stocks, exchange cryptocurrency, and make budgets. vide access to pipeline builds, such as TeamCity, Bamboo, and Jenkins.
FinTech isn't just for consumers, however. It can also provide better Microservices scale extremely well, accommodating increasing numbers
financial services to businesses, such as expense tracking, accounting of users and transactions and delivering new functionality rapidly.
software, employee payment, and even sales tracking and invoicing. Responding in real time to demand isn't an option without an effective
implementation of a CI/CD solution.
Many banks and early FinTech companies were built on legacy systems,
which they've relied on as they build new apps and interfaces, but the INTEGRATION
shift towards digital services necessitates greater flexibility and agility. Microservices make it easier to manage and secure the API layer through

Microservices are a perfect fit, as financial services organizations seek isolation, scalability, and resilience. The APIs enable easy communica-

agility and scalability, but may require significant cultural and archi- tion with both internal and external services. Well-defined APIs enable

tectural shifts. A few important Agile and DevOps competencies for you to prevent dependencies between microservices while still enabling

application delivery teams looking to make the transition to microser- the exchange of data.

vices include:
SECURITY
• Security embedded in DevOps processes. When deploying microservices, it's important to build security into

• Continuous Integration and Continuous Delivery (CI/CD). your development processes. By embedding security processes and

• Automation of Core Infrastructure and Releases. automating them, it's possible to bolster security in your applications.
The platform used to deploy microservices should provide developers

Microservices Benefits and Requirements with options for identity and access control and authorization (such
PROGRAMMING LANGUAGE AGNOSTIC as OAuth), certificate management capabilities, automated security
Microservices do not force any specific programming model, style, or updates, periodic automated vulnerability and security scanning, and
language due to their technology independence. As each microservice control over the container images available for use to limit security risks.
communicates with other services through standard channels like APIs,
they don't rely on technology-related restrictions. This enables devel- DATA PERSISTENCE
opment teams to choose the programming language that works best for A microservices architecture isolates each microservice from the others,

each microservice, as well as choosing a particular pattern or database so you have a choice when addressing data storage and data persistence.

based on what's best for their use case. Using microservices and con- This is not the place to permit open access to a single monolithic

tainers, a single instance can host native code, .NET, Java, or any other database, which traditional monolithic development environments fre-

programming language that is the best fit for the particular microservice. quently allow. If your microservices can communicate with one another
through the database, you're likely to see unexpected coupling. Different
REGULATIONS microservices each own the data related to the business functionality
New regulations are emerging to address the evolving digital payment supported by that service, and they may require different options. Some
economy, which aim to address questions about the use and ownership of will best use a NoSQL storage system, while others require a SQL-based
data, operational resilience and business continuity, and increasing com- relational database. Regardless, each microservice should use unique
petition. In the European Union, the Payment Services Directive version credentials and access should be limited to that microservice's data.
2, or PSD2, aims to bring banking into the open API economy, which will Some examples of databases that pair well with microservices are:
drive interoperability and integration through open standards. In order to
meet these standards, financial services will benefit from the advantages • MongoDB, an open source NoSQL database.

microservices bring to APIs, integration, and open data requirements. • NuoDB Community Edition (CE), a free distributed SQL database.

LOGGING AND MONITORING CONTAINERS

Logging and monitoring go hand in hand with security, and are essential Containers are the most common deployment mechanism for micro-
for successful microservices deployment. Since microservices architec- services, in part because they deliver many of the same benefits that
ture is highly distributed, it can be hard to determine where a failure microservices offer, such as platform independence, scalability, isolation,

3 BROUGHT TO YOU IN PARTNERSHIP WITH

 MANAGING MICROSERVICES

resource efficiency, and speed. Because containers can easily be scaled resource efficiency, speed, and isolation. They also enable flexibility and
out and back, it's relatively simple to spin up a number of instances of scalability for organizations deploying applications, because containers
a specific version of your service for development, test, staging, and can easily be scaled out and back individually based on demand for
production environments. those services.

DISTRIBUTED SYSTEMS As containers have grown in popularity, managing them at scale is the
Microservices architecture enables the concept of decentralized data next real challenge, which created a need for container orchestration. In
management, supporting distributed deployment. Microservices de- response to this need, Google released Kubernetes as an open source
ployed in containers allow you to reprovision any container individually, platform for automating deployment, scaling, networking, managing,
or replace, deprecate, or add new microservices when there's a new and maintaining availability for container-based applications. Using
feature to release, a vulnerability to patch, a bug to resolve, or any other microservices, containers, and container orchestration tools together
change that you want to roll out rapidly. They're also simple to scale can simplify running applications in the cloud, which greatly improves
independently and responsively, so you can scale out based on demand business agility.
for a particular service without scaling the entire application.
Using microservices, containers, and container orchestration, develop-
LOAD BALANCING AND RESILIENCY ers now have on-demand access to IT resources and the architectural
In a microservices environment, load balancing functionality is typically paradigms that help them speed up the process of both development
moved into the software layer, performing the load balancing logic at and moving code from the dev environment to production. This signifi-
the distributed edge. Microservices also provide resiliency by handling cantly improves your ability to transform slowly maturing applications
errors through retries, queuing, deadlines, and default and caching into adaptable containerized microservices. This is particularly true
behaviors. When done correctly, microservices architecture can help when building applications that are stateless.
you deliver self-healing applications that operate even when there are
partial outages, automatically deploying new containers that allow your Building and deploying stateless applications in containers is relatively

application to recover quickly and seamlessly. easy. Every time you start a stateless application it has the same infor-
mation that it does every time you start it, which makes them easy to
MANAGING SERVICES scale horizontally to accommodate increased user demands (add more
When first starting with microservices, your microservices architecture
instances) and protect against failures (start new instances).
is likely to be small, and managing them seems simple. However, as the
number of microservices grows, you need to start thinking about the Many applications, however, require persistent state. That means that
macro-architecture of your microservices environment. There are many these applications require the ability to store data to protect against fail-
solutions that offer infrastructure, often referred to as service meshes. ures so that the application will not lose any data. Traditionally, stateful
Service meshes provide a control plane, which sets the policy that will applications have been much harder to fit into the world of containers.
be enacted by the data plane through configuration files, API calls, and While databases are the standard for managing state for applications,
user interfaces, and a data plane, which translates, forwards, and ob- traditional databases have a number of issues when managed by a
serves every network packet that flows to and from a service instance. container orchestration solution, typically Kubernetes.

• Linkerd is an open source service mesh that acts as a proxy EXTERNAL PROCESS LIFECYCLE MANAGEMENT
between services and provides load balancing, circuit breaking, Kubernetes automatically distributes running containers across the
service discovery, dynamic request routing, HTTP proxy integra- cluster, which is one of the advantages it provides. If a machine fails, any
tion, retries and deadlines, TLS, transparent proxying, distrib- containers running on that system are automatically restarted on other
uted tracing, and instrumentation. Protocol support includes nodes in the cluster. Kubernetes also automatically rebalances container
HTTP/1.x, HTTP/2, gRPC, and anything TCP-based. distribution periodically; it's fairly common for containers to be stopped
and then restarted on different nodes. Kubernetes controls the lifecycle
• Istio is another widely used open source service mesh and
management of container processes.
provides automatic load balancing, fault injecting, traffic shaping,
timeouts, circuit breaking, mirroring, and access controls for HTTP, It's important to note that this lifecycle management is simple for
gRPC, WebSocket, TCP traffic, automatic metrics, logs, and traces, stateless containers. Stateless containers can be started and stopped at
and infrastructure level run-time routing of messages. any time, and stateless containers can be run on any node in the cluster.
As long as you have at least one instance of the container running at any
How to Manage Microservices time, the service that application provides is always available.
With the rise of popularity of microservice architectures, containers are
now the best deployment mechanism for microservices. As noted above, Stateful containers aren't as flexible, partly because the state informa-
containers provide many benefits, including platform independence, tion needs to be accessible on any node to which the container can be

4 BROUGHT TO YOU IN PARTNERSHIP WITH

 MANAGING MICROSERVICES

moved. Kubernetes recently added container-native storage solutions components, which are owned by teams that can resolve issues that
to allow the state to be accessed in this way. Issues related to container prevent the system from operating properly.
lifecycle management remain, such as: to migrate a container from one
Most DevOps advocates consider CI and CD defining attributes of
node to the other, Kubernetes shuts down the current container and
DevOps. Continuous Integration allows developers to integrate changes
starts a new container. It's possible that the two container instances
into the source code mainline as soon as they're completed, which is
(new and old) briefly run concurrently during this time, which means
easier when creating microservices because there's less testing needed
that applications could connect to either instance.
when each component is built to operate independently. Likewise, Con-
Traditional databases can't handle this scenario, because there can only tinuous Delivery allows microservices to be updated as needed.
be a single "active" instance of the database at any given time. All data
Automating the process using CI/CD tools is also essential for successful
written to the database instance being shut down is lost while the new
adoption of DevSecOps, which is when security is automated and inte-
container becomes the active one. To work in containers and the Kuber-
grated within DevOps. Including (and automating) security tools into the
netes orchestration environment, databases must be capable of handling
DevOps process is essential, because there simply isn't time in a mature
multiple processes running at the same time without any data loss.
microservices environment for security to be an afterthought. To build
SCALE OUT an environment in which microservices and security co-exist, you must
By design, Kubernetes addresses performance issues by deploying more develop both a plan and a framework for development, governance, and
containers, thus enabling horizontal scale out. This horizontal scale out management of microservices.
is simple for stateless applications. However, because traditional data-
bases only support a single "active" process, they require scale up, not OPERATORS
scale out. Scale up doesn't translate well to the Kubernetes environment. Kubernetes Operators help encode the human operational logic

Kubernetes and containers are built to scale out based on demand, normally required to manage services running of a Kubernetes-native

using as many or as few processes as necessary to handle throughput. application and aim to make day-to-day operations easier. Operators

Traditional relational databases can't spawn new Kubernetes pods; that on application container platforms, such as Red Hat OpenShift and

would require a more expensive machine or necessitate that you shard Rancher, can help end users experience the next level of benefits from a

your database. To work well in Kubernetes, you need a database that Kubernetes-native infrastructure, with services designed to work across

can scale out for both reads and writes on demand, not one limited by a any cloud where Kubernetes runs. As microservices are typically deliv-

single server. ered via containers, Operators are an important part of the deployment
process for deploying stateful applications in Kubernetes.
CONSISTENCY
In scale out architectures, there are multiple instances of the container. Kubernetes Operators and operator catalogs, such as the new OpenShift

For stateful containers, it's important that clients are able to connect to OperatorHub and OperatorHub.io, take complicated technical solutions

any instance of the container and receive a consistent view of the data. and make deploying them simple. When Operators were first made

Different scale out databases have different consistency models. It's im- public in a 2016 CoreOS blog post, the goal of Operators was to make the

portant for application developers to understand the consistency model software itself include operational knowledge that previously resided

supported by the database they are using. outside of the Kubernetes cluster. Operators simplify that process by
implementing and automating the most common Day-1 and Day-2 activ-
For some applications, eventual consistency works. Some databases ities in a piece of software running inside the Kubernetes cluster.
are able to achieve high availability in distributed environments using
eventual consistency. With this consistency model, the application must Operators make the process of modernizing existing applications and

be able to handle consistency conflicts. This may require significant building new applications a lot easier. While Kubernetes has made it

application changes to support that ability. Many applications being mi- pretty easy to manage and scale web apps, mobile backends, and API

grated to the cloud and containers require a stricter consistency model, services, until recently it's been more difficult to manage stateful appli-

particularly applications handling business-critical data. cations such as databases, caches, and monitoring systems. The new
application domain knowledge contained in Operators makes it possible
DevOps + Microservices to scale, upgrade, and configure these types of applications in Kuberne-
DevOps is an evolving philosophy, and its goals are to tightly link the tes in multiple pods across the cluster.
development of
Using the Operator Lifecycle Manager (OLM), users can subscribe to an
software and its delivery to IT Operations, thus improving the quality Operator --- including individual channels, such as stable vs. beta releas-
of the software systems as a whole. Much like microservices, a DevOps es, so subscribers are continuously updated to the latest version and its
approach accomplishes this by segmenting the system into manageable new capabilities.

5 BROUGHT TO YOU IN PARTNERSHIP WITH

 MANAGING MICROSERVICES

Using microservices deployed in containers, application container

Conclusion
Cloud-native applications built on cloud-native infrastructure make it platforms, Kubernetes, and Operators, you bring many powerful tools

possible to increase the velocity of software delivery, enable devel- together. These solutions enable applications to scale well to accom-

opers to be more agile, and allow greater application scalability. By modate increasing numbers of users and transactions and deliver new

developing and delivering applications using microservices, contain- functionality rapidly, which is essential for distributed systems. As you

ers, and Kubernetes, technology innovators can deliver the agility, build new applications and redesign legacy applications, microservices

scalability, and availability of applications that modern businesses and will serve you well, provided you select solutions that portable, flexible,

consumers demand. and scalable.

In this Refcard, we've reviewed how microservices require the right infra-
structure and technical skills within your organization. While microser-
vices provide many advantages, there's a lot to consider when deploying
your microservices-based infrastructure. From the considerable benefits
of providing a programming language agnostic framework to the ability
to respond quickly to changing regulations to the tools and skills es-
sential for effective logging, monitoring, and integration, microservices
enable a new degree of flexibility that many developers and engineers
will be quick to embrace.

Written by Ariff Kassam, Chief Technology Officer, NuoDB

Ariff is responsible for defining and driving NuoDB’s product strategy. Kassam brings 20 years of database and
infrastructure experience to NuoDB to help the company achieve its vision of a distributed database that can manage
an organization’s most valuable data while exploiting the emerging benefits of modern infrastructures such as cloud
and containers.

Devada, Inc.
600 Park Offices Drive
Suite 150
Research Triangle Park, NC

888.678.0399 919.678.0300
DZone communities deliver over 6 million pages each month to
more than 3.3 million software developers, architects, and de- Copyright © 2019 Devada, Inc. All rights reserved. No part of this
cision makers. DZone offers something for everyone, including publication may be reproduced, stored in a retrieval system, or
news, tutorials, cheat sheets, research guides, feature articles, transmitted, in any form or by means electronic, mechanical,
source code, and more. "DZone is a developer’s dream," says PC photocopying, or otherwise, without prior written permission of
Magazine. the publisher.

6 BROUGHT TO YOU IN PARTNERSHIP WITH