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

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.

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.

EC2 is a managed solution but you still need to manage servers.

I am curious what made you unsatisfied. As a member of the Serverless team I'd love to hear the feedback so we can potentially improve the experience for you and others.

Shipping value is important. If you can build a solution faster in a monolithic, MVC style framework running on EC2 instances, then do that. I think people get too bogged down in the minutiae up front and forget they are being paid to solve a problem ASAP. Worry about optimisations and improvements when its going to add more value than right up front when the burning need of the business is to have something - ANYTHING - up and running and helping generate revenue.

I have been building JAMstack apps since 2016 using exactly the stack you are asking about. Using something like the Serverless Framework to help you build and deploy your collection of microservice backends into AWS as well as your static frontend into S3 is just awesome to behold. I have had an app running for 3 years with spikes of traffic and have never had to worry about maintenance or downtime.

I am not entirely sure this is correct. There are definitely ways to delete or update data.

Serverless Framework. And you have some choices. You can use the serverless-express component to just get Express deployed into Lambda: https://github.com/serverless/components#serverlessyml

Or you can use the original Serverless Framework. There is a good tutorial in using it right here: https://www.serverless.com/learn/courses/full-stack-applicat...

If you use a tool like the Serverless Framework, you can trigger Lambda functions off of many different events, includinmg a schedule: https://www.serverless.com/framework/docs/providers/aws/even...

I just want to add in about version controlling Lambda code, this is entirely possible using the available tooling with something like the Serverless Framework at serverless.com

Not entirely true. The largest use case we see for Lambda is as the compute service for an API backend provisioned with API Gateway (so a full application backend) with synchronous responses over HTTP (so rapid response provided within milliseconds) and for mundane tasks that store data in a database just like a regular web application.

The perfect use case we see repeatedly is for high volume HTTP requests to API Gateway endpoints that trigger Lambda functions that respond in less than a second depending on what compute is running.

There are an enormous number of people using Lambda's as a part of very complex workloads including customer facing platforms. Your specific use case of 100 000 incoming requests in 20 seconds is actually far more extreme than most users use cases; Lambda can do 3000 instantly and then adds more capacity over time unless you contact AWS and ask them to increase the limits in which it can do a lot more.

There are very many users of Lambda that run very high volume production workloads (billions of requests a month) and save an enormous amount of money doing so compared to traditional techniques. A lot of that saving comes from the ability to create solutions in days as opposed to weeks or even months and the fact that for most use cases the capacity exists to handle the volume most users need.

If anyone is initially fooled by the naming that illusion is broken very quickly after just a few seconds of looking into it so I doubt that this was an intentional act to trick people

Autoscaling is monstrously good on DynamoDB. You can turn on on demand mode so that it will scale up to the sheer limits of DynamoDB itself, but you pay per usage. So if you do want to set some kind of limit based on affordability you can set limits as to how much the tables scale.

As to how that autoscaling performs, its instant and always available so you have nothing to worry about there. Rather spend your time focussed on optimisation of queries than managing the scalability of your datastore which is as it should be.

DynamoDB costs you nothing when its not in use. It only charges based on actual reads and writes performed. As opposed to a traditional Relational database that always has to be on and has to be scaled up vertically to the maximum anticipated load permanently and with a read replica if you really want redundancy.

DynamoDB gives you redundancy out of the box (your tables are replicated across the three availability zones in a region), the scale is available to you if you have sudden traffic in on demand mode or you can set a limit if you wish to manage costs; your queries may receive errors about being throttled at some point if you approach those limits.

For OLTP workloads, DynamoDB (and a lot of other NoSQL-style, cluster based databases) cannot be beat for performance, capacity, scalability and costs. Which is exactly what you want on the front line of a workload that can receive large amounts of traffic.

For OLAP workloads with unknown query patterns across a variable set of data that can change over time and large table scans, a relational database is king because the actual volume of traffic is low but the size of queries are a lot larger usually.

You forget a few things:

1. AWS and other cloud vendors don't have just one data centre per region, they usually have three redundant locations for availability reasons connected via a direct fibre link. 2. Cost of time; time to find hardware, prep hardware, maintain hardware 3. Cost of your agility. If you need more compute capacity, it will take you weeks to get the hardware required and installed, otherwise you need to have unused hardware sitting around "just in case". 4. Cost of your availability. What if you have a sudden spike of traffic within minutes and the current available hardware cannot service it? At least in the cloud you can spin up short lived resources to manage that load before it throttles back down again. 5. Permanent running costs of fixed hardware. A lot of implementations do not need permanent hardware running and can throttle down to a base of almost nothing so the average running cost on a monthly basis is actually very low.

There are organisations with 1000's of services on Serverless seeing enormous benefits in reduced management overhead and reduced costs compared to the Kubernetes solution they previously ran.