Serverless: A replacement for servers?

A couple weeks ago I had the pleasure of attending ServerlessConf Austin 2017, sponsored by A Cloud Guru, an Australian e-learning company that specializes in AWS training.  Being a self-employed/contract developer, I managed this only through a generous scholarship that A Cloud Guru provided to several female Austin developers through Women Who Code. I attended the pre-conference day of workshops, where I learned how to make an AWS workflow into which you can upload videos in a couple formats that are then automatically transcoded into a standard YouTube-acceptable format in a couple sizes. It was a fun exercise and inspired confidence in A Cloud Guru’s enthusiasm, attention to detail, and love of serverless workflows. However, despite excellent instruction and guidance, my seatmate and I both ran into a persistent 403 error that proved beyond the scope of the exercise to debug. This was my first introduction to serverless — impressive as hell and just as hard to debug. At the conference, service providers like Microsoft Azure, AWS, and IBM delivered their ad schticks. FaaS (functions as a service) services were presented as a glorious trifecta: low-maintenance, infinitely scalable, and with a pay-per-use structure that obviates the expensive downtime of owned bare metal servers. A developer I spoke with at lunch told me he hosts his personal website in an AWS S3 bucket for a dollar a year. An air of excitement permeated everyone’s conversations. The future was now (the future was then?). Some presenters were more guarded. Charity Majors of Honeycomb.io, a cutting-edge analytics and operations monitoring SaaS, checked the serverless community on its unspoken “#NoOps” ethos. Serverless is great for decoupled processes, she argued, but you’ve got to be conservative when you consider purchasing a service to perform your core business functions. IS serverless great for hosting?, she asked. Majors was skeptical about the universal superiority of FaaS as a way to deliver the web. Marcia Villalba of the Finnish company Rovio (Angry Birds) talked about refactoring their existing a streaming cartoon service with AWS. Villalba was effusive and enthusiastic about the app her team built, but prominent in her presentation was her experience of load-testing their new service. When her team threw a ton of server traffic at their app, they immediately got a call from their AWS rep. It turns out that a lot of traffic is still a lot of traffic, and beyond a certain volume, serverless doesn’t scale itself. And that pay-per-use structure is fundamentally stateless. For processes that require polling or any kind of server wakefulness, converting to a serverless architecture can be an exercise in “serverless for serverless’ sake”. So said Forrest Brazeal of Infor, whose team converted an existing serverful app to a serverless structure to see if they could do it. It was a hot mess until AWS released Step Functions in late 2016 — State-as-a-Service to coordinate FaaS and be polled (like, ehm, a server). The case of Infor and Step Functions showed how available serverless environments are evolving as fast as we can develop for them, possibly faster. Security was the elephant in the room. Several speakers mentioned that it was important, that serverless makes it more critical than ever, but no one shared experience actually securing a serverless workflow. Guy Podjarny of Snyk.io came the closest, speaking in largely hypothetical terms about the change in the types of threats facing serverless architectures. Most memorably, he spoke about the idea that serverless architectures have more “exposed edges” than traditional serverful architectures. When you control and run functions on your own server, they are all bundled together into one castle that can be stormed. When you rent functional space, your decoupled functions are like 25 border outposts surrounded on all sides by ne’er-do-wells, with only the resources that your service provider’s package can muster. My takeaway from the conference was that, as of right now, serverful and serverless architectures don’t do the same things. In the final delivery of web content and services, they can appear to do the same thing, but that is an illusion created by the magic of presentation. Servers are a secure and time-tested option for hosting static data with optionally dynamic presentation; serverless is great for apps that perform active, multi-step data transformation represented to the user with a relatively static presentation layer. The more dynamic your app or service, the better candidate it is for a serverless architecture. The more that your app requires security layers, delivers mission-critical data or services, or relies on tons of state, the better off you are sticking to servers. For the time being. Check back with ServerlessConf next year.