Microsoft Dynamics AX – Public, Private or Hybrid, it’s your choice

The team at AgileCadence have been working with Microsoft Dynamics AX systems since version 3 of AX. One thing has been extremely apparent over the years and this is the staggering growth and complexity increase of the solution. However as with all products and technology, experience cannot be learnt and we have more experience than most.

We now use that experience to size and manage some of the largest AX implementations in the world. Either working directly with the end customer or via the partner.
The exciting piece for us at the moment is the sheer possibilities that are opening up for organisations that adopt AX as their principle line of business application. Linking all of this with the offering of ALM and DevOps experience AgileCadence possesses makes us quite a force in the technical space of AX.


Public Cloud

The Public Cloud – This is really your choice, as with all options of infrastructure deployment. You may choose to deploy to Azure, AWS or another provider. This really does not matter to us in terms of managing your line of business application. However, if you select Azure then we can offer you the full range of services and operational advantages.
If you have any queries or concerns over your Public Cloud decision, please contact our team who will step you though the decision making process.

Private Cloud

The Private Cloud – Things change quickly with cloud technologies. There is either your traditional datacentre approach to managing and hosting Microsoft Dynamics AX, or you may be considering the implications Azure Stack will bring to your IT deployment strategy. At AgileCadence we can help you to plan and design your internal infrastructure and also help you to evolve to allow the project team to deliver whilst also constraining within your IT budgets.

Hybrid Cloud

The Hybrid Cloud – We see this as the main design principle for Dynamics AX, even though AX7 will be released initially as a cloud only option. Organisations have invested heavily in their own datacentres and wish to keep an element of compute and data ownership close at hand. We completely get that and see many ways in which the Public Cloud can be utilised for Dev and Test scenarios, whilst keeping Production under tight control. Or given the right infrastructure even host the data within the local datacentre, but the app tier in the cloud. One thing is for sure, AgileCadence will use the Hybrid cloud to allow our DevOps practices to flourish as this will never restrict us to the decision you make, this makes us Agile.

Agility Designing for agility and the demands of the organisation, especially on global deployments, is key to success. We know this, because we live in this world.

Cadence – project heartbeat Keeping agility and application heartbeat in mind allow the infrastructure design to be looked at in a different way. Projects scale as they evolve, design this in upfront and overall reduce cost.

Baked in Monitoring, Configuration and Infrastructure as Code

When using AgileCadence, the question over how a system should be built is very relevant as we have an absolute answer and a fully implementable answer no matter what systems you are running. The team have been working to develop solid templated deployment and infrastructure guidelines and structures so that all of our customers can gain best of breed implementations that just work, and that will pass muster when being interrogated by the Microsoft Premier Field Support consultants.

From the very first server deployed to the last, all systems are monitored from the first heartbeat they make. We take performance extremely seriously and spent time building an entire suite of monitoring and metrics that just keeps getting bigger and better.

Configuration Drift? Maybe Not

With all implementations of hardware and software, it is likely that at some point you will experience configuration drift of some description. This may even happen from the moment a server is delivered from the operations team to the project team.

Due to the way we approach our implementations, this should never be an issue again. We make sure that any new system is implemented as a templated node. We know what it should look like and we know when it changes, even better we can make the systems auto manage.

Imagine that? An AOS server becomes uninstalled by a junior administrator, but the server knows what it should look like and simply reapplies its designed software. This is what we do, we already have this and we already use this.