Kubernetes Microservice Application

Microservice architecture based kubernetes application

Application Overview

For this blog the application architecture I have used involves stateful and stateless applications.

The solution comprised of below components:

• Polyglot database design, SQL container instance on Linux are used
  • Staff DB (SQL Server container) : This store all staff records
  • Product DB (SQL Server container): This will hold all product records
• Staff API (.NET Core): This API layer helps in accessing staff records
• Product API (.NET Core): This API helps in accessing product records
• Sales API (NodeJS): This API consumes Staff and Product API it then massages the data to build enriched Sales entity by mapping products with staff.
• UI Frontend (ASPNET Core): UI has Home screen from where you can navigate to Staff , Product or Sales records.

Database Component

Staff and Product DB are both deployed as a container. The container uses native Microsoft SQL Server container image. Database is a statefull application hence it also needs a persistent storage. Since container are build on the ideology of kill and recreate if error. Hence if the database containers do not use external persistent storage, the data will be lost once the container is killed.

There are wide variety of options to choose from, for persistent storage. In this demo I am using Azure storage disk for persistence.

API Components

Staff & Product API (Github Link)

Staff & Product API is build using ASPNET Core, with openAPI standards. The solution I pretty simple, it has below API’s :

• GetMetadata : This is just for internal testing, I would not keep this open if deployed in production. This was just for checking the connection details with DB container. I am pulling the connection details from environment variable, which set through the container deployment Yaml.
• Get “Get All Staff/Products”: Staff & Product API method does nothing much fancy, below are the activity performed by this API:
  • It builds the database schema if not exists
  • It seeds the database with records
  • It connects to database and pulls all records.
  • It then return the records as a custom entity generic list.

Sales API (Github Link)

Sales API in contrast to Staff and Product API does not interact with any database. Also Sales API is build using NodeJS with express. It relies on Staff and Product API for data feed. Below are activity performed by Sales API

Get Sales:

• Connect with Staff and Product API to source data
• Model Staff and Product data to build Sales entity, by mapping Staffs to Products
• Return Sales entity as a response to API call

User Interface Frontend (Github Link)

UI project is a vanilla ASPNET Core MVC project. It basically has four screens as below:

• Home Screen: It has menu items using which you can navigate to relevant screens
• Product Screen: View gets the data from controller which call the Product API for data feed
• Staff Screen: View gets the data from controller which call the Staff API for data feed
• Sales Screen: View gets the data from controller which call the Sales API for data feed