In this blog post, I show you one possible implementation of an on-demand trigger on AWS. To enable you to tinker with the architecture, I publicized the code to reproduce the example at GitHub. I also included code snippets throughout the post to help you follow along with the implementation details.

Note:_ this approach is not meant to be a blueprint, let alone a best practice architecture. Instead, it is meant to provide some insights on what is possible with the cloud and how an actual implementation would look like. And it was fun to build, too._

---

The upcoming pattern covers two major functional requirements:

1. Our customers want to trigger computations whenever they see a need to do so. However, they refuse to wait for manual support, neither in the form of a contact person, nor a ticketing system. On the other hand, we have absolutely no intention to provide them with direct access to our precious cloud. Consequently, we need to implement a mechanism that allows automated triggering without access to the actual infrastructure.
2. In addition, we want to be informed every time a customer triggers a computation. From experience, problems tend to arise when people use our products and we want to be prepared to extinguish fires if necessary.

In this blog post, I show one solution for both requirements that uses an email endpoint. The customer can write a message to an address managed by AWS, which then triggers a computation. Let me show you the details.

_Note: _verifying a domain within AWS is outside of this post’s scope, but it is needed to use AWS email services. See here and here for information on how to do it.

---

The overall Architecture

To cover the requirements, we need to realize three functionalities:

1. We need to implement an email address that receives mails.
2. We need a coordination mechanism that reacts to incoming mails and triggers the desired computation. We use the same mechanism to fulfill the monitoring requirement.
3. We need a place where the actual computation takes place.

Each of these functionalities translates into one service within AWS’s ecosystem:

• The** Simple Email Service (SES) **receives mails from the outside and forwards them. To do that, we need to implement an appropriate rule.
• **Simple Notification Service (SNS) topics **accept the forwarded mail and pass it on. Since SNS pushes messages to all subscribers, we don’t need to implement a polling mechanism.
• Lambda’s serverless functions handle whatever it is we want to trigger with our architecture.

Here is a graphical overview of this simple architecture:

The receiving end and the processing logic connect via an SNS topic. SNS topics work via the publish/subscribe paradigm. That is, SES publishes incoming mail to the SNS topic; the Lambda function automatically receives them via its subscription to it.

In this blog post, I show the implementation in Terraform, but you could also realize this architecture via the web interface or CloudFormation. If you have no previous experience with Terraform, check out their introduction material, or ignore the specifics. Be aware that AWS configures some of the details in the background when you use the web interface. That is convenient, but might be problematic once you need to debug the infrastructure.

#programming #terraform #cloud