[Zelphyr]

It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat. Want a debugger? Nope. Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more[1]. Don't get me started on the massive vendor lock-in inherent with a Serverless Architecture[2].

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.

[laumars]

I don't disagree with you that serverless is a step backwards if you want control about your running platform but your debugger example can be argued away by the fact that you shouldn't really be debugging a live platform. If your code is portable enough to run "serverless" then you should be able to spin up a docker container or whatever and run the same tests in there.

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.

[Zelphyr]

How do I debug locally/on Docker with services like SNS and ElasticTranscoder? I know there are emulators but those have gaps in services that providers like AWS offer. Not to mention, I'm debugging with an emulator and not the real thing.

[scarface74]

I can’t speak for ElasticTranscoder, but there is nothing stopping you from running your lambda function locally and still connect to all of the AWS services.

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.

[laumars]

This is exactly how we test our lambda code that call AWS media encoders

[laumars]

You could run the docker container on an EC2 instance or have an SSH bastion / VPN tunnel between yourself and your AWS VPC.

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.

[matchagaucho]

Serverless architecture certainly benefits from a localhost-first environment with mock data and unit test feedback prior to deployment.

But then... any architecture benefits from localhost-first.

[Zelphyr]

We found that the further we got into using different services the more difficult local development became. I just assumed that, as in the old days of web development, we would be forced into not being able to do local development at all. So then we'd have to have duplication of services. One for development and one for production. Or multiples for development so that each developer didn't step on the toes of the other. There goes the cost savings touted by Serverless Architecture.

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.

[laumars]

It's good practice to have separation of dev and prod service anyway. I don't see that as duplication, I see that as different operating environments.

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).

[mmt]

> There have always been appliances in IT.

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.

[jjeaff]

Localhost first is ideal. But not always possible.

[eyjafjallajokul]

Can you explain why?

[Zelphyr]

Why its ideal or not always possible?

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.

[scarface74]

Which services are you using for which you are concerned about cost while you are developing?

You can access most (all?) of AWS services without running on AWS EC2/Lambda.

[chii]

Can't these services be mocked out? Surely you are wrapping the service API with your own code to prevent vendor lock in right?

[jdo20bbx]

Doesn’t everyone just spinup and teardown either an EC2 based Docker host or and EKS worker as needed?

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.

[jjeaff]

Proprietary software or hidden configurations. I have my site on localhost docker container. But I can't spin up an Aurora instance. So I use a similar mysql container. But it's not exactly the same.

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.

[dsp1234]

Want a debugger? Nope.

https://www.markheath.net/post/remote-debugging-azure-functi...

[Zelphyr]

That's great. I'm sure Amazon and Google will follow suit. But they're not there yet and Amazon is the big guy that most people are on.

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.

[inopinatus]

These are complaints about the immaturity of the implementations. About which I’m inclined to agree but still recognise that the architectural style has legs.

[stcredzero]

It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat.

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?

[hayd]

I'm a big fan of serverless, but these are valid questions to which there really ought to be better answers than "nope".

[stcredzero]

I'm working on making all of those a "yup."