Notifications Service #
Description #
The Notification Service is designed and built to send and track notifications (messages) sent to users. Messages sent through this service are stored in a repository and are available for users to browse at any time.
Optionally, in addition to storing and displaying messages through a notifications screen, messages can also be specified to be sent via email or SMS protocols directly to a user as well. Any message sent via an external provider are tracked and updated automatically based on factors such as sent status, delivery, read, etc…
Purpose of this Document #
This reference architecture shows a serverless, event-driven architecture that ingests data (notifications or messages), processes the data, and writes the results to a back-end database, while optionally leveraging external providers to support send of notifications via email or sms.
This reference architecture walks you through the decision-making process involved in designing, developing, and delivering the Notifications service for SpheraCloud. You will be given hands-on instructions for configuring and deploying all of the architecture’s components, with helpful information about each component along the way. The goal is to provide you with practical hands-on experience in working with several integral Azure services and the technologies that effectively use them in a cohesive and unified way to build a serverless-based microservices architecture. We hope this will leave developers with a newfound appreciation for how serverless can be leveraged for both large-scale and small solutions, and the confidence to apply what you learned in your own projects.
Design Principles #
This service was focused on addressing 5 basic pillars that define a well architected cloud application. Creating a software system is a lot like constructing a building. If the foundation is not solid, structural problems can undermine the integrity and function of the building.
When architecting technology solutions for the cloud, if you neglect the five pillars of operational excellence, security, reliability, performance efficiency, and cost optimization, it can become challenging to build a system that delivers on your expectations and requirements. Incorporating these pillars into your architecture helps produce stable and efficient systems. This allows you to focus on the other aspects of design, such as functional requirements.
See more information about Sphera’s 5 pillars approach to design here.
Serverless approach #
The term serverless has two distinct but related meanings:
- Backend as a service (BaaS). Back-end cloud services, such as databases and storage, provide APIs that enable client applications to connect directly to these services.
- Functions as a service (FaaS). In this model, a “function” is a piece of code that is deployed to the cloud and runs inside a hosting environment that completely abstracts the servers that run the code.
Both definitions have in common the idea that developers and DevOps personnel don’t need to deploy, configure, or manage servers. This reference architecture focuses on FaaS using Azure Functions, although serving web content from Azure Blob Storage could be an example of BaaS. Some important characteristics of FaaS are:
- Compute resources are allocated dynamically as needed by the platform.
- Consumption-based pricing: You are charged only for the compute resources used to execute your code.
- The compute resources scale on demand based on traffic, without the developer needing to do any configuration.
Functions are executed when an external trigger occurs, such as an HTTP request or a message arriving on a queue. This makes an event-driven architecture style natural for serverless architectures. To coordinate work between components in the architecture, consider using message brokers or pub/sub patterns. For help with choosing between messaging technologies in Azure, see Choose between Azure services that deliver messages.
Additional details and considerations about serverless technologies on Azure are discussed in more detail here.
Architecture Overview #
The primary architectural components that make up the Notification Service are:
| Component | Technology | Description |
|---|---|---|
| Api Gateway | Azure API Management | An API gateway that acts as a front-end to the solution APIs. Among many other benefits, the API management service provides SpheraCloud APIs with security verification, usage telemetry, documentation and rate limiting. |
| Notification APIs | Azure Functions | A single set of Function Apps are deployed to serve Sphera’s Notification APIs: send, change, and read. This API is exposed to consuming applications via the API manager and provide CRUD operations for each of Notification entities. |
| Pub/Sub | Azure ServiceBus | This service leverages Azure ServiceBus Topics and Subscriptions to manage all non-read related activities within the notification system. This provides for a completely asynchronous approach for repository writes without affecting performance for read operations. |
| Queuing | Azure ServiceBus | This enables the applications to process event-driven status and delivery state changes to ensure ordered processing while allowing for autoscaling functionality. |
| Repository | Azure SQL as a Service | Acting as a fully compliant SQL Server with automated backups and redundancy handled by Microsoft Azure. |
Sphera decided to use the following criteria to determine when a certain piece of functionality is to be considered a Microservice:
- The functionality must be able to scale or be deployed independently from other parts.
- The functionality must/can be written in a separate language/technology like Node.js in case there is some certain expertise that is only available in that specific technology.
- The functionality must be isolated by a clean boundary (bulkhead).
- Circuit-breaker functionality must exist when internal components interact with each other.
High-level Logical Architecture #
The high-level architecture and decision making process in selecting technologies and approaches for this effort can be found here.
Essentially, all choices were run past the Sphera 5 Pillars approach to design to help identify the best candidate technologies to use balanced against business needs. The number one consideration, as always, when designing software is does this add business value? Whenever possible, candidate technology or competing possible approaches were weighted towards using native Azure PaaS functionality rather than self-managing or building comparable features when all other factors were equal.
Normal Operation #
The notification service standard operational diagrams and workflows can be seen here.
This link provides information on the sequence of operations that service incorporates to complete a given business task.
