Status quo of an AWS engineer: Writing a Java-based service

Alan has been working at AWS for the last six years. He's accustomed to a fairly standard workflow for launching Java-based services:

• Write a description of the service APIs using a modeling language like Smithy.
• Submit the description to a webpage, which gives a standard service implementation based on netty. Each of the API calls in the modeling language has a function with a /* TODO */ comment to fill in.
• As Alan works with his team to fill in each of those items, he makes use of a number of standard conventions:
  • Mocking with projects like mockito to allow for unit testing of specific components.
• Alan uses a variety of nice tools:
  • Advanced IDEs like IntelliJ, which offer him suggestions as he works.
  • Full-featured, if standard, debuggers; he can run arbitrary code, mutate state, step into and out of functions with ease.
  • Tools for introspecting the VM state to get heap usage information and other profiling data.
  • Performance monitoring frameworks
• As Alan is preparing to launch his service, he has to conduct an Operational Readiness Review (ORR):
  • This consists of a series of detailed questions covering all kinds of nasty scenarios that have arisen in deployments past. For each one, he has to explain how his service will handle it.
  • For most of them, the standard framework has pre-generated code that covers it, or he is able to use standard patterns.