The difference is that the model is based on usage not seats and revenue is going to be shared with builders of extensions used by users of the framework (80% of the revenue) to help grow the serverless ecosystem
The "bankrupt your company with the wrong keystroke" is not entirely accurate. AWS does work with companies (or even individuals) if they genuinely made an error that wracked up a huge bill. Personally they have dropped bills of $1000's when I made a bone headed mistake and have seen companies get $100 000's of bills credited due to the same issue. They are not in the business of ripping people off in the short time who would spend a lot more than that in the long term.
I have watched almost all those talks as they are technically dense and full of very good and very useful technical knowledge that I would be much poorer for not watching. These are not sales videos but highly complex instructional content meant for developers on the ground
Have you looked at the recent crop of Serverless rechnologies that rtuly abstract away even considering the underlying hardware platforms. I am talking about tools such as Serverless Cloud where you write code and it infers the hardware needed underneath and creates it for you automatically. https://www.serverless.com/cloud
I have worked with many teams and found lambda to be by far more cost effective. Did your calculations include the time lost waiting to deploy solutions while infrastructure gets spun up, the payment for staff or developers spending time putting infrastructure together instead of building solutions, the time spent maintaining the infrastructure, the cost of running servers at 2am when there is no traffic. Perhaps even the cost of running a fat relational database scaled for peak load that needs to bill you by the hour, again even when there is no traffic.
Serverless as an architectural pattern is about more than just Lambda and tends to incorporate a multitude of managed services to remove the cost of managment and configuration overhead. When you use IaC tools like Serverless Framework that are built to help developers put together an application as opposed to provisioning resources, it means you can get things up fast and ready to bill you only for usage and that scales amazingly.
Funnily enough, I have made almost the opposite experience.
In my experience IAC and serverless bring all the troubles of dev ops to „regular“ developers. Your plain vanilla mid-level full stack dev now needs to understand not only a bunch about FE & BE code, but also a much bigger bunch about servers, networking, VPCs, etc. than in a non-serverless setup.
How do you resolve this in your projects? (Serious question).
This is such a big problem for some of the projects that they are now only able to hire senior develops (which brings it‘s own set of problems).
But VPCs and networking and distributed computing aren't serverless. Serverless is using AWS Lambdas or GCP functions and not dealing with VPCs beyond having an endpoint to hit.
There's not getting around the networking and such - that's the full part of full-stack (FS) - it's more than simply FE+BE. Maybe call them distributed systems engineers instead.
What it sounds like though, is your organization (regardless of what we call it) is large enough to organize into FE, BE, and FS roles, with FS running the platform and being in charge of the fleet and for them to work on the system itself so that FE and BE can work without having to know about fleet - and FS folk are building internal tools that the rest of the org use to do their job, and to shield them from any of the implementation details your fleet has.
Again though on my framwork-ification point -- in our case, we have a full VPC setup, and jets actually allocates the VPC for us we just configure it in our application.rb file. I'm sure the serverless framework has something similar. Either way, we have gotten away with not having a dedicated devops person or persons because of how much the framework does for you.
Yeah, framework-ification of this process has been the real differentiator in the last 5 years that has taken lambda from being obtuse and glitchy to work with to quite a joy if you just lean on your framework.
All of that said, I vastly prefer google cloud functions personally and would switch to that in a heartbeat if they had capabilities like API gateway but it's not there yet.
I also regret that there isn't a better cross-cloud solution currently, but that's something I have a lot of open source ambitions about creating soon. I don't like serverless that much so stay tuned for something from me in the coming years, probably in Rust.
This is where using a tool like the Serverless Framework helps solve a lot of these problems:
- Use async/await promises instead and the specific plugin for the Serverless Framework for configuring your Step Functions makes it easy!
- Nothing specific here but just call it hat makes sense.
- Use your runtimes dependancy management tool. NPM for Node for example
- Just us "serverless remove" (you used "serverless deploy" to set them up)
- No need for the console with the Serverless Framework
- Use Serverless Framework. Literally 3 lines of yml configuration and you are done. https://www.serverless.com/framework/docs/providers/aws/even...
The dev cycle can be super fast. I have never before built stuff so quickly. Using "serverless deploy function -f functionName" means I can push my code changes into the cloud in 3 seconds for testing purposes so need to even setup local testing environments which can get very complex and be totally inaccurate compared to the environment that exists in AWS
I agree somewhat, but its a little more nuanced. Right up front, you could absolutely get infrastructure setup yourself using things like EC2 etc that would eventually be cheaper when traffic gets high enough but there this does not take into account a few things:
1. The cost of paying the professionals to get this all up and running
2. The delay in getting solutions out to customers to generate revenue since the dev team needs to wait for infrastructure to be spun up first.
3. Ability to handle spikes in traffic. Traditional VM and even container based architectures can take minutes to spin up new infrastructure in response to sudden traffic spikes.
And the comment about "the bills go through the roof" aren't 100% true either. AWS isn't sitting around trying con you into spending all your money. If they were they wouldn't have:
1. Reduced the price of AWS Lambda multiple times since launched
2. Switched from billing for AWS Lambda in 100ms increments to per ms increments, saving everyone using a lot of money.
3. Developing an alternative v2 solution to API Gateway that is faster, easier to use and cheaper per request than API Gateway v1 was.
4. Constantly bringing prices down for all services such as S3, SNS, SQS, etc.
And if you happen to be a high volume user, one chat to your account representative and you get very generous volume discounts across the board, saving you even more.
FaaS has been remarkably good for many companies with very late stage products running with very large numbers of users for a very long time. The speed of development even in a mature product and the much lower maintenance overhead make FaaS (or rather serverless) applications a very compelling way for teams to get solutions out fast and cheap over a long term and with very large user bases. This is after designing, building and working with dozens of teams to build serverless applications using Lambda and many other AWS services since 2016
Non-relational databases match one of the largest use cases that exist; large volume OLTP workloads. Non-relational databases typically can handle far more load on reads and writes than relational databases due to their intrinsic distributed structure, meaning that if you have any kind of transactional workload, for example, a frontend to a busy store (such as Amazon.com), non-relational databases are incredible. You can also back these frontend non-relational stores with relational ones but at much smaller scale in order to handle the OLAP requirement where relational databases shine, allowing for massively flexible queries when needing to pull data for reporting etc.
No disagreement from me. Relational doesn’t address every business requirement, nor do non-relational databases. They have enough overlap that you have to make an informed decision from experience.
The SQL vs. NoSQL debate got framed early on in terms of better and worse, old vs. new, which is unfortunate because it created ideological camps. Not every supposedly new thing is better than the old thing. Some NoSQL techniques predate relational databases, but no one younger than 50 has experience with what we did before Oracle and DB/2.
Choice of tools should match the requirements, not fads or anecdotes or personal preferences (or ignorance).
Not to mention that that same infrastructure you say is in abundance is usually pretty heavily utilised already so there isn't just spare capacity lying around. Procuring new hardware can take months and if there is no rack space you are looking at more months to get that deployed.
The people that need to plan, coordinate and install all of this are also pretty heavily overworked at the moment because, believe it or not, there is a very large shortage of skilled sys admins in the world.
Using the cloud doesn't solve those problems, but it does help reduce their impact.
