Slides from my talk at OSCON 2018.
From functions to containers to databases, serverless is a huge paradigm shift. The ability to only pay for what we use and not worry about underlying infrastructure is very tempting to developers and DevOps engineers, and the rate of innovation in this area has been very rapid across all major public cloud providers. Serverless architectures are the natural evolution of microservices design. While Lambda has become synonymous with serverless in AWS, there are several new and upcoming patterns that take serverless architectures to the next level.
Manish Pandit explains how to identify these patterns and put them to use. Using Marqeta’s efforts to move its payments infrastructure to the public cloud as an example, Manish explores the services that Marqeta considered, customized, hacked around, and successfully implemented as a part of this move.
Amazon Cognito is a managed service that provides federated identity, access controls, and user management with multi-factor authentication for web and mobile applications. The service is very rich - any application developer can set up the signup and login process with a few clicks in Amazon Cognito Console by federating with identity providers such as Google, Facebook, Twitter, etc. One of the best features of Cognito is Lambda integration (Triggers), which allows Lambda invocation on events like pre-signup, pre and post authentication, etc.
In this post I will walk through a not so fancy, yet very useful Cognito feature - which is server to server authentication. This is one of the most common scenarios in a microservices world, where services need to talk to other services securely, and using an established standard such as OAuth2. This is also known as
2-legged OAuth. Amazon Cognito provides a simple and cost effective option to implement it.
Amazon API Gateway is a great way to wrap Lambda functions as microservices exposed over HTTP/S, among many uses. However, any API Gateway endpoint is publically accessible. There are ways to restrict access using IAM and Authorizers, but for simple task of IP whitelisting was always somewhat challenging, if not downright hack-y.
Recently AWS announced Resource Policies for API Gateway, which make IP whitelisting a breeze. This is extremely helpful for a company such as mine, as we deal with a lot of integrations that rely on IP whitelisting as one of the many layers of security. In this post I will walk through setting up IP whitelisting on an API hosted on API Gateway. We will use API Gateway’s built in Mock API feature to create a simple API, and secure it via IP Whitelisting.
This post is an overview on running ElasticMQ in Amazon ECS. This can help simulate SQS for development purposes, and running it in ECS would help with resourcing, as well as having an ALB to act as an
endpoint-url. I’ve used EC2 and not Fargate, but this can just as easily be launched as a Fargate task. While there is also localstack, for this particular case, I just wanted to run SQS Mock and not all other services localstack comes bundled with.
Familiarity with ECS, specially around creating Task Definitions, Services, and associating them with Application Load Balancers will definitely help.
Presentation on Disaster Recovery and Reliability.