Microservices Making Your Life Simple: Bank at Your Fingertips

0

Microservices, also known as the microservice architecture, is basically an architectural style that structures an application as a collection of services that are loosely coupled, independently deployable highly maintainable and testable and are organized around business capabilities.

The microservice architecture enables the deployment of large, complex applications. It also enables an organization to evolve its technology stack. Microservices are very small and targeted in scope and functionality. It gives developers the freedom to independently develop and deploy services and are Loosely coupled & can communicate with other services on industry-wide standards like HTTP and JSON.

Microservices app splits monolithic applications into a set of services that via open APIs. Each service performs one thing; the service and its API are a product that is discoverable, well-defined, and carefully maintained. These self-contained services are then assembled as required to deliver complex functionality, even if they are deployed independently of each other.

However easy and simple this concept of online banking looks to the customer, it is a very complex system and takes a lot of efforts and technologies to create the same. You can even compare different products, invest in the right one and even withdraw them whenever required. In the digital age like today, one needs total connectivity and mobility.

Development of cloud-native apps that are broken down into a set of microservices has been praised and commended as best practices in software development methodologies. Software stacks like Kubernetes, which enable cloud-native computing, have therefore picked up quite a bit of popularity. However, it’s a lot more fun to try and build a so-called cloud-native app, than to talk about the logistics for one. So, here’s our attempt: We’ll take a use-case scenario that has a bit of real-world familiarity to it — a digital bank. Inspired by Monzo, we have a demo bank called “Innovate”. Note: This is a demo site and will not collect any PII.

This code pattern is meant to describe how a hypothetical, real-world application can be broken down into a set of microservices, where core functionality is delegated to the appropriate microservice, and the web-app portal is left as lightweight as possible. Ideally, the pattern is meant to portray some of the 12-factor-app characteristics in use and justify the use of microservices, where appropriate. In this case, the microservices are independently deployable and independently scalable

Flow

  1. Portal: Loads the UI and takes care of user sessions. Relies on all other microservices for core functionality.
  2. Authentication: Handles user profile creation, as well as login & logout.
  3. Accounts: Handles the creation, management, and retrieval of a user’s banking accounts.
  4. Transactions: Handles the creation and retrieval of transactions made against users’ bank accounts.
  5. Bills: Handles the creation, payment, and retrieval of bills.
  6. Support: Handles communication with Watson Conversation to enable a support chat feature.
IBM Microservice Cloud Architecture

Setup

You have multiple options to setup your own instance:

  • Deploy to IBM Cloud with one-click (automated via toolchain)
  • Run it locally
  • Deploy to IBM Cloud the hard way (manual, multi-stage)
  • Deploy to IBM Cloud Private

Deploy to IBM Cloud

NOTE: This is an automated setup & deployment to your own Kubernetes cluster hosted on IBM Cloud; it packages all 7 microservice as one docker image, one deployment, and one multi-port service. To get a better grasp of the concept, you should follow the steps to configure your cluster and deploy each microservice independently.

You can deploy this application using a toolchain by clicking on the Deploy button below. Note that you should have a cluster ready before you start. To deploy a new one, find Containers in Kubernetes Clusters under the IBM Cloud catalog and click create. Allow it some time to deploy.

Analyze the results

Once all jobs in the delivery pipeline are completed, you’ll be able to access the portal on port 30200 of your cluster’s worker node public IP address.

To take a look at the resources now deployed to your Kubernetes cluster, navigate to the IBM Cloud Dashboard, find your cluster, and click on the Kubernetes dashboard button

Check out the Award Winning #1 Antivirus Solution for Android, Windows & MacBitdefender

IBM Cloud Deployment Result Analysis

Once your Kubernetes dashboard has launched, switch to the correct namespace and observe the resources deployed to your cluster. You should have the following provisioned:

Persistent Volumes:

innovate-bank-mongodb: a hostPath volume which mounts a directory from the host node’s filesystem into our pod, in which we can store all the data our digital bank requires to operate.

Read more about Persistent Volumes

Persistent Volume Claims:

innovate-bank-mongodb: requests persistent storage for our pods. Kubernetes uses the claim to look up its bound persistent volume. The volume is then exposed to the pod.

Read more about Persistent Volume Claims

ConfigMaps:

innovate-bank: allows us to decouple configuration artifacts from image content to keep containerized applications portable. We use it to store data our app will need to run, like MongoDB’s connection string, and backend endpoint paths.

Read more about ConfigMaps

Deployments:

innovate-bank: describes the desired state of our app, creates and manages pods, used to take care of self-healing, restarts, updates, and rollbacks.

innovate-bank-mongodb: describes the desired state of the MongoDB instance running in our cluster.

