5 step process to make an application performant
Application Performance is like a well functioning body. Stability of our body depends on health of our blood, heart, lungs, kidney, skin, muscle etc. Similarly when all layers of the applications including Storage, Compute, Database, Caching, network, Scaling all work hand in hand, we get an optimal performance. In this article, we’ll build a performant application by step by step process(Agile way) rather than changing everything in a single go.
Let’s get into it.
The Legacy Architecture
Let’s assume we have an application, built using APS.NET and WCF Services with database as SQL Server. Below is the architecture -
Need to revisit the application architecture due to below reasons -
- As business is increasing, 2 Web servers and 2 App servers are not sufficient to handle load during peak season
- As the business is seasonal, at least a large part of the year the servers remain idle hence adding server may not be optimal throughout the year
- Even during normal load, the application response time is not satisfactory
- Reporting is very flat and takes a lot of time to get on demand custom report
In the first step, let’s do only lift an shift in Cloud with some minimal changes.
STEP 1 — Lift and Shift to Cloud ( Auto Scaling )
Objective — Handle server load during peak demand yet save money by reducing the servers during off season
Revised Architecture
Explanation
Transfer the data (Not mentioned in the diagram) — Few Options to transfer data from on premise to AWS Data center
- Snow Ball / Snow Mobile (Terabytes, Petabytes volume of data)
- AWS DataSync
- AWS Direct Connect
We will consider Snow ball / Snow Mobile in here for a secure yet low cost data transfer from on-premise to AWS
Computing — As we have chosen step by step process let’s choose the below for compute and load balancing.
- EC2
- AWS Auto Scaling
Storage — AWS RDS with SQL Server
Network— Route 53 and ELB takes care of DNS routing, Region wise and Application / Network load balancing
Benefits and What’s Yet to be Achieved
Achieved (We fixed this by Auto Scaling)
- As business is increasing, 2 Presentation and 2 App servers are not sufficient to handle load during peak season
- As the business is seasonal, at least a large part of the year the servers remain idle hence adding server may not be optimal
Yet to Achieve
- Even during normal load, the application response time is not satisfactory
- UI is not responsive enough and page load time is yet to be satisfactory
- Reporting is very flat and takes a lot of time to get on demand custom report
Let’s continue with subsequent steps to achieve better performance.
STEP 2 — Application Refactoring — Microservices
Objective — Break the monolith backend Services into Microservices to achieve scale and maintainability.
Follow the instructions mentioned in the below link to break your application in Microservices.
Now follow the below as applicable to achieve performance in microservices development
- Materialized view — In case of any complex query which is taking time during run time, use materialized view. Materialized view creates physical copy of the underline table data in flat table format and get refreshed in a defined interval. This improves performance multi-fold and an excellent choice in case your data does not get updated very frequently and you are fine with near real time data. Refer this link for materialized view
- CQRS — Command / Query Responsibility separation, this can be implemented in two ways -
- DB level Changes i.e. create separate DB table for Read and Write and update using eventual consistency
- Model level changes i.e. separate Read and Write Payload in order to achieve better data transfer performance
Refer my friend’s blog to get more details on CQRS.
- Amazon SQS or SNS for messaging to get benefits of serverless and non Real time computing, some of the examples are workflow, Printing, Sending Email, Processing Order, Processing Payment etc. We can break large work into smaller chunks and implement some chunks Realtime and some can be pushed into queue for eventual processing
- First of, Reporting DB should be different as Cloud Gurus Say “One Size does not fit all” and AWS Design purpose driven Database
- So, in case we have some data which is difficult to accommodate in RDBMS like customer preferences, Site Configuration Data where where number of fields / record are not uniform, use No SQL i.e. Amazon DynamoDB
- Let’s continue to use RDS for SQL server for all OLTP data need
- Use Caching for master / reference data or other transactional data but caching should be done carefully but effectively (Use Right Consistency (Write Through or Write Back) and right eviction Policy (FIFO, LRU)). Recommending to use Amazon ElasticCache for Redis
Tips for caching
https://aws.amazon.com/caching/
Revised Architecture
STEP 3— Application Refactoring — UI
Objective — Break the monolith UI into component based structure and use different Preloading Strategies and CDN
- The first step in any UI transformation is to break the monolith UI application into different Modules and Components thus creating component hierarchy like below
- Follow Angular.io style guide and Cheat sheet
- Use Lazy Loading and different Pre-Loading Strategy for better user experience, let me try to explain the pre-loading strategy though a diagram
- A good Angular Architecture should look like below
- Use CDN (Edge location) for Static contents delivery to reduce latency. AWS Cloud front / S3 combination can improve the delivery performance of static files, images, videos
- Choosing the right S3 service based on your need for cost effectiveness yet optimal performance. Some of the S3 buckets are S3 Standard, S3 Standard IA, S3 one zone IA etc.
We can get better performance by spreading reads across different S3 prefixes, as there is a read cap / prefix. Eg. If Per Prefix Read Cap = 5000/sec, spreading the content in 4 prefixes increase the reading throughput to 20000/sec
What is S3 Prefix?
Example — mybucketname/folder1/subfolder1/myfile.jpg
{BucketName}/{Prefix}/{FileName}
So, the prefix is the path between the bucket (which is globally unique) and the fileName.
STEP 4 — Reporting & Analytics
- We can use ETL / Offline batch for Reporting DB data load (AWS Glue for ETL)
- Alternately can use pub / sub model to publish all necessary changes to a topic in a Streaming service like Azure Event Hub or AWS Kinesis using the same microservice which is responsible to update the data in SQL Server. then finally update the Reporting DB
- Use Amazon Quick Sight or Azure Power BI for interactive reporting
STEP 5— Last but not least — Monitoring and Continuous Improvement
System performance can degrade over time. Monitoring the system is essential to identify degradation and remediate internal or external factors, such as the operating system or application load.
Amazon CloudWatch is a monitoring and observability service that provides data and actionable insights to monitor application workload, respond to system-wide performance changes, optimize resource utilization, and get a unified view of operational health. CloudWatch collects monitoring and operational data in the form of logs, metrics, and events from workloads that run on AWS and on-premises servers.
AWS X-Ray helps developers analyze and debug production, distributed applications. With AWS X-Ray, you can glean insights into how your application is performing and discover root causes and identify performance bottlenecks. You can use these insights to react quickly and keep your workload running smoothly.
Refer the below Article which is excellent source of performance in AWS
Revised Architecture
Congratulations, you have transformed a legacy application to a performant, modern application using this 5 step process.
Hope this helps, till next time, cheers!
