July 27, 2019 | XEO
“Your site needs to scale, when it needs to scale” – Xeo
What is Scalability Anyway?
Scalability is the ability to scale with the current site or app usage. Scaling a system up is done by throwing hardware at the problem.
However, this means spending more money to the hosting company than is needed. Scaling a system out is the process of adding capacity where
it is needed with the flexibility to alter that capacity during faster and slow periods. AWS Elastic Beanstalk is a classic example
of a scale out solution; the beanstalk knows how to add capacity and remove capacity and does this when events happen such as increased
CPU usage or simultaneous logged in user counts change. Good software design takes the future growth into consideration and future proofs
the application prudently. This is our high scalability blog to help you get an understanding of this topic.
Can’t We Just Scale Later?
Scalability of a system is often ignored by website builder and corporate blog builder services. These services are aimed at getting a glitzy
marketing site up as quickly as possible to start taking orders. So we understand that scalability only comes to mind when the site
starts acting really slow or frequently becomes unavailable.
Determining how fast to add website scalability is a key function of Product Management as they analyze the market.
Building software is a complex multi-sided equation largely determined by the project budget. The project budget is itself greatly
dependent on revenue and usage. This strategic question comes up a lot: Is it worth spending money on future proofing the software
before there is significant revenue and usage? From an Agile and Lean perspective, yes this can always be added later. However,
we have found it is better to plan the scalability system design early on and watch key usage growth metrics to know when to add on each step.
The reality is that scaling changes are significant changes to the software itself and will take longer than expected to stabilize.
Taking the time to scale each piece correctly is important to offer the best possible customer service, but if you wait too long to get
started, customers may have to deal with a slow and clunky service while you rush the scalability work. Rushed coding work means it will
need to be patched and refactored later on so you may end up paying for it twice.
Starting at $0.00
We apply Lean principals during Web App Development to scale up to your expected usage.
During initial development there are just a few test users. Initial scale can typically be handled by a single server running multiple server roles.
On the Amazon Web Services (AWS) platform, the free tier hosting level keeps costs low and some clients are seeing $0.00 per month.
We build using best practices including the capability to scale out, but do not activate those elements until the business needs to start paying for them.
What to Scale?
There are four main assets to make into a scaling system in a website or mobile application: code, database, session state, and user data.
- 1. Code is always scalable. Our architecture secures the code in a source code repository (typically bitbucket or github)
and we configure the server to pulls the latest version whenever updates are available.
This means that the code is now flexible and can be placed on any number of servers as needed. - 2. Database can be moved. Our database best practices design initially places the database on the web server itself for simplicity and cost savings.
As usage grows we simply move that database to its own server or Amazon RDS and choose the server size needed. - 3. Session state is how the server knows what a user is doing on the site. Logged in users have a session to track that they are logged in.
Initially this session data is stored on the web server. As usage grows we simply move this to Redis so that multiple web servers
can share this data. - 4. User data is always scalable. Our architecture secures these user uploaded files directly into S3 storage which is the same place
that Netflix and Dropbox store their files. Since this is not on a server or in a database, this is already scaled from day 1.Things to Scale?
There are four main aspects to consider about scaling out. They are: role separation, shared caching, deferred processing, and optimization.