Read more about Deployments

Pods:

innovate-bank: created by our app’s deployment, pulls the app’s docker image from your private container registry on IBM Cloud, and starts all microservices. It’s bound to environment variables read from our ConfigMap, some set dynamically before deployment.

innovate-bank-mongodb: created by MongoDB’s deployment, pulls an official MongoDB

image from a public repository, makes use of a persistent volume on your cluster.

Read more about Pods

Services:

innovate-bank: exposes the app’s deployment through multiple ports, one for each microservice.

innovate-bank-mongodb: exposes MongoDB’s deployment through a specified port, to be consumed be all microservices.

Read more about Services

Run Locally

1. Clone the repo

Clone the innovate-digital-bank repository locally. In a terminal, run
$ git clone https://github.com/IBM/innovate-digital-bank.git

2. Create an Instance of MongoDB

This demo heavily depends on mongo as a session & data store.

From the IBM Cloud catalog, find Compose for MongoDB and click create. Give it a name, choose a region, pick the standard pricing plan and click create.

Get your mongo connection string. Almost all your microservices need it; keep it safe!

IBM MongoDB Instance

3. Configure your environment variables

Each of the 7 microservices must have a .env file that stores all credentials.

An example is already provided within each folder. From the directory of each microservice, copy the example file, rename it to .env, and fill it with the appropriate values.

For example, from within the /innovate folder, navigate into the accounts folder
$ cd accounts

Next, copy and rename the .env.example folder
$ cp .env.example .env

Finally, edit your .env folder and add your MongoDB connection string

Repeat these steps for all microservices. In addition to your mongo URL, most will need the public IP address of your Kubernetes cluster, You can find that under the overview of your cluster on IBM Cloud.

4. Configure your environment mode

When running the app locally without Kubernetes, the microservices do not run on the NodePorts specified in our helm chart, so we need to point our portal and userbase microservices to the correct ports.

If you’re running on macOS or any linux-based system, run the following in a terminal from the git repo’s directory

$ export NODE_ENV=development

if you’re running on Windows, edit the NODE_ENV attribute in your .env file from within the /portal folder and the /userbase folder to the following:

NODE_ENV=development

5. Run

Finally, navigate to each microservice folder, and start it. Make sure you run the 7 microservice in 7 separate terminals.

$ npm start

You can now visit localhost:3100 to access the portal

Deploy to IBM Cloud the Hard Way

NOTE: This guide requires a paid/upgraded account on IBM Cloud. You cannot complete the steps with a free or lite account.

  1. Get the tools
  2. Clone the repo
  3. Login to IBM Cloud
  4. Create a cluster
  5. Create an instance of MongoDB
  6. Configure your deploy target
  7. Configure your environment variables
  8. Configure kubectl
  9. Initialize helm
  10. Deploy

1. Get the tools

You’ll need each of the following pre-requisites:

once you’ve downloaded the IBM Cloud Developer Tools CLI, in a terminal, run:

$ bx plugin install container-service -r Bluemix

     the container registry plugin in a terminal, run:

$ bx plugin install container-registry -r Bluemix

2. Clone the repo

Clone the innovate-digital-bank repository locally. In a terminal, run:

$ git clone https://github.com/IBM/innovate-digital-bank.git

3. Login to IBM Cloud

Both through the console and your terminal

NOTE: If you need to specify the region you want to deploy in, you can do so by adding the -a flag followed by the region URL.

$ bx login

4. Create a cluster

From the catalog, find Containers in Kubernetes Clusters and click create. Choose a region and a cluster type, and create your cluster. Allow it some time to deploy.

IBM Cloud Cluster

5. Create an instance of MongoDB

This demo heavily depends on mongo as a session & data store.

From the catalog, find Compose for MongoDB and click create. Give it a name, choose a region, pick the standard pricing plan and click create.

Get your mongo connection string. Almost all your microservices need it; keep it safe!

IBM MongoDB Instance

6. Configure your deploy target

Each of the 7 docker images needs to be pushed to your docker image registry on IBM Cloud. You need to set the correct deploy target. Depending on the region you’ve created your cluster in, your url will be in the following format

registry.<REGION_ABBREVIATION>.bluemix.net/<YOUR_NAMESPACE>/<YOUR_IMAGE_NAME> For example, to deploy the accounts microservice to my docker image registry in the US-South region, my deploy_target will be:

registry.ng.bluemix.net/amalamine/innovate-accounts

If you need to get your namespace, run:

$ bx cr namespace-list

You can also add a new namespace by running:

$ bx cr namespace-add <NAME>

From the directory of each microservice, replace the deploy target in cli-config.yml &

in /chart/innovate-<MICROSERVICE_NAME>/values.yaml with the correct one

