How to scale out Logic Apps

Scaling applications to meet growing demands is a challenge many developers face. Among the various solutions available, Logic Apps offer a flexible and powerful way to automate workflows and integrate services. However, as the usage of Logic Apps increases, questions about effective scaling strategies become paramount. In this discussion, we delve into the intricacies of scaling Logic Apps, exploring both vertical and horizontal scaling options. We’ll examine the considerations for choosing the right scaling approach and provide insights into optimizing your Logic Apps for efficiency and performance. Whether you’re just beginning your journey with Logic Apps or looking to expand your existing setup, this guide aims to equip you with the knowledge to make informed decisions about scaling your applications.

A question I’m often asked is, how do we scale out our logic apps? So, the scenario might be that you’ve created a few logic apps, you’re early in your journey, and now you’ve got more workloads when you go on the same platform. How do I scale this up? Well, you’ve got a few main options, and I’m going to run through those, and then we’ll talk a bit about which one is going to be best for you. So, generally, scale comes in three forms. You’ve got vertical scale, as in, I’m going to put this on a more powerful computer. And then you’ve got horizontal scale, which is, how can I add more computers to share that work across? So, vertical is quite simple, really. On a Logic App hosting plan, you’ve got three tiers of which you’ve got one CPU and one gig of RAM, two CPUs and two gigs of RAM, four CPUs and four gigs of RAM. So, you have three different hosting plans. And really, that’s going to be driven by memory requirements, and to a certain extent, by CPU as well. So, we can measure the workload and see whether vertical scaling is appropriate.

But then, you’ve got two different ways of horizontally scaling. So, you can scale out the number of instances. A Logic App’s hosting plan is a bit like a virtual web farm because, ultimately, a Logic App is like a page on a website, or it’s like a website on a web server. And so, when you’ve got a hosting plan, that will scale horizontally, either automatically or you can set the number of instances you want between the maximum and a minimum value. So again, you can say, I’m going to put all my Logic Apps on one hosting plan and let the instances scale up. And that’s not a bad strategy. And certainly, that’s probably your first strategy to go to. So as you go from a very small number and you add more, just put them on the same hosting plan, allow it to scale, see what happens, measure the usage. And then, if you find that you’re still hitting memory constraints, you might then find you want to scale up vertically. If you find that you’ve got issues with different workloads clashing, then we can move on to the other strategy, which is splitting it across multiple hosting plans.

So, you can put some Logic Apps on one hosting plan, some on another, and so on. Now, there are a few things here that are just worth bearing in mind. A Logic App hosting plan will scale up and scale down automatically, but you’ve generally got a minimum of one instance. So again, the smallest instance and one of them is the smallest cost you’ll bear, which is around £150 a month. So again, if you go to a bigger vertical scale, one instance might be £600 a month. So just bear that in mind. Similarly, if you’ve got two hosting plans, then you’ve got two times £150 or two times £600. So, your minimum burn rate goes up as you start to scale out. But there are advantages because, first of all, you get the noisy neighbor effect. If you’ve got some logic apps that are really demanding, other things that run on the same hosting plan, in other words, run on the same virtual servers, they might get affected. They might not have enough resources left for them. So, you might find that some workloads that are really critical in terms of their responsiveness, you might want to isolate onto its own infrastructure.

And that might be slightly underutilized, but you want to protect that because those are the ones that need to respond quickly. If there’s a website ordering page that you want to submit, the customer’s waiting, and then they’ll get an acknowledgment, you want that to be fast. So, you want to protect that work. So, you might isolate that onto its own plan just so you know that when it’s needed, it’s got resources. Similarly, there might be other bits of work that doesn’t matter how long they take, but you just want to get through that work as efficiently as possible. You might put all those onto another plan and just let that work at full capacity and churn through the work in its own time. So, there aren’t any particular do’s and don’ts. It’s going to depend on your workload, and you need to measure how your workloads behave for you. But generally, what to do first is just allow things to scale horizontally, then segregate critical workloads onto their own hosting plan, and the others on another hosting plan. Use a first thing. And then, if you’re still getting memory or CPU constraints, then look at scaling vertically.

There’s no absolute right or wrong answer, but just some general guidelines on the way you might go about it.

Chat to us about your Integration journey

Get in touch

Share this post