Power Platform Solution Architecture: High availability and redundancy considerations

In this next post within my series on Power Platform solution architecture we’ll move onto a final consideration for solution architects to make taking things into account at a high level relevant to the platform. We’ll focus specifically on needs and considerations for solutions… READ MORE [https:
close up shot of keyboard buttons
Photo by Miguel Á. Padriñán on Pexels.com
In: Low Code Lewis Content 🚀

In this next post within my series on Power Platform solution architecture we’ll move onto a final consideration for solution architects to make taking things into account at a high level relevant to the platform. We’ll focus specifically on needs and considerations for solutions that should have ‘high availability’ and we’ll look at considerations for backup and redundancy.

What is high availability?

When we refer to high availability we’re talking about highly scalable solutions with no single points of failure or potential failure, backed on a highly scalable cloud platform (Microsoft Azure) and that have granular monitoring and error reporting for mitigation and resolution.

The outcome of following these principals should be that we have a highly available solution that doesn’t encounter outages regularly if at all.

When it comes to Dynamics 365 first-party product and Power Platform products and the backend functionality of the objects we build with, we don’t need to worry about these and Microsoft manage the high availability of these.

The areas we have to think about are areas of custom logic. These are areas where the responsibility lies with us as solution architects to ensure the code we develop is reliable enough to be highly available and has the various things in place that follow the previous principals we spoke about. That may include things like monitoring and logging issues to something like Azure Monitor.

Redundancy

When it comes to redundancy or backup options Microsoft handle the best part of this for us in terms of location based outages if these arise. There are areas as solution architects we should consider though. For example if building plug-ins or integrations as options for custom logic, we should ensure they have the appropriate functionality implemented to utilise and handle retries if needed. Or let’s say the endpoint for an environment has changed. Integrations should use the global discovery service for endpoint discovery to get the latest environment endpoint. These are some of the things we should be thinking about in terms of redundancy and these are based around custom logic we implement.

Written by
Lewis Baybutt
Microsoft Business Applications MVP • Power Platform Consultant • Blogger • Community Contributor • #CommunityRocks • #SharingIsCaring
Comments
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to LewisDoesDev.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.