Cloud Hosting Overview

Background

Previously we completed our mobile theme by discussing Coding Key Points for the iOS app. Next we will begin a theme on modern deployment, and describe how the corresponding cloud infrastructure was created.

URL Design

Hosting should start with a URL design, and this blog uses a subdomain approach, to represent component separation on a small scale:

Domain Description
https://web.authsamples.com The Base URL for Single Page Apps
https://api.authsamples.com The API Gateway Base URL
https://login.authsamples.com The Authorization Server Base URL
https://mobile.authsamples.com Hosts assets for Mobile Apps

Each subdomain can be a Serverless or Cloud Native endpoint. This blog will mix and match, depending on which option best meets our requirements.

DNS Setup

The AWS cloud is used, which starts with registering a parent domain of authsamples.com in Route 53:

Multiple internet accessible subdomains can then be registered as ‘A records’ under a Hosted Zone:

If you have your own cloud domain and subdomains, you could reconfigure this blog’s samples and deploy them there, with the same technical steps.

Managed Internet SSL Certificates

AWS Certificate Manager will issue TLS 1.3 certificates to our subdomains, using the same wildcard concept we’ve used on a local PC in earlier posts:

We will only have a single certificate to manage, and AWS will automatically renew it when it gets close to expiry.

Web and API Separation

The API base URLs support multiple microservices hosted behind the same API gateway:

The web base URL supports hosting multiple micro-frontends for the same business area:

SPA Deployment

The SPA deployment model will continue to be just static content, and we will just deploy our web resources to the web.authsamples.com S3 bucket:

We will then use AWS CloudFront as a Content Delivery Network:

Cloudfront pushes web content to many locations, to enable globally equal web performance, in a technically simple manner:

Serverless APIs

Initial cloud API endpoints will use the Serverless Framework. This enables us to host APIs at low cost, with minimal infrastructure to manage:

The AWS API Gateway will be the entry point for Serverless APIs:

Initial Cloud Authorization Server

Earlier in this blog we described  AWS Cognito as an initial low cost authorization server. We will explain the AWS setup shortly:

Cloud Connected Code Samples

Use of cloud hosting enables any reader of this blog to run this blog’s OAuth code samples. Deployed endpoints are especially useful for mobile apps:

The Code Samples Quick Start page provides details of online URLs and guest credentials for running the demo apps.

Centralized API Logs

APIs will use this blog’s Effective API Logging design to write immediate log data to AWS Cloudwatch. These logs could then be aggregated to a managed Elasticsearch service. The Kibana tool would then be used to Analyse API Activity:

Serverless Costs

The AWS costs for the above setup (excluding Elasticsearch) are around 13 USD per year to register the base domain, along with a further 0.60 USD per month. This is an attractive option when getting started with cloud hosting:

Kubernetes Deployment

The API side of the architecture can also run in a Kubernetes environment. In AWS this would be managed by spinning up an EKS cluster, that hosts this blog’s final APIs, along with any suppporting components.

Where Are We?

We have defined our desired behaviour, and the following blog posts will describe some implementation details. In all cases our application code will remain portable so that it could easily be hosted elsewhere.

Next Steps