One of the things folks turn to SaaS for is they do not need to manage the hardware, the OS, the application and can concentrate on running your business. Sometimes you need more control and intimate control as a business advantage. That’s great, we support you for that as well. Some of our techniques will make their way from our internal usages down to the on premises products #Safe Harbor of course#. Until then, these are some things to consider as some tricks we have learned internally.
It has long been discussed how to deploy multiple versions of ERP 10. The questions comes down to one faced in any hosted scenario - how to get more density in a data center? How to be more realiable? How to increase flexibility. ERP 10 is a vanilla IIS app that takes advantage of a lot of off the shelf MSFT approaches. This is a good thing. This allows you to use all the same tricks you are used to leveraging. If you are learning new approaches, then you will learn valuable techniques to leverage in other systems #NoThrowAwayKnowledge.
Not all of these tricks are used in every flavor of Epicor SaaS hosting. We have several environments in ‘SaaS’ - some our external customers, some sandboxes for validation with our ISV partners and some for various internal uses, so not all of these are in use across all the environments. That’s a part of the innovation in approaches to find the best model to scale not only the data center but also the IT staff. This little post discusses one approach we have been using successfully in a massive automation deployment we have.
<Safe Harbor >
Don’t assume every Install and Admin Console and configuration feature in the product will work seamlessly in this approach - it won’t. This environment uses experimental automation not released to the wild over classic UI tools and lots of clicking. This is a technology demo, not an E10 demo 
</Safe Harbor>
On to a trick. I’ll cover my first and favorite in this post.
Hopefully everyone has seen that Epicor has signed a big deal with MSFT to leverage Azure. It’s a great platform but many of the approaches discussed will work in AWS, GCP or your on premises data centers. I love Azure but I am not trying to be religious in these approaches. Choosing a partner goes way beyond a simple UI, a feature or a $. For us, MSFT fit our needs best. #NoReligion
So with Azure as with most Data Center scenarios, the first stop is virtualization. The Industry has been doing that in the data center for a decade. VMWare, Virtual Machine, Hypervisor, etc. I won’t cover that as
you have probably seen that discussed a million times by now. The point is it’s the first step to ‘the public cloud’. Lift the virtual app server from your hardware and put it on rented space in Azure for these examples. Aka - Lift and Shift. This works great. No need to swap hard drives, budget for the three year old servers, etc, etc. It’s not a final destination. Using Containers and cloud native services are next steps to be discussed in the future. For now, let’s look at some options for lift and shift or virtualization to ease your deployments.
First, don’t combine the app server and db. Just don’t. I know folk want cost savings thru density. The way to do that is not by putting the whole stack of ERP into a toaster, it’s to scale out similar but distinct deployments. This allows but less downtime due to High Availability approaches. Reuse a good DB Server for many workloads. Scale ERP and other workloads across multiple app servers to balance workloads and keep the lights on for users if an app server dies. The trick is savings is to manage their workloads on the app servers to make things easier for IT and less impact on the users. I won’t cover ARR or F5 configuration but assume one fronting the VMs as needed.
Trick one - Using DNS for flexibility
This is such an overlooked feature that is so simple. Using the internet for you can give you some easy flexibility. Adding a new site to IIS and binding it to a DNS name gives you an interception point. If the load gets too heavy with one endpoint sucking up too much CPU or memory, you want to move it to a new VM. But standing up a new endpoint name is a pain. It CAN be done in E10 where the sysconfig is updated but a user will always have something stuck. Instead, just change the Internet.
I’ll show CNAME updating in Azure but the technique works for any DNS toolset you are using.
Create a DNS name for the machine.
In my case, BartDemo. This is pointing at an Azure VM instance named by the same name I stood up in USWest2.
Next I setup different CNames for each instance I want to deploy. Dev, Test, Live. These all point to the URL created above pointing at the box. This can also be different internal systems that are not E10 or different versions.
Now in IIS, you can create Sites for each. For each site, do the DNS trick of binding the public URL to the website. Each Sysconfig will point to the appropriate Application Instance. Bonus points for using clear names so the users now exactly what the instance is for based on the clear name of the URL.
No magic Epicor or Azure here, just adding flexibility thru the power of DNS and simple mapping tricks in IIS. If the load on Test gets too high, give it a new VM and Site, update the CName to the new VM and no change in sysconfig needed.
You will not be able to use this in the off the shelf E10 tools but the approach is solid for your applications in the data center. You CAN piece this together manually if you really know what you are doing and moved into full automation yourself (You have searched on Command Line tools in the help right?). It’s not for the faint of heart but if you are not taking advantage of SaaS, you are challenged with managing your own infrastructure as a competitive advantage so can teach me a few tricks