My key takeaways from ServerlessDays Stockholm

After a day of 10 talks from experts on serverless technologies drawing from real-world experience, here’s what I picked up.

Ok, so just to show this blog isn’t dead despite having an unfinished draft of a sequel to my (already ancient) Go & SAM post hanging around for a year I thought I’d share central themes from the ServerlessDays Stockholm conference I just attended. The event was rather small which created a cozy experience but the speakers and organization were excellent. Thanks to the organizers, speakers and sponsors — I’d be happy to attend again!

I won’t be summarizing all of the talks, but you can check out the event website for the agenda. Hopefully some slides or recordings will be available there soon as well. As a developer-oriented event the agenda was full of exciting technical tidbits but I’ll try to document some higher level themes here.

Serverless is a mindset

One reoccurring theme in the talks was that “serverless” is not only a technical concept revolving around Functions as a Service and managed highly scalable databases. Instead, serverless was seen as a drastic change to the way applications are designed and going “serverless first” has implications not only on the programming model but all layers of the application, related tooling and how decision making power is distributed and risks are mitigated in the organizations developing the software.

That sounded an awful lot like marketingspeak so should we append serverless to the long list of buzzwords that supposedly change everything but everyone has their own definitions of (think Agile, DevOps…)? Let’s try to flesh out the serverless mindset a little based on the talks. As Richard Boyd mentioned in his introductory talk, the lack of heavy up-front investment and focus on building applications from small building blocks enables the “tactical level” of the organization (that’s us doing the hands-on work) to experiment with technology without a huge buy-in or investment from the higher-ups in advance. Meanwhile the usage of fully managed services gives the tactical guys ability to focus on the mission at hand (business) instead of undifferentiated ops work.

Most real-world applications need some kind of persistence and in her talk “What to do with your data in a serverless world” Angela Timofte from Trustpilot shared some of their adventures regarding serverless database offerings when implementing their “Serverless First” strategy where they started to move from self-managed MongoDB clusters to DynamoDB and Aurora Serverless. Importance of monitoring consumed capacity, sensible scaling and deep knowledge on peculiarities of the chosen product were highlighted. The architectural approach chosen by Trustpilot was pragmatic: their general guideline was to consider serverless first, and rely on container-based solutions if applicable serverless solution was not available or was impractical. Plain VM instances they consider legacy that they’re fading out.

Efi Merdler-Kraviz demonstrated their development process and toolchain at Lumigo whose product is a monitoring tool. Since their product is serverless they ensure reliable end-to-end testing of feature branches by using developer-specific AWS accounts with full instances of their systems, something that might be prohibitively expensive if large monolithic dependencies or pre-provisioned services like traditional databases were involved. However, the serverless mindset shines in their choice of tooling: they run none of their development-related tooling themselves but rely on GitHub for Git repositories, CircleCI for CI/CD and a SaaS product called Lumigo for monitoring.

What appears to be the core tenet of serverless is to strive for either outsourcing or eliminating anything that doesn’t generate direct business value — like the Business 101 “focus on core competencies” rule applied to a software stack.

Power of asynchronous event-driven architectures

While hooking up some functions to an HTTP endpoint is a great pattern for implementing microservices, at the conference we saw a few interesting examples of the event-driven programming model of FaaS applied to rather complex business processes.

In Angela Timofte’s database talk there was an example on how at Trustpilot they improved an existing user data management service based on periodic table scans by refactoring it to an event-driven model. A nice example on how playing to the platform’s strengths can be both cost-efficient and improve service quality.

Katarina Svedman showed how to address some resilience concerns related to CQRS pattern implementations using event sourcing from Azure Cosmos DB change feeds and Durable Entities (a thing I didn’t know even existed before the session). The live demo of replaying the events after application changes was quite impressive!

Amazon EventBridge is a relatively new event bus service from AWS. James Beswick’s talk described its features and how its pub/sub model can be used to keep components of an application loosely coupled and prevent them from turning into a monolithic serverless spaghetti. EventBridge integrates well with AWS services and custom code but has also built-in support for various existing SaaS applications. It will be very interesting to get some hands-on experience with it.

While event-driven architectures are not a new idea, serverless approach provides an economical way for implementing them.

Methods for dealing with legacy applications

Serverless first strategies are a great option when building greenfield applications. Yet, most applications don’t live in a vacuum and most organizations own services implemented in a traditional manner. Rewrites of existing applications to a new architectural pattern pose a huge risk and especially in case of applications in maintenance mode provide little value.

Image for post
Image for post

Containers are a great way to deploy traditional applications to the cloud without changing the programming model. AWS Fargate already provides an excellent way to run them without worrying about the underlying infrastructure. At ServerlessDays Bret McGowen demonstrated Cloud Run, GCP’s approach to serverless containers. It brings a few very interesting features to the table for running stateless services: request-scoped pricing and scaling, and configurable concurrency (concurrent requests served by the same container instance). Judging on the live demo, a lift-and-shift of an existing HTTP API to Cloud Run can be done with very little effort.

What if you want to refactor or enhance an existing application using serverless? The Strangler Pattern mentioned by Simon Aronsson provides a safe track of incremental applization modernization. Things like AWS Lambda ALB triggers are a great way to achieve this — building “stairs” for existing workloads towards serverless.

The serverless community is awesome!

It was really exciting to see experienced developers and the representatives from all the major cloud platforms sharing their take on serverless. All the talks provided valuable lessons — even if I didn’t mention them specifically in this post. The event itself was organized extremely well, the vegetarian lunch was tasty and the people were so nice and friendly that even a not-too-outgoing Finnish guy like me traveling alone felt comfortable and welcome.

From the workshop programme I chose to attend the Cloud Development Kit workshop organized by AWS. The instruction provided by Richard Boyd was first class but walking through the workshop individually by using the materials linked above is definitely possible. While I’m still more inclined to define my infrastructure in a declarative manner by using Terraform, CloudFormation or SAM, the opinionated and object-oriented programming model with strong typing provided by CDK seems to take friction away from many things that are less convenient in other methods like applying the least privilege principle to IAM and configuring the Amazon API Gateway. I’m looking forward to experiment more with CDK — but that’s probably a topic for another post, hopefully not taking a year or two to bake.

Written by

Your friendly neighborhood code monkey

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store