The leading global conference devoted to the serverless trend, Serverlessconf is a community conference that aims to share experiences about developing applications for so-called serverless architectures. Serverlessconf will take place in Paris on 14 and 15 February. Today we choose to present you one of the inspiring speakers that will join ServerlessConf, Dana Engebretson. In this interview, we talk about how to get started with serverless and the question of the learning curve.

Dana Engebretson is a Performance Engineer at SPS Commerce, where she uses her background in Data Science to analyze software performance of distributed systems. She is also the founder of PyLadies Twin Cities. In her free time, you may find her writing bad computational poetry.

How did you start working with Serverless ?

I discovered Serverless through my colleagues and started working with Serverless AWS Services about a year ago. I sort of stumbled into it, really. At my last job, I was focused on building machine learning models for large scale classification. I got hired at my current company to analyze data, but the data they wanted me to analyze needed to be collected from one of our vendors in order for me to analyze it. My team didn’t have the budget to hire a Data Engineer, so I took a shot at it. I wrote my first solution in Python and used multiprocessing. I put it in a docker container and ran it on an EC2 instance. That solution was too expensive. So I tried Spot Instances, which turns out, aren’t really suited for long running processes. I wasn’t excited about refactoring my code to avoid losing work every time my bid was too low. So I turned to Serverless because I was looking for a cheap solution and something that was easier to maintain over time. That’s actually what my talk is about. I’ll share a couple of unsuccessful serverless architecture patterns I tried and finally, a solution that worked.

How does Serverless make development easier ?

Well, I think it makes Operations easier. It’s easier to focus on the core functionality of your application instead of being responsible to also manage the underlying infrastructure.

That being said, I think the argument that going Serverless means faster time to market is missing an important disclaimer. The hype around that made me feel insecure when I was building my first Serverless app. I felt embarrassingly slow because I took so long fumbling through failed architectures. Learning Serverless is an investment. I’d anticipate some upfront costs in learning it before you expect to start experiencing the benefits.

What challenges did you have to tackle with Serverless ?

The first problem I had was spending too much time on trivial decisions. I deliberated about writing my cloudformation in json or yaml and in retrospect, either would have been perfectly fine.

A number of times, I found my code working locally but not in the Lamba I deployed. So I learned to use Docker containers for both building dependencies and testing, which made Lambda development a much smoother process for me.

Architecturally, I ran into many unexpected challenges, which I’ll go into more detail about in my talk.

Is it a game changer for developers ?

That feels like it might be a bold statement. I mean, what does it mean to be a game changer? I like the idea that being a developer is like playing a game. I guess I see Serverless as a game changer in the sense that it changes the rules that developers have to play by and the financial incentives that help you win.

Container orchestration requires deciding which containers to put in which VMs. There are different algorithms for this decision process, which optimize for different things. Another decision that needs to be made is how many VMs you want to run idly to account for spikes in traffic.

Cloud providers are now offering to take on the financial responsibility of solving those problems for you and they will only charge you for your usage. The caveat is, you will pay a higher rate for your usage and you have to follow more restrictive rules. If you have consistent, predictable compute and memory needs, Serverless is less useful to you. You will see the cost savings for processes that only run occasionally or processes that experience bursts of usage.

This offering makes sense to me when I think about predicting usage statistically. It’s harder for a company to predict when their apps will have a spike in traffic than it is for a cloud provider to predict how much cpu and memory will be needed per hour, by a large number of companies. Equivalently, it would be difficult for you to predict when you will get sick while an insurance company can quite accurately predict how much healthcare will cost for a large group of people over a given year. So cloud providers can drive higher utilization rates of their resources which lets them serve more people. With serverless, they can make a larger profit while giving all participating companies significant discounts. It’s a win-win.

What is the downside of serverless ?

A valid concern right now is getting locked in to a service provider. If you’re running your app from a docker container, it’s easy to move that container to any VM. All of my AWS lambdas call other AWS services. I would have to completely rewrite my code to switch to another service provider.

I’ve hit a few boundaries with AWS offerings but it’s an evolving field. Some things that are difficult now might not be forever. For example, some of the python packages used for data science are quite large and they exceed the maximum size allowed for a lambda’s dependency zip file.

Again, I think the learning curve and human component shouldn’t be minimized. It’s still in the developers’ hands to implement things well and to anticipate all the costs associated with their decisions. You have to optimize against new rules and incentives you don’t fully understand. At my company, we often are noticing unanticipated costs or inefficiencies and iterating towards better solutions. We’ve all seen really impressive things that are built from Legos, but that doesn’t mean you’ll build the spaceship you intend the first time you sit down with a box of Legos.