Solving imaginary scaling issues

Michele Riva

Michele Riva

Real-World Next.js

Scalability

Software scalability is an attribute of a tool or a system to increase its capacity and functionalities based on its users’ demand. Scalable software can remain stable while adapting to changes, upgrades, overhauls, and resource reduction.

Source: https://fullscale.io/blog/what-is-software-scalability

Scalable software can remain stable while adapting to changes, upgrades, overhauls, and resource reduction.

The system should remain stable when applying any kind of change to both the infrastructure and application

Changes

e.g., switching from Compute Engine to Cloud Run to make the whole infrastructure more cost-effective

The system should remain stable when upgrading any of their components

Upgrades

e.g., releasing a new software version or upgrading the runtime

The system should remain stable during maintenance and debugging

Overhauls

e.g., if the system is not working properly, it should be easy to inspect production deployments

The system should remain stable
under high load

Resource reduction

e.g., an e-commerce is rolling out a great promotion with huge discounts, there's a lot of traffic on the website and the connection should remain stable

just 4 scenarios

imaginary issue #1

"This programming language doesn't scale"

imaginary issue #1, debunked:

You're not Facebook, Twitter, or WhatsApp

• How many active users do you have today?
• How many active users do you expect to have in five years from now?
• How much would it cost to teach your whole team to code in Erlang, Rust, C++, Scala, or any other "highly scalable" language?

imaginary issue #1,

debunked (again):

Good PHP code scales better than bad Erlang code.

Good Ruby code scales better than bad Scala code.

imaginary issue #2

"We need to use cloud functions to manage high traffic. Serverless computing scales better"

Simple REST API example

Let's say we have a simple but critical REST API that gets 50 requests per second (129,600,000 requests per month).

The average execution time is 300ms.

We can use the cheapest RAM option (128MB).

We require around 100kb of bandwidth per execution.

Simple REST API example #2

Let's say we have a simple but critical REST API that gets 100 requests per second (259,200,000 requests per month).

The average execution time is 300ms.

We can use the cheapest RAM option (128MB).

We require around 100kb of bandwidth per execution.

imaginary issue #2, debunked:

Cloud Functions are good at managing spiky and unpredictable traffic

imaginary issue #3

NoSQL databases scales better than RDBMS

Companies actively using sql databases

Good PHP code scales better than bad Erlang code.

Good Ruby code scales better than bad Scala code.

Remember?

Good MySQL knowledge is better than any NoSQL poor knowledge

Good experience with PostgreSQL is better than no experience with NoSQL

imaginary Issue #3, debunked:

imaginary issue #4

We need everything custom, so it fits our use case 

Frameworks

Frameworks already provide everything we need to implement most of the custom business logic we need in our apps

imaginary Issue #4, debunked:

how do I determine if my application is really scalable or not?

Is my team scalable?

Are we adopting this technology because we're excited about it, or are we doing this because it's the best solution to our problems?

Do we know our app traffic?

But I want to have fun!