Home > AWS, re:Invent > AWS re:Invent 2018: Inside AWS: Technology Choices for Modern Applications – SRV305

AWS re:Invent 2018: Inside AWS: Technology Choices for Modern Applications – SRV305

November 29th, 2018

20181129_013016739_iOSTim Bray from AWS

Tim Bray from AWS, very distinguished software engineer, developed XML and JSON!

AWS is happy to sell you some of everything. The AWS console is a vast list of choices, but how do you chose when there are multiple technologies to link together to achieve an outcome, never mind multiple options of the dame thing? Multiple databases, multiple streaming options, multiple instance types. Serverless or containers? Is Java over?

AWS has always maintained it doesn’t have an opinion on which services to chose. When it comes to building AWSs own services, their engineering groups DO have some strong opinions. Tim’s presentation was all about navigating the high-level choices available.

What is a modern application? This was a question which came out of the analyst relations group who wanted guidance on what services to use.

You have 4 ways to modernise apps

  1. Lift and Shift:  -> EC2
  2. Re-platform: VMs –> containers
  3. Refactor: monoliths –> microservices
  4. Re-invent: host-fleets -> serverless

Modern applications

  1. Security/compliance first
  2. use microservices
  3. serverless where possible
  4. CI/CD
  5. monitor, monitor, monitor
  6. Databases
  7. Integration interfaces

Tim wasn’t going to touch all points but highlighted a few.


Tim used an example of SQS which is an early service from 2006 and has been thoroughly modernised, decoupled, its database moved from Oracle to DynamoDB, split apart into microservices


Why serverless?

  • Frugality
  • Security
  • Elasticity
  • Better Design?
  • Only write business logic

Serverless example he used for Amazon MQ.

Did use serverless for the control plane stuff

Didn’t use serverless for the data plane because it uses stateful TCP connections to ActiveMQ but this means its super fast

A few examples of AWS services with a serverless control plane


Why not serverless?

latency: you need to understand latency requirement and for what percentage of you workloads. Can you tolerate any latency or for what percentage of your apps?

sources of latency: runtime start-up and state hydration; cold start vs warm start; serverless platform startup vs. language runtime startup. P50 vs P90 vs P99 vs P100

Keeping functions warm, he says its kind of dumb, customers shouldn’t have to do that but for now its something you can use.

Programming languages have an impact. Java is slow but often the issue is us, with crazy dependency injection. Node (although NPM dependency is hell), Python and Go have better start characteristics even when cold. Python good for data science. Go the clear fast winner as an excellent runtime. Readability is also important and Go is good for that. Go for Go for serverless.

Worth reading about runbook.cloud and their use of GO for multi-threaded Lambdas

State hydration: can split things up, like videos and then individually process the pieces for parallel processing which helps avoiding state hydration.

State can also be put in a lot of different places so don’t only use databases.



Modern databases can still be RDS for relational or non-relational like DynamoDB or NoSQL.

Relational or not? Inside Amazon, they prefer not to use RDMS. It gives complexity to developers, availability is hard and based on failure which can take time. DBAs are required which shouldn’t be required.

AWS use DynamoDB for lots and also Amazon Quantum Ledger Database (QLDB) which was announced this morning but has been used heavily in AWS for a number of years. It’s like SQL and is an immutable ledger but not blockchain as there isn’t consensus.

20181129_020859529_iOS 20181129_020934111_iOS


They do use containers but pretty much exactly the same way as customers do, nothing special. Don’t use Kubernetes much but generally ECS and moving to Fargate.


Containers and Serverless.

Orthogonal in theory but now things have changed with the release of Firecracker which is super tiny VM which starts in 200ms.

Trend will be VM/Container/Function no difference in latency performance and you’ll chose whatever for functionality



A very well presented session, Tim has engaging and really had good information on what choices to make for modern applications. Certainly worth watching the recording, there’s no way I could take in and write everything!

Comments are closed.