Back for my Second Re:Invent
It’s an honour to be back representing Telstra Purple at Re:Invent 2019, and just like last year, I’ll be posting each day, going through all the highlights from AWS’s premier event from my own unique perspective. This year the Purple contingent are all staying at the New York New York hotel.
Reducing the blast radius with cell based architectures (Session)
This session took a look at the Cell Based Architecture and discussed how this kind of architecture can be used to minimize the blast radius of application failures, to improve reliability and availability of a service at scale. They then proceeded to walk through how this architecture is used to implement security monitoring and real-time remidiation of AWS Accounts internally.
This was my first introduction to Cell Based Architectures, so I was glad for a quick 101 of the concepts. The concept seems to steal bits and pieces from App Mesh, Microservices, Actor Pattern, and general serverless concepts. I won’t go into detail here (read the reference architecture if you’re interested), but the basics are, a cell consists of multiple components that are manageable and observable individually. Each cell then becomes the horizontal scaling point in order to meet demand. On top of these cells sits a thin routing layer that is used for things like load balancing, policy, and scaling. Cell based architectures are particularly useful for very high scale integration style applications where sharding is necessary to ensure the correct amount of parrallelism to achieve the processing in a timeley manner.
The talk focussed mainly on how to implement this using AWS serverless components. For example, events are created when objects are added to S3, this is then added to an SQS queue, where it is picked up by a routing lambda that is responsible for routing it to the correct cell. Each cell is identical, and spun up using infrastructure as code to ensure consistency and repeatability. These cells consist of whatever AWS infrastructure is required to perform the operation, for example, this might be a lambda, a S3 bucket, and a kinesis firehose. This approach gives the routing lambda the ability to detect slow/failing cells, and attempt recovery, or re-provision a new cell to replace it. The speakers also discussed how this fairly easily opens the door to creating multiple envirnments, say for stress testing as well as replaying failed events.
The speakers did warn about the possibility of hitting lambda concurrency limits (1000 concurrent requests per region) and suggested that a possible solution was spreading the architecture across regions if this were likely. Of course that adds some complexity to the architecture.
This has certainly peaked my interest in the idea of cell based architectures. I find the concept of the horizontal scaling point being the cell which contains all necessary components to accomplish a slice of functionality quite logical.
Building serverless applications with Amazon DynamoDB and AWS Lambda (Workshop)
Last year, I spent all of my time going to sessions and chalk talks, (not to mention the odd Keynote). This year I decided to actually spend 2 and a half hours in an actual workshop getting hands on experience. My focus for a while has been on Serverless, and after watching This ReInvent Video, I have been interested in single table design in DynamoDB, and keen to see how it worked in the real world.
The workshop was in four parts. The first part set up a fairly standard static hosted SPA using S3, backed by an API using API Gateway, to a lambda (written in python of course) writing to a single DynamoDB table. The web app was a basic e-commerce site that sold products from a catalog stored in DynamoDB, and allowed a user to place orders which were then stored in the same DynamoDB table. The table had a partition key and a sort key. For a product, thie partition key and the sort key were both set to the item name. Customner orders were stored in a de-normalized fashion by storing only the lineitems of the order. This was achieved by creating a unique timebased prefix that started with ‘CUSTOMER-ORDER-‘ followed by a timebased epoch that uniquely defined the OrderId, then appending a monotonically increasing integer for each new line item. Operation metrics such as “total orders” were also stored in this table. An itemType field was added to both products and operation metrics, but interestingly, not to customer orders. This was used later to create an efficient Global Secondary Index that could be used to quickly pick out either products or metrics.
In Part 2 we used DynamoDB Streams to update inventory stock levels (In the DynamoDB table Product entry), and create vendor orders (yet another type of object stored in the DynamoDB single table) as well as sending data to AWS Kinesis Firehose, and aggregating sales in realtime by product and time in 1 minute increments, and then store the results in S3.
In Part 3, we added an operational dashboard that used cognito Identity Pool Unauthorized flow to provide very specific access to AWS APIs without the need to define IAM credentials, so that we could display stock levels.
Finally in Part 4, we used an AWS Glue job to create an parque schema across the S3 bucket that our firehose analytics were being delivered to, and then used Athena to query the analytics from this database.
A nice final step might have been to display it all using AWS Quicksight.
ANZ Welcome Reception
The ANZ welcome reception was a chance to network and chat with other AWS partners and customers from Australia and New Zealand. There were a few ex-Readify/Ex-Kloud people there, and even an ex-Telstra Purple person, not to mention a significant number of our competitors as well.