How I Used Render To Scale My Microservices App With Ease

As a software lead and feature developer, I witnessed a team learn an important lesson about resource scaling and the cloud. Spoiler alert: the lesson was that if you’re not careful, scaling can get expensive!

The team felt they had no choice but to keep increasing the number of instances for a given service that was under heavy load. When they finished scaling up, the number of instances was several times larger than the number of instances that were configured by default. What they didn’t realize at the time was that—despite the load returning back to a normal state—their extra instances remained in place.

Everyone seemed to be okay with this “scale up as much as needed” approach… until they received their next invoice from the cloud provider.

This situation got me thinking about Render, a platform I’ve been adopting more and more for some of my projects. It made me wonder just how easy it could be to implement scaling in cloud-based applications and services with Render. Another spoiler alert: it’s easy.

The Concept of Cloud-Based Scaling

Consumers of your application or service have one common expectation: all of their requests should be handled in a reasonable amount of time. 

At the same time, solution owners have expectations, which include:

• Ensuring that customer expectations are met
• Keeping costs within a planned budget
• Minimizing downtime and outages—especially those related to performance

All of these expectations are easy to meet when the level of demand is less than the max capacity of the technology used to handle each request. When demand begins to exceed those levels, that’s when things get interesting.

The challenge is finding that sweet spot that meets expectations and keeps costs reasonable. That’s where the concept of cloud-based scaling comes into play. With cloud-based scaling, the focus is on scaling up the number of service instances to meet the current demand but scaling back down when the demand subsides.

A Trio of Scenarios

There are three use cases for auto-scaling that we will talk about:

1. Manual scaling
2. Auto-scaling up
3. Auto-scaling down

Let’s explore each use case with a scenario example.

Manual Scaling

The manual scaling concept is for teams with a strong understanding of the demand for their applications or services.

As an example, consider an income-tax-related service that answers customers’ questions as they populate their tax returns. The team supporting this service may have decades of information regarding usage patterns, allowing them to determine how many service instances are required throughout the entire year.

With this information in hand, the manual scaling approach will allow consumers to be satisfied because the team always knows how many instances ought to be available. Solution owners are pleased because their monthly spend is completely on budget.

Of course, this information does not consider major changes to the expected usage patterns. For example, maybe a press release on the service comes out, suddenly impacting demand positively or negatively.

Auto-Scaling Up

The auto-scaling up approach puts the number of instances into the hands of pre-defined thresholds created by the service owner but enforced by the cloud provider. As those thresholds are exceeded, the number of instances will grow until demand falls to an expected level. Most providers allow users to set a maximum number of instances to cap the number of instances which can ultimately be spawned.

While there is some uncertainty regarding the impact on the monthly budget, solution owners might use the rationale that increased demand for their service is often related to new or upgraded subscriptions, which result in additional income.

This is where the concept of “you have to spend money to make money” comes into play. 

When implementing auto-scaling up policies, I always recommend doing the same for auto-scaling down, too.

Auto-Scaling Down

The auto-scaling down approach is similar to auto-scaling up, except the number of services decreases to coincide with a reduction in demand. While the auto-scaling up functionality is very quick to introduce new instances, auto-scaling down is often delayed to avoid scaling down too soon.

Thinking back to the team mentioned in my introduction, had they employed auto-scaling down for the service I mentioned, they would not have encountered the sticker shock of leaving all of those instances running well after the peak demand had subsided.

Cloud providers that offer auto-scaling are now getting into the practice of combining auto-scaling up with auto-scaling down since this is the more common implementation of this functionality.

Scaling with Render

I have written about the Render platform several times this year. Here are links to some of my other publications on the subject:

• Using Render and Go for the First Time
• Under the Hood: Render Unified Cloud
• Purpose-Driven Microservice Design
• Launch Your Startup Idea in a Day

I’ve learned that they take their Zero DevOps promise very seriously. As one might expect, scaling with Render is easy and driven by a simple user interface.

With a service running at the Starter plan (or above), the ability to manually scale the number of instances is as simple as sliding to the required level in the Scaling menu of the Render Dashboard:

If you’re interested in using auto-scaling with Render, simply enable Autoscaling, then:

• Select the number of instances
• Enable and set a target CPU utilization
• Enable and set a target memory utilization

Keep in mind: it is possible to limit auto-scaling to depend on only CPU or memory utilization (instead of both).

After implementing auto-scaling, the Render Dashboard communicates as changes are made to the number of instances running:

Additionally, metrics are provided to justify the auto-scaling implementation:

From a billing perspective, changes to the cost structure are based upon the amount of time the new instances are in place in a given month. This means if you double your number of instances for seven hours on a single day of the billing cycle, the cost for that billing cycle will not double; instead, it will only double for those seven hours where the number of instances doubled.

Other Available Integrations

Services deployed with Render can also integrate with the following solutions:

• Datadog: Provides Postgres metrics and log streams into the Datadog observatory platform
• Scout APM: Provides application performance monitoring (APM) for Ruby, PHP, Python, Node.js, and Elixir-based services

These integrations provide insights, which can be helpful to larger, enterprise-scale applications and solutions running on the Render platform.

Conclusion

Technologists who have worked for less than 13 years have been fortunate not to have to worry about the side effects of a global recession. Present-day economists suggest that the next recession will begin soon, and some economic indicators already justify such claims.

This means that corporations are likely to be more conservative with their spending to preserve their bottom line. One area of scrutiny for corporations is cloud spending.

I still believe that cloud-based products and services can strongly outweigh the costs to support and maintain similar configurations within a dedicated data center. That said, there are certain aspects that can significantly impact the periodic costs related to cloud-based technology:

• Having a good understanding of each incurred cost
• Knowing how and when to scale applications and services to meet demand

For those using cloud services from Amazon, Google, or Microsoft, firms like CleanSlate Technology Group offer services to help you with these concerns.

Since 2021, I have been trying to live by the following mission statement, which I feel can apply to any technology professional:

“Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”

- J. Vester

In the time I have been utilizing Render for my own applications and services, I have been able to focus on delivering features strongly because of its Zero DevOps model. For those looking to simplify their cloud architecture, Render provides mission-critical scalability without becoming an expert in the technologies adopted by their competitors.

Have a really great day!