How to size your instances according to your needs

As a Solutions Architect, one of the questions that often comes up from our customers regarding instances, is which type and size to choose. Having an infrastructure that is not optimized is time and money consuming. If you would like to learn more about cost optimization, you can check out this blogpost. But today we talk about a different subject.

I’m here to give you tips on how to plan your resource sizing. This exercise is interesting for multiple departments within a company. For instance, the marketing team might gather all the data on the market’s and the company’s trajectory in the future. Those data can be used as some indicators by the R&D teams to build their product accordingly. They can also help optimize business and financial driven decisions on an executive level. What I would advise in the beginning is to take into account every indicator to have a big picture of where you would like to go. Once you define everything you need, you can start thinking about your technical components.

Start with the right questions to define the right plan for you

Before deploying an infrastructure, one should ask themselves: what do you need in terms of application layer? What do you need in order to answer your workload? Would you be able to predict the mutual or total connections that you expect? What do you store in terms of data? In my experience, startups who didn’t ask those questions often find themselves in a position where they get blocked on their growth, simply because their business needs wouldn’t match their technical possibilities. For instance, one of my customers started with an ElasticSearch cluster to store big JSON files. The way they used ElasticSearch created a lot of performance problems. That’s why they decided to change into a database more fitting to storing documents such as MongoDB.

The reason why I’m talking about your technology stack choices is that it will be decisive on your instance choices. Listing your technical needs will help you get more information on the minimum and preferred configurations of each underlying layer. You have to find that sweet balance between familiarity, performances and cost optimization.

Once you define the services that you need, one question that comes to mind is to define which resources to use. In order to host your application, you would need some compute power: that’s when instances come into the equation. They are crucial for the availability of your application. The key part is to define which technical specifications are important for your workload. When I talk about technical specifications, one should think of different properties of an instance: CPU, RAM, I/O utilization per second, bandwidth, etc. There’s usually one or few traits that are crucial for your application. This could be a great base for your initial choice.

If one tries to be more specific about the exact instance you need , you would have to go further. You have a general idea on what type of infrastructure you would like to go with, however you do not have any information on your exact needs. You’re not the only one, that’s why there are some tools and tips that exist.

Adjust by measurement

First, you can measure the performance of your service and determine the peak and the average usage. For example, you can check the latency of your application relative to requests per second or bytes per second or the error rate. This is possible thanks to tools such as JMeter or K6 which are both open source software to measure performance and load test functional behavior. Thanks to the previously collected performance data, you can calculate the minimum and the optimal specification requirements. That way you’re able to predict the necessary instance properties for your workload.

When you go with a cloud provider, there can be a great number of types of instances. In the beginning, it is always complicated to choose the type of instance you would like to deploy. The advantage of a public cloud ecosystem is that you’re not committed to keeping any resource that you decided to try out. This gives you more flexibility on your design choices. Cloud Service Providers often supply different types of resources according to different business needs. The best example would be the different instance flavors: a persistent database application layer would most likely be IOPS intensive whereas a network application would be sensitive to the bandwidth availability. Even with two instances which have the same specifications with the one having an SLA (Service Level Agreement), it might be more interesting to go for that one in a production environment to match your availability expectations. As you get familiar with your cloud provider, you will be able to choose resources that are suited best for your needs.

Another advantage of using a public cloud ecosystem is to have access to managed services. They allow you to use different applications and resources without being concerned about the underlying infrastructure. Additionally, managed cloud products let you have access to various features and guarantees to assure reliability, availability and redundancy of your product.

Build a flexible infrastructure

Your needs will change as a startup, so will your infrastructure needs. That is why the initial infrastructure may not be fitting to your current needs. It is important to put in place some logging and monitoring tools in order to get the necessary data to make decisions about your stack. That way, you can easily visualize your compute power usage and deploy solutions accordingly. For instance, in your monitoring stack, you would be able to see that you attain a threshold in terms of bandwidth and that impacts your production performances. On the contrary, you might see that your CPU/RAM usage on your instances does not reach even 10%, that could probably mean that you provisioned some instances that are way too big for your use case. Piecing all of these insights help you optimize your infrastructure according to the usage.

It’s important to keep a flexible approach regarding your instances. The implemented monitoring tools will help you readjust your infrastructure accordingly. That way your application can operate efficiently while using the needed resources.

On another note, flexibility can come from within, by using scalable solutions by nature. Cloud providers often provide managed resources which can handle horizontal and vertical scaling. That way you wouldn’t have to take care of the manual tasks of migrating to bigger or smaller instances. Containerization takes a great part of it. The best use-case of using containers would be a Serverless architecture. The framework makes deploying containers really easy. On top of that, deploying those in a CaaS environment allows you to have an architecture where you do not care about the underlying instance and you no longer need to size those.

Final Thoughts

In conclusion, your choice of instances will depend on many factors such as your underlying stack, your performance expectations and your company needs . Your infrastructure sizing is something that evolves over time. The more you plan your infrastructure beforehand, the easier it will be to size it according to your business objectives.