loading...

re: Architecture for Everyone VIEW POST

FULL DISCUSSION
 

Wow, thanks so much for writing this! You explain things in such a clear and entertaining way. Just out of plain curiosity, what would the process of scaling things yourself look like? Adding more servers, connecting them together in some sort of way, etc. etc.?

 

Scaling means lots of different things to different people, and it's one of the most commonly misunderstood things in software.

When a programmer says "scaling" - they might mean "making the code more available or perform faster". When a product owner means scaling, they might mean "scaling the business model", when sales say scaling they might mean "can we onboard thousands of users right now" and when a technical manager says scaling, they might mean "how many people can I meaningfully have working on this codebase".

Most software doesn't need to scale technically. Most software doesn't really have high volume traffic problems. For the majority of people, vendor provided autoscaling (think Azure App Services autoscale, or AWS Elastic beanstalk, or Heroku) are more than enough, set a memory and CPU scale out threshold and let the platform do it for you. The same goes for K8S, albeit with more operational complexity.

The more difficult form of scaling from a software perspective is scaling concurrent contributors - and this is all related to the size of your codebase, how well compartmentalised it is, and how well it avoids change hot-spots (files that get changed in every commit are scary files).

Then the even more difficult form of scaling (yes! more difficult than the technical one!) is scaling your operational processes around user onboarding.

So while "scaling is mostly commoditised" in todays managed cloud platforms, all the knock on effects of maintenance, support and human factors are an equal sized hurdle to just adding more computers to a piece of software.

🖤

code of conduct - report abuse