Cloud Native Applications

OF VIEW

The main purpose of a digital transformation is to very rapidly build new applications, which are usually relatively small in terms of functionality, in order to improve the efficiency of an existing process. This mainly requires two things:

■A very good understanding of the process, to be able to pinpoint where it can be improved and therefore deliver the right application

■The ability to deliver applications very quicly, using up-to-date and state-of-the-art technologies.

Designing Cloud Native applications allows the development teams to focus on the added value of the application, its functionality, rather than wasting time and resources on aspects that are not part of the company’s core business. Putting the focus on delivering a solution to the business requirements, receiving feedback and then adapting the solution accordingly is very difficult when most of the energy is spent on other activities that don’t bring value to the application. Examples of such activities are infrastructure and environment management, code deployment, coordination between many teams (business analysts, developers, testers, installers, project management, operations, etc.), inadequate or obsolete tooling (versioning, build, etc.) and incorrect or obsolete architecture principles. These are all activities that slow down or prevent building the right app at the right time.

To achieve the challenge of their digital transformation, the banks must be able to focus 100% on the banking value of their applications, to ship functionality quickly and to adapt to feedback. It requires to leave behind all the activities that prevent them doing so. Adapting existing applications to be Cloud-Ready, and designing new applications to be Cloud-Native is a key to success.

3

Why Cloud Native?

CLOUD NATIVE

A cloud native application can be defined as an application that has been designed and implemented to run on a Cloud Platform installation and embrace horizontal elastic scaling.This article aims at defining the different concepts found in this short definition. What is really behind the term “Cloud”? What is a Cloud Platform? How to best design and implement an application for the cloud? First and foremost, why is it so important for a company like Sopra Banking to build cloud native applications?

Let’s digress for a moment and talk about electricity distribution. We are all used to connecting our various devices into standardised wall plugs and immediately using them. All electrical device manufacturers release their products with the same power cord and can industrialize their production around the 220V/50Hz retail standard (in Europe), usually by using standard components built by other companies.Electricity is produced by many different generators of different types (nuclear, oil, wind, …), is delivered on the transmission network and is shaped and distributed to the different types of consumers (retail, industry, railway, …) based on standards such as 220V/50Hz. When connecting a device to the endpoint, the user doesn’t know or care where and how the electricity was produced; they can just enjoy an available and reliable power source without having to produce it themselves.The analogy to cloud computing is easy to see, as Cloud services are produced from many datacentres all around the world (power generators), are based on many different technology stacks (generator types), and are distributed through the internet (transmission network) to consumers, web giants or individuals as disposable utility services (power plugs).

THIS MODEL HAS SEVERAL ADVANTAGES:

■For software creators to industrialize their production by relying on well-established standards. These development standards are already implemented by open source libraries or frameworks, which can be re-used immediately or adapted to fit requirements. ■For software creators to allocate every possible resource (time, budget, personnel) to building a valuable product for the consumer without wasting time and energy on replicating the environment on which it will be deployed and run. Thanks to Cloud Platforms, this environment is standardised with abstractions, as explained below. ■For consumers to request more and more power when it is necessary, and lower their consumption when it is not. From an IT perspective, additional servers are provisioned and released on the fly depending on the load, and the software running on them is cloned on these servers to answer that demand automatically. This is called horizontal elastic scaling. ■For consumers to enjoy the plug-and-play product thanks to a highly available and reliable service. The customers of Sopra Banking Software are counting on us more and more to deliver such plug-and-play products. From a software point of view, a plug-and-play product is a Cloud-Native application.

CLOUD SERVICES ARE DISTRIBUTED BY MANY DIFFERENT VENDORS (AMAZON, GOOGLE, IBM, ETC.) WITH DIFFERENT LEVELS OF ABSTRACTION, AS REPRESENTED IN THE FOLLOWING TABLE

4 5

Cloud and Cloud Platform

Application Resilience

Application Resilience

Application Resilience

TTRADITIONAL IAAS CAAS CLOUD NATIVE PLATFORM

(PAAS)

Your application code Your application

code Your application code Your application

code

User management User management User management

Aggregated Logging

