So, "serverless" is a marketing concept in which you pay for a server? I can't wait for my manager to be sold on the idea of "functionless" computing.
Maybe the revolution has stalled because the emperor in charge has no clothes?
The Serverless Revolution Has Stalled
551–560 of 670 posts
Re: The Serverless Revolution Has Stalled
#552Earlier quoted context omitted.
Yes, it (Python) was chosen because we could leverage existing internal code that was written in Python and it happens to be my strongest language. If I could do it all over, I would still choose Python. That being said, I have been working professionally (building apps like this) for almost 14 years so my willingness to bite off a homebrew Python framework endeavor as I did here is a lot different than someone just…
Could you elaborate on why you dislike Django? Would be great to hear from someone with extensive Python experience.
That is such a tough question to answer carte blanche.
All-in-all, Django is not bad software. I have a bad taste in my mouth though because as I learned and developed new approaches to solving problems in my career I feel like Django got in the way of that.
For instance, there are some really killer ways you can model certain problems in a database by using things like single table inheritance or polymorphism. These are sorta possible in Django's ORM, but you are usually going against the grain and bending it to do things it wasn't really supposed to. Some might look at me and go: ok dude well don't do that! But there are plenty of times where it makes sense to deviate from convention.
That is just one example, but I feel like I hit those road blocks all the time with Django. The benefit of Django is it is pre-assembled and you can basically hit the ground running immediately. The alternative is to use a microframework like Flask which is very lightweight and requires you to make conscious choices about integrating your data layer and other components.
For some this is a real burden - because you are overwhelmed by choice as far as how you lay out your codebase as well as the specific libraries and tools you use.
After your 20th API or website backend you will start to have some strong preferences about how you want to build things and that is why I tend to go for the compose-tiny-pieces approach versus the ready-to-run Django appraoch.
It's really a trade-off. If you are content with the Django ORM and everything else that is presented, it is not so bad. If you know better, you know better. Only time and experience will get you there.
Re: The Serverless Revolution Has Stalled
#553Earlier quoted context omitted.
And I’d argue the mere possibility of the server breaking at any time contributes to non-negligible amounts of sustained psychological stress.
Yes, this exactly. The fact that I can guarantee that my code is running, and have entire massive teams at Amazon whose literal job title is to keep my code running, it is such a freeing feeling. I might be able to delete rows from Dynamo from my code messing up, but Dynamo will never go offline.
> Dynamo will never go offline.
That's some ridiculous propaganda. AWS has whole regions going down for hours.
Re: The Serverless Revolution Has Stalled
#554Earlier quoted context omitted.
> Software written in any programming language (as long as it targets WASM) is a lot easier to host than existing models. For the past 20 years you have been able to target x86 gnu/linux and have it running without modification on a readily available server, either your own hardware or rented/public cloud. How does switching from one binary format to another (x86 to WASM) change anything (except maybe slowing down yo…
> As I understand it, the main draw of WASM is running non-JS code in a web browser. Simplified deployment + automatic sandboxing? AFAIK with x86 you can't just write a client app and have it automatically run on any computer that visits your website.
Are people reinventing java as if it never existed?
Re: The Serverless Revolution Has Stalled
#555Earlier quoted context omitted.
> It's that it makes that level of code reuse that much simpler. You have all of these helper infrastructure functions that you implement for every single project you work on, and reusing that glue code is so, so much easier in Lambda/GCF/AF/etc. That sounds great until you need to add a feature or fix a bug in the reused code. Then you deploy a change to a Lambda function that impacts X other projects immediately, w…
Lambda has pretty good support for versioning and aliasing so you can control that sort of roll out.
Sure you can do that, and that works ok in some scenarios. But there are some problems.
In a scenario like:
> Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done.
Ok, so you got AWS set up to fire your Lambda when an object is created in an S3 bucket. You decide you need another "stream", we'll call it, so you start dumping stuff into another prefix. How does one go about testing that the right function is invoked?
A smart person will probably say that they have a dev environment and they manage infrastructure with Terraform. Great! That's probably the best solution there is.
But that still leaves a massive, glaring problem: it's quite difficult to implement any sort of automating testing of this Lambda function setup. In all likelihood, you're probably just pushing a file up to an S3 bucket in dev and watching it run through.
Let's say you made a pass at automated testing, and let's continue with the example of creating resized avatar images. The end product of this Lambda resizing process is probably a different file somewhere in S3. So you fire off the automated test and it fails. How did it fail? Well, if you're lucky, the Lambda function actually had an execution that errored out. Then it's up to you, or your automation, to look up logs in CloudWatch to troubleshoot the failure. What if it didn't error out, and instead just put the file in the wrong place?
This kind of stuff is where Lambda falls over. Running Docker images on EC2 in some fashion puts way more sanity around testing as a whole. You have real Docker artifacts that you ran tests in, not just some zipfile abomination that does nothing to create a good local development environment.
Re: The Serverless Revolution Has Stalled
#556This 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…
I've never really understood this argument for serverless. Everything you do in AWS is through an API. I've never quite understood how replacing one set of API calls to provision an EC2 (or ECS cluster) is so much more complicated than another set of API calls to create a severless stack. If anything, my experience has been the complete opposite. Provisioning a serverless stack is much more complicated and opaque.
Re: The Serverless Revolution Has Stalled
#557Earlier quoted context omitted.
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…
How is the spin-up time for such a container?
In my experience pretty good, even for a Django app. I believe the container sticks around for a while and is throttled to 0 CPU.
Re: The Serverless Revolution Has Stalled
#558Earlier 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 don't agree, serverless code in itself tends to be portable. It's the surrounding services that lock you in.
That depends a lot on the use case. The ephemeral nature of serverless environment generally require you to proprietary solutions by the cloud provider to have things like DB access and such. So you end up using DynamoDB instead of Postgres (as an example). You CAN make portable serverless code but it generally requires a fair amount of work to do so.
Re: The Serverless Revolution Has Stalled
#559Earlier quoted context omitted.
I disagree. Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule. If I wanted to run these on Azure or Google only the most inconsequential parts of the function would need to be changed.
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…
Or even worse, giant yaml config files
Re: The Serverless Revolution Has Stalled
#560Earlier quoted context omitted.
You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?
It's a lot easier to change providers, if your service is an (eg.) docker image(s), than to move something relying on amazons api.
It's even easier if your application is just (an equivalent of) a binary, or a tarball.