7 ms·
I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serve
by aeturnum 6y ago
I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution.
As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these environments have difference performance, cost and maintenance characteristics, but I think of the star feature of serverless as the light deploy. For companies that don't have a deploy chain, that makes serverless very attractive, but if you've already invested in one it seems less compelling.
I think serverless products have a ton of potential for side projects and hobby projects. It's great that you can just type out python and access it on the internet immediately! That quality just never seemed to be what was holding back SAAS companies.
- mobilefriendly 6y agoPart of the problem is that the hobbyist market is overwhelmingly PHP, which Lambda doesn't support natively.
- colinbartlett 6y agoI’d be curious to see the data behind that claim that the hobbyist market is overwhelmingly PHP. I must not have any exposure to that ecosystem because PHP does not come to mind when I think of hobbyist development.
- lhorie 6y agoMaybe not hobbyists, but wordpress alone powers like a a third of the web.
- robertlagrant 6y agoSure, but Wordpress is nothing to do with PHP lambdas.
- lhorie 6y agoYes, that's kind of my point :)
- deleted 6y ago[deleted]
- rupertdev 6y agois it, though? Every person I know with side projects writes them in either nodejs/ + react/vue or django/flask + react/vue/templates
- spyridonas 6y agoIn my workplace our main product is written in PHP. Still we have a bunch of Lambda functions written in node we use all the time
- ceejayoz 6y agoNot natively, but fairly easily. We’re using Laravel Vapor - it handles all the setup and deployment of Lambda bundles that include the app code and a PHP runtime. Smooth and fast so far.
- lostcolony 6y agoYeah; I'd imagine anyone technically savvy enough to use Lambda + API Gateway, in any form, is savvy enough to bundle PHP if they really want to use it. And if they're not savvy enough to do that, they're probably using hosted Wordpress somewhere and it's a moot point.
- fennecfoxen 6y agoAnother niche where it shines is the small, low-volume tool. You don't want to give it an entire VM, because that's a major waste. You don't want to have it share one "tools box," because it is awkward sharing like that, security becomes more of an issue, and it generally devolves into a mess. So if you've got other things running on AWS, then AWS Lambda is great for this. Do you need a random web-facing snippet to receive a webhook a few times a day and send a Slack message to your team? Perfect. Not the core of your app, but a tool of great utility. On the other hand, this isn't exactly the Serverless Revolution either.
- ryanmarsh 6y agoThis is why Serverless will be huge in enterprise IT. You just described 90% of workloads.
- viraptor 6y agoI use that a lot. There's the joke lambda spackle sticker (https://www.thecloudpod.net/product/lambda-spackle-sticker/ https://www.thecloudpod.net/product/lambda-spackle-sticker/) but that's exactly the great use case.
- jbrodley 6y agoThanks for mentioning our Lambda Spackle sticker. :-) Just throw a little lambda at all your op problems.
- jacques_chester 6y agoI called it "dabs of glue", usually in the context of warning against going crazy with the glue gun.
- superfrank 6y agoI'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable. If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution, it probably won't be able to bring new servers up in time. Serverless provides a solution for that case as well, since you have almost unlimited resources. But yeah, serverless is a tool for solving a certain set of problems. This idea of the "Serverless Revolution" was kind of silly from the start
- viraptor 6y agoTo be honest, the serverless environments I dealt with had worse deploy experience than plain servers. There's a bit of a ritual around deploying a lambda for example and it requires a specific packaging process. I can't easily use poetry for python projects there. I guess if we count fargate as serverless, it's much better for this use case.
- takeda 6y agoWhile I am not that big fan of serverless projects (I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) you can use poetry with lambda. I'm sure there are other ways of doing it, but the way I do it is using serverless framework (is a nodejs app) together with serverless-python-requirements plugin. The plugin understand poetry (make sure you don't leave requirements.txt because it will use that, you don't need that file if you use poetry). Anyway it has warts, one big thing is that nodejs developers don't care about norms and standards and constantly reinvent the wheel so for starters you're pretty much forced to create project.json project-lock.json files, which then will create node_modules directory in root of your project. Then you need to start project through npx command (I believe you could still install serverless globally but looks like that's being depreciated). The node_modules directory will contain over 200MB of javascript code after you install it. But after all of those things, when you get it to work it is not terrible.
- leptons 6y ago>(I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) I've created a whole photo sharing website in AWS Lambda, including a complete user accounts system (register, login, forgot password, email verification, profile photos, etc), social aspects, as well as other things like youtube video search and transcoding in the same system. I also had to create my own Lambda build system because what was out there wasn't what I wanted. I wanted to be able to hit save on a file and have it repackage my Lambda on AWS (using a Lambda to create the lambda) including shared code in 'Layers'. Kind of a "live-reload" for Lambda. It's all working very efficiently. This was a lot of effort though, but now that I've got a basic system I can extend it to any kind of website. My photo sharing site for friends costs me about $0.25 every few months, and that is mostly/all the cost of storing gigabytes of photos on S3. No, it doesn't see a lot of traffic, and that's exactly why I chose Lambda to build this site on, because I don't have to run an EC2 instance for my photo sharing site 24/7 if nobody is using it. It's worked out exactly how I wanted, costs me practically nothing to run every year. And, if I did build a system with a ton of active users, Lambda handles the scaling of that. Another reason I spent the time to create this build system and write all the code to handle user accounts, etc.
- linuxdude314 6y agoServeless platforms like AWS Lambda are great for "glue" between services, or for workloads that are used infrequently. It can also be a great replacement for scripts that need to be run via a cron job (its surprisingly hard to create a highly available idempotent cron system using servers) provided all of the dependencies fit in the small space allotted. I'm not sure I understand your point about not needing a deployment chain. I developed a framework (open sourcing it soon) using Jenkins Pipeline DSL for deploying Lambda functions and its very useful and helpful. Regardless of the target environment the reasons for using a deployment pipeline are still there even if you use a server less platform.
- cle 6y agoAmong other reasons, enterprises love serverless b/c it relieves them of many server maintenance costs and risks. This includes things like: - OS patches and emergent fixes - Compliance certification - SSH access control and auditing - Secret distribution - Log rotation and storage - TLS termination - Configuring and testing auto-scaling policies - Deployment configuration (rolling deploys, blue/green deployments, connection draining, etc.)
- Aeolun 6y agoThey can do the same thing with fargate, and that’s tons easier to manage.
- AWebOfBrown 6y agoFargate is considered a serverless service. Serverless generally encompasses FaaS + BaaS. Think anything whose infrastructure you can use without touching the underlying VM(s): SQS, SNS, EventBridge, RDS, Lambda, Fargate, Athena, Kinesis and so on.
- deleted 6y ago[deleted]
- iends 6y agoFargate is still pretty expensive.
- tupputuppu 6y agoYou don't need serverless for that. Any PaaS such as heroku provides those benefits.
- cle 6y agoI'm not really interested in having the 1,000th discussion about the definition of "serverless". The parent was wondering what the value of the paradigm is, so I provided a list of specific features that many companies consider valuable with serverless offerings.
- GordonS 6y agoOne serverless scenario I find useful is for processing messages from low-volume queues. It avoids having to stand up "real" infrastructure that would be under-utilised. Of course, if you already have servers with something like k8s or Swarm running, you might deploy a container there instead.