garethmcc

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

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.

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.

This happened to me once and AWS entirely reversed the charges no questions asked. And its really something you don't need to worry about. AWS makes more than enough money off of legitimate traffic they don't need to deny someone asking for a refund for a genuine mistake.

And playing around with Serverless is awesome. Things can be created rapidly and very little maintenance. These days I cannot see myself building an application without at least some element of Serverless infrastructure if not the entire solution.

Hi tdfirth. I am with the team at Serverless, Inc, creators of the Serverless Framework. I can totally understand the frustration, especially with new development architectures such as serverless.

Over the years of building serverless applications there are some unique differences in building them compared to traditional applications you build entirely locally then "throw over the wall" to be run on a server somewhere. And for this reason there are many teams and organisations working to make the developer experience better, including making deployments to the cloud to test easier and faster. Unlike mainframes of old, new code can be deployed in seconds and logs available in less than that when testing invocations of your Lambda functions. For example, the Serverless Framework has a command to deploy just the code changes of a Lambda and does so in seconds. There are other tools that do similar.

Its a really broad topic to get into but am more than happy to do so if you wish or have any specific questions I can help you answer. If its easier to ask privately feel free to do so

And I would just like to leave saying that I am a proponent of serverless development not because I happen to work for a company bearing the name, but because I sincerely think its the future. They just happened to spot that and asked me to join them.

Oh yes, and serverless is not just Lambda, its a about the whole suite of cloud services you combine together to build your solution.

This is not entirely true. Firstly because Lambda keeps getting cheaper with the move from per 100ms billing to pwe 1ms being a big contributor. but also that I see organizations handling millions of requests per hour at peak but because of the dynamic nature of Lambda, any cost increase during the peaks are entirely offset by the reduced cost during low traffic periods since Lambda and associated services cost $0 when its doing nothing. Add in other services that act the same way such as S3, DynamoDB, API Gateway, etc and you have a very powerful, redundant and scalable applications without even really trying. No to mention that because spinning things out is so quick you can get a feature in front of users earning revenue way faster than any traditional service that requires some effort to start up, configure and maintain. And the costs associated with having VM's of the right size up to handle peak loads that are much slower to ramp up and down, creating significant periods of over provisioned capacity you pay for.

Lambdas are not slow to boot because of the methods used to tune how hot they stay; in a production application doing millions of invocations a day we saw 0.03 % of all invocations suffering a cold start that added an additional 100ms latency only. And if you absolutly have to have warm Lambdas always for even that 0.03% you can use provisioned concurrency that always keeps a certain number of Lambda functions warm.