Earlier quoted context omitted.
> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.
I use Google Cloud Run to run my serverless code for exactly this reason. GCR is literally just a container that runs on demand (with scaling to 0). Literally the only GCR specific part is making sure the service listens on the PORT env. If I was so inclined, I could deploy the exact same container on any number of services, host it myself and/or run it on my laptop for development purposes. There's also Kubernetes K…
The Serverless Revolution Has Stalled
541–550 of 670 posts
Re: The Serverless Revolution Has Stalled
#542Earlier quoted context omitted.
In my experience, having started and abandoned side projects in both aws lambda and google app engine, half your project becomes: * Well, obviously we use a hosted database * And obviously, AWS provides our logging and all our analytics. * Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms. * Of course, we can't blindly let…
This, but it was told by serverless experts, on stage, in front of hundreds of people. If that was their sales pitch, their reality was likely even less impressive.
It was a complete omnishambles - to the point I avoided the fancy lunch and went to the Pub for a ploughman's lunch, In case I suddenly blurted out "this is all S*&T" and caused a political row with the mobile side of the company I worked for.
Re: The Serverless Revolution Has Stalled
#543This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…
With newer power technologies becoming more affordable and effective, solar, wind, & storage are increasingly being used to power factories and other businesses.
It's all about control of your product and operations. If it is economically feasible, it's always better to control your own stack all the way down.
Does serverleds actually deliver better control over your development, portability, reliability, security, etc. for your application & situation, or not?
This sounds a bit like the "When will they turn off the last mainframe?" arguments a while back - I wouldn't expect servers to disappear either...
Re: The Serverless Revolution Has Stalled
#544This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…
Re: The Serverless Revolution Has Stalled
#545As for running actual code, many types of workloads currently do not map to serverless at all and you won't find out until you hit the limits. Anything that needs to read in a lot of data from a file or do a lot of in memory computations are a lot less efficient or impossible in Lambda given the memory constraints. If any single invocation of your lambda needs more than the alloted memory, it'll just fail and you'll either need to implement some heuristics based routing to the different lambdas (same code with the appropriate amount of memory) or you'll just eat cost on every lambda invocation. You'll find you end up doing things like re-writing lambdas from Python into Go to make it easier to fit more in memory. How is that not insane?
Although it's not 100% true anymore, at the time serverless development was often easiest using SAM which ties you directly to AWS CloudFormation which is the biggest mistake any company can make. CloudFormation is easily the worst thing that AWS has ever created. It's fine for infrastructure with lower rates of change but for applications it's an absolute nightmare to the point where it comes up in every sprint retro on some of our teams.
I /won't even go into how crappy testing is. It's a complete afterthought and it shows.
That team has started moving towards ECS/Kubernetes and even running Docker containers directly on EC2 instances in some cases because it's actually saving them time over futzing with Lambda and it's enabling them to do more faster.
Re: The Serverless Revolution Has Stalled
#546Earlier quoted context omitted.
Tracking exactly what individual db entries ran and didn't run when there's one of these "serverless" "painless" interruptions to an ETL, ensures that you have an endless number of ever-changing status columns and re-run processes. Are you really sure that it all re-ran? No. You have to query your latest batch - which means you have to have arbitrary boundaries for when failures might have occurred like say, last 24…
Here's the beautiful thing about thinking serverless. "Are you really sure that it all re-ran?" Yes I am, because Dynamo streams or Kinesis streams guarantee message delivery. If my Lambda code has a bug in it, which yes sure that happens, I can as part of my exception catching, put that message into a dead letter queue and process it later or report on it. No polling, no querying, I know exactly what went wrong and…
I can appreciate that. A lot more people than you might think, use Kafka or SQS because of various requirements (like that's all their infrastructure supports) and you end up with a massive "source" DB which is a duplication of all-time messages. Such is the reality of a larger byzantine organization. If it can't be audited by someone else, at their own pace, it's not approved.
Re: The Serverless Revolution Has Stalled
#547Earlier quoted context omitted.
I don't know, it sounds like you've just implemented all of those things n+1 times.
I think a lot is hidden inside "which calls SES" versus "point it at your MTA, do a ton of configuration, then it may work." Email is unfortunately a moving target. What worked before, gradually stops working as the big providers put up increasing obstacles to your own MTA doing a successful delivery. I've heard Amazon SES also has delivery problems so take with a pinch of salt. But I would hope they generally try to…
Re: The Serverless Revolution Has Stalled
#548Earlier quoted context omitted.
>"I'd agree that it's stalled, but moreso out of fear and ignorance than anything else." How about simple common sense instead of "fear and ignorance". I have a C++ monolith that serves me just fine already for years. The performance is great and I am able to rent dedicated servers that can serve at least 10 times more requests that I have at a price that is a tiny fraction of AWS for the same work. Why would I switc…
Can your business adapt to change well? That’s the first issue with any monolith.
Re: The Serverless Revolution Has Stalled
#549Earlier quoted context omitted.
AWS in particular seem to have a carefully refined technical sales/certification/advocacy channel whose main product is those fucking stupid architecture diagrams. Hello world service with $4000/mo. worth of geo-replicated backing databases, CloudWatch alarms, API Gateway instances, WAF etc. But don't let it encourage you to think serverless has no value, or it can't be done portably or cheaply. It has its sweet spot…
Reminds of something that was on the HN frontpage some month ago, where readers are not sure if it's a parody or not, because of the architecture you're required to deploy yourself to use this new "Perspective" product. Direct link to the architecture, that in the end serves the use case of generating a diagram of your AWS resources: https://d1.awsstatic.com/Solutions/Solutions%20Category%20Te... https://aws.amazon.c…
Re: The Serverless Revolution Has Stalled
#550Earlier quoted context omitted.
Eh? I was able to go from a docker image to live and 0 downtime deploys in a few hours?
But how many hours/days/years did it take you to learn how all the parts move before you became capable of setting something like that up within a few hours? Anecdotally, stories of businesses abandoning entire cloud automation projects because they wasted weeks and never had anything to show from it don't seem unusual, so evidently a considerable amount of knowledge and skill is required to get value out of these to…