For example, from within the /innovate folder, navigate into the accounts folder

$ cd accounts

Next, edit line 58 of cli-config.yaml file. Replace the deploy-image-target with the correct value.

deploy-image-target: “registry.ng.bluemix.net/amalamine/innovate-accounts”

cli-config.yml

Edit line 6 of the values.yaml file. Replace the repository with the correct value.

values.yml

repository: registry.ng.bluemix.net/amalamine/innovate-accounts

Repeat these steps for all 7 microservices.

7. Configure your environment variables

Each of the 7 microservices must have a .env file that stores all credentials.

An example is already provided within each folder. From the directory of each microservice, copy the example file, rename it to .env, and fill it with the appropriate values.

For example, from within the /innovate folder, navigate into the accounts folder

$ cd accounts

Next, copy and rename the .env.example folder

$ cp .env.example .env

Finally, edit your .env folder and add your Mongodb connection string

Repeat these steps for all microservices. In addition to your mongo URL, most will need the public IP address of your Kubernetes cluster, You can find that under the overview of your cluster on IBM Cloud.

8. Configure kubectl

Run the following command:

$ bx cs cluster-config <YOUR_CLUSTER_NAME> Then copy the output and paste it in your terminal

9. Initialize helm

$ helm init

10. Deploy

Finally, navigate to each microservice folder, and run the following command

$ bx dev deploy

Once done, you’ll be able to access the portal on port 30200 of your cluster’s public IP address, which you can find under the overview of your cluster on IBM Cloud.

Deploy to IBM Cloud Private

If you have an instance of IBM Cloud Private running, you can follow the steps below to deploy the app. If you’d like to deploy your own instance of ICP, you can follow this great writeup.

  1. Create a persistent volume
  2. Create a persistent volume claim
  3. Create an instance of MongoDB
  4. Configure your environment variables
  5. Add your ICP’s address to your hosts file
  6. Login to docker
  7. Configure kubectl
  8. Deploy

1. Create a persistent volume

This demo heavily depends on mongo as a session & data store. From ICP’s menu, click on Storage > Create persistent volume. Give it a name and a capacity, choose storage type Hostpath, and add a path parameter

Create Persistent Volume

2. Create a persistent volume claim

From ICP’s menu, click on storage > create persistent volume claim. Give it a name and a storage request value

Create Persistent Volume Claim

3. Create an instance of MongoDB

From the catalog, choose MongoDb. Give it a name, specify the existing volume claim name, and give it a password

Create Instance of MongoDB
Create Instance of MongoDB 2

Get your mongo connection string; Almost all your microservices need it; keep it safe!

Your connection string will be in the following format:

mongodb://<USERNAME>:<PASSWORD>@<HOST>:<PORT>/<DATABASE_NAME>

4. Configure your environment variables

Each of the 7 microservices must have a .env file.

An example is already provided within each folder. From the directory of each microservice, copy the example file, rename it to .env, and fill it with the appropriate values.

For example, from within the /innovate folder, navigate into the accounts folder

$ cd accounts

Next, copy and rename the .env.example folder

$ cp .env.example .env

Finally, edit your .env folder and add your Mongodb connection string

Repeat those steps for all microservices. In addition to your mongo url, you may the IP address of your ICP.

5. Add your ICP’s address to your hosts file

Add an entry to your /etc/hosts file as follows

<YOUR_ICP_IP_ADDRESS> mycluster.icp

6. Login to docker

$ docker login mycluster.icp:8500

7. Configure kubectl

From your ICP’s dashboard, copy the kubectl commands under admin > configure client

Configure kubectl

8. Deploy

Finally, navigate to each microservice, and run the following command

$ bx dev deploy

If you don’t have the IBM Cloud Developer Tools CLI installed, get it here first

Once the deployment is successfully completed, you can access the portal on port 30200 of your ICP’s IP address.

(Optional) Adding Support with Watson Assistant

The support microservice connects to an instance of Watson Assistant on IBM Cloud to simulate a chat with a virtual support agent.

NOTE: This is an optional step. You need it if you’d like to enable the support feature on the app.

  1. Create an instance of Watson Assistant
  2. Get your credentials
  3. Configure your environment variables
  4. Deploy

1. Create an instance of Watson Assistant

From the IBM Cloud Catalog, choose Watson Conversation, and click create.

2. Get your credentials

Navigate to the credentials tab and copy your username and password

Get IBM Credentials

3. Configure your environment variables

From within the support folder, edit your .env to include your newly acquired credentials

4. Deploy

Redeploy the support microservice, the support feature should now be accessible through the portal.

$ bx dev deploy

To learn more more about Data Science check this out!