How to make your apps serverless

[Rss Bot 1]

In 2016, we witnessed the rapid rise of a new buzzword: serverless. At face value, the term makes it sound like servers no longer exist. Of course, this is absurd. Every serverless application is running on a server somewhere. But it does mean that entire applications can be successfully built without deploying code to your own servers.

While the term 'serverless' may be misleading, the value of delegating server management to a third party is very real. The dream of spending less time worrying about servers and more time building software can be a reality.

Serverless in action

At Bustle (where I work as director of engineering) we serve content to over 50 million unique readers a month. This means traffic at our scale is significant but also sudden, as articles can go viral at any moment. Our legacy VM-based infrastructure was having trouble keeping up and our engineers were spending too much time on operations. We started looking at serverless platforms as a solution and, after a few successful experiments, began moving over our entire stack. It has been a complete success; our projects are more maintainable, easier to operate, and cheaper.

Amazon Web Services

It is difficult to talk about serverless without focusing on Amazon Web Services (AWS). AWS has become synonymous with serverless because it answers one critical question: Where does the custom code go? The concept of using third-party services and platforms is not new. Databases, push notifications, caching, and many other layers of an application have all been available 'as a service' for a while, but they sat on the edge of your application. You still needed a place for core application code, which was usually a server (and often many of them) responding to external requests. 

This is where AWS came in. Its products AWS Lambda and AWS API Gateway exposed primitives that made it simple to deploy custom application code without the overhead of managing your own servers.

AWS Lambda

Lambda is Amazon's version of functions-as-a-service (FaaS). It is quite simple: you write code and upload it – though currently only Node.js, JavaScript, Python and C# have official support. AWS will then run that code in response to events including HTTP requests, S3 uploads, DynamoDB updates, Kinesis streams, and many others. Scaling happens automatically and you are only charged when your functions are running.

None of these features are strictly a requirement for serverless, but AWS has certainly set the bar high. Any serverless platform will likely have a stateless FaaS offering with very granular billing because of the precedent set by AWS.

Other platforms

Amazon may have the lead, but other providers are catching up quickly. All the major cloud platforms have recently launched services targeted at serverless applications. Here are a few:

• Google Cloud Functions: Still in alpha, this provides similar functionality to AWS Lambda and can also be triggered by HTTP requests.
• Azure Functions: This is also similar to Lambda and still relatively new. Azure has a pleasant UI and makes it easy to expose functions over HTTP without needing a separate routing service.
• IBM OpenWhisk: The only major serverless platform that is open source. If you are interested in deploying your own serverless platform or just curious how they work under the hood, you will want to investigate this.

Challenges

No servers doesn't mean no operations

Serverless does not come without its challenges. The space is new and as such, the community is still discovering best practices – especially when it comes to operations. I've seen people assume that no servers also means no operations. This could not be further from the truth. 

My favourite definition of operations comes from Charity Majors: "Operations is the constellation of your org's technical skills, practices, and cultural values around designing, building and maintaining systems, shipping software, and solving problems with technology." This beautifully captures how integral operations is to any software team, and serverless does not change that. More than ever we are in need of tools for deploying, maintaining and monitoring our applications. 

Unfortunately, having no access to the server means we are unable to use many tools that have been battle-tested over the last couple of decades. I anticipate that we will see many new startups' third-party services targeted at solving these problems for serverless developers. Some companies have already sprouted up or modified existing tools, including IOpipe and Honeycomb.io.

Tools

The open source community has recognised some of these challenges and responded with a wide range of tools and frameworks specifically targeting serverless. Here, the market dominance of Amazon is apparent, as most of these only currently support AWS. 

Of course, it is possible to manually build and deploy serverless applications yourself, but I wouldn't recommend it – with even a few endpoints, building, packaging, zipping, uploading and versioning all become difficult to manage. 

Here are just a few of the frameworks out there for you to consider:

• Serverless Framework: This is the oldest and most established framework for building serverless applications. It has a robust plugin system and integrates with many community developed plugins. Its stated goal is to eventually support deployment to any of the major cloud platforms.
• Apex: This is written in Go but supports Python, Node.js, Go and Java runtime languages. The creator, TJ Holowaychuk, is a fixture in the open source community and has a great sense of what makes for good developer tools.
• Chalice: The only framework created and maintained by AWS. It currently just supports Python.
• Shep: Bustle's own open source framework, used for all our production services. It focuses exclusively on the Node.js runtime and strives to be opinionated about how you should structure, build, and deploy applications.

The future

2017 will continue to see the rapid adoption of serverless technologies by everyone from startups to Fortune 500 companies. Even in its nascent state, the serverless movement is a significant step forward in enabling teams to build better software. That has been our experience at Bustle, and I've talked to engineers at other companies with similar stories. Capital One, iRobot, and Nordstrom have all talked publicly about their adoption of serverless.

Servers will never fully go away, but it is a joy to build software and let someone else worry about them. If it fits your use case, I highly recommend you consider serverless for your next project. 

This article originally appeared in net magazine issue 292; buy it here!

Related articles:

• 4 of the most game-changing developments in tech
• 20 useful tools for web developers
• 15 APIs developers need to know

View the full article