The Cloudy Path to Development Bliss: Balancing Simplicity, Scalability, and Visibility in D365
One of the significant concerns of developers regarding the D365 development experience is the use of Visual Studio to develop packages. While Visual Studio is a popular development environment that many developers are familiar with, it is not the ideal tool for developing packages for D365. In the past, D365 (previously known as Axapta or AX) had its own Integrated Development Environment (IDE) that represented a one-stop shop for all development needs. Developers could create projects, manage metadata, and deploy changes from within the IDE. However, with the move to Visual Studio, developers have to deal with several tools, including the Dynamics 365 Development Tools extension, to manage their development environment on top of putting the code package through administrative heavy compilation and deployment processes.
In years prior developers typically had a setup that involved having their own Application Object Server (AOS), backend SQL Server database, and file share combined with a vast array of developer productivity tools that provided for rapid application development and collaboration previously unseen. The ability to provision developers with their own environment provided the clarity needed when it comes to telemetry and visibility of internals. Developers were now able to see orphaned Service Profile Identifiers (SPID), they had direct access to SQL Profiler, and SQL Query Analyzer for optimizing queries, as well as CPU and memory utilization. This level of access was essential for developers to diagnose performance issues and optimize the system to meet their organizations' needs single-handedly.
In the past, developers could extract code changes in the form of XPO files, which made for seamless migrations of code to other environments, code packages after a few clicks were then compiled and immediately ready for end user consumption. However, with the move to cloud-hosted scheduled deployment via packages, developers now have to deal with scheduled downtime to deploy their changes. This approach can be frustrating for users and developers who are anxious for their changes to be made to the system in real-time.
While the D365 development experience has its drawbacks, there have been improvements in some areas. For example, the move to Visual Studio has made it easier for developers to manage their code changes, especially when working with version control systems. Additionally, Microsoft has been adding new features and functionality to the system, such as the ability to develop custom extensions, which has made it easier for developers to extend the system's functionality.
The developer experience of D365 is a complex issue with both pros and cons. While the move to Visual Studio has brought some challenges, having a dedicated development machine provides several benefits, and Microsoft has been making efforts to improve the system's development capabilities. Ultimately, the decision to use D365 for ERP development will depend on the unique needs of each organization and the experience and skills of their developers.
Onions Have Layers, Ogres Have Layers, KISS The Ogre?
Microsoft introduced the chain-of-command approach in Dynamics 365 Finance and Operations as a replacement for the layering concept used in previous versions. The chain-of-command approach aims to provide a more flexible and maintainable way of customizing and extending the application. Instead of creating new code layers, developers can create extension classes that hook into the application's standard methods and events using the pre- and post-event handlers. This approach enables developers to customize the application's behavior without modifying the standard code, making future upgrades and maintenance easier.
One of the advantages of the chain-of-command approach is that it provides better code isolation, reducing the risk of introducing side effects or conflicts with other customizations. Since the custom code is contained within the extension classes, it is easier to manage and troubleshoot, and there is less risk of interfering with other customizations or upgrades.
Another advantage of the chain-of-command approach is that it promotes modularity and reuse. Developers can create reusable extension classes that can be used across different projects, reducing development time and improving consistency. This approach also facilitates collaboration among developers, as they can work on different parts of the application without worrying about interfering with each other's code.
However, the chain-of-command approach also has some pitfalls. One potential issue is that it can be difficult to determine the order in which the extension classes will be executed. This can result in unexpected behavior if the extensions rely on specific execution order. Additionally, since the custom code is not part of the standard codebase, it can be harder to diagnose issues that arise from the interaction between customizations.
Potential pitfalls of the chain-of-command approach is that it can lead to an excessive number of extension classes, which can make the application harder to manage and maintain. This can happen if developers create too many small extension classes rather than consolidating their customizations into larger, more cohesive units.
The chain-of-command approach in Dynamics 365 Finance and Operations offers a more flexible and maintainable way of customizing and extending the application. It provides better code isolation and promotes modularity and reuse. However, it also has some potential pitfalls, including issues with execution order and excessive use of extension classes. Developers should carefully evaluate the trade-offs and use best practices when implementing customizations using the chain-of-command approach.
Perhaps it is time to revisit the KISS (Keep It Simple, Stupid) principle which is a well-known design principle that advocates for simplicity and ease of understanding in code development. This principle has significant benefits in ERP development, where complex code and business logic can quickly become overwhelming and difficult to maintain.
Adhering to the KISS principle in ERP development leads to more maintainable code, faster development times, and ultimately, happier end-users and upper management. When developers focus on simplicity, they can more easily understand and modify code, reducing the time and cost required to make changes.
Moreover, simpler code is less prone to bugs, leading to fewer errors and better overall performance, and perhaps more importantly simpler code is easier for new developers to understand, speeding up onboarding and reducing the risks of knowledge silos.
It's essential to remember that at the end of the day, the end-users and upper management don't care how cool the code is, they just want it delivered quickly and it to work consistently. Staying beholden to the KISS principle ensures that developers keep the focus on delivering reliable code that meets business needs, rather than getting bogged down in overly complex solutions.
Direct Access Denied: How Cloud-Hosted D365 Left Developers and Business Users in the Dark
Of significant concern for developers regarding the D365 development experience is the lack of direct access to the underlying SQL Server. In the past, developers could assist business users with their complex data needs and provide ad hoc research for their organizations. They could quickly diagnose issues, optimize queries, extract data, and provide expedited solutions to complex problems.
However, with the move to D365 and the cloud, developers have lost much of this critical functionality. They no longer have direct access to the SQL Server, which removes much of their ability to assist business users with their data needs. Instead, developers must rely on multiple data entities and various mini data warehouses to provide the requested data. This process can be time-consuming and complicating, ultimately removing what was once a quick and easy problem resolution.
The lack of direct access to the underlying SQL Server also impacts developers' ability to diagnose performance issues and optimize the system. With limited visibility into the system, developers must rely on telemetry and other diagnostic tools, which may not provide the level of detail necessary to identify the root cause of issues. Ultimately this results in longer resolution times and increased frustration for developers and users as the course of action is the dreaded Microsoft support ticket and going through a series of scripted redundant questions.
Furthermore, the lack of direct access to the SQL Server can impact business users who rely on the system for their daily operations. Without direct access to the data, business users may not be able to get the information they need to make critical business decisions. This can result in delays, missed opportunities, and decreased productivity as now critical ad hoc data must be requested via some self-service business intelligence option which probably isn't developed and made available yet, or engaging with report development to gather requirements for a report that might be a one-time need.
While there are alternative solutions, such as data entities and diagnostic tools such as Microsoft Lifecycle Services, these do not provide the same level of transparency as direct access to the SQL Server.
From Slow Searches to Quick Wins: The Impact of Performance Monitoring in Axapta/AX
To better understand the impact of performance monitoring and capabilities of a Dynamics AX 2012 installation, let's take a look at a real-life problem involving Kim in accounts payable.
Every day, Kim has to search for a specific record in the system by voucher. She knows that this search can be a lengthy process and chooses to start the query and go for a coffee break while she waits for the results.
Meanwhile, Steve the system analyst is responsible for monitoring the performance of the ERP system. Using the Data Management Views of SQL Server, he notices Kim's query and conducts some analysis to identify areas where the underlying query has some opportunities for optimization.
After some investigation, Steve identifies some indexes that can drastically improve Kim's query performance. He quickly raises a ticket to deploy this change, given the ERP's ability to apply changes without scheduling an outage and the change being of low risk (no change in data, no change in logic), Steve is able to work his changes in mid-week after hours free of the dreaded downtime.
Upon arriving to work the next day, Kim notices an immediate increase in performance. She is now able to accomplish more in her typical day, thanks to the improvement in system performance. Kim no longer has to wait for extended periods to retrieve data, and she can complete her work more efficiently.
This scenario illustrates how performance monitoring and improvements can have a significant impact on ERP users. By having the ability to closely monitor system performance and identifying areas for improvement, organizations can enhance the productivity of their employees and reduce the frustration and delays caused by slow system performance. Unfortunately, with the move to cloud hosted D365, visibility into these type of system behaviors is much more difficult to identify leading to frustrated users, and more importantly diminishing the abilities of developers and system administrators to make efficient use of compute resources.
It is crucial for organizations to prioritize performance monitoring and improvements in their ERP systems. By doing so, they can ensure that their employees can work efficiently and effectively, which can ultimately contribute to the success of the business.
Right Sizing Your Infrastructure: The Benefits of Transparency
One of the benefits of on-premises deployments of D365 or previous versions is the ability to have visibility into the CPU utilization of the Application Object Server (AOS) against a backdrop of concurrent users. This information allows organizations to right-size their infrastructure according to load by using hard facts instead of having to trust cloud-providers suggested scalability, which is unfortunately often motivated by increased revenue on their side.
Having this level of visibility is critical for organizations to ensure that they are not overspending on their infrastructure while also avoiding situations where their infrastructure becomes overwhelmed due to high user loads. This information allows organizations to make data-driven decisions about infrastructure needs and to avoid costly upgrades in compute resources.
In contrast, with cloud deployments, organizations have limited visibility into the underlying infrastructure, and the cloud provider may recommend scaling up or down based on their algorithms and billing models regardless of actual usability. This approach may not always align with the specific needs of the organization and can result in unnecessary costs or degraded system performance.
By having on-premises visibility of AOS CPU utilization, organizations can monitor and manage their infrastructure needs more effectively, ultimately leading to better system performance and cost savings.
The Control Conundrum: Balancing Cloud Benefits Among the Tradeoffs
Microsoft Dynamics 365 Finance and Operations (D365) offers organizations a powerful tool for managing their business processes and data. However, as with any complex system, there are trade-offs between the benefits of cloud-based deployment and the control offered by on-premises deployment. While cloud-based deployment may offer benefits such as scalability and ease of deployment, on-premises deployment offers benefits such as direct access to telemetry data, the ability to optimize SQL Server performance, and greater control over infrastructure needs. Ultimately, the decision between cloud-based and on-premises deployment will depend on the specific needs of each organization. However, it is clear that on-premises deployment of D365 offers a powerful set of tools for organizations to manage their business processes and data with greater control and visibility.
It's important to note that while cloud computing has been marketed as a cost-saving solution, it's more of a move to allow organizations to get out of the data center business and focus on their core competencies. The trade-offs of increased integration challenges, budget-constrained compute resources, and a lack of visibility into system internals can result in indirect costs that negate any infrastructure gains, making it crucial for organizations to carefully evaluate their deployment options.
Comments
Post a Comment