If you grasp the title of this post, you’re likely one of the many seasoned consultants familiar with the Dynamics platform. You might also relate to the cover photo, hinting at the point of this post
Being a Solution Architect on our platform is often a frustrating endeavor. On one hand, you have Dataverse, an exceptional platform. On the other, Microsoft seeks to capitalize on its potential, which sometimes complicates solution design. Have you ever caught yourself thinking:
- Table Strategy: “I need to rethink my table strategy to avoid excessive storage costs in Dataverse. The client won’t be pleased with the added expense.”
- API Calls: “This integration will result in numerous extra API calls, pushing us into the ‘RED zone.'”
- Execution Limits: “I have to shift the logic outside of Dataverse due to the 2-minute execution limit.”
If these thoughts resonate, you’re not designing the optimal solution based on what could be, but rather one constrained by cost and enforced technical limitations. When you master this, I name you a “Workaround Specialist.” Coming from me, this is a compliment—it means you truly understand the platform.
I could make a long list of many things that are considered workarounds, but in the last few years the following ones have been the main challenges I have been facing:
1. Storage Challenges
Microsoft values feedback, except when it concerns storage costs. The first issue is the tough price per GB per month compared to other services Microsoft offers. However, it’s cheaper than Salesforce storage, so a price drop seems unlikely soon ☹
Another issue is Microsoft’s inclusion of their solution files and resources, consuming your storage regardless of your needs. This is tied to the cost per GB, prompting partners and customers to push for change.
As a Solution Architect, you must be aware of these factors and plan accordingly, making some projects more challenging and requiring creativity in data storage strategies within Dataverse.
2. API Overages
Microsoft introduced API usage rules years ago, detailing what’s included in licenses and what happens with excessive queries. While free unlimited API access could put a high strain on Dataverse servers, most customers aren’t significantly affected by the limits of today. However, in larger solutions, optimizing API calls is crucial because of the large volumes of data.
This often means offloading logic to other services before Dataverse processes the results. A change chat we all felt when moving from OnPremise to SAAS.
3. Execution Timeout Plugins
The 2-minute execution timeout on server-side code is interesting. New developers don’t always understand why this is a problem, and seasoned developers will always argue that anything running for that long is bad logic or poor design.
While the senior dev’s have a point on the 2-minute limitation design, you often see them offload logic to Azure Functions, which may exceed the 2-minute limit outside Dataverse. So again creating a scenario where logic moves outside of Dataverse to enrich.
What if ?!??!?!?!?!
There may be several reasons why Microsoft needs restraints. Could be technical limitations or the need for monetization. I’m not upset with Microsoft, but it’s interesting to consider what designs could emerge without these restrictions.
- What if we didn’t need to offload data to save on costs?
- Provide cheaper storage at reasonable prices. Make the platform a datahub💡
- What if we could expose our data via “unlimited APIs”?
- Dataverse could be the master of “all data” where all systems and employees interact
- What if there were no 2-minute execution limits on Dataverse code?
- Make async plugins work the same way Azure Functions work. We pay for all compute time over 2 minutes (or something similar). #PayForPlay
Do you now see why I call us Workaround Specialists? 😊 Most of us understand how to navigate the platform’s quirks to achieve goals. The “best architecture framework” exists due to cost and technical limits, not because the platform couldn’t handle more (I believe). Without these constraints, maybe we could avoid building a cobweb of services to solve the customer’s challenges!
We are not the only platform with these challenges, but I’m arguing that we represent a platform where this actually doesn’t have to be an issue. Microsoft owns their own infrastructure in a way many other companies don’t, and therefore have the upper hand on infrastructure.