Deployment scenarios between AX 2012 and Dynamics 365 For Finance and Operations can now be compared with the on premise version, called Local Business Data, of Dynamics 365 For Finance and Operations, or F&O for short. Below we'll compare and contrast each scenario, sizing, latency, other hidden requirements as well as when you would select Dynamics 365 F&O in Azure or the LBD flavor.

AX 2012 / 2009

Infrastructure

Typically for AX 2012 most everything was either on premise or through a cloud provider with infrastructure as a service (IaaS). Regardless, it was typically an end user managed set of servers and the application was also end user managed. Some or all of this management could be outsource to various partners but the end user would have to engage to make that happen. Once an instance was created, anything that needed to be replaced was a small project to replace that component. For instance, if in our example architecture we lost AOS-08, we would have to build a replacement to AOS-08 from near scratch. There was also very little magic or redundancy built in on the infrastructure side. you can build in some of that on your own but its not required (although highly encouraged). Servers and services were not typically deployed in a high availability fashion with load balancers. It was an option but typically round robin load balancing was used and that was it ( based on my time in both the end user and partner space ). The overall time to implement, manage and maintain the infrastructure required a small team and that team scaled with your implementation. The above example is taken from a real client that is currently live and has a support staff 5 IT fulltime technical staff to keep it up and running plus the occasional resource from a partner for issues that require additional help.

Orchestration

No orchestration at all, basically. You can do some stuff with power shell and VM templates but unless you build it yourself with some help from online documentation, this is going to be a journey for the customer alone or with their partners help.

Environment Types

In a typical environment, you would have at least one developer environment, a build box, a sandbox / UAT environment and a production environment. Typically more for developers, maybe one for pre-UAT testing and another for integration testing of some sort. Each one would be built from near nothing which can be time consuming. We'll outline the different types by VM count (minimalist) below:

• Developer - 1 VM: all in one
• Build - 1 VM: all in one
• Sandbox / UAT - 3 VMs: 1 AOS, 1 SQL and 1 terminal server ( assuming no EP )
• Production - 6 VMs: 2 AOS, 2 SQL (cluster) and 2 terminal servers ( assuming no EP)

Dynamics 365 for Finance and Operations Local Business Data (LBD)

Infrastructure

On Premise Dynamics 365 For Finance and Operations, or Local Business Data, is similar to AX 2012 in a lot of ways. Its all on end user hardware but its not going to be cloud provided infrastructure. It is not supported on VMs running on any major cloud provider including Azure but also Amazon, IBM and Google. So this is on the end users hardware with little wiggle room. It may be possible for this to be implemented on a private external cloud but the verbiage on this topic from Microsoft only addresses public cloud and not private so I would tend to think private external cloud is also not supported. Next, on premise has the Azure Service Fabric while AX 2012 doesn't. This one change makes quite a significant difference to the overall delivery of an environment and how that environment operations. The Azure Service Fabric is a distributable systems platform to package, deploy and manage scalable apps. To learn more about it in detail, check out this link. In a Azure Service Fabric cluster, you have the OS (Window Server 2016), installed on top of that you have the Azure Service Fabric then deployed on top of that you will have the various apps that make up your deployment for Dynamics 365 F&O. AX 2012 has a simpler model that we are all very accustomed to which was an OS and an application installed onto that OS. With LBD, you'll be able to administer the apps very little because they are wrapped in the Service Fabric. That's neither good nor bad, its simply a fact of this deployment style. For the more technically focused, you will still have access to a lot of the same tools as you do with a developer or non-LCS slot environment. However, LCS is still the primary orchestration tool for all of your environments.

Orchestration

LCS is where all Dynamics 365 F&O orchestration happens. This is where you will create, manage and destroy all environments. Also, you can use cloud hosted environments for targeted engagements, like a DEMO environment, if you want. It is very easy to create a DEMO machine once you have started your project, if you already have a project or even just want to try things out. For LBD, you will need to create a connector to your environment then deploy an environment to it. In order to do you, you have to have successfully created a Azure Service Fabric Cluster as defined here. This can be a long and time consuming process but once you that cluster online, you can deploy, maintain and destroy as much as you like. The cluster is just the container for whatever LCS has to deploy to it. However, when you have an on premise style project in LCS, all of your environments slots are on premise only. You can deploy one-box VMs as cloud hosted environments but any other deployment must be to an on premise fabric cluster. Also, unlike other cloud based Dynamics 365 F&O implementations, LBD projects in LCS have very little governance. I can go from new project to production environment in a day if I want to. Of course, you would never do that but you could.

Environment Types

Similar to a 2012 instance, you will have the same types of boxes for the various roles for your implementation and post go live support. However, you have some options not available with 2012. LCS will let you spin up a developer machine using LCS to orchestrate with Azure and have a machine ready to go with demo data in a few hours. They also offer a VHD based image of a working VM that can be downloaded to a laptop and used as is. You could also take that VHD, convert it to a VMWare template and clone it as many times as you need.

• Developer - 1 VM: available in Azure, on premise in data center or locally on machine (VHD)
• Build - 1 VM: Available in Azure or on premise in data center
• Sandbox / UAT - 9 VMs (MSFT recommended minimum)
  • 3 orchestrators
  • 2 AOS
  • 1 MR
  • 1 SSRS
  • 1 ADFS
  • 1 SQL
• Production - 11 VMs (MSFT recommended minimum)
  • 3 orchestrators
  • 3 AOS
  • 1 MR
  • 1 SSRS
  • 2 ADFS
  • 2 SQL (Clustered)

Selection

Now, we get to the part of the article where we select which option you should select if your coming from AX 2012 to Dynamics 365 F&O. First, review the deployment options as MSFT lays it out, comparison of cloud and on-premise features and features not currently implemented on premise. Those articles are full of great info but the "Why on-premise" section of the deployment options article is very conservative so as not to offend with its verbiage so I'll be more clear. You do not select LBD. This is a choice that is made for you. What I mean is that if there are key features or requirements that only the LBD deployment option can satisfy, then your options go from two to one and that one option is LBD. This may be data residency related or data access related. As of the writing of this article, China does not have 2 F&O approved Azure data centers so if you want implement Dynamics 365 F&O there, you have to keep all data in the country so that leaves you with LBD as your only option. Another example may be that a parent company dictates that a child company maintain a copy of their transactional data on premise. Again, we cannot currently do this in Azure so LBD is our only option.

If you have the option to deploy in the cloud, you should take that route and forget that LBD is even an option. MSFT is a cloud first company so by virtue of that anything that is not in the cloud is at best going to be second.