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.
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.
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.
Its not as simple as that. Just because its the case of "we have lots of old stuff" doesn't mean you need to ignore the new stuff. Building solutions with traditional data centers and staff, even if you have a lot of it, is often a lot slower. You can spin up entire fleets of servers (or even use services such as AWS Lambda, API Gateway and DynamoDB so you never use servers) and get a solution out in much less the time. Its not just about responding to load but also to be fast enough to get new stuff out there. Traditional financial services organisations are notoriously slow to adapt to changes in the market. Using cloud resources alongside the legacy infrastructure is one way to try and remain competitive.