We recently joined in an interesting two-hour long conversation about Serverless JavaScript led by Steve Faulkner of Bustle who answered questions on Bustle, the Shep framework, the mindset behind the AWS Lambda infrastructure, and related topics.  

The discussion took place on the Sideway conversation-sharing platform on January 6th. Here we present the best takeaways from the session which really should be taken notice of by anyone working on AWS.

Steve Faulkner:
At Bustle we serve over 50 million unique readers per month through a "serverless" architecture based on AWS Lambda and Node.js.  Of course there are still servers but we don't manage them. This shift has allowed us to develop products faster and decreased the cost of our infrastructure. I'll answer any questions about how we made this transition and how it has worked out. I'll also discuss some of the tools and best practises including our open source framework shep

Eran Hammer:
When would you NOT use serverless architecture?

Steve Faulkner:
AWS Lambda functions specifically are stateless and have a 5 minute max execution time. This is no problem for our use case, but obviously there are many that would be disqualified immediately based on those two constraints. Serverless can also be expensive if you have very uniform predictable load. In Bustle's case this is where serverless shines. We are able to scale with our spikey traffic quite easily.
I could also see some performance critical situations where serverless wouldn't be ideal. We have done a lot of work to achieve good response times with API gateway and Lambda, but if you are trying to tune for ultra low response times it might now be ideal. I'll say we are quite happy and regularly achieve < 200ms response times for our server side rendered JavaScript applications

Peter Piekarczyk:
Besides the 5 minute execution time, were there any other road bumps you faced? Was there anything that could have been a potential deal breaker from utilizing Serverless?

Steve Faulkner:
Oh plenty. When we started experimenting with serverless (about 1.5 years ago) it was very difficult to setup and deploy these apps. It is a big reason we wrote shep. Getting all the environments setup properly and having a fast repeatable deploy process was a huge pain. I'm not sure we had any deal breakers, but there were definitely moments of "ugh why are we doing this?"

But things have gotten much better. API gateway is a much better product. They added many features and it is much easier to use now. Same with Lambda. I think you still need some kind of framework or deployment tool though. Manually doing everything with a few functions or APIs is not super fun.

The payoff has been great. We are definitely happy we made this move and if I was starting from scratch today on an app I would probably default to the same setup.

I will say there are still some issues. Logging and exceptions are still hard. Basically everything goes to cloudwatch. Which is a bit like a needle in a haystack. There are some third party services that are trying to fill the gap. Check out IOPipe. 

Adilson Schmitt Jr:
It seams that this architecture is very dependent on AWS, is possible to simulate it locally for development?

Steve Faulkner:
That is where our tool shep comes in. It is able to run the functions locally. There are several other frameworks that will do the same thing. Running a whole set of interacting functions is still hard to do and one of the current pain points with serverless.

The flip side is that provisioning new environments is not too difficult and you only pay for usage, so testing and developing in the cloud is not a bad option. Using tools like cloudformation or terraform it is easy to spin up these new environments for each developer.

I will note that there is a difference between "serverless" and AWS Lambda. Right now they are very often used together, but that will be short lived. I think "Serverless" is the concept that you can rely entirely on services to build your application. Lambda was really the missing piece of that picture. Where does your business logic live in a world with only third party services? There is nothing about "serverless" that requires you to use AWS, but I think they just happen to be pretty far ahead out of every other provider in execution. Google and Azure are catching up quickly, which is great. Competition in this space is great for users.

Nikos Vaggalis:
What is the difference with Azure functions, and why AWS over Azure?

Steve Faulkner:
I have only briefly played with Azure functions. This was a few months ago and you had to manually choose a scale for them to operate at. Maybe they called it a consumption plan? It reminded me a lot of heroku and dynos. Serverless isn't only about simple scaling, but it is a pretty important part. That said, they worked ok. If I was on azure I would consider using them.

The bigger reason for Bustle is we were already heavy AWS users. It made much more sense to stick with Lambda as it integrated nicely with all the other AWS products we are using.

So much attention gets focused on the function part, but I think the more interesting one is actually the router API gateway. I don't believe Azure offers this product yet. Google just recently got it. I have not tried it. Lambda itself had existing for quite some time before we started using it.

Really API gateway is the key that unlocked an end to end serverless setup for our application. It allows you to route end user calls to functions. It is super critical to running a user facing serverless app and I think Google and Microsoft are both pretty far behind with that product.

