I've built and maintain quite a large serverless system, with a large team of people, and most of these issues aren't really a big deal. Cold start is well-known and also has well-known mitigations (e.g. don't use the JVM, which wasn't designed for fast startup times).<p>I use AWS extensively, so I can elaborate on AWS's approach to these problems. Deployment is straightforward with CloudFormation, VPCs/security groups/KMS/etc. provide well-documented security features, CloudWatch provides out-of-the-box logging and monitoring. Integration testing is definitely important, but becomes a breeze if your whole stack is modeled in CloudFormation (just deploy a testing stack...). CloudFormation also makes regionalization much easier.<p>The most painful part has been scaling up the complexity of the system while maintaining fault tolerance. At some point you start running into more transient failures, and recovering from them gracefully can be difficult if you haven't designed your system for them from the beginning. This means everything should be idempotent and retryable--which is surprisingly hard to get right. And there isn't an easy formula to apply here--it requires a clear understanding of the business logic and what "graceful recovery" means for your customers.<p>Lambda executions occasionally fail and need to retry, occasionally you'll get duplicate SQS messages, eventual consistency can create hard-to-find race conditions, edge cases in your code path can inadvertently create tight loops which can spin out of control and cost you serious $$$, whales can create lots of headaches that affect availability for other customers (hot partitions, throttling by upstream dependencies, etc.). These are the <i>real</i> time-consuming problems with serverless architectures. Most of the "problems" in this article are relatively easy to overcome, and non-coincidentally, are easy to understand and sell solutions for.
Drawbacks I experience:<p>- Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present.<p>- Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up.<p>- Security/monitoring: having fewer functions make this less of a worry, but it's still difficult and it's clear that there's not much of an ecosystem and best practices.<p>- Debugging: this can be really annoying. I can usually avoid this by having a proper local testing setup (see below), but when that doesn't cut it, this gets annoying.<p>Drawbacks I haven't really experienced:<p>- Statelessness: this is probably due to not splitting up my code in too many functions, and thus not having that much complex interactions, but this hasn't really been a problem for me.<p>- Execution limits: haven't run into them yet.<p>Drawbacks I've managed to contain:<p>- Local testing: I'm writing Node Lambda's. Since they're just stateless functions, it was relatively easy for me to write a really simple Express server, transform the Express requests into the API Gateway format, and convert the API Gateway response format back into Express format. This works fine for local testing, and reduces the effects of vendor lock-in. That said, I do do a lot of the request parsing in the Lambda function itself, rather than letting API Gateway do this.<p>- Deployment: this is actually pretty sweet. I'm using TerraForm which, although it's a bit immature and thus cumbersome to set up, has been getting the job done and allows me to easily deploy new copies of the infrastructure for every branch of my code.<p>- Remote testing: as mentioned above, deploying it for every branch I have allows me to see what it's going to look like in production.<p>Hmm, perhaps I should turn this into an article sometime...
CGI scripts with a new name. Lambda and the like are interesting but any system is a composable set of components.<p>You can say the same about Object oriented programming or func programming. separation of concerns but on the network. Server functions arent a panecea cause you still have to manage all the other pieces.<p>An elegant thing would be your entire app is in that single lambda but without state there goes your db. even so, people cant resist taking something and adding and adding more to it.
The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way.
With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to:<p><pre><code> * Manage/deploy servers
* Monitor/maintain/upgrade servers
* Figuring out tools to deploy your app to your server
* Scaling an app globally.
* Coping with outages in a data-centre/availability
* Worry about load-balancing & scaling infrastructure</code></pre>
> Drawback of Serverless: Vendor lock-in, statelessness, local testing, cold/warm start perf, security, deployment, execution, monitoring, remote testing, debugging.<p>Excuse me? Let's use lambda for what it was meant to do, not replace your entire stack.
I tried the excruciating task of building a real-time multiplayer game with server-side authority using only Firebase and Google Cloud Functions.<p>Basically I handle all the logic in Firebase rules and lambdas. Any destructive action goes through a GCF that updates the Firebase Realtime Database. Actions that happen often (like moving) are updated directly by the client but validated with some overly complicated Firebase rules.<p>It's very nice not having to worry about servers and scaling, but it can be a really painful development experience.<p>Let me know if you want to try it out and I'll post the URL.
For me the BIGGEST gain of using serverless architecture is security. For example, this year I started two ecommerce platforms. One's a digital delivery e-shop - selling ebooks, training and stuff and the other is a physical delivery e-shop. Normally, I'd write my own Phoenix/Rails app, but this time, I decided to go serverless for my furniture shop and wrote it all in Jekyll. Yes, the static site builder. I use netlify to manage the production aspect of it (which IS pretty AWESOME) and simple excel sheets to track inventory (which is what my vendor provides me, anyway). For payment, I simply use the checkout/cart functionality provided by Paypal and all this just works! The site is designed in such a way that you can't even tell anyway what's being used for the backend. No one can tell it's just a bunch of static HTML pages on display.<p>Whereas, for my digital delivery store, I regularly need to check my logs to see if anyone's doing anything suspecious. For example, a lot of IPs randomly try to visit wp-login.php or /phpmyadmin. Maintaining a production web application is a full time job by itself, if you don't have a team.<p>Having said that, many people would immediately assume static page builders are generally dumb. That isn't exactly true - You can automate a lot of stuff. For example, my local machine has a custom Jekyll plugin for my store that resizes and optimizes product images before pushing to prod to keep the page load time small. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Or maybe write some code to communicate with an third party API and usually, it's not free.<p>End of the day, I make sales and that's all that matters. That's when it hit me hard that my customers needn't care nor know what's behind their favorite site.
> grouping a bundle of functions together behind an API gateway, you’ve created a microservice<p>Always beats me why people don't warn the readers about the almost impossible nature of logging and monitoring such systems :/
What I've found having to use serverless is the local development tools are broken. You'll find cloudformation is the only way to reliable manage all the proprietary paid for services which will require you to read several documentation on various tools (kinesis, dynamodb stream or fifo, standard queues) to work out which one might work. To find out it doesn't necessarily work in your applied function (CloudWatch Insufficient Alarms I'm looking at you). So you then have a choice to use cloudformation and another deployment tool to push your services. This is more typical after you've given up trying to manage dynamodb-local across platforms for your codebase.
One thing I would like to see in articles like this are more concrete use cases for using serverless. The article begins talking about the concept as though you should write your entire app in serverless, and then in their case study, use serverless as a background process to convert image types.<p>The other use case I always come across is image scaling.<p>I'd be interested if anyone would like to share their use cases as entire apps or background processes.
I’m looking forward to Amazon Fargate which is less extreme than Lambda but still server less in some sense. Basically you can still write proper apps (Spring Boot apps in my case) but, so long as you containerize them, you don’t have to provision servers, just tell Amazon what resources they need and how many instances you want.