Recently the Plexure engineering team completed its initial integration of Azure Mobile Engagement with the Plexure platform. Azure Mobile Engagement, or ‘AZME’ as it’s referred to around here, is an Azure product focused on providing sophisticated push message targeting for mobile devices, with excellent tagging and segmentation and powerful push message features. You can read more about it on the Azure site.
Evaluating Azure Mobile Engagement and Notification Hub for push messaging
Deciding to integrate it as a core part of the Plexure platform was a no-brainer for our product and architecture teams. Push messaging is just one of the channels the Plexure platform uses to engage customers, and targeting a push message at an individual is usually the result of a variety of platform inputs coming together to decide how to engage a customer, with a push message being but one of the possible ways of doing so. While Plexure has been a long term user of Azure’s Notification Hub (and even participated in preview programs with Microsoft), the opportunity to bring the feature set of AZME to the Plexure platform was one we definitely had to make the most of.
For us, the most significant technical difference between the two products is the approach taken to actually send the messages. Notification Hub focuses on a synchronized tag set allowing it to send millions of push messages in just a few minutes; while AZME’s sophisticated tagging engine allows marketers to create complex targeting rules which are evaluated at the time of sending – this leads to longer send times but much more flexibility in the criteria used to target individuals. The AZME team are continually optimizing the send pipeline though, so eventually we expect this point of difference to disappear.
Based on these fundamental differences the product team took a decision early in our AZME implementation to support both methods of sending push messages – so both Notification Hub and AZME are supported as distinct push message channels in the Plexure platform, to support two kinds of customers: Those with a requirement to send push messages to millions of consumers very rapidly, and those who want to access the more sophisticated tagging and segmentation AZME provides but don't need them all sent straight away. Although we don’t expect both channels to be active at the same time, having options to suit our customer’s unique needs adds a lot to this area of our product.
Overcoming architectural challenges with microservices
The architectural challenge was clear – we needed to implement both channels in a way which isolated the new AZME feature-set from our core platform features and was nicely configurable so it could easily be ‘switched on’ to support customers who wished to adopt it. Luckily, the engineering team has been focused on migrating our core platform features to a microservice based architecture, so the prospect of creating a brand new integration with a downstream system was quickly identified as one microservices could help with.
One very appealing benefit of microservices is the ability to form small teams focused on delivering the service using their own style and practices – and so our first true microservice team was created. It consisted of a couple of senior engineers and an automation tester working very closely together to deliver a self-contained AZME ‘façade’ service, responsible for sitting between our core platform and the AZME APIs. The team chose to deliver the service using a combination of Web API, Web Jobs and table storage, along with an SDK delivered as a Nuget package the core platform team could bring into the platform code base for all interactions with AZME services. The team also worked hard to have a great DevOps story for the service, with a full continuous delivery pipeline orchestrated by Atlassian’s Bamboo and Azure Resource Manager templates for managing infrastructure.
The only real challenge we had was a typical multi-team one – the AZME team were delivering features that had to be consumed by our core platform team – so naturally there were some interdependencies that had to be resolved. However these were largely process problems rather than any real technical challenges. Overall the choice of delivering this as a discrete microservice by a separate team has been a resounding success, and has given us some excellent lessons we can take forward into the rest of our architectural roadmap as we implement more microservices for different parts of the platform.
We're now tackling the challenge of creating a great 3rd party mobile developer experience to adopt AZME’s unique benefits along with the Plexure SDK – watch this space!