Nikos Vaggalis:
what is the difference between Lambda Function Integration and HTTP Endpoint Integration? which one do you use and why?

Steve Faulkner:
HTTP endpoint integration lets you call through to any endpoint. You could do something like wrap twitter's API with API Gateway if you wanted. Or wrap your own legacy APIs. We have done this in several cases. Lambda function integration can take a few forms, but we heavily prefer where lambda functions return objects of the form { statusCode: XXX, headers: {}, body: 'stuff' }. API Gateway can do much more complex things and you can write templates to transform data as it comes in or goes out. We really try not to do this anymore as they are hard to maintain and written in a template language (VTL) we are not huge fans of.

Nikos Vaggalis:
do you think that the process of starting out with Lambda and API gateway on AWS is cumbersome? I mean too much too setup, logs,permissions,etc but most of all figure out the relation between the components and how one affects the other?

Steve Faulkner:
I think it is getting better. shep makes it super easy. I think you can get from nothing to a deployed public API with shep in just a few commands. But at scale it is still hard. We have hundreds of functions and keeping track of everything is still difficult. We're thinking of adding features to shep that help document and visualize some of the relationships you are talking about.

But generally I think getting anything truly "production ready" is hard. Even architectures with really well established tooling and practises are hard. AWS and Serverless is the same, it is new and different and will feel unfamiliar to many people.

Nikos Vaggalis:
isn't IAM authentication enough? why also go for tokens?

Steve Faulkner:
Having all of our users in IAM would be amazing. Unfortunately due to various legacy stuff we have to support it would be a very hard thing to do. We've looked at is a few times and just can't see a great path. Now that cognito user pools are more mature we should look again and see if it is possible.

Nikos Vaggalis:
regarding Lambdas, is there a notion of state, i.e in subsequent calls or when one function calls another?

Steve Faulkner:
Lambdas can call other lambdas and pass data. But functions themselves are stateless. Once the function is done executing anything done in that execution frame is gone. It is possible to hang onto some things, like database connections, between calls, but don't rely on it. We use clients or code that always check for existing connections before talking to external services.

Nikos Vaggalis:
would you say that in essence Lambdas are a substitute for a RESTful API that lives on a VPS and calls your functions written in your backend framework of choice?

Steve Faulkner:
That is definitely one way to use them, and the primary one for us. But Lambda can be triggered by SNS, Kinesis, DynamoDB, S3, and other things on AWS. We use them to do indexing in elasticsearch, data migrations, analysis. Not just for responding to end user HTTP calls.

Tyrone Tudehope:
You mentioned earlier that keeping track of all these functions is still quite difficult. How do you manage them currently?

Steve Faulkner:
We use shep and have multiple projects/repos. That setup is decently manageable for us. We kind of group them by "microservices" although I'm not sure that is best word to use. We also have been moving many of our APIs to a single graphQL endpoint which helps decrease the number of functions. Our front end applications are all served via one shep project

Nikos Vaggalis:
for debugging you rely only on the logs or are there other ways too?

Steve Faulkner:
console.log and cloudwatch most of the time. I wish I had a better answer.We're actively experimenting sending our logs to various third party services so we can get a better handle on this. Kibana and ElasticSearch are also easy to setup inside AWS if that is your preference.

Amazon X-Ray is very exciting for helping solve this problem. Not available for Lambda yet, but hoping soon.

Tyrone Tudehope:
When deploying changes, is there any downtime involved? What kind of strategy do you use for deployments?

Steve Faulkner:
As best we can tell there is no downtime and the change to new code happens nearly instantly. Obviously it can't be actually instant, but we haven't noticed any issues as a result of deploys. We deploy many times a day, sometimes from CI and sometimes manually. One of the reasons for shep was that we wanted to make deployments as simple as shep deploy production. It is very important to me that anyone on the team can deploy any of our applications quickly.

Nikos Vaggalis:
In shep's readme on GitHub you mention "excessive amount of manual work such as zipping files".is that an alternative way of creating your Lambdas?

Steve Faulkner:
Simple lambdas can be written directly in the AWS web UI. But for anything with even minimal complexity you'll need to zip up the file along with any dependencies and upload it to AWS. This can also happen via S3. Shep handles all the zipping for you.

I am always happy to answer more questions. Feel free to email me: steve at bustle dot com.

More Information

Bustle

shep framework on GitHub

Related Articles

AWS Lambda For The Impatient Part 1

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info