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 an application framework. At Galvanize, AWS is our framework, and the more we leverage it by using its Serverless offerings, rather than fight it by managing our own "Serverfull" solutions, the more we can focus on our customers' problems.

We're here to have meaningful impact and solve customer problems. We're not here to manage servers.

Serverless computing

AWS changed how we think about computing when it first introduced AWS Lambda as its "event-based computing" solution. They basically asked “Why don’t we just compute on event?” After all, HTTP requests areevents, so why do we have long-running processes and servers that sit idle waiting for events. Why not instead spin up processes on event to process them, and thus easily scale them too. 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 care that the applications we provide them solves 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, 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

At Galvanize, AWS is no longer just our infrastructure provider; it's not even our platform provider. Rather, AWS is our framework, and it lets us focus far more on our customers, than on already solved server management or scaling problems.

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

Increasingly in Galvanize, what triggers our company’s business logic, is AWS itself.

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

AWS isn't acting like an infrastructure provider in these scenarios, rather it's acting like a framework!. And like any framework, if we can leverage the framework to its fullest, rather than fight it or add competing frameworks to the architecture, we are able to piggyback on a ton of benefits from the framework itself:

  • No patching servers - AWS patches all underlying servers of its Serverless components
  • No scaling required - AWS auto-scales its Serverless components too
  • 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 Containerized task or Lambda easily
  • Easy scalable queues - SQS & SQS FIFO allow you to create queues for your event-based applications
  • No separate secrets management tool required - AWS Lambda can read secrets from AWS SSM and AWS Secrets Manager
  • No complex network permissions required - IAM allows a far more granular security perimeter for your functions
  • 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 traditional servers or frameworks with AWS, when you can just code directly for AWS? Why spend time doing undifferentiated heavy lifting that AWS already does for you? Instead, use AWS as a framework and focus on the customer problem. 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're a Serverless company and integrate deeply with AWS.

Serverless & You

With AWS and Serverless being our foundation, we’ve then layered on other techniques and technologies thoughtfully. 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. TypeScript, 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.

For our engineers, all of this means working in a place that emphasizes solving customer problems and being exposed to the entire technology stack when solving those problems. We want individuals to be exposed to the front-end, back-end, and even infrastructure. We believe this allows individuals to grow rapidly in their understanding of software development and thus their career. Similarly, we want teams to have a large toolbox to architect and design solutions with. By using AWS as a framework, we can both solve our customer problems, and rapidly develop our engineering talent! ♥️

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. You can also read our more in-depth blog post on using AWS as a Framework, and find all available roles on our careers page.