Don't get me wrong; from a resources management and scaling perspective it's great. But that doesn't outweigh the massive pain during development that it creates.
We're in the process of rebuilding a project to move everything out of a Serverless Architecture. After six months of building it on serverless we finally all agreed it was a big mistake.
[1] That's our experience with AWS. May be different with other providers.
[2] I recognize that Serverless Framework helps mitigate this but that's just yet another abstraction on top of abstractions in my opinion.
I think the issue is some people see "serverless" as an all or nothing scenario which it really isn't. Some problems are solved well with serverless and some are not. It's like the container vs virtual machine argument. One isn't designed to replace another - they're just different tools for solving different problems; each have their own strengths and weaknesses.
Just like people have been calling their controller actions from test harnesses for ages to test their APIs. You can call call your handler the same way.
At the end of the day, AWS is just passing you a JSON message. You can call your lambda function manually with the same JSON payload locally.
I tend to opt for the SSH tunnel route for personal projects but use OpenVPN with a secrets management (eg Vault or AWS's new key store) for professional projects (ie when you have several people on your team).
AWS is versatile enough that you do actually have several options available to you.
But then... any architecture benefits from localhost-first.
These are problems that will be solved eventually, I have no doubt. But they haven't been solved yet and that is what makes Serverless Architecture not ready for prime time in my opinion.
Even back in the days of self hosting, I've lost track of the number of times a Dev script has gone wild and caused excessive load on the RDBMS or tried to spam the SMTP relay. On a Dev environment you can catch that without affecting live services.
As for the other issues you meantioned, this is nothing new. There have always been appliances in IT. Whether it is physical rack mountable appliances like hardware video encoders, or SaaS solutions on a public cloud like AWS media transcoders, you interact with then the same. The only difference with public cloud solutions is you you first have to bridge your office network with your AWS (or whatever) virtual private network. Thankfully you have a variety of tools at your disposal to do that. (Over the years I've used no less than 4 different methods to bridge a local network with an AWS VPC - each taking advantage of their own specific business requirements).
Indeed, and, as a general rule, they were astonishingly expensive, especially in up-front purchase cost.
> The only difference with public cloud solutions
I posit that another difference is that the up-front cost is approximately zero. That makes the adoption decision much easier (even possible in the first place) for much smaller companies, especially startups.
That also means what would otherwise have been an up-front cost is hidden in the pay-as-you-go cost.
That cost-hiding does create a new problem, albeit a sublte on. A startup faced with having to buy a $300k appliance might think nothing of it if there were a smaller/dev version available for $30k for that environment. However, if that appliance actually needed to be duplicated in the full $300k form [1] in both (or maybe more, if they have stage/qa/integration, research, and/or multiple dev envs), that startup would take a serious look at alternatives. Those relative costs aren't as stark with the cloud version of applicances, until well after the choice has been made.
[1] Or, worse, an even more expensive version, if dev, testing and/or research use of the appliance is heavier than production. I expect that's a rare, outside of storage.
Ideal because it's faster development time. And free since I'm not paying Amazon compute time to run my code while I write it.
Not always possible because I don't have AWS's services locally. As mentioned elsewhere, there are emulators but, by virtue of their emulation, may not always perform like the real thing. That's a debugging ball of wax that I personally hate having to untangle.
You can access most (all?) of AWS services without running on AWS EC2/Lambda.
Especially for CRUD apps and otherwise simple apps, testing should start after git push.
Don’t want to wait each time? Automatic build and teardown of test envs on a schedule, to avoid always up.
I still local test low-level code. But anything running in a cloud should really just be tested there.
And sometimes the data is too large to have fully on localhost. You can work with a subset, but if you have a 2tb database, it's not feasible to have the whole thing local for testing.
https://www.markheath.net/post/remote-debugging-azure-functi...
As I've said before; these are all problems that all of the cloud providers will solve eventually. But until they do I'm not sold on building a production application on a Serverless Architecture.
So what if I gave you a command-line tool to simply make the current code in your development environment live?
Want a debugger? Nope.
And I also gave you live step debugging, plus replays of recent server state?
Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more.
And the logs from the instance you're debugging are available instantly?
No-worries devops experiences are nothing new. See Heroku.
That aside, I agree that there are a lot of secondary concerns that are important when running things in production but that aren't available out-of-the-box when you run something on AWS Lambda. I'm thinking about error monitoring, performance monitoring, logging,... All those things need to be set up and that's quite time-consuming.
However, I think that's more due to serverless being relatively new and not as mature as the traditional way of doing. I don't think it will take long before we'll have the equivalent for serverless of adding `gem 'newrelic_rpm'` to your Gemfile and magically having performance and error monitoring across your app.
Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises.
> I think AWS has already started that with Amazon Aurora.
Just in time when we were talking about fanfare. Spend 10-20 minutes searching on the Internets to see what actual experiences people have with it.
Its 3X write increase? Bollocks. Usually the performance is worse than when you administer your own DB(Postgresql/MySQL). You might(or not) see some read-performance increase, which... well everyone can scale on reads so I don't see the point.
I suspect it has other goodies pertaining to administration/provisioning, but performance/scaling is not one of them.
> Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises.
Traditional relational databaases have indeed solved many issues that some newer datastores struggle with. But the flip side is that it is non-trivial to design traditional databases that are not Single Points Of Failure.
Storing data is surprizingly hard in a cloud environment, and involves trade-offs. Reaching a comprehensive solution (fast, HA, consistent, easily recoverable, scalable volum, evolvable schemas...) is hard no matter what technology you pick.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Auror...
Aurora DB clusters must be created in an Amazon Virtual Private Cloud (VPC). To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora DB clusters in a VPC, you use a VPC security group. These endpoint and port connections can be made using Secure Sockets Layer (SSL). In addition, firewall rules at your company can control whether devices running at your company can open connections to a DB instance. For more information on VPCs, see Amazon Virtual Private Cloud (VPCs) and Amazon RDS.
That said, where I work (MaaS Global) we have a production PostgreSQL database hosted on AWS Relational Database Service (RDS):
https://aws.amazon.com/rds/postgresql/
We connect to the AWS RDS instance in our lambda functions using an ES library called knex.js and some environment variables to store the DB credentials:
It's been a problem for years and there's been no sign of a solution. Example article from last month: https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat...
These are the sorts of problems that turn people off from using serverless architectures.
For the DB connection you put the lambda in the same vpc that the RDS exists in. Then you open the connection pool and reuse it if its active. Not that a new connection is a big overhead over leveraging an established socket.
Wonder where all this misinformation is coming from on lambda DB access issues.
1. This doesn't work if you were actually trying to build your API as microservices. You might have 60+ functions, some which call each other, and keeping them all warm is not really a good option.
2. Keeping a minimum number of instances warm fails to account for half the point of using serverless architectures: being able to scale. Sure, if you have little to no traffic, you can keep a couple instances warm and be up, but if your app needs to scale to 5 or 10 or more instances to handle bursts of traffic, the surfers who hit that cold start end up dealing with an extremely bad experience.
More importantly, as Lambda gets more popular, uptime pingers get less and less useful because of tragedy of the commons. The reason for needing cold starts at all is that AWS is rotating out instances to be able to keep up with overall demand with limited resourcs. If only a few people are sending heartbeats to their instances, their instances stay in rotation because other people's get rotated out instead. If everyone is sending heartbeat requests, some of them will still end up getting rotated out, and therefore everyone will need to increase the frequency of the heartbeat requests to keep their functions warm. It's not a sustainable solution, and I'm baffled that AWS tacitly promotes it as a resolution to the problem they themselves have caused.
It's been years. AWS needs to fix Lambda VPC cold starts.
Keeping Lambda functions warm is great until you have 2 or more requests hitting the function simultaneously. They won't queue behind the pre-warmed function, they will spin up additional Lambda containers to serve in parallel. Unless you don't expect to get concurrent requests, there's no effective way to pre-warm Lambda functions.
Here's the data model part of my todo app if you want to see queries in the app: https://github.com/fauna/todomvc-fauna-spa/blob/master/src/T...
Those options work fine, if you were OK with using a NoSQL DB. But what if you wanted to use an actual relational database? For that you pretty much need Lambda in VPC, and it's not really usable because of the cold start issue.
At some point Amazon will release Aurora Serverless[1], giving a serverless option for an on demand relational database. Will that work somehow with Lambda without needing VPC, therefore defeating the cold start issue? What cold start issues we'll it have itself? I guess we'll wait and see for now.
Tried FaunaDB few month ago the latency was beyond 200ms for a simple a read , and beyond 600ms for an insert.
Would not recommend it at this point.
And I was complaining about 500ms cold start times on Firebase Functions.
I think I'll stop complaining now.
Exactly the same way you would with an EC2 instance...
Wait, oops, you have state now.
Serverless is nice, but the ecosystem of serverless tool is really missing today IMO
Why does this keep getting repeated? You get a publicly accessible host and use the same drivers you use on prem or you put both the lambda and the database inside your VPC.
I don't think we'll be considering a fully serverless architecture anytime soon due to cold-start times, but it's awesome for anything outside of the user request/response loop or internal microservices where response time is perhaps not such of a problem.
[1] https://aws.amazon.com/premiumsupport/knowledge-center/inter...
Look, there's nothing dirty about re-framing the conversation every once in a while. It may feel like BS at first but over time we attach new meaning to old words and it becomes easier to communicate capabilities.
For me serverless is pay-as-you go pricing, no over- or under-provisioning and last but not least, no server-management.
Lambda, DynamoDB, S3, AppSync, Device Farm, Aurora, etc. are all serverless.
Yep. Lambda may be functions-as-a-service, which is a great name for it, but the whole shebang is more than that. Thus, serverless.
As a consumer, I essentially get to treat it as such - there is no server I need to manage.
In AWS-land this is a big differentiator over a system I have to manage, such as EC2, that just executes containers (meeting FAAS). Now I have FAAS and I don’t have to manage the infra, which is huge because AWS will be far better at meeting a patching SLA than I will be.
Yes, obviously there is a “server”, but I don’t have to think about it.
Any of those other than IaaS itself can be "serverless".
OK, well it's the most important part for me. I don't want to manage patching a box.
And yes, marketing is a real thing, and names are also picked because they sound cool. There are worse things.
That is - a piece of code in a monolith may fail, and a piece of code in a microservice may fail, but I've already written the code to handle network errors for the microservice case, which means I've also implicitly handled the "bug in code" case.
If I have a local function in the same language I can pretty much assume that a call to that function will actually call that function. With a remote call over HTTP or whatever I can't, so that is an additional failure I need to handle.
I'll grant you that there is more complexity in this approach, but I believe that fault tolerance is something you improve with microservices, not something you regress on.
Yes, you have to handle the failure case of "network call". Microservices add this failure case. But you already had to handle the case of "code blew up because of a bug".
By forcing you to handle comm errors like network failure, you also force people, implicitly, to handle "code blew up because of a bug" errors. Even though it adds a second error case, you pretty much handle them the same way in the same place.
There was always an error case - the fact that code may blow up.
I'm handling bugs very differently than network failures though, because network failures are usually temporary while bugs are usually (or even by definition) permanent.
Dealing with temporary outages in lots of places is extremely difficult. You may need retry logic. You may need temporary storage or queuing. You may need compensating transactions. You may need very carefully managed restarts to avoid DDOSing the service once it comes back online. There may be indirect, non-deterministic knock-on effects you can't even test for properly.
Microservices cause huge complexity that is very hard to justify in my opinion.
Depends on the bug - there are transient bugs that are not networking related.
But let's assume it's a "hard error" ie: a consistently failing bug. I would say where that bug is makes a huge difference.
If it's a critical feature, that bug should probably get propagated. If it's a non-critical feature, maybe you can recover.
By isolating your state across a network boundary, recovery failure is made much simpler (because you do not need to unwind to a 'safe point' - the safe point is your network boundary).
But it often depends how you do it. I personally prefer to write microservices that use queues for the vast majority of interactions. This makes fault isolation particularly trivial (as you move retry logic to the queue) and it scales very well.
If you build lots of microservices with synchronous communications I think you'll run into a lot more complexity.
Still, I maintain that faults were already something to be handled, and that a network bound encourages better fault handling by effectively forcing it upon you.
And the ones you aren't responsible for are ones that the rest of the world uses every day at 1000x the scale you do.
In your opinion, it easy to differentiate between dev/prod environments for development? How about logging?
Differentiating dev/prod is not too bad, everything is labelled based on your naming scheme for serverless.
Having said that I think lambdas are a great use case for cron jobs.
because it's purely a marketing concern, it means nothing from an architectural standpoint, it"s a buzzword, like 'cloud', 'nosql', 'web 2.0' or 'the blockchain'.
Serverless computing is an system architecture design that focus emphasis is abstracting the entirety of the infrastructure to let developers focus solely on code.
Per say , with AWS Lamba + API Gateway + S3 developers can create Web Application that usually required EC2 Servers and web framework like Spring , Laravel etc...
Apps hosted on AWS with EC2 requires strong knowledge in system architecture and system design . They also are quiet complex to scale , monitor and manage.
Serverless abstract all this and lets you focus only on code.
AWS Lambda is self healing meaning when a function crash , only that function crash not the entire server , API Gateway is managed by AWS it won't crash ( or very unlikely ) S3 , as i'm concerned , as never let me down.
Meaning I could author an entire application similar to Hacker News without any "Server" logically speaking, technically speaking there is always a server just like NoSQL doesn't mean "NO SQL" but "Not Only SQL" and is not buzzword :)
Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs.
Originally it was a marketing buzzowrd designed to make Amazon's FaaS offering seem like a bigger deal than it was, and somewhat misleading in that role because FaaS of the type it was applied to aren't any more serverless (even from the perspective of what the customer needs to manage) than common PaaS offerings.
OTOH, I kind of like the way Google seems to have adopted it as a blanket term for cloud services where the customer is not concerned with physical or virtual servers as such; it seems the term.is being wrestled into being descriptive and non-deceptive.
> Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs.
The non-existence of servers isn't what it communicates, only technical people who also lack any sense of what matters to business world think that. (It's also targeted more to CTOs/CIOs than CEOs).
Everybody also knows that a wireless vacuum has wires inside it, the value prop is that the wires never get in your way. And so with serverless.
Instead of a couple of servers you have thousands of small virtual servers running on real server and call that serverless. It's comical.
I wonder what hell this approach will be for legacy serverless systems where there is stuff running everywhere and no one got a clue where to pull the plug or patch stuff.
It’s the name. It infuriates people because obviously there still really are servers. But I think of it like WiFi - there still are wires, you just don’t see them.
With wireless networking and even phones, the wires have actually been eliminated, replaced wholesale by something else, radio. A better analogy would be something like the powerline ethernet systems, but nobody is calling them something controversial like "wireless" or "cableless".
Put another way, I've seen cloud computing (of which "serverless" is, arguably, merely an evolution into increasing levels of abstraction) called "somebody else's servers". The equivalent with the Wifi analogy would be "somebody else's wires", and, usually, what wires there are, for the backhaul [1], aren't even somebody else's.
EDIT:
Ultimately, my point is this:
The analogy is weak becasue WiFi is not an abstraction layer on top of wired networking that merely hides the existence of (and, ideally, some of the downsides of dealing with) the wires, instead being a different technology with different upsides and downsides. Serverless is such an abstraction layer.
[1] Which brings up a nitpick: Wifi can remain even wireless in its entirety, with various mesh networking techniques.
> You think WiFi connects your laptop directly to the server in the datacentre? Interesting.
The way you've selectively quoted one sentence out of what is a very short post anyway just so you can imply that I'm oblivious to other infrastructure - even when my very next sentence describes other infrastructure - is in very poor taste.
Plus you're still failed to prove point. Yes ethernet over cat5e/6 cables and fibre exist, but they're not WiFi. Neither is 4G, Bluetooth, nor FM radio despite actually being wireless (unlike cat6 / fibre).
What you're arguing is beyond nonsensical; it's like saying "I drive to the railway station every morning therefore the train I then catch is also classified as a car."
The daft thing is if you'd talked about the wireless radio's antenna then you might have had a genuine point. Yet you went the "network cables are WiFi as well" argument instead. Go figure.
I believe my analogy to be a sound one, in that all wireless does is insulate the end user from mile upon mile of wiring, just as serverless insulated the user from racks upon racks of servers, and that you were - and are - being needlessly pedantic.
Isn't the point of HN that you can have a discussion when you disagree with someone?
I called it a spat because you both got personal. It's nice that you both enjoyed it, but it's still against the rules here. It sets a bad example for others, who unfortunately aren't so convivial.
So congrats on the funding, I hope you can convert some haters :)
[1] obligatory plug: https://notify.run