In Part 2 I talked about the different environments and what pros and cons it has to deploy environments in a given way. What is SIT, SAT, UAT, Playback, Gold, Build, Prod etc.
In this third and final part I will discuss in a little bit more details about the different environment types and what strategy is good to consider for some of the environments
In Part 1 and Part 2 I talked about the challenges we can face to decide on the right amount of environments since too few environments will cause the implementation team to struggle to deliver. And then on the other hand too many environments can be hard to justify to the client since each environment is subscription based and the client has to pay for it.
When it comes to the environment purpose there are few things we need to have in mind and this applies for the whole implementation time.
Environment purpose: What role/purpose does the environment have in the overall implementation plan. The purpose can be one of the most important thing to have in mind because you use this information to tell the client why they need to pay for this particular environment.
Environment topology: Development, build, development test, UAT, demo and all those environments we might need for a given implementation. Development, demo, build and often data migration are Tier 1 environment. UAT is commonly a Tier 2 environment and then we have higher tiers for things like performance testing that is Tier 3 or even 4.
Environment tier: The tier of the environments is very important concept to understand before you go and advice a customer what environments should be used and on what tier each environment should be deployed to. Needless to say but the higher the tier the better the hardware is and the price goes up as well. Tier 4 and tier 5 can be VERY expensive and the client should always be involved in any decisions that have to do with tier 4 or 5 environments
Tier 1 environments
All tier 1 environments are a so called single box deployments/installations, that is one server that hosts all the software and applications that are needed to run D365 FO. Due to this simplicity tier 1 environments are used to deploy development boxes and the rule of thumb is to deploy one environment per developer and it is important that each developer signs into Visual Studio with his/her named account. This is for connection to Azure DevOps (formerly VSTS) so the developers can access their work items and mark each check in and code change with their user.
Tier 1 environments can be deployed by the partner via Life Cycle Services and the they are always deployed to the Azure cloud. That means they are”pay as you go” and virtual machine should be configured to automatically shout down about the same time when people finish their working day, 6:00 pm is a very common setting.
Tier 2 and above environments
When it comes to the higher tier environments it is Microsoft that takes care of the environment deployment and from planning perspective it is good to give Microsoft at least one if not two working weeks to deploy your tier 2 or higher environments. Tier 2 and higher environments are all deployed to LCS as cloud hosted environments and are on a different scheme than the Azure cloud hosted ones. This depends on the subscription and licensing deal each customer has with Microsoft. The positive thing about this scheme is that it can be running 24/7/365 and the cost will always be the same.
Example of environments that are deployed in tier 2 or three are the following, note this is just an idea from me and there are most likely as many variations out there as there are environments:
- User Acceptance Testing – UAT, T3
- Data migration reconciliation, T2
- Training, T2
- System Integration Testing – SIT, T2
- System Acceptance Testing – SAT, T2
With a regular subscription for Dynamics 365 for Finance and Operations clients get three environments and those are:
- Tier 1 environment used for development or test
- Tier 2 environment often used for SAT or SIT
- Tier 4+ environment which is the production environment. Each client with the help of their Microsoft partner needs to finish one Excel document called “Subscription Estimator“. This Excel file is used to gather various metrics about the user landscape and an estimated workload that the production environment might experience after go- live
Is this then all you need to know about different environments, deployments and technical architecture for D365 FO? I am sorry to say that the answer is NO.
There is lot more about environments that needs to be considered before an environment is deployed. One thing is what technical architects normally call the VM size, but that is the size and type of various resources that each VM regardless of the tier gets allocated. Lets end this with one quick example.
You need a fairly powerful VM for 4-6 months while you are performing CPU and memory intensive integration work and development. One option you have in that scenario is to deploy a Tier 1 development box but choose the biggest CPU and memory allocation that is available for the Tier 1 environment. That might make the monthly running cost of this Tier 1 environment by higher than for a Tier 2 environment. But since the Tier 1 is hosted in Azure on pay as you go scheme you can shut it down after you are done using it when then Tier 2 environment is likely to be running from 12-24 months since it is a cloud hosted environment in LCS.
This might be a topic for a new blog……………………