Effectively scale your web application
Scaling web applications requires you to balance opposing forces/factors, which are.
Updated
On this page
Updated November 2026. This was first published on 6 September 2020. The idea is the same. Any number below is what the original piece said then. It is not a new count.
Key takeaways
- Scaling web applications requires you to balance opposing forces/factors, which are.
- Speed (How fast should your application respond) Reliability (How consistent and accurate is the data returned by the application) Availability (How resilient is your application).
- All of these factors are opposing because they will pull you in opposite directions.
Scaling web applications requires you to balance opposing forces/factors, which are.
Speed (How fast should your application respond) Reliability (How consistent and accurate is the data returned by the application) Availability (How resilient is your application).
All of these factors are opposing because they will pull you in opposite directions.
Banking systems Reliability and availability is of paramount importance for Banking systems. A system with high reliability is achieved via making writes transactional that supports ACID principles, this slows down the system. Also availability is achieved through standby systems in different geographies and ability to scale dynamically to serve increasing workloads. Stock exchange Speed and availability is paramount for Stock exchange system. stock rates change rapidly, so updates should be quick. Speed is achieved in systems via parallelism. Social Media Speed and reliability is important for social media like twitter, as you would like updates to be quick for events/disasters/news, but not so much availability. Even if the social media system goes down, it can come back up after a while, it is not mission critical.
As you see only two of three factors can be enabled in a web application. You will need to decide which two factors are critical for your web application.
Currently there are lot of options by cloud providers, that provide tools to help in deploying, managing, and scaling web applications.
Saas (AWS Lambda, Google Cloud Functions, Google App Engines) #
These tools build your application, and also set up, configure and run your application. All you need to do is provide the source. You do not need to worry about creating docker files, creating deployment yaml etc. This is used for quickly deploying your application. You forgo control in favor of lesser complexity.
Paas (Google Cloud Run, AWS Fargate, Heroku, Pivotal Cloud) #
These tools are serverless container platforms, where you are responsible for the built artifacts (docker images). The deployment of your container is managed for you.
Iaas (AKS, EKS, GKE, Digital Ocean Kubernetes) #
These tools provide Kubernetes as a platform, and you can run your containerized workloads on them. You will need to create and configure deployment yaml to instruct Kubernetes where to deploy your workloads. This is a good balance between control and complexity.
VM/Physical Servers (EC2, Google Compute Engine, Bare Metal Servers) #
These only give you server/vms on which you need to install, configure, and manage Kubernetes. Here you have complete control, but also you need dedicated devops teams to maintain your infrastructure.
You need to select your appropriate platform/stack based on below below metrics.
You can use a variety of higher level tools to manage your deployments in a CI/CD pipeline. These tools can be used with Paas and Iaas categories as defined above.
Containers**: While Docker files are de facto for creating containers, you can use buildpacks to build reuseable, transparent docker images. Refer to Modularizing docker images Managing deployments: Helm is the de facto for easy packaging and deploying workloads on Kubernetes. It provides manifests that can be used to template your deployment and reuse a base deployment and provide overlays (deltas) for each landscape Managing clusters: To manage your cluster as a whole, you can look into Argo. This provides an automated way to update your cluster by monitoring your git versioned deployment files. Also while Kubernetes ensures that specified number of pods are running, if a deployment is decommissioned using kubectl, or any changes are made to the deployment, Kubernetes is not aware of these changes. So Argo monitors whether your running cluster matches the desired state.
As you can see, a lot goes into making sure your web service can scale up. So if you are starting out it makes sense to start with Saas category products. If this does not handle your workload, you will need to progressively hop to the more granular categories.
“Which compute option is right for you?” > > Cannot wait to hear your thoughts in the ???? and be sure to drop your topic ideas too! #GoogleCloud #CloudComputing #sketchnotes pic.twitter.com/yuypWw6pNT > > — Priyanka Vergadia (@pvergadia) July 21, 2020.
Questions and answers #
What is the main point? #
Scaling web applications requires you to balance opposing forces/factors, which are.
What else did the original piece say? #
Speed (How fast should your application respond) Reliability (How consistent and accurate is the data returned by the application) Availability (How resilient is your application).