A question was recently asked on LinkedIn about whether you think rightsizing is important or not. I left a comment on the post but did not elaborate. This post attempts to expand on the comment.
When I talk to people about rightsizing, I frequently get the impression that they feel it is all about EC2 autoscaling, underutilised EBS volumes, or EC2 instance type. In my perspective, it's more complex than that. Data consumption and suitable configuration settings are also included in rightsizing.
So here are a few of the reasons why rightsizing is important. They're as follows:
1. Avoiding Downtime & Account limit issues
You may encounter a variety of account limits and downtime issues if resources are not correctly sized. This could then impact your delivery. As an example:
- If you over-provision DynamoDB table capacity, you may be unable to pre-provision capacity for other DynamoDB tables in the account. This is due to the possibility that you have hit the soft account level restriction. As a result, selecting the appropriate capacity is important. This can happen in a non-production account if distinct DynamoDB tables have been configured for use by different teams and test environments.
- Another case in point is IP address fragmentation on ENIs. You believe you have an enough number of IP addresses, but you do not. You continue with the deployment in an environment, but it fails because of a lack of IP addresses.
Both of these cases demonstrate an unanticipated effect of failing to rightsize resources. The cost in the preceding situations is the time spent by team members detecting and resolving the issue, which might have been avoided if rightsizing had been done appropriately.
In addition, I have firsthand experience of both of these situations.
2. Monitoring
Rightsizing can help you reduce the number of resources you need to monitor. You may be able to minimise the amount of data ingested for monitoring purposes as well. All of this leads to the fourth step, which is cost reduction.
Rightsizing can also assist you in reducing the number of third-party agents needed to monitor the resources. Once again, this can help with the cost reduction. Datadog, for example, charges based on the number of instances, so the more nodes there are, the more money there is. Splunk charges a daily fee based on the amount of data that the Splunk instance indexes. There is a data transfer fee if data is transferred to a different region for Splunk to index than where the application is located.
3. Improved Application Performance
Rightsizing may have an effect on the performance of your application. For example, rightsizing the proper memory for the lambda function might assist lessen the impact of the cold startup.
Similarly, choosing the appropriate AWS SQS polling mode and timeout setting will optimize your application's performance and cost. I recall the first time we implemented short polling and how it affected performance, resource use, and cost. With a little redesign and the correct configuration, we were able to enhance performance, select the best resource to provide the required throughput, and minimize costs.
4. Managing Cost
When considering costs, you must include both direct and indirect costs associated to rightsizing. If a cost can be easily attributed and accounted for to a product or service, it is classified as direct; otherwise, it is classified as indirect.
In the case of the ENI example above, the deployment failure required someone to troubleshoot the problem before re-triggering the deployment. That was an unintentional cost incurred. Someone had to stop what they were doing to investigate and resolve the issue. It also meant that no further deployments could take place until the issue was resolved.I'm sure there are plenty such examples of indirect costs incurred as a result of productivity loss that were never accounted for. This indirect cost will be borne by someone, somewhere.
The direct cost, on the other hand, is the same as switching EC2 instance types. The price change will be obvious.
Depending on the circumstances, a software licence may be deemed a direct or indirect cost. Regardless of whatever category it fits under, it is still a cost that can be influenced by resource rightsizing.
Final Thoughts.
Rightsizing is a continual process, not a one-time activity. Furthermore, rightsizing entails far more than EC2 instance types, Autoscaling, and underutilized EBS volumes.
For the reasons indicated above, rightsizing is important to me. To get the benefits of the cloud, you should make a reasonable effort to rightsize your cloud resources. So, why aren't your cloud resources being rightsized?
Thanks for reading!
If you enjoyed this article feel free to share it on social media 🙂
Say Hello on: Linkedin | Twitter | Polywork
Github: hseera
Top comments (2)
Thanks for the article, I agree with you on these points but choosing the right options isn't something easy, its something needs time and experience. I know some examples that they're using crazy number of instances with gigantic aspects for normal workload, and when you asked them why? Its working why would I change? This issue cannot be solved in a night or in a meeting. It needs experience.
Also, the most important point is cost, because if your resources made you broke, you have nothing to monitor. Your architecture isn't written in stones, you have to update it and use the new services that could save you money and even enhance your performance in the market.
Agree that choosing the right option is not easy. It requires multiple iterations. Hence why I mentioned that it needs to be a ongoing process. Things changes i.e. new feature added or removed, traffic patterns have changed etc will all influence the sizing.