Aggregated Logging

Aggregated Logging

Data

base

Data

base

Scal

ing

& Lo

ad

bala

ncin

g

Scal

ing

& Lo

ad

bala

ncin

g

Mes

sagi

ng

Mes

sagi

ng

Operating System

IAAS IAAS IAAS

PAAS

Physical Server

Container Orchestration

6 7

Infrastructure as a Service (IaaS) is the foundation of cloud computing. It offers servers, network, storage and other computing services under the form, usually, of virtual machines. The main IaaS actors are Amazon AWS, Google Cloud Platform, Microsoft Azure, IBM, Pivotal VMWare, etc. Note that the underlying infrastructure is not necessarily public. Solutions like VMWare or Azure can provision private infrastructure, therefore building what is called a private cloud.

Most of these actors also provide a container engine, for example Docker, as well as a scheduler to orchestrate these containers (Kubernetes, Docker Swarm, Mesos). These additional services are regrouped under the term Container as a Service (CaaS). Containers are an additional level of abstraction over the hardware and operating system. Concretely, the software running inside a container relies on the abstraction and is not aware about the hosting hardware and operating system. This allows the software editor to build such a container around the software and therefore be certain that it will run exactly the same way on any other infrastructure (e.g. the infrastructure of the bank). Containers effectively allow a plug-and-play delivery for the software and the usual 3rd party components it relies on (database, message broker, mail server, etc.). All in all, containers accelerate the development of software and its shipping and installation on the client side.

Next, a complete development and runtime platform can leverage this container engine. The responsibility of this platform is to provide the usual transverse components like databases, message brokers, build tools, microservice ecosystems, monitoring tools, resilience, log aggregation, etc. as services. This is called a Platform as a Service (PaaS). The number of different services, supported stacks and their level of abstraction differ depending on the offer. The main actors in this category are Heroku, Pivotal CloudFoundry, IBM BlueMix, Redhat OpenShift, Google App Engine and others.

To be able to leverage the advantages of a Cloud Platform completely, the design of the software must be adapted in order to avoid the potential pitfalls of distributed systems in general, and cloud platforms in particular.

As a reminder, a cloud-native application can be quickly defined as an application that has been designed and implemented to run on a Platform-as-a-Service installation and therefore to embrace horizontal elastic scaling.The journey to Cloud-Native can be developed around four main axes, as pictured below:

Cloud-Native application

ORGANIZATION

Small, domain-centric teams covering all aspects (dev, builds, test, deploy, delivery). Collaboration between devekopers and IT operation. Common incentives, process and culture.

AUTOMATION

Automated pipeline from requirements to

delivery. Each changes is a potential release.

Act of releasing is dull and reliable.

Quality of code.

ARCHITECTURE

Distributed systems. Loosely coupled components, bounded contexts. Each service can be deployed, upgrated, scaled and restarted independently.

CONTAINERIZATION

Package each application into a

standalone container. Virtualisation of the runtime enviroment.

Quotas and ports clearly described.

CLOUD NATIVE

DevOps

Microservices Containers

Continuous Delivery

The Twelve Factor App methodology is a bundle of 12 design principles, dispatched in all of the four axes described above, to guide architects and developers towards Cloud Native applications. They have been released initially by Heroku, one of the first public PaaS, to generalise good practices and facilitate the usage of their platform.These principles are agnostic of the technology used to develop the application, and can therefore be applied the same way to any language (if not, that language should not be considered at all for building modern applications).Explaining these 12 factors in detail goes beyond the scope of this article. Interested readers are invited to consult https://12factor.net/ where each principle is explained in much more detail. Here is a quick list of the 12 principles:

Twelve factor app methodology

9

While the organizational and cultural axis (DevOps) is a necessity to enable teams delivering cloud-native apps in good conditions, the other aspects can be developed progressively on both existing applications and new applications to help them reach the cloud. A kind of “cloud maturity model” can help teams to focus on key aspects:

The first stage, Cloud Ready, is actually a subset of 4 to 7 of the “12 Factor App methodology” from the Cloud Friendly level. Let’s have a look at these factors.

8

CLOUD READY

