undefined | Better HN

0 pointsZelphyr7y ago0 comments

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.

0 comments

laumars7y ago

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

mmt7y ago

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

j / k navigate · click thread line to collapse