How I Used Render to Scale My Microservices App With Ease | by John Vester | Nov, 2022

When it comes time to top/down, time is money. See how easy it is to scale your apps and services using Render

photo by imgix Feather unsplash

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

The team realized that they had no choice but to increase the number of instances to service the service under heavy load. When they finished scaling, the number of instances was many times larger than the number of instances configured by default. What they didn’t realize at the time was that — despite the load returning to normal — their additional instances remained in place.

Everyone seemed fine with this “scale as needed” approach… until they received their next invoice from the cloud provider.

this situation got me thinking render, a platform that I’m adopting more and more for some of my projects. It got me wondering how easy it can be to implement scaling across cloud-based applications and services with Render. Another spoiler alert: It’s easy.

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

At the same time, solution owners have expectations, including:

  • ensuring that customer expectations are met
  • keeping costs within the planned budget
  • Minimizing downtime and outages — especially as related to performance

All of these expectations are easier to meet when the level of demand is less than the maximum capacity of the technology used to handle each request. When demand starts to exceed those levels, things get interesting.

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

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

  1. manual scaling
  2. auto-scaling up
  3. auto-scaling down

Let’s look at each use case with a scenario example.

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

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

With this information in hand, the manual scaling approach will satisfy consumers because the team always knows how many instances should be available. The owners of the solution are happy as their monthly expenditure is completely on budget.

Of course, this information does not consider major changes in expected usage patterns. For example, a press release on a service can positively or negatively affect sudden demand.

The auto-scaling up approach puts the number of instances in the hands of pre-defined thresholds created by the service owner but enforced by the cloud provider. As those limits are exceeded, the number of instances will increase until demand drops to the expected level. Most providers allow users to set a maximum number of instances to cap the number of instances that can be generated.

While there is some uncertainty about the impact on monthly budgets, solution owners can use the argument that increased demand for their service is often related to new or upgraded subscriptions, resulting in additional income.

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

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

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

Thinking about the team I mentioned in my introduction, had they employed auto-scaling for the service I described, they would have faced the sticker shock of having all those instances running well after peak demand subsided. Wouldn’t have had to.

Cloud providers that offer auto-scaling are now combining auto-scaling down with auto-scaling down as this is the more common implementation of this functionality.

I’ve written about render platforms several times this year. Here are links to some of my other publications on this topic:

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

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

All remaining images by the author

If you are interested in using auto-scaling with render, enable autoscaling, then:

  • Select number of instances
  • Enable and set target CPU usage
  • Enable and set target memory usage

Be aware that it is possible to limit auto-scaling to depend only on CPU or memory usage (instead of both).

After auto-scaling is implemented, the render dashboard communicates as changes are made to the number of running instances:

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

From a billing perspective, changes to the cost structure are based on when new instances occur in a given month. This means that if you double the number of your instances for seven hours on the same day of the billing cycle, the cost for that billing cycle will not double; Instead, it will double only for those seven hours where the number of instances has doubled.

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

  • datadog – Provides Postgres metrics and log streams to 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 that can be helpful for larger, enterprise-scale applications and solutions running on the Render platform.

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

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

I still believe that cloud-based products and services can greatly exceed the cost of supporting and maintaining the same configuration within a dedicated data center. That said, some aspects can significantly affect the periodic costs associated with cloud-based technology:

  • have a good understanding of each expense
  • Knowing how and when to scale applications and services to meet demand

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

Starting in 2021, I’m trying to live by the following mission statement, which I think can apply to any technology professional:

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

At the time I was using Render for my own applications and services, I was able to focus on robustly delivering features because of its Zero DevOps model. For those looking to simplify their cloud architecture, Render provides mission-critical scalability without having to specialize in the technologies adopted by its competitors.

Have a really nice day!

Leave a Reply