CLOUD FRIENDLY

CLOUD RESILIENT

CLOUD NATIVE

■ No permanent disk access ■ Self-contained application ■ Platform-managed ports

and networking ■ Consumes platform-

managed backing services

■ Fault-tolerant and resilient design

■ Cloud-agnostic runtime implementation

■ Bundled metric and monitoring

■ Proactive failure testing ■ 12 Factor App methodology

■ Horizontally scalable ■ Leverages platform for

high availability

■ Microservices architecture ■ API-first design

ONE CODEBASE, MANY DEPLOYS ■ One reference codebase for the app ■ Many environments from same codebase

BUILD, RELEASE, RUN ■ Strictly separate build and run stages ■ Release is build output + config

DEPENDENCIES ■ Explicitely declare dependencies ■ Never rely on system 3pp

STATELESS PROCESSES ■ Each request is independent ■ Share nothing, store in backing services

CONFIG IN THE ENVIRONMENT ■ Config vary between deploys ■ Store config in the environment

BACKING SERVICES ■ Treat backing services as resources ■ Datastores, queues, SMTP, cahes, ...

DISPOSABILITY ■ Fast startup, graceful shutdown ■ Manage backing services on shutdown

DEV/PROD PARITY ■ Keep all env. as close to prod as possible ■ In terms of code, tools, and personel

PORT BINDING ■ Self-contained app, embedded webserver ■ Expose services like HTTP through a port

LOGS ■ Treat logs as event stream ■ Collect them all into central place

CONCURRENCY ■ Scale by multiplying app instances ■ Easy when app is stateless

ADMIN PROCESSES ■ Run admin processes as one-off processes ■ Database migrations, maintenance scripts

Many of these principles are already applicable to any modern application, but they all become paramount as soon as the target is a cloud environment. Technologies, frameworks and open-source libraries like those provided by Pivotal in the Spring ecosystem make these principles easy to apply out of the box. Other container technologies such as Docker allow an existing app to embrace some of these principles without too much effort and reach Cloud-Ready maturity.

ConclusionNowadays, people expect more and more online services from their financial institutions such as continual availability. This is why we can witness the emergence of new directives like PSD2, expansion of the Fintech market and creation of alternative applications such as aggregators, payment processors, peer-to-peer lenders and new investment platforms.

For financial institutions, it is therefore important to react quickly to these market trends and provide the adapted software functionality. Relying on Cloud Computing to do so can greatly accelerate the release of these functionalities to their customers and also quickly react to their feedback. This is true for both proprietary cloud-native software but also for cloud-native software provided by creator like Sopra Banking Software. When both the creator and the financial institution rely on Cloud Computing, the delivery of software components can be made with better agility, since the same standards and level of abstraction are applied to the development and the execution of the software. Thanks to this, the costs for installation, infrastructure, environment management, testing and operations are greatly reduced, since the cloud platform brings a high level of automation to these tasks.

The benefits of Cloud Computing for a software editor like Sopra Banking Software are also obvious. Being able to focus on building banking added value and delegate all the expensive and repetitive tasks to a cloud platform allows the software application to be thinner, simpler to maintain and ready to evolve. It is necessary though to avoid the potential pitfalls of distributed systems and therefore design our applications appropriately, by adopting Cloud-Native principles up to a complete microservices architecture. With such a design, the financial institutions can enjoy the benefits of cloud computing: horizontal scaling, high availability, resilience and fast time-to-market.

1110

Authors : Olivier Ducarme & Jocelyn N’takpe

info@soprabanking.com

With over 3 500 experts and one of the deepest, broadest portfolios of software and services, Sopra Banking Software is a trusted, long-term partner of over 800 banks in more than 70 countries. Sopra Banking Software has an unequalled ability to address the requirements for banks and financial institutions of any size and scope, allowing them to innovate and expand their services. Cassiopae is part of the Sopra Banking Suite. Sopra Banking Software is a subsidiary of the Sopra Steria Group, a world leader in digital transformation, with more than 40 000 employees. In 2016, Sopra Steria achieved a pro forma turnover of € 3,7 billion.

www.soprabanking.com