Software consultant. Bestselling Author. Loves rum, alt culture, games & metal.
Formerly Head of engineering, chief technical architect, head principal engineer, lead dev, etc.
Location
London, UK
Work
Independent Software Consultant at Electric Head Software
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.
🖤
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
🖤