(Written in collaboration with Gerasimos Fousekis & Stefan Starke)
While our roots are firmly planted in traditional software development methodologies, our commitment to innovation and client satisfaction drives us to continuously explore new horizons. This leads us to consider various emerging platforms, like Microsoft Power Platform, as potential additions to our already extensive toolkit.
While this might seem a bit unconventional for a software development company, our motivation is rooted in a deeper understanding of the ever-evolving business landscape and the diverse needs of our clients.
"What was your goal?", you ask.
In brief:
Fast results
How much faster can we implement solutions when working in an environment with topics such as authentication, infrastructure and deployment, more or less out of the box?
Customer empowerment
Can the use of something like Power Platform help clients maintain their applications, run updates, and introduce new features with little to no prior coding knowledge?
Project diversity
Which projects do we see this approach as being beneficial, optimal even?
Are there any blockers that could prevent us from following this approach?
Overview
Microsoft Power Platform is a suite of integrated tools and services designed to assist individuals and organizations in creating custom business applications, automating workflows, analyzing data and generating reports.
It's comprised of four core components:
Power Apps & Power Pages
They allow users to create custom applications without extensive coding knowledge, to begin with. They offer canvas apps and model-driven apps: canvas apps enable building applications with a visual interface, while model-driven apps are more data-centric and built on the Common Data Service. Both interact with (business) data stored in the Dataverse with the main difference being that Power Pages is targeted at external users backed by the many authentication options (e.g. Azure AD, LinkedIn, Facebook) that are available out of the box.Power Automate
Formerly known as Microsoft Flow, enables the automation of repetitive tasks and workflows across various applications and services. It connects to hundreds of apps and services, allowing users to create automated processes without much complexity (e.g. automated email sending).Power BI
A powerful business analytics tool that allows users to visualize data, generate reports and build dynamic dashboards. It's particularly useful for data analysis and decision-making by turning raw data into actionable insights.Power Virtual Agents
Allows users to create chatbots that can be used to engage with customers, provide support, answer queries and automate various interactions.
Aiming to fulfill the requirements mentioned previously, we ultimately focused on the use of Power Pages and Power Automate.
Pros & Cons
PROS | CONS |
Smaller, data-driven applications can be clicked together really quickly | Generally useful features (i.e. manual code changes, template presets) are better avoided altogether due to limited usability |
Out-of-the-box ecosystem (e.g. infrastructure, scaling, IP whitelisting etc.) | Frequently unreliable and lengthy loading times during development, especially when reloading the Designer |
Built-in application lifecycle management (e.g. environments with pipelines) | Cost can become very high for projects with a larger audience |
Built-in i18n capabilities | Changes performed directly on the tables inside the Dataverse (e.g. scheduled job manipulating some rows) can take up to 15 minutes to apply |
Limited monitoring capabilities and having no way to see where anonymous users come from (i.e. IP addresses) |
Next, we'll share some useful insights gained along the way.
Pricing & Costs
First, a word of advice - make sure to understand the licensing and billing of the entire Power Platform ecosystem to avoid unpleasant and costly surprises. In our setup, the main cost driver (besides Dataverse storage) was the amount of monthly active users, both anonymous and authenticated. Prices vary depending on the chosen subscription plan, meaning either a package of a set number of users or the option of "pay as you go" (PAYG). Technically, we used a billing policy linked directly to an active Azure subscription.
That being said: be aware that current costs are not immediately visible and it can take up to 24 hours until they become available within Azure cost management.
"Why is there so much emphasis on pricing?", you might be asking.
Imagine a scenario where someone sets up a basic cron job that operates on the Dataverse every minute or so. A premium flow that can either run in the cloud or attended costs $0.60 per run, mind you.
We'll let you do the math and figure out how high the costs get when the cost management alerts start triggering, which - as explained above - can take up to 24 hours to be updated.
Spoiler alert: It's $864.
Use a Power Automate license in similar scenarios.
Speaking of monthly active users...
They are reported in a daily summary, downloadable within the Power Admin Portal.
Considering the uniqueness of an anonymous user being tracked using a browser cookie, we see a potential risk of unpredictable costs as a consequence. The claim is that malicious attacks, bots and crawlers are excluded from being counted, but we could not 100% confirm this statement.
TL;DR
Understanding the main use case for the application, with regards to target users, is highly advised to avoid precarious financial situations
Make sure to choose the optimal licensing model from the very beginning
As in all cloud projects: enable cost alerts from Day One!
Development
As with every new technology, there will be a learning curve. It's not particularly steep when it comes to the Power Platform itself, but one has to be wary that the workflow is not comparable to a 'traditional' software development process. Coupled with the documentation provided by Microsoft, which sadly tends to be a bit outdated at times, this can be a cause for sudden spikes in the overall learning curve.
Coming into this methodology, it took us some time to get used to the way collaborative work can be set up on a shared Power Pages environment. Because there's no implementation of version control, merge requests or individual commits, it took further coordination to avoid interfering with one another. This is easily manageable for smaller-scale projects, though not recommended for larger projects. In turn, we recommend a team size of no more than 3 people for optimal workflow.
One undisputable upside is that coming from a background of data-driven applications with CRUDL (Create-Read-Update-Delete-List), overall development time is crazy fast. It essentially boils down to "creating tables, views and forms (rinse and repeat)". Development is further sped up by the use of provided components for features, such as:
Login
User Registration
Authentication Providers
TL;DR
Ideal for small, low-complexity projects
Works best for smalled-sized teams (2-3 people max)
Close to no collaborative features, a developer would normally be accustomed to
Always use (and re-use) components whenever possible
Testing
We know how much developers love testing code (*sarcasm*). Good news: manual testing is pretty much your main 'go-to' approach in the Power Platform. For those interested in automated testing, we can use our default framework (Cypress), triggered by an external build.
Deployment
When it comes to deployments, we set up a pipeline that can be executed within the Power Platform, together with the typical pattern of cross-environment deployment: Dev → Test → Prod.
We have noticed that it is sufficient for the before-mentioned, smaller projects.
Of course, it is not as powerful as either Gitlab or TeamCity, but that would not be needed.
Scale, Expand & Maintain...ability
In terms of scalability, besides maybe investing more money into a broader user base or file storage capabilities, not much to add in this regard. If the final goal is to create smaller, lower complexity applications, we think the expandability options provided should suffice (an API for CRUDL can be used, as well as Azure Functions with an HTTP trigger, for more complex logic).
Similarly, with the premise of a smaller application, maintainability options offered should again suffice for most projects.
i18n ("Internationalization")
i18 support is provided on the platform. There's a reasonable list of available languages that can be activated for every given page, the pattern used is a 'key-value'-type approach: language → translation.
Except for a few components that are translated automatically (i.e. login), translations must be provided contextually on each page, for each desired language. On the flip side, there's the option of providing a resource file for said translations (that being said, we did not delve into this approach enough to confirm its utility).
Lessons Learned
For some, Microsoft's Power Platform might seem to only thrive in specific scenarios (think one-trick pony). We believe that it has earned its place in the ecosystem of modern technology stacks, and when it comes to:
Rapid Fire MVPs
Purely data-driven projects
"Set it and forget it"-type projects
Pre-defined user bases
Minimal UI
Pre-existing Microsoft ecosystem integration
"Developing without developers" (Welcome to 2023)
there is close to no competition. We say "give it a try".
It might end up being the solution you were looking for.