GCP Cloud Native

Reference Architecture R20 v1.0, April 2020

GCP Cloud Native Reference Architecture R20 v1.0

Contents
GCP Cloud Native ................................................................................. 1
Reference Architecture R20 v1.0, April 2020 ........................................ 1
1 About this document ........................................................................ 3
1.1 History ................................................................................................................................ 3
1.2 Legal .................................................................................................................................. 3

2 Introduction ...................................................................................... 5
2.1 GCP architecture diagram .................................................................................................. 6
2.2 Virtual Private Cloud (VPC) ................................................................................................ 7
2.3 Users .................................................................................................................................. 7

3 Peripheral services........................................................................... 8
3.1 Google Cloud DNS ............................................................................................................. 8
3.2 Internet gateway ................................................................................................................. 8
3.3 On premise connectivity ..................................................................................................... 9
3.4 API gateway ....................................................................................................................... 9
3.5 Cloud Key Management Service ...................................................................................... 10
3.6 GCP Firewall .................................................................................................................... 10
3.7 Cloud Armor Web Application Firewall ............................................................................. 10
3.8 Third Party WAFs ............................................................................................................. 11
3.9 Google Cloud load balancer ............................................................................................. 11
3.10 Google Container Registry ............................................................................................... 12
3.11 Message broker ............................................................................................................... 12

4 Google Kubernetes Engine (GKE) .................................................13

4.1 Automating containers...................................................................................................... 13
4.2 About Google Kubernetes Engine (GKE) ......................................................................... 13
4.3 Kubernetes cluster diagram ............................................................................................. 14
4.4 Kubernetes terminology ................................................................................................... 14

5 Deployment on GKE ......................................................................17

6 Microservices .................................................................................18
7 Logging and monitoring .................................................................18
8 Database ........................................................................................19
8.1 NuoDB.............................................................................................................................. 19

2
GCP Cloud Native Reference Architecture R20 v1.0

1 About this document

1.1 History

Version Date Change Author

1.0 March 2019 First release Jumpstart team

1.1 April 2019 Broker corrections Jumpstart team

1.2 Legal
© Copyright 2019 Temenos Headquarters SA. All rights reserved.

The information in this guide relates to TEMENOSTM information, products and

services. It also includes information, data and keys developed by other parties.

While all reasonable attempts have been made to ensure accuracy, currency and
reliability of the content in this guide, all information is provided "as is".

There is no guarantee as to the completeness, accuracy, timeliness or the results

obtained from the use of this information. No warranty of any kind is given,
expressed or implied, including, but not limited to warranties of performance,
merchantability and fitness for a particular purpose.

In no event will TEMENOS be liable to you or anyone else for any decision made or
action taken in reliance on the information in this document or for any
consequential, special or similar damages, even if advised of the possibility of such
damages.

TEMENOS does not accept any responsibility for any errors or omissions, or for the
results obtained from the use of this information. Information obtained from this
guide should not be used as a substitute for consultation with TEMENOS.

References and links to external sites and documentation are provided as a

service. TEMENOS is not endorsing any provider of products or services by
facilitating access to these sites or documentation from this guide.

The content of this guide is protected by copyright and trademark law. Apart from
fair dealing for the purposes of private study, research, criticism or review, as
permitted under copyright law, no part may be reproduced or reused for any

3
GCP Cloud Native Reference Architecture R20 v1.0

commercial purposes whatsoever without the prior written permission of the

copyright owner. All trademarks, logos and other marks shown in this guide are the
property of their respective owners.

4
GCP Cloud Native Reference Architecture R20 v1.0

2 Introduction
Our GCP Cloud Native Reference Architecture, though tried and tested, is a
model architecture. You’re free to change any part of it to meet your particular
requirements.

We designed this architecture for T24 Transact, our next generation core banking
solution. T24 Transact is a classic three tier application – Web, Application and
Database. We’ve included the message broker for scalability and availability
reasons.

Our reference architecture is designed to run in containers in the public GCP cloud.
The containers run on GCE, of course. That’s different from traditional on premise
architectures, which are installed and run on either virtual or physical hardware.

5
GCP Cloud Native Reference Architecture 1.0

