I’m thinking ahead of where are currently at, but right now our IT environment is primarily virtual machines that we manage within a data center private virtual cloud. We do have an on-prem server that we use for things like AD etc. We use O365 for email, etc.
We have 2 application servers, a file server, and a database server within that data center environment. These servers and their applications are entirely managed by my IT team, but the main draw of the data center environment was backup redundancy and ease of access. We also have a load balancer that they manage outside of the “seen” environment which serves as a secure HTTP gateway for REST integrations with Epicor.
Given the trend towards Azure by Epicor and that we are a Microsoft shop through and through, it seems like it might be prudent to explore what a full migration to Azure would look like for our IT environment.
I would like to know more about the positives and negatives of this approach and what others with similar experiences could share with me about it.
I am not looking to do it yet, but perhaps within a year or two, if it’s the right move.
@Aaron_Moreng
I guess the first things to do is make sure your team knows and understands Azure. Look at what you can do with regards to mitigating spiraling subscription costs. There a few tools that will help you there.
The other thing I wanted to comment on was the fact that by the sounds of it the pieces of the puzzle are mostly there you have O365 so you can extend with Azure AD to move off that on-prem server. There are plenty of VM migration tools to Azure available as well as other components of Azure to take into account of some of the additional infrastructure like load balancing and of course backup and failover. Of course all that comes at a cost, hence me going back to my comment about subscription costs. Once you understand that, then I reckon you would be good to go.
Our current environment is a mix of on-prem for our legacy ERP and AD, but we are moving things slowly over. Our Epicor environment is all on VMs in Azure. It works not too bad, but we are still implementing and have not done any fine tuning.
The other thing I am really interested in SQL Azure and Epicor, but as I understand it, it’s not there yet.
Like @Hally said, you first want to get a grip on what your costs will be. (Costs are fixed in Public Cloud SaaS) There are tools to measure it and warn you when it’s getting crazy. There are also subscription models, like Reservations, that work to hold down costs. If you’re going single tenant, might as well do Azure yourself. You’ll have control of your system and know how to support it. Making Pilot/Dev instances are just a PowerShell away…
I can see Epicor adding features like dynamically adding compute when running MRP. Now you’re not buying a larger server to run MRP once a day or week or on demand.
If not already, check out some of the Azure podcasts. There is something new every - single - week. It’s crazy.
Would it bae asking too much for someone “in-the-know” to make up a table of what you can do with on-premises, that you couldn’t with an Azure setup?
Being my OS and SQL knowledge are JETBD level (Just Enough To Be Dangerous), I don’t regularly do stuff at the OS or DB level. But sometimes I do.
Some examples:
Epicare provided a solution for me that included a SQL script that needed to be run on the SQL server in SSMS.
Copying the PROD DB to the TEST DB, requires access to SSMS
After adding UD fields to standard tables, a Rengen is required in EAC. And this often (like 100% of the time) requires cycling the App Pool.
I’ll often browse the Epicor folders on the Appserver with Windows explorer. In azure woul I be forced to use the Server Download Program, and be limited to the areas (file paths) it has access to?
I Use ODBC connections to the DB for some quick and dirty data extraction into Excel. Usually for one off debugging, so a BAQ isn’t really the way to go.
Are these things I could do in an Azure Setup?
I’m not in the IT department, so I don’t really manage our current App and DB servers. I’ve just been given access to remote desktop in and do what is necessary to maintain E10. So if a certain level of access (and knowledge to make sure I don’t shoot myself in the foot) is required in an Azure environment, I’d like to know.
If you’re using Azure as IaaS (Infrastructure as a Service), then you should be able to all these things if granted server access by your IT Team. If you’re using Epicor’s SaaS solution, the SaaS team would do SQL Scripts, Data Model Regen, and Copy Live to another instance for you but you would not have ODBC, Server File Access, or SSMS access.
I’m TDTBA, (Too Dangerous To Be Admin) so with SaaS, I don’t get blamed for anything.
To clarify, I am also only interested in the IaaS model in azure, not a fully managed environment. I was also curious about the sql latency issue; is that utilizing azure sql or is that the case still with simply running a vm with sql on it?
We are a lot alike Calvin. I was also a “captive consultant” - a non-employee doing Epicor for over 10 years (nearly 20 years doing their ERP) and I, too, learned the Sys Admin stuff as needed.
The best use case for Azure is stand it up, test it and throw it away.
In Azure that is a few dollars, on premises, think about all the hardware you need for having test and dev instances. If you use automation scripting for the creation of your environments, you have an identical production and test instance so no surprises on deployment day. If you need an extra app server, easy to add another one for a length of time and throw away at the end of the need. Scale up the Task Agent server for a large MRP run, throw it away or scale it down afterwards.
As to some specifics on elements of Azure - Azure SQL is optimized for lower querying volumes than is normally seen in data centric apps like ERP 10. SQL Managed Instance is the new sexy kid on the block in the SQL world and is fast as heck. Take a look at Redirect Mode on SQL MI which is the fastest sql engine going
The subtle thing here is the use of 11000-11999, not just the Azure SQL Database gateway IP addresses on port 1433. Basically it logically gives you 1000 sockets to the disk instead of a single 1433 socket. Since SQL is always limited by I/O this is a huge new feature on Azure.
And no - no immediate plans to move to SQL MI in ERP cloud as there are some gaps still to figure out if it would fit ERP needs. The inclusion of SQL MI in the conversation is a recommendation for any custom work you are looking into in the cloud.
