In the same way the AWS Cloud Foundations can be thought of as a lightweight version of ITIL practices, the AWS Well-Architected Framework can be thought of as an AWS-specific take on enterprise architecture frameworks such as Zachman or TOGAF. It is organized into six pillars – operational excellence, security, reliability, performance, cost optimization, and sustainability.
The AWS Well-Architected Tool is available at no cost in the AWS Management Console. It is a guided walkthrough of many subcomponents of each of the six pillars. It provides specific architectural guidance and best practices in the context of specific AWS services and configurations. It helps you review the state of your applications to identify opportunities for improvement and track your progress toward them over time.
AWS Trusted Advisor is a service that will continuously evaluate your AWS environment against the best practices outlined in the AWS Well-Architected Tool. Note that even if you use this service, it is still important that you walk through the manual exercises in the AWS Well-Architected Tool to connect the intent of your organizational policies and goals with how things are configured.
Infrastructure as code
It is vital that you implement an operational policy whereby nothing gets changed within a production AWS account except by some form of Infrastructure as Code (IaC). AWS CloudFormation or Terraform templates that are part of a CI/CD pipeline in AWS CodeBuild or GitLab are excellent starting points.
This is likely to be more work than simply logging in to the AWS Management Console and manually doing everything – at first, anyway. Once your team gets the hang of these tools, the visibility thus gained will yield exponential gains in the speed with which they can implement new features or respond to problems in the application.
Most importantly, you will be able to easily assess the impact of any proposed changes because you can deploy an exact duplicate of the application – including its underlying infrastructure – into a test account before pushing it to production.
Now that you’re familiar with a systematic approach to building your edge computing applications, let’s take a look at some recommendations as well as pitfalls to avoid.
Patterns and anti-patterns
This section will review recommended architectural patterns you should try to follow. It also touches on anti-patterns to outline some key pitfalls to avoid when architecting a distributed edge application on AWS.
Leveraging cloud-native services
It would certainly be possible to develop a globally distributed Industry 4.0 application without using any cloud-native services. Some customers are inclined to do this because they wish to reserve the option of moving their application to another cloud service provider or to an on-premise data center. The trouble with this approach is that you are forced to use only least-common-denominator features that are common across all CSPs or private clouds. In the context of AWS, this means you can only use standard S3 buckets, a limited set of EC2 instance types, and only the most basic features of supporting functions such as VPC. This has the effect of making your task of application design far more complex.