Auto-Scaling in the cloud-Everything the product manager needs to know
It’s a new issue reported by customers which says the cloud is not processing messages from devices fast enough… The product manager takes stock of the resources and raises a request for scaling up the infra… Sounds familiar?
While the request goes through its approval workflow, a seasoned technical architect walks through the code along with the developers, only to find a small piece of code that should have been multi-threaded instead of sequential processing. Quickly after the issue is identified the development team completes the code change, a new configuration setting is added for the number of threads needed and the processing speed jumps up ten-fold, with no extra resource!
The point to take home? Scalability is not only about adding more expensive resources to physical infra or the cloud. Neither is it a quick fix to be thought about just in time when the demand increases. Here are a few points to ponder upon about scalability, especially if you are a product manager
- How will this work when we get 10x/100x more traffic/visitors/devices? This is the right question to ask during design discussions of the product.
- Scalable components will be a by-product of the initial design that follows high-cohesion-loose-coupling principles.
- If you have to scale up the entire app for the congestion in one component, it’s a signal that the product design is not-so-good. You should be able to scale up only the required components of a product.
- Scalability doesn’t always require more compute power, sometimes running multiple container instances also does the trick.
- Your storage may still be a bottleneck if you increase the service instances. You need not replicate the storage, but take a look at the connection pool size.
Which incident came to your mind after reading this post?