2.1 GCP architecture diagram

6
GCP Cloud Native Reference Architecture 1.0

2.2 Virtual Private Cloud (VPC)

Whether it’s on premise or cloud, it’s important that your network is safe and secure
from the rest of the world. VPC is your own isolated and secure cloud within the
public GCP cloud.

VPC also gives you your own private address space.

2.3 Users
Our channels users are internet users. Our branch users are the bank’s employees
and their customers, who are accessing the bank’s system from a branch.

You usually make branch connections through a secure VPN, but our architecture
needs Internet gateways and API gateways – this ensures that our infrastructure is
safe from the internet.

7
GCP Cloud Native Reference Architecture R20 v1.0

3 Peripheral services
3.1 Google Cloud DNS
DNS servers play a very important part in your architecture, if you’re exposing part
of your architecture over the internet. We use DNS servers:

 With both on premise and cloud architectures.

 To translate website names like www.bankoflife.com to IP addresses like

10.23.5.78.

Google Cloud DNS is a scalable, reliable and managed authoritative Domain Name
System (DNS) service running on the same infrastructure as Google. It has low
latency, high availability and is a cost-effective way of making your applications and
services available to your users.

Google Cloud DNS is programmable. You can easily publish and manage millions
of DNS zones and records using its simple user interface, command-line interface
or API.

For more information, see https://cloud.google.com/dns/

3.2 Internet gateway

Google has a built in internet gateway that can be specified from routing rules.
Default system routes allow instances with public IP addresses to communicate
over the internet.

If your architecture includes instances without public IP addresses and private

Google Kubernetes (GKE) clusters to connect to the internet then Cloud NAT is the
solution.

For more information, see https://cloud.google.com/nat/docs/overview

8
GCP Cloud Native Reference Architecture R20 v1.0

3.3 On premise connectivity

Cloud VPN securely connects your on premise network to your GCP Virtual Private
Cloud (VPC) network through an IPsec VPN connection.

Traffic travelling between the two networks is encrypted by one VPN gateway then
decrypted by the other VPN gateway. This protects your data as it travels over the
Internet.

Other options are available. For more information, see GCP

documentation.

3.4 API gateway

The API gateway takes all the requests from the client, determines which services
are needed, and combines them into a synchronous experience for the user. The
API Gateway can help you with several aspects of creating and managing APIs:

 Metering.

 Defining a plan to meter or restrict third party access to your APIs.

 Producing a utilisation report per API key.

 Access Control

 Resiliency.

 API Lifecycle Management

Apigee is the official API management solution in GCP. However, you’ll need a
separate Apigee account to access Apigee.

9
GCP Cloud Native Reference Architecture R20 v1.0

3.5 Cloud Key Management Service

With Cloud Key Management Service (KMS) you can create and manage
cryptographic keys in a centralised cloud service. You can use Customer-Managed
Encryption Keys, Cloud HSM, or even and External Key Manager.

It supports AES256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384
cryptographic keys.

You can find more information on Cloud Key Management Service at

https://cloud.google.com/kms/docs

3.6 GCP Firewall

Google Cloud firewall rules let you allow or deny traffic to and from your virtual
machine (VM) instances based on a configuration that you specify. The rules are
defined at the network level but enforced on a per-instance level. That means that
rules defined in a VPC are enforced in all VMs for traffic inside or outside the VPC.

3.7 Cloud Armor Web Application Firewall

Cloud Armor is a Web Application Firewall (WAF) that you can use to:

 Configure advanced firewall rules based on IP ranges and applied to load

balancers, with built-in support for custom HTTP status codes (403, 404,
50x),

 Prevent DDoS attacks.

 Force TLS policies on HTTPS endpoints.

You can only enable Cloud Armor for GCP Global Load Balancer backends, which
effectively means:

 K8S Ingress’

 Load balancer type K8S Services.

 Backends configured on top of Managed Instance Groups.

10
GCP Cloud Native Reference Architecture R20 v1.0

It makes sense to use Cloud Armor in front of a public service, but it’s not
applicable to internal configurations.

If you would like to use additional security layer for internal traffic - and potentially
protect T24 endpoints from risks such as SQL injection, brute force attacks and
bots, you might consider using a 3rd party WAF, like F5's.

