Architectures - Dunderly

Posted Jul 15, 2023

By Sakharam Shinde 11 min read

Company: Dunderly

Sells Paper Supplies (Printer Paper, Envelopes, etc)
Needs a new HR System for
- Managing Employess
- Salaries
- Vacations
- Payments

Architecture Process

1. Understand the System’s Requirements

Below are the functions requirements provided by the client:
- A. Web Based
- B. Perform CRUD Operations on employees
- C. Manage Salaries
  - Allow Manager to ask for employee’s salary change.
  - Allow HR manager to approve/reject request
- D. Manage Vacation Days
- E. Use External Payment System

2. Understand the Non-Functional Requirements

Below are the non-functional requirements that we know:
- A. Classic Information System
- B. Not a lot of users
- C. Not a lot of data
- D. Interface to external system
Below are the questions that needs to be clarified:
- How many expected cocurrent users?
  - 10
- How many employess?
  - 250
- What do we know about the external Payment system?
  - Legacy system, written in C++
  - Hosted in the Company’s servers farm
  - Input - only files :(
  - File received once a month
- What is the Data Volume?
  - 1 Employee = ~1MB in data
  - Each employee has ~10 scanned documents (contract, reviews, etc.)
  - 1 Scanned Document = ~5MB
  - Total Storage for 1 employee = ~51MB
  - Compnay expects to grow to 500 employees in 5 years
  - Total Storage: 51MB x 500 employees - 25.5GB
  - Need to consider storage options for storing documents
- What is the SLA/How ciritical is the system?
  - Not Very Critical
Below is the summary of non-functional requirements:
- 10 Concurrent Users
- Manages 500 Users
- Data Volume forecast: 25.5 GB
  - Relational and Unstructured
- Not mission critical
- File-based interface

3. Map the Components

Based on below requirements, we can define different services:
- Entities: Employees, Vacation, Salary
- Interface to the Payment System
Services:
1. Employee Service: Performs CRUD Operations on Employees
2. Salary Service: Salary Approval Workflow
3. Vacation Service: Eployee’s Vacation Management
4. View Service: Return’s statuc files to the browser (HTML, CSS, JS)
5. Payment System:
  - Payment Interface: Sends payment data to payment system
6. Data Store: Single or Per Service Data Store?
  - Data is shared between services, so a Single Data Store is better.
7. Logging Service

Messaging Phase:

  flowchart TD
  %% Nodes
      A("fab:fa-youtube <a>User's Browser</a>")
      B("fab:fa-web <a>Employee Service</a>")
      C("fab:fa-web <a>Salary Service</a>")
      D("fab:fa-web <a>Vacation Service</a>")
      E("fab:fa-web <a>View Service</a>")
      F("fab:fa-web <a>Logging</a>")
      G("fab:fa-web <a>Payment Interface Service</a>")
      H("fab:fa-database <a>Data Store</a>")
      I("fab:fa-web <a>Payment System</a>")

  %% Edge connections between nodes
      A -- REST API/HTTP --> B 
      A -- REST API/HTTP --> C
      A -- REST API/HTTP --> D
      A -- HTML --> E
      B -- Queue --> F 
      C -- Queue --> F
      D -- Queue --> F
      E -- Queue --> F
      B --> G 
      C --> G
      D --> G
      E --> G
      G -- File --> I

  %% Individual node styling. Try the visual editor toolbar for easier styling!
      style E color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
      style G color:#FFFFFF, stroke:#00C853, fill:#00C853
      style H color:#FFFFFF, stroke:#2962FF, fill:#2962FF
      style I color:#FFFFFG, stroke:#2962FF, fill:#FF4F,stroke:#FFD600

Description:
- The user’s browser will call/invoke the view service to the login page, and then call/invoke all the other services to get the relevant information.
- The best way for the browser to interact with the three service (employee, salary and vacation) is through REST API/HTTP because of the following reasons:
  - It is extremely easy to implement.
  - Most of the modern frameworks support REST API.
  - Synchronous operation.
- All the services will be interacting with the logging service to write the logs.
- The best mechanism for logs transfer is Queue, because all the services would prefer fire and forget mechanism.
- The logging service is responsible to query the logs records for creating dashboards or alerts.
- All the services will interact with the Payment Interface, which will then invoke the Payment System using the File method.

4. Select the Technology Stack

Based on the client requirements, they would like to use Azure Services and .NET for application code.

5. Design the Architecture

Logging Service:

Questions:
- Is there an existing logging mechanish used by the compnay in the cloud?
- Should we develop or own or use a 3rd party?
- What is the cost associated with the logging solution which be implemented?
Logging in Azure:
- Azure Log Analytics:
  - Part of Azure Monitor
  - Great Integration with a lot of services
  - Handles huge amounts of data
  - Offere query language for analysis
  - Can be streamed to log analytics tools (Power BI, etc).
- Azure Monitor
Pricing:
- If we estimate 100 MB of data to be ingested into Azure Log Analytics, then the cost would be ~$10.

  flowchart TD
  %% Nodes
      A("fab:fa-youtube <a>User's Browser</a>")
      B("fab:fa-web <a>Employee Service</a>")
      C("fab:fa-web <a>Salary Service</a>")
      D("fab:fa-web <a>Vacation Service</a>")
      E("fab:fa-web <a>View Service</a>")
      F["<div style='text-align:center;'>
      <img src='/assets/img/icons/azure/log-analytics-workspace.svg' width='20' height=20' />
      <span>Logging</span>
      </div>"]
      G("fab:fa-web <a>Payment Interface Service</a>")
      H("fab:fa-database <a>Data Store</a>")
      I("fab:fa-web <a>Payment System</a>")

  %% Edge connections between nodes
      A -- REST API/HTTP --> B 
      A -- REST API/HTTP --> C
      A -- REST API/HTTP --> D
      A -- HTML --> E
      B -- Queue --> F 
      C -- Queue --> F
      D -- Queue --> F
      E -- Queue --> F
      B --> G 
      C --> G
      D --> G
      E --> G
      G -- File --> I

  %% Individual node styling. 
      style E color:#FFFFFF, fill:#AA00FF, stroke:#AA00FF
      style G color:#FFFFFF, stroke:#00C853, fill:#00C853
      style H color:#FFFFFF, stroke:#2962FF, fill:#2962FF
      style I color:#FFFFFG, stroke:#2962FF, fill:#FF4F,stroke:#FFD600

View Service1:
- What it does:
  - Get requests from end users’s browsers
  - Returns static files (HTML, CSS, JS)
- This type of services would be fit for the Web App or Web API (Not Mobile App, Console, Service, Desktop App)
- Implementing static website in Azure:
  - App Service
    - Fully managed web app and API
    - Supports many platforms
    - Autoscale
    - Support for Web Jobs
    - Cost: Standard Tier - $73/month
  - Static Web Apps
    - Fully managed static web site
    - Complete integration with source controls (Git, Azure DevOps, etc)
    - Extremely cost effective
    - Cost: Standard Tier - $9/month
- Considering the cost and the requirement, Static Web App seems idle in this scenario.

Employee Service:

What it does:
- Allows end users to query employees data using REST API
- Allows performing actions on data (CRUD) using REST API
What it doesn’t:
- Displays the data
This type of services would be fit for the Web App or Web API (Not Mobile App, Console, Service, Desktop App)
Technology Stack : .NET
Implementing Web API in Azure:
- App Service
  - Fully managed web app and API
  - Supports many platforms
  - Autoscale
  - Support for Web Jobs
  - Cost: Standard Tier - ~$73/month
- Function Apps
  - Fully managed serverless functions
  - Lightweight
  - Autoscale
  - Integration with cloud services
  - Extermely cost effective
Since Azure Functions are designed for lightweight actions and the employee API will perform some heavy actions like updates, docs, etc., App service seems to be an idle choice in this scenario.
Selecting Database for employee service
- Employee Data (Relational)
  - Azure SQL
    - Cost: Gen 5 2 vCore General Purpose with reserved option - $255/month
- Documents
  - Storage Account
    - Cost: Hot Access Tier 25GB - $1/month
Employee API details:
- Get Fully Employee Details by ID
- List of Employees by Parameters
- Add Employee
- Update Employee Details
- Remove Employee
- Add/Remove/Get Document
- Retrieve Document by Parameters

Sample API’s:

Functionality	Path	Return Codes
Get Employee details by ID	GET /api/v1/employee/{id}	200 OK / 404 Not Found
List Employess by parameters	GET /api/v1/employees/?name=…&birthdate=…	200 OK / 400 Bad Request
Add employee	POST /api/v1/employee	201 Created / 400 Bad Request
Update employee details	PUT /api/v1/employee/{id}	200 OK / 400 Bad Request / 404 Not Found
Remove employee	DELETE /api/v1/employee/{id}	200 OK / 404 Not Found
Add document	POST /api/v1/employee/{id}/document	201 Created / 404 Not Found
Remove document	DELETE /api/v1/employees/{id}/document/{docid}	200 OK /404 Not Found
Get document	GET /api/v1/employees/{id}/document/{docid}	200 OK / 404 Not Found
Retrieve documents for employee	GET /api/v1/employees/{id}/documents	200 OK / 404 Not Found

Employee Service Redundancy
- Using App Service Auto Scale feature to increase the amount of instances of the employee service.

Salary Service:

What it does:
- Allows managers to ask for an employee’s salary change
- Allows HR representative to approve/reject the request
This type of services would be fit for the Web App or Web API (Not Mobile App, Console, Service, Desktop App)
Technology Stack: .NET
Implementing Web API in Azure:
- App Service
  - Fully managed web app and API
  - Supports many platforms
  - Autoscale
  - Support for Web Jobs
  - Cost: Standard Tier - ~$73/month
- Function Apps
  - Fully managed serverless functions
  - Lightweight
  - Autoscale
  - Integration with cloud services
  - Extermely cost effective
Since Azure Functions are designed for lightweight actions and the salary API will perform some heavy actions like updates, delete, etc., App service seems to be an idle choice in this scenario.
Salary API Details:
- Add salary request
- Remove salary request
- Get salary requests
- Approve salary request
- Reject salary request

Sample API’s:

Functionality	Path	Return Codes
Add salary request	POST /api/v1/salaryRequest/	200 OK / 400 Bad Request
Remove salary request	DELETE /api/v1/salaryRequest/{id}	200 OK / 404 Not Found
Get salary requests	GET /api/v1/salaryRequests 200 OK
Approve salary request	POST /api/v1/salaryRequest/{id}/approval	200 OK / 404 Not Found
Reject salary request	POST /api/v1/salaryRequest/{id}/rejection	200 OK / 404 Not Found

Salary Service Redundancy
- Using App Service Auto Scale feature to increase the amount of instances of the salary service.

Vacation Service

What it does:
- Allows employees to manage their vacation days
- Allows HR to set available vacation days for employees
- This type of services would be fit for the Web App or Web API (Not Mobile App, Console, Service, Desktop App)
Technology Stack: .NET
Implementing Web API in Azure:
- App Service
  - Fully managed web app and API
  - Supports many platforms
  - Autoscale
  - Support for Web Jobs
  - Cost: Standard Tier - ~$73/month
- Function Apps
  - Fully managed serverless functions
  - Lightweight
  - Autoscale
  - Integration with cloud services
  - Extermely cost effective
Since Azure Functions are designed for lightweight actions and the vacation API will perform some heavy actions like updates, delete, etc., App service seems to be an idle choice in this scenario.
Vacation API Details:
- Set available vacation days (by HR)
- Get available vacation days
- Reduce vacation days (by employees)

Sample API’s:

Functionality	Path	Return Codes
Set available vacation days	PUT /api/v1/vacation/{empid}	200 OK / 404 Not Found
Get available vacation days	GET /api/v1/vacation/{empid}	200 OK / 404 Not Found
Reduce vacation days	POST /api/v1/vacation/{empid}/reduction	200 OK

Salary Service Redundancy
- Using App Service Auto Scale feature to increase the amount of instances of the salary service.

Payment Interface
- What it does:
  - Queries the database once a month for salary data
  - Passes payment data to the external payment system
- This type of service would be fit for the type Service as it runs on a schedule (Not Web API, Mobile App, Console, Desktop App)
- Technology Stack: .NET
- Implementing Payment Interface in Azure:
  - App Service WebJob
    - Runs on Schedule
    - Part of App Service
    - No additional cost
  - Function Apps
    - Fully managed serverless functions
    - Lightweight
    - Autoscale
    - Integration with cloud services
    - Extermely cost effective
  - Virtual Machines
    - Expensive
    - Manual Maintenance
  - Logic Apps
    - Too complex for this specific job
  - Azure Batch
    - Used for huge processes
- Since Azure Functions are designed for lightweight actions and the payment interface service will perform some heavy actions like data export, etc., App Service WebJob seems to be an idle choice in this scenario.
- Payment Interface Redundancy
  - No built-in redundancy for WebJobs
  - Not critical – runs once a month
  - Add monitoring for catching failures
Security:
- Data Encryption
  - Data in Azure Storage Account is encrypted by default using 256-bit AES encryption.
  - Traffic to Storage Account is encrypted using TLS
  - Data in Azure SQL is encrypted by default using 256-bit AES encryption.
  - Traffic to Azure SQL is encrypted using TLS
- Network Security
  - Currently all the app services are exposed to internet.
  - We can add applicaiton gateway and web application firewall to the app services, which will provide below benefits:
    - Load Balacner
    - Web Application Firewall
    - Autoscale
    - Spphisticated Routing
  - Cost: App GW Web Application Firewall V2 - ~$350/month
- Access Restrictions
  - All the Web API services should only be allowed from the App Gw.
    - Add NSG rule to allow traffic from the App GW’s VNET to the app services.
    - Setting available under App Services -> Networking -> Access Restrictions -> Add Rule of type Virtual Network
  - Access to the Data stores should only be allowed from the Web API services with the help of a firewall rule.
    - Settting avaiable under Azure Storage Account -> Networking -> Allow access from Selected networks -> Add App Service Outbound IP
    - Settting available under Azure SQL -> Firewall and Virtual Network -> Add App Service Outbound IP

6. Write Architecture Document

7. Support the Team

cloud, azure

This post is licensed under CC BY 4.0 by the author.

Company: Dunderly

Architecture Process

1. Understand the System’s Requirements

2. Understand the Non-Functional Requirements

3. Map the Components

4. Select the Technology Stack

5. Design the Architecture

6. Write Architecture Document

7. Support the Team

Trending Tags