Herding Code 236: Will Green on Going Serverless With AWS

Download / Listen: Herding Code 236: Will Green on Going Serverless With AWS

Kevin and Jon talk with Will Green (@hotgazpacho) about how his small team uses serverless development on the AWS platform to maximize their productivity.


  • (00:20) Will’s team builds the FireEye Market, which enables you to “discover apps, extensions, and add-ons that integrate with and extend your FireEye experience.”
  • (02:51) FireEye is a relatively large company, but Will’s team is just four people, and they’re using serverless development to scale and get a lot done quickly. The FireEye Market is a greenfield development project. It’s primarily a single page application that uses GraphQL. When new apps are published, an external provider pings webhooks that kick off background process that cache binaries, notify consumers, etc.
  • (07:05) Kevin asks about what pushed their team towards serverless technology. Will talks about how serverless lets them maximize the time they devote to delivering business value.
  • (08:30) Will talks about how they were able to successfully pitch the project internally. While there were some additional costs as they scaled up, they’ve also been able to take advantage of new AWS services that allow them to scale on demand, which has led to savings.
  • (11:10) Jon asks for more clarification of what Apollo GraphQL‘s role in their architecture.
  • (12:38) Kevin asks about the learning curve. Will says a lot of it was pretty natural since the team already had a Node background, but learning things like cold start took some work.
  • (14:25) They used the serverless framework, which helped take care of setting up tedious infrastructure. If they were starting today, they’d seriously look at AWS Amplify, which is a lot more feature rich and includes support for CI/CD.
  • (15:50) Jon asks how they handle failures, including both code errors and service outages.
  • (19:49) Kevin asks about concerns with vendor lock-in. Will explains why he prefers to just pick a cloud vendor and learn it.
  • (20:49) Kevin asks how they manage the complexity of many small services interacting; Will talks about the use of AWS Step Functions to manage state and workflow, and keeping updated diagrams really helps.
  • (22:40) Kevin asks about the local vs. cloud development experience. Will talks about some local development emulators from the community, but it’s not quite the same as actually hitting the real service.
  • (24:00) Kevin asks about the testing strategy.
  • (25:15) Jon asks how things work with version control. Will explains how AWS CodeBuild handles git push build and deploy for them.
  • (26:00) Jon asks how Will keeps up with all the different AWS services, especially since many aren’t intuitively named. Will defines all the different services they’re using.
  • (28:48) Will describes his bias against containers: you still have to worry about the underlying operating system, whereas with serverless that’s all abstracted away.
  • (30:00) Will explains how they designed the system, starting with diagrams on draw.io, continuing to work through requirements, and evolving the system.
  • (31:52) Will explains what’s different about working with DyanmoDB. There’s a lot, especially access patterns.
  • (36:03) Jon asks how they handle versioning multiple services and data changes; Will talks about using Step Functions and handling data failures.
  • (38:25) Jon asks for advice for people who are getting started with serverless on AWS, and Will highly recommends AWS Amplify. There are lots of samples for serverless framework.
  • (40:39) Kevin asks if it’s possible to migrate an existing application to a serverless architecture. Will says it’s challenging, but you can use CloudFront as a router to start distributing work to serverless services based on URL path segmentation.
  • (41:50) Kevin asks about the experience of moving from Ruby development to JavaScript development.
  • (42:40) Will’s team is hiring right now, here’s the job listing: Senior Developer (US Remote – Prefer Eastern Time Zone).