Today’s serverless architecture design is new. Really, really new. (Yeah, yeah, Grandpa, you could argue that your mainframe apps were serverless, but you’re missing the point. Go back to yelling at the cloud.)
That immaturity has a lot of drawbacks by itself:
- Learning serverless is hard – the awesome list of serverless resources is a good place to start
- Hiring is nearly impossible – the tech is so new that few people know it yet, and those who do are expensive
- Getting help is tough – there’s hardly any questions & answers on StackOverflow, for example (AWS Lamdba – Windows Azure Service Fabric)
- Best practices don’t exist yet
- If it’s down, it’s just down – it’s outside of your control
- Vendor lock-in – each vendor implements it differently right now, and porting code between Amazon and Microsoft would be very expensive
That last one is ugly because in theory, you’re worried about any vendor screwing it up. They could jack up prices, make a breaking change, or just deprecate the whole platform.
The next major drawback is single-transaction performance. Today’s serverless platforms have much higher latency – for example, if your function hasn’t run recently, AWS Lambda has to start up a container for it. Forget running an e-commerce site on this – after a second or two, Google-referred users will just hit the back button and try someone else’s store.
The cons above add up to one thing: if you’re a midsize profitable company, building a traditional application or web site, you should probably not use serverless design. Your application will be slower to build, slower to access, and harder to troubleshoot.
But if you go in knowing those drawbacks, the advantages can make it a good fit for a few types of applications, like the ones we’re building at the moment.
The Advantages of Using Serverless Architecture
Someone else manages uptime and that related staffing. When the serverless provider’s servers go down, they’re the ones who have to manage it, not me. For a non-critical app like the one we’re working on now, that makes perfect sense.
Hosting costs and performance scale linearly. If no one is using your app, you don’t pay. As more people use it, your costs go up. For the applications we’re working on now, we’re only projecting dozens of users per hour, which means hardware or VMs would be sitting around idle. If it catches on later, great – but even if only dozens of folks use it, we’re still quite happy with the costs.
We’re getting valuable experience. We have a lot of application & service ideas that all involve asynchronous access (queues), low performance requirements, and analyzing stored data. With one company, we picked an app that was the easiest one to bring to production first, and we’re testing whether serverless architecture will work for the rest of the ideas.
Choosing a Serverless Platform
Mid-2016 is a tough time to bet on a platform. Several smaller independent players got in before the big guns, and we won’t review the smaller folks here since we don’t have any experience with them. Focusing on the big ones:
Amazon Web Services offers Lambda, which charges by the number of times your code runs, plus a per-second cost for the memory you use. You can run Node.js, Python, and Java code as Lambda functions.
Microsoft’s equivalent is Azure Functions, but it’s brand spankin’ new:
- It’s only in preview right now
- The documentation is woefully light
- Prices are listed as to-be-determined
- They’re open source (although the lack of commit activity doesn’t exactly inspire confidence)
Microsoft is playing one heck of a game of catch-up in the cloud business. Given how new and undocumented AWS Lambda is, Microsoft stands a pretty good chance of being competitive in the serverless space.
This is an Alpha release of Google Cloud Functions. This feature might be changed in backward-incompatible ways and is not recommended for production use. It is not subject to any SLA or deprecation policy.
Ouch. Your platform decision will come down to the serverless landscape at the time you’re making the decision, plus your reliance on the other cloud services provided by each vendor.