Serverless Engineering

Public Cloud providers are no longer providing just infrastructure. At this point, they’re providing entire capabilities you would have typically found in a framework. AWS in particular has pushed this idea to the limit. They’ve basically asked “Why don’t we just compute on event?” After all, HTTP requests are events, so why do we have long-running processes and servers that sit idle when we can instead spin up environments, on event, and automatically scale too. In fact, in the initial release of AWS Lambda, Werner Vogels described it as “Event-driven computing”.

This paved the way for an entire paradigm shift that today falls under the umbrella of Serverless development. Serverless Engineering fundamentally questions our need for server management. After all, our customers don’t care how our applications are hosted, they just care that the applications we build solve their problem. So why do we want to setup servers, or create Docker images, when we can just write business logic and let AWS run it for us. And as a bonus, run it only when there is an event, so we don’t pay for idle time. THAT is much more aligned with what businesses need in order to serve their customers. Initially though, Serverless capabilities, particularly AWS Lambda, was extremely limited so it was hard to believe in this vision. Today though, AWS Lambda is integrated into every aspect of AWS’s services, and numerous Serverless capabilities exist to incorporate into our applications.

Lambda Integration Points

In fact, at this point, we use AWS as infrastructure, as a platform, and as a framework!

What’s the definition of a framework?

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework’s code then calls your code at these points. (Martin Fowler)

That’s exactly how we develop with Serverless capabilities, particularly AWS.

  • On message (SQS), AWS calls our business logic
  • On event subscription (SNS or Event Bridge), AWS calls our business logic
  • On HTTP request (API Gateway), AWS calls our business logic

And naturally by using AWS as a framework, we are able to piggyback on a ton of benefits from the framework itself:

  • No server patching required - AWS patches all underlying servers itself
  • No scaling required - AWS
  • Auto-scales Serverless components itself
  • Out-of-box monitoring - AWS Lambda invocations, durations, errors, are monitored by default
  • No logging setup required - Standard output automatically is piped into AWS’s logging capability
  • Minimal tracing required - AWS Lambda environments are already configured for tracing
  • No web server required - Cloudfront serves static assets hyper-effectively as is
  • Distributed “cron” out-of-box - use Cloudwatch Events to trigger a Serverless task or Lambda easily
  • Easy scalable queues - SQS & SQS FIFO allow you to create queues for your event-based applications easily
  • No separate secrets management tool required - AWS Lambda can read secrets from AWS SSM and AWS Secrets Manager easily
  • No complex network permissions required - IAM allows a far more granular security perimeter for your functions to start (although if you run it in a VPC, for safety, you’ll want to still ensure secure network architecture)
  • No restriction on data storage - AWS gives you a plethora of storage solutions, multiple of which have utility-based pricing, so you use what you need for storage.
  • And so forth... and so forth.

Despite the long list above, it’s only a subset of what AWS gives you to develop applications with! We didn’t even touch on the plethora of Serverless machine learning capabilities AWS gives you. So with so many capabilities that AWS gives, why spend time figuring out how to integrate your traditional server’s or framework’s capabilities with AWS, when you can just code directly for AWS? Why spend time doing heavy lifting that AWS addresses for free? Instead, use AWS natively, write Lambdas (in the language that makes sense to you) and focus on your business. Your customers don’t know about your technology underneath; they care about the problems you solve. And at Galvanize, because we care about our purpose and impact so deeply, we 100% agree and integrate deeply with AWS.

We believe the future is event-driven computation. We believe the future means empowering engineers to use the entire stack. And we believe the most interesting and practical way to use AWS is to use it as a framework.

That’s correct. Not as an infrastructure provider; not as a platform provider; but as a framework! And in doing so, we can be in every AWS data center, in a highly secure way, so we can serve our customers where they want their data to be and served from.

That is why Galvanize does Serverless Engineering.

With that foundational understanding, we’ve then layered on other technologies thoughtfully. We are a TypeScript centric company since it provides the right balance productivity and typing in Lambda. We are an API-first company, since we can then build true SPA React applications on these APIs as well as enable our customers to directly interact with their data. We design our contracts first before development, so that teams can then independently and quickly develop their microservices based on these contracts.

Of course we have other technologies in Galvanize too (e.g. Go, Terraform, Python, Rails), but it is all built with a Serverless Engineering mindset that tightly integrates with AWS so we can solve real-world customer problems.

If that sounds exciting to you, and you agree with our philosophy, then reach out and let’s talk and what we can build together.