DEV Community


Why should I scale?

dmevanct profile image Evan Haston ・2 min read

"Why do I need to be able to scale? I only serve 3 customers". This is something I have heard more than once.

If you are a company no matter what the industry your goal is generally to grow and take on more clients. Some companies see small growth over time while others like the company I work for see 50% growth year over year. We never expected to grow this quickly. This being said we never really built the code to scale.

What do we do it now? Well it's never to late to start scaling code. Start at your bottlenecks. If you fix anything but the bottlenecks it does not improve the throughput of your application. As you scale you keep moving down through each bottleneck correcting them as you can. Don't be discouraged if you create more bottlenecks when you solve another. This is common and a good problem to have.

No Silver Bullet

One thing to remember when talking about scaleability is there is no silver bullet. For example people often talk about docker containers which are great in concept but if your code can't scale easily with these docker containers it's only adding lipstick to a pig. When scaling with Docker you need to build smaller code bases that are easy to store and pull that also have a quick startup time. If your docker container is 2GB and takes 5 minutes to start it's not really scalable.

Providing Value

Scaling and velocity go hand in hand. After you are able to scale your application for your clients you want to also provide value quickly. One thing every company should be thinking about should be how do you provide value to your customers. TDD pipelines and multiple deploys a day is one approach. With this approach companies should should be focused on how they break apart services so that we can easily make code changes test code changes and deploy code changes to production within the same day. If you can't run tests against a service in a timely manner then you need to break apart those services. You don't need to have thousands of services but enough to make the code manageable and deployable.

Final Point

Remember scaling is about fixing bottlenecks and increasing velocity for your deploys. If you can't service at least 50% more customers every year you should probably take a step back and focus on scaleability. Don't go crazy and spend all of your time on scaleability without adding valuable features. Create a balance and drive feature development with the thoughts of scaleability when the features are created rather than after.

Some things to remember:

  • Break large code into smaller more scaleable code. Make sure it can start and run quickly

  • Use TDD with front end and back end code. If you can test all the way through quickly you can add features / fix bugs quicker, adding velocity.

  • There are no silver bullets. You need to build your code in a way that will be complemented with a technology ex: Docker.


Editor guide