Building Serverless Applications on AWS

[ Part-I ]

1. Use Serverless or Hybrid architectures [serverless functions + containers] 
2. IAM – Identity and Access Management 
3. Use decoupled and asynchronous architectures 
4. Let architecture handle the complexity while the code has single responsibility principle implementation 
5. Enable proper Observability built into the architecture
   1. Observability is used to view the Bottlenecks in the application 
   2. Observability is used to view the Errors in the application 
   3. AWS X-Ray (inbuilt) and Lumingo (a third party service) are available to monitor and debug applications. Thundra is also for distributed. 
6. Use purpose-built databases 
7. Implement security 
   1. Use WAF with CloudFront 
   2. CloudFront OAI [Origin Access Identity] to restrict access to the public website, etc. 
8. CIP: FuelPass system in Sri Lanka received a million requests on the launch day 
9. Caching:
   1. The more we move into our application, caching becomes costly (e.g., at the database level, etc.). So, usually we keep it at the outer level (for example, CloudFront, etc.) 
   2. If we have CloudFront caching enabled, and let us say our frontend application is hosted on the S3 bucket. Then, the user will not go to the S3 again and again, but the user request will be served through the CloudFront cache, instead. 
10. Amazon Cognito:
    1. For passwordless user authentication
    2. Managed 
    3. Charges / month based on number of Users 
    4. Has auth challenges as well 
    5. Once the User authentication challenge is successful, they will be added to the Amazon Cognito User Pool and it will return tokens (id and access tokens)
       1. AWS Amplify will manage all the tokens generated above and will sit between the frontend application and the Amazon Cognito to timely refresh the token nearing their expiry, etc. 
    6. After the Amazon Cognito auth processes are finished, we can invoke our own Lambda functions and do the desired processing of those registered users 
11. SNS – Simple Notification Service to send SMS, etc. to the end users through Amazon Cognito  

    

12. AWS -> Managed Services Design Principle 
    1. Concurrency limits – AWS only allows 1000 Lambda concurrent request per account (increase this limit by raising a Support Ticket) 
    2. Define Reserved Currency for Lambda (Ceil) to not let other Lambda functions choke in case one Lambda function is requiring too much web server resources 
13. Databases are not inherently as scalable as the Lambda functions 
14. API Gateway:
    1. A managed REST service from AWS 
15. Event Bridge:
    1. A managed service from AWS – being a managed service, scalability is already there 😉 
    2. It is a Serverless Event Bus Service – just like a Pub-Sub service 
    3. Create our own Event Bus here and start publishing events 
    4.  Event Bus is a content-based – i.e., it can look at all the attributes (content, headers, metadata, etc.) of the event (which are JSON objects) and creates filtering rules to direct traffic to the intended targets 
    5. Uses:
       1. Event Bridge really helps to extend the functionality of your application; especially for the evolving architectures 
16. SQS 
    1. AWS managed service 
    2. Can process millions of events 
    3. A transit service infact 
    4. Can hold messages up to 14 days (default is 4 days) 
    5. Uses:
       1. EventBridge can invoke as many Lambda functions as it wants due to the builtin scalability in AWS. To control the number of Lambda functions, SQS is used to throttle and keep the costs lower. 
       2. Also, if third-party applications or integrations are being invoked based on the EventBridge events, then the 3rd-party web server might get rundown due to the large number of requests directly from the Lambda functions invoked by the EventBridge concurrently. 
       3. Sometimes, the 3rd-party applications might be down already, so the request will be re-queued so that it can be pushed to the third-party again, once that system gets back online. 
17. AWS Step Functions Express Workflow
    1. A managed service from AWS to manage your Workflows
       1. highly scalable ~100k workflows can be invoked in parallel 
       2. Has 5 minutes duration limit 
       3. Can not bind with asynchronous workflows directly 
    2. Unlimited execution history is available in the CloudWatch logs for this 
    3. Only Standard Workflows supported – standard workflows support asynchronous requests
       1. Standard workflows are expensive as you are billed for the state-transitions [roughly $25/1 million state transitions] 
18. SAGA design pattern