151–160 of 670 posts
That abstraction should allow you to develop serverful, and allow you to go serverless with minimal effort.
Because serverless is not serverless. Fundamentally this doesn't work because if you've gotta have a server in the end, why not either admin yourself or use one of the cloud vendor's other products for more control?
It's a silly term, but successful. If anything, arguing against it made it more successful through mere repetition of the word.
Issues we had in our adopting it: I like the term "nano services" is it probably the wrong term. But I like it. We went monolith -> micro services -> micro services + nano services Everything that adds complexity in a micro service system, adds far more complexity with nano services. Debugging and tracing is a nightmare. And yes, logging, a lot of logging and instrumentation helps. But if you add too much of it then…
Earlier quoted context omitted.
> Serverless provides a solution for that case as well, since you have almost unlimited resources. Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic. Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.
multiple seconds?? what platform?
In my eyes, the bigger problem with many FaaS products (which most equate with serverless) is the barrier to entry. The setup isn't very user friendly. The code doesn't "just work" like it does locally. Limitations on data size, runtime, etc. cause you to building workarounds in your scripts just to get them running. Not to mention that once you have it all set up, visibility into everything running is a nightmare and only available to the most technical users.
Based on my experience, I'm currently building a [platform](https://www.shipyardapp.com) to try and make serverless data pipelines easier for teams to setup and manage. Would love to hear someone else's perspectives on serverless setups for data management. I know I'm not alone on these existing frustrations.
I am still on the serverless high, and I don't see it going away any time soon. For the large corporation that I work for, things like soc2, patching, server maintenance, etc. are a giant pain every single month. The quicker we switch as many things as possible to serverless the better. One of the services I converted over went a year and a half with absolutely no attention from our engineers. It was great seeing how…
How does moving to 'serverless' change the need for patching and other security maintenance? You've just moved it to a server owned by someone else. Sounds more like passing the buck rather than ensuring security.
So for example, if we have a service deployed in an EC2 instance, we have to update the instance(s) every month by a certain date. Sometimes, we have to update early if there is a severe security issue. We also have to manage things like security software that has to run on every instance, logging for soc2 compliance, access controls, manage ssh keys, etc. etc.
That's a lot for our engineers to handle every single month. A lot of context switching. It's not so bad if we only have one service to manage. But the actual issue is that we have many services to manage. So every month, our board had about 12 stories related to patching. Patch service X development. Patch service x staging. Patch service x production. Patch service Y development.... and so on.
For serverless, the team responsible for SOC2 compliance gets the reports from AWS without us ever having to do anything. No patching stories, no security software that breaks on occasion, no access management, etc.
All we have to worry about in terms of SOC2 compliance are the basics like principle of least privilege (i.e. lambdas do not have full access to DynamoDB), no public endpoints, we use VPCs blessed by the security team, and that's about it. Things we're used to doing everywhere else and things that we only worry about when writing the terraform.
Now when I add a Lambda, I only worry about writing the Python code for the lambda and copying the terraform code. That's it. There is no patching story for this service.
And yes, of course we're passing the buck. That's kinda what we pay for in the premiums that AWS gets from our massive bill every month. That's kind of the entire point for cloud-based systems, anyway. We're passing the buck on a ton of other things, like not having to manage hard disks, not having to manage network cables, not having to manage a building, not having to manage HVAC, not having to manage backup batteries, etc.
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
I used to be complain about the same thing and even asked someone who was head of BD for Serverless at AWS what they recommended, and didn't get an answer to my satisfaction. After working with more and more serverless applications (despite the development pains, the business value was still justified) I realized that local development was difficult because I was coupling my code to the delivery. This is similar to t…
Of interest, I've spent some free time crunching on CNCF survey data over the past few months. Some of the strongest correlations are between particular serverless offerings and particular delivery offerings. If you use Azure Functions then I know you are more likely to use Azure Devops than anything else. Same for Lambda + CodePipeline and Google Cloud Functions + Cloud Build.
Earlier quoted context omitted.
> Serverless provides a solution for that case as well, since you have almost unlimited resources. Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic. Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.
We happily connection pool using sequelize by leveraging the fact that lambdas run in reusable containers. If the next lambda invocation happens within minutes of the previous one ending, you can carry forward a db connection from the older lambda, no magic needed. Just place your db connection object in global scope (nodejs).
Now if you somehow get a spike of requests to some endpoint that goes over your DB connection limit, suddenly all your newly scaled functions fail because they cannot get a connection to the database.
AWS added a service for RDS to deal with this, but it all just feels like a big kludge to deal with a problem that shouldn’t have to exist in the first place.
As a data guy, I've have an entirely different perspective on serverless. While it may not work well for running entire parts of an application, it works great for building out and managing internal data pipelines. You don't want your pipelines crashing because your jobs overlapped and you ran out of memory/cpu on the servers you set up. You want each stage of the pipeline to run independently and scale as needed. In…
Batch jobs can't exceed 15 minutes. Memory limit is 3GB. Payload sizes are 256kb max.
If you are used to batch processing large amounts of data, Lambda seems to be the exact opposite of this. I think it is good for "small data, highly concurrent event processing" but this is a very different use case from batch processing data pipelines.
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
Have you tried Amplify?