-
Notifications
You must be signed in to change notification settings - Fork 1
d2a serverless web ux
This document will provide a modern recipe for building highly available, scalable, low-latency, low-cost serverless user/customer centric cyber secured browser experiences in the cloud. A prototype application will be provided for reference and curated list of solutions for common development problems will be provided.
d2a (direct 2 amazon) programming is a change in the way browser based applications communicate with services. Traditionally there has been a false desire to create a middle layer of restful APIs or micro-services. However, with the evolution of the cloud and especially the innovations of AWS no longer this is necessary. Instead the costs and complexity of applications can be decreased while actively increasing scalability using secure, direct communication with services in the cloud in the browser alone.
The entire monolithic or complex ecosystem of restful monoliths and/or complex containerized micro-services can be replaced with d2a. This frees up an organizations ability to focus on user experiences rather than architecting unnecessary domain modeled middle-men between the browser and cloud services. This is realized through signed http requests. All outgoing http requests can be signed to cement a zero-trust link between a browser application and cloud service such as aws. Applications built on this model allow organizations to focus completely on user experience and cloud instead of managing complex, convoluted containers in kubernetes or legacy restful apis on outdated technologies.
This is a working example of such an application. All data is consumed via zero-trust signed http requests to aws in the browser.
This programming model fully enforces modern cyber security best practices while also providing benefits of highly-available, scalable, simplified, low-cost, low-latency browser based applications.
https://aws.amazon.com/security/zero-trust/
The foundation of this approach and central most important aspect is security. AWS Cognito provides the capabilities necessary to achieve zero-trust links between a browser and aws cloud api. The innovation that is central this is federated security or federated identities in cognito. Federated identities allow authorization systems outside aws to transparently authenticate users and map them to roles with policies to grant access to aws cloud resources like a specific service or operation.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html
Following is a curated list of highly available, scalable, low-cost, low latency aws services to replace more traditional relational databases or even more recent nosql solutions like mongo. All services on aws cloud can be used in combination with identity federation to have fine grained control over operations unauthenticated and authenticated users can perform on any given cloud service.
Robust modern search solution that can completely replace a relational database for search operations and provides a slew of other powerful features like fine grained access control, template queries with params, faceting, etc.
AWS also offers their own hosted open search service in the cloud that is fairly easy to set-up for basic user/pass auth. Taking it a step further with fine-grained access control knowledge of aws security like iam users, roles, cognito, identity pools and federated authentication will be necessary.
https://aws.amazon.com/opensearch-service
The cost of running open search domain in aws is astronomically less expensive than traditional relational databases with also a ton of features that those traditional relational databases don't have.
Open search is really not meant for master document storage. For storing master documents like entities traditionally stored across a complex entanglement of relational tables a simple solution would be AWS s3 object storage. That complex entanglement can be made simple and straight-forward by simply storing documents/entities in natural form as json in s3.
https://aws.amazon.com/pm/serv-s3
The demo provided above uses both these technologies and does so by making http requests directly in the browser with a simple server-side proxy to circumvent CORS directly to aws apis. There are several other technologies that could be relevant building a full featured web experience. The detail will be left out but below are a few other aws services for common use cases in web development.
- queue | AWS SQS | | https://aws.amazon.com/sqs/
- email | AWS SES | https://aws.amazon.com/ses/
- notifications (pub/sub) | https://aws.amazon.com/sns
All of which have restful apis that can be used directly in browser using singed http requests. Additional investigation is needed regarding connecting to a websocket for pub/sub using this methodology without a middle layer for security.
When no aws service fits the bill or migration to an aws service is more trouble than its worth. There are always lambda. Lambda provides a means to create custom apis and augment events within aws such as; when an object is added to s3. Lambda supports many different languages such as; javascript, python, go, etc. Languages and frameworks with low cold start times are best for Lambda. Java/JVM and C#/.NET are not such languages and should probably be avoided. Although containers can also be used in Lambdas.
https://aws.amazon.com/lambda/
To expose lambdas to the outside world aws api gateway can be used. AWS api gateway provides a simple, low-cost means of making it possible to execute a http request and response compatible lambda functions.
https://aws.amazon.com/api-gateway/
Lambdas are key aspect to what is referred to as serverless computing. Serverless computing is another essential building block of allowing organizations to focus on apis and not the infrastructure since lambdas are auto scaling and completely managed in the cloud by the ecosystem vendor.
The demo provided above is actually being served via api gateway and lambda. The major advantage of this instead of using a static cdn is that server-side rendering environment is available. Therefore, SEO will not be impacted since the initial content will exist physically on the page. Although the demo above does not do this just yet there are some bugs to work out of the server-side rendering related to waiting until the page is "complete". For internal applications where SEO isn't necessary s3+cloudfront is the way to go. The browser webpack compiled javascript for the above demo is being served from cloudfront cdn.
https://aws.amazon.com/cloudfront/
A noteworthy mention for managing serverless computing like lambdas is serverless framework. Alternately the more direct route of using cloudfront templates or manually creating lambdas can be taken. Although manually creating lambdas in the console is probably not best for a well architected cloud environment only learning purposes.
Lastly, although this discussion and approach has been centered on aws cloud. In theory the approach could also be used for any service or cloud vendor. However, the provider need implement key components like identity federation, fine grained access control, and signed http request to communicate with services within the ecosystem.