Day 1 Session Summaries
While at AWS Re:Invent 2018, I am concentrating mainly on serverless, and I’ll be keeping a daily update of the sessions I attend, and highlighting the key takeaways.
First session was an ANZ (Australia & New Zealand, not the bank) partner private session with Mark Ryland (security expert). It was a “fire-side” chat (still feel cheated that there was no real fire place), at an obscure hard to find meeting room at the Linq Hotel. The discussion focussed mainly on infrastructure and data sovereignty. Interesting take aways for me were around governments and organizations needing to be willing to re-evalute the reason they even want data sovereignty. Mark stated the basic truism that it would be far better to have a well secured application running and storing data in another country, than to have a poorly secured app running and storing data in on-premise or sub-optimally managed data centers, as no attacks these days occur at the physical level, but rather at the network level. He also talked about countries beginning to form aliances for regions where entire aws data centers don’t make fiscal sense (to AWS), gauranteeing in principle”sovereignty” of data for those countries (feeling a bit sorry for our NZ friends).
I have been really excited to learn more about Aurora serverless, so was really looking forward to this session. It was a very good, warts and all discussion about the state of Aurora serverless.
A few key takeaways from this session. As with all serverless, the automated scaling point is the key. When moving from IAAS or PAAS to serverless, you are essentially trading off the cost benefit (both engineering cost as well as server costs) for the loss of fine grained control over scaling. Aurora Serverless uses a multi-tenant proxy pattern with warm buffer pool to make the scaling as seamless as possible. The scaling occurs when either CPU usage is greater than 70% or maximum active connections is greater than 90% for more than 5 minutes. It will also look for a “safe scale point”, where no connections need to be dropped. This last point has impacts on how you design your application. It means that long running transactions are the enemy of scaling. Yet again (IMHO) another reason serverless encourages you into good architectural patterns. On the flip side, it also can be a blocker to existing apps migrating to serverless. There will obviously be a slight drop in throughput (higher latency) while the vertical scale event occurs, but that’s to be expected.
Aurura Serverless will also scale down completely (i.e. servers will stop completely), if no connections are made for 5 minutes. This is a great cost saving, especially for Dev/Test workloads, but in production workloads, this could cause significant cold start latency which (according to the second speaker who was an end user) was inconsistent and in extreme cases unacceptible.
Another exciting thing is the new integration points into AWS Lambda and App Sync, including an HTTP based RDS Data API.
Other coolness: RDS Console Query Editor, Aurora serverless recently GA’d in Sydney (amongst other regions), and PostgreSQL compatibility (coming soon).
Serverless Architecture Patterns and Practices
This session was an in depth look at patterns and practices that have been emerging in the serverless space. It focused on 4 types of applications; Web Applications, Stream Processing, Datalake, and Machine Learning.
I was most familiar with Web Application patterns, new to me were concepts such as Lambda@edge (Lambda running at the cloud front endpoint), Regional Endpoints (Lambda balanced across a region), and Private Endpoints (Lambdas executing inside VPCs). These features are set to enable some really interesting scenarios, and hopefully lower the barriers to adoption.
I was less familiar with the stream processing style of serverless application, and it has peaked my curiosity in services like Amazon Kinesis in particular Firehose, and the tooling available to get realt-ime insights into the data stream. It also segued nicely into the Datalake style applications where this provides a great way to ingest the data.
Although not my area of expertise, the serverless datalake patterns were fascinating. The starting point for a serverless datalake application is the humble S3 bucket. It’s amazing to see the different technologies developing around S3, such as Athena, and how they can be cobbled together with services like AWS Glue.
The Machine Learning focused on services like Polly, Transcribe, Transalte, Comprehend, and of course Lex, demonstrating how these could be used to improve experiences like call centers enabling simple tasks to be completely automated, freeing up humans to concentrate on higher value customer experiences.
Architecting Next Generation SaaS Solutions on AWS
This talk started by stating what seems like (for me at least) the obvious. Serverless is a great fit for SaaS style applications. Reasons given were; smaller deployment units, natural isolation, optimized consumption, service decomposition, simpler operations footprint, focus on IP. The speaker then dived deep in to some of the challenges of operating a SaaS offering in a serverless manner.
Onboarding of tenants: Should be completely automated regardless of the size or number of tenants you are expecting. Identity: Should be resolved at the API Gateway before your business functions are called API Keys, Usage Plan, throttling: can be handled at API Gateway Isolation: 2 options
Separately deployed functions use IAM roles to ensure separation
- Fine provided you don’t have too many tenants. Some resources may hit capacity (e.g. IAM roles)
Isolation with tokens - Single set of functions, every function must be scoped with tokens. Assume role for tenant scope (wrapper based isolation)
- This needs to be implemented in a stack dependant way
- Also opens up possibility of state residue if local state isn’t cleaned up properly. This was left as an unanswered question, but with a warning to think about it when designing your isolation strategy.
Monday Night Live - Keynote
Lots of cool stuff announced, new Amazon CPU based on ARM Architecture, new EC2 instance sizes for different workloads, new offerings around networking, all sounding very interesting. From the serverless perspective, the main announcement was that AWS’s Micro VM software that powers AWS Lambda and AWS Fargate has been open sourced.