Serverless computing in Azure: How to build a petition site

This example shows you how to use Azure services to build scalable, serverless web applications

Current Job Listings

The other day, I found myself watching a ticker on a petition site slowly roll over at a million signatures. It was clear that the site was struggling, with authentication emails taking anything up to 24 hours to send, resulting in queues full of unapproved signatures waiting to be written to a database. Watching that ticker count up, I started to wonder how a service like this could be built using some of the more modern cloud-first design options available with Azure, putting together many of the tools and services I’ve written about in this column.

The architecture for a service like this is relatively simple. You need a web front end to collect signatures, a messaging framework to deliver them to a scalable back end, using microservices to write them into a database and to verify sender identities. You can then use other messaging tools to keep track of signatures, and you can use analytic tools and machine learning to identify invalid entries.

Designing a web tier

One key element of a service like this is the web content. It’s important to choose the right web development framework. If you’re going to use Azure microservices to handle page-generated events, a single-page web application (SPA) is a useful framework to build on. Azure’s tools for handling scalable web content provides a platform for delivering content, using its content delivery network to scale out static content and page templates, with Azure Front Door’s built-in application gateway to handle load-balancing web application servers and to provide a web application firewall.

I would use React as a web framework because it works well in SPAs, and its responsive nature makes it a good fit for an application that needs to work across multiple devices. It makes it easy to connect form elements to JavaScript, letting you construct a CloudEvents payload and send it to your microservices back end.

Building a service like this around a messaging-driven event architecture makes a lot of sense. You need to be able to scale, and you need to be able to work across an environment that’s rapidly changing. Messaging, especially when tied into a message broker, can handle dynamically changing infrastructures and standards-based message formats such as the one at the heart of CloudEvents give you a framework for building and constructing message headers and payloads.

To continue reading this article register now