You can find a list of partners Google recommends for 3rd party WAF
solutions at https://cloud.google.com/security/partners/

3.8 Third Party WAFs

GCP allows for the easy integration with a list of third party WAFs:

 AlertLogic

 Brocade

 CloudFlare

 F5

 Imperval Incapsula

 NGINX WAF

 Qualys Cloud Platform

 Reblaze

 Fortinet Security Fabric

3.9 Google Cloud load balancer

Google Cloud load balancer is a Global, High performance, scalable load balancing
solution offered as a managed service. The types of load balancers comprise:

 HTTP Load Balancer

11
GCP Cloud Native Reference Architecture R20 v1.0

 SSL Proxy

 TCP Proxy

 Network TCP/UDP

 Internal TCP/UDP

In our reference architecture, we run public facing applications on the public cluster,
for example the older T24 Browser. When more than one T24 Browser container is
running then you need a load balancer to distribute the load between them. The
traffic to web containers is HTTP of HTTPS. HTTP load balancer is perfect for this
requirement.

Operating at the individual request level (Layer 7), HTTP load balancer routes traffic
to targets within the GCP Virtual Private Cloud based on the content of the request.

3.10 Google Container Registry

The Google Container Registry (GCR) can be utilised as a private registry in your
deployment manifests. GCR natively supports Docker so you can push and pull
images from your private container registry using the standard Docker command
line interface.

3.11 Message broker

Our reference architecture uses a message broker for scalability and availability
reasons. Message brokers allow different software systems - often using different
programming languages, and on different platforms - to communicate and
exchange information.

TAFJ, our Platform framework, uses JMS and MDBs which use the JCA resource
adapter to connect to message brokers. Until this changes and we support AMQP
we utilising Apache ActiveMQ installed on Virtual machines. You can deploy
Apache ActiveMQ in either Master – Slave mode or in multi master setup to achieve
high availability, but this depends on customer preference and skill set.

12
GCP Cloud Native Reference Architecture R20 v1.0

4 Google Kubernetes Engine (GKE)

4.1 Automating containers

If you are running 100s of VMs in your data centre then you’ll need 1000s of
containers. When operating at scale, automating the deployment, management,
scaling, networking and availability of containers is essential.

Kubernetes (K8S) is the most popular container management/orchestration system.

Most cloud providers provide K8S as a managed service to make it simple for
users.

4.2 About Google Kubernetes Engine (GKE)

Google Kubernetes Engine is a managed, production-ready environment for
deploying containerized applications. Launched in 2015, Kubernetes Engine builds
on Google's experience of running services like Gmail and YouTube in containers
for over 12 years.

Google runs billions of containers a week, and they were running containers for
over a decade before Docker made containers popular. Google’s Borg was the first
ever container cluster management system. Later, the engineers who worked on
the Borg project created Kubernetes (K8S) to address pain points that users had
identified with Borg.

Kubernetes was handed over to CNCF and open sourced in 2014. Since then it’s
become the most popular container cluster management/orchestration system
available. Most cloud providers provide Kubernetes as a managed service to make
it simple for the users.

Kubernetes Engine allows us to get up and running with Kubernetes very quickly,
by completely eliminating the need to install, manage, and operate our own
Kubernetes clusters.

13
GCP Cloud Native Reference Architecture R20 v1.0

4.3 Kubernetes cluster diagram

4.4 Kubernetes terminology

Term Definition

Kubernetes Kubernetes is a production-grade, open source platform that

orchestrates the placement (scheduling) and execution of
application containers within and across computer clusters.

Cluster A cluster is a group of either physical or virtual computers. Cluster

consists of at least one cluster master and multiple worker machines
called nodes. These master and node machines run the Kubernetes
cluster orchestration system.

Master node The master node is responsible for managing the cluster. The
master coordinates all activities in your cluster, such as scheduling

14
GCP Cloud Native Reference Architecture R20 v1.0

applications, maintaining applications' desired state, scaling

applications, and rolling out new updates.

Node A node is a VM or a physical computer that serves as a worker

machine in a Kubernetes cluster. Each node has a Kubelet, which is
an agent for managing the node and communicating with the
Kubernetes master.

The node should also have tools for handling container operations,
such as Docker or rkt (GKE only supports Docker, though containerd
support is currently in Beta.). A Kubernetes cluster that handles
production traffic should have a minimum of three nodes.

The cluster master runs the Kubernetes control plane processes,

including the Kubernetes API server, scheduler, and core resource
controllers. The master's lifecycle is managed by GKE when you
create or delete a cluster. This includes upgrades to the Kubernetes
version running on the cluster master, which GKE performs
automatically or manually at your request if you prefer to upgrade
earlier than the automatic schedule.

In a managed service like GKE, the master is managed by the cloud

provider.

Node pool Although not really a Kubernetes term, node pool is a good term to
know. A node pool is a subset of node instances within a cluster that
all have the same configuration.

Pod In Kubernetes, a pod is a group of containers that are deployed

together on the same host. If you frequently deploy single
containers, you can generally replace the word "pod" with
"container".

Deployment Deployable units of computing that can be created and managed in

a cluster. Deployment runs multiple replicas of your application and
automatically replaces any instances that fail or become
unresponsive.

In this way, Deployments help ensure that one or more instances of

your application are available to serve user requests. Deployments
are managed by the Kubernetes Deployment controller.

15
GCP Cloud Native Reference Architecture R20 v1.0

Kubernetes config A file that defines the configuration for a Kubernetes object. Using
file ‘kubectl’, Kubernetes objects can be created, updated, and deleted.

16
GCP Cloud Native Reference Architecture R20 v1.0

5 Deployment on GKE
In our architecture, we’ve used two Kubernetes clusters – one cluster for public
facing user agents and APIs and the other cluster for Applications like Transact,
Infinity and TPH.

In GKE, it is possible to attach more than one node pool to a cluster. This makes it
possible to have just one cluster and run all our deployments in it by isolating them
to a specific node pool and controlling access using firewall rules.

Another reason for using fewer clusters is that we get better resource utilisation.
Packing in more containers on the nodes and using fewer clusters means fewer
master nodes. Because GKE is a managed service it manages the master node –
provisioning, scaling, patching and so on – for you.

Each cluster runs its own master node and of course its replicas.
We recommend three master nodes for PROD systems.

17
GCP Cloud Native Reference Architecture R20 v1.0

6 Microservices
Transactions in banking systems are stored in OLTP systems and are required to
be really fast when it comes to committing transactions but reading is generally not
that important. Enquiries on the other hand require really fast response time when
reading (selecting) data. For this reason we have decided in Temenos to
architecturally separate these two types of requests.
The transactional requests are processed normally with no change to what we were
doing until now. Specific read requests that are particularly expensive and frequent
are services by exposed microservices.
We need three components:
1) An event streaming product.
We need an event streaming product for Transact to stream business events. Now
we have support available for Kafka which will be run in GKE.
2) Ingester
Ingester is a service, written in Java, which consumes the data made available by
the event streaming product. In GCP the Injester is deployed in GKE.
3) NoSQL Database.
These are needed as data stores for the microservices. For all microservices, we
prefer/support Cloud Datastore which is a highly scalable NoSQL database offered
as a managed service. We are in the process of evaluating MongoDB but it is
unlikely it will be available in R20.

7 Logging and monitoring

All our R20 containers are built to stream logs to Stackdriver. Stackdriver is a fully
managed service that performs at scale and collects data relating to performance,
uptime, overall health, metrics and events, from all Cloud services. All this
information, along with our system log data can be analysed and presented in rich
dashboards.

Although Stackdriver is preferred as the GCP native solution, there is also support
for Splunk through the Splunk Add-on for Google Cloud Platform. After the
installation of the add-on, you can analyse the data using prebuilt panels that are
included with the add-on.

18
GCP Cloud Native Reference Architecture R20 v1.0

8 Database
8.1 NuoDB
NuoDB’s distributed SQL database combines the elastic scale and continuous
availability of the cloud with the transactional consistency and durability that
databases of record demand.

Most importantly, NuoDB is Active Active cross cloud. NuoDB is not available as a
managed service in GCP just yet.

19