AWS
x86 Price $0.0000166667 for every GB-second $0.20 per 1M requests
Arm Price $0.0000133334 for every GB-second $0.20 per 1M requests
DO $0.0000185/GB-second
So basically a little higher price for each GB/s but no cost pr request.
AWS free tier provides 400,000 GB-s and 1 million free requests per month
DO free tier 90,000GB-seconds of usage for free per month
So cheaper in some respects compared to AWS. Google and Azure is roughly the same as AWS.
Also DO include egress which is expensive on AWS (it does not say it cost anything).
The key difference is that unlike lambda where you are charged for network waiting time, Cloudflare from what I can tell, doesn't count time the CPU is suspended for networking operations.
I use a cloudflare worker for DDNS updates, and it runs on the free tier. If the 10ms included network time, my worker would consistently timeout, but it hasn't timed out yet so I must conclude that it doesn't count network time.
This is absolutely correct. I have a worker function that takes ~200ms clock time to execute but most of that is waiting on I/O and doesn’t count against CPU.
Last I checked I think our median is 6ms (against a limit of 50 IIRC) on Workers Bundled.
There's some clarification on the "limits" page [1]:
> Most Workers requests consume less than a millisecond. It is rare to find a normally operating Workers script that exceeds the CPU time limit. A Worker may consume up to 10 ms on the Free plan and up to 50 ms for Bundled Workers on the Paid Plan. The Paid Plan also offers up to a 30 second duration for increased compute time. The 10 ms allowance on the Free plan is enough execution time for most use cases including application hosting.
> There is no limit on the real runtime for a Workers script. As long as the client that sent the request remains connected, the Workers script can continue processing, making subrequests, and setting timeouts on behalf of that request. When the client disconnects, all tasks associated with that client request are canceled. You can use event.waitUntil() to delay cancellation for another 30 seconds or until the promise passed to waitUntil() completes.
My understanding is that you could consume 1/10 ms of CPU time every hour, and your worker would hit the limit only after 100 hours for the free tier. This would also work with the paid plan - bundled, with up to 500 hours. However, this wouldn't work with the paid plan - unbound, as you pay GB-s, which are counted even if the CPU is not used. From the "Duration" part of "Limits":
> Duration is the measurement of wall-clock time. This is measured in Gigabyte-seconds (GB-s). When a Worker is executed, it is allocated 128 MB of memory . As the Worker continues to execute that memory remains allocated, even during network IO requests.
> For example, when a Worker executes via a scheduled event , it executes for four seconds, including network-bound IO time: 4s x 0.125GB (or 128Mb) = .5 GB-s.
There is also a pricing page that's more detailed [2].
Thanks this was the information I was looking for and glad I won't be moving off AWS Lambda anytime soon.
Really puzzling why DO would announce a new product and make it more expensive than incumbents.
Typically, you would want to undercut existing competitors right out of the gate because your competitors will do it for you....by making the first move to reduce their prices, diminishing your own market.
Perhaps there is some other lining here but I don't understand how you launch a serverless hosting and make it more expensive than AWS.
Because they want to be a profitable and cash flow positive company
They don't want to be like most of the other cloud infrastructure companies like Cloudflare that are burning a lot of cash to look cheap. Eventually they will have to increase prices too.
AWS, Azure, GCP get the advantage of having contracts with big technology companies that they can oversell their products too to help make up for the loses they have from basic users. It a lot easier to sell junk to big corporations to increase revenue than it is for DigitalOcean to do the same for SMB and start ups.
Digital Ocean's pricing model lines up more with how I expect serverless to be used. It's cheaper for APIs that are very simple and lightweight, but need to be able to handle infinite traffic. I like it. I think it incentives people to use it correctly.
It's probably more that you don't have to shift from DO to AWS because you wanted to run lambda. Although I'm not sure if this product is (yet) compelling enough to keep you on DO.
As serverless has been gaining traction a lot of users have moved from traditional vps deployments to serverless offerings because it is more affordable for sporadic workloads.
Finally! DO were seriously lagging behind some competitors in the "small, easier, cheaper than the big3" space. Scaleway have had serverless functions and containers ( which is even better because even easier to migrate across providers), message queue for a couple of years now?
Congrats on the work anyways, and let's hope they put out a Container as a Service soon too.
The foundation is Apache OpenWhisk https://github.com/apache/openwhisk with DO specific customization to work with App Platform, managed databases, trusted sources, log shipping, and other DO specific capabilities. The closest programming model is AWS Lambda in terms of the semantics and execution model.
OpenWhisk functions are vendor agnostic and have a generic signature of JSON in and JSON out and no other dependencies. Functions on DigitalOcean may also run functions from Netlify and AWS Lambda (and vice versa). You can run the same functions on IBM Cloud Functions and Adobe I/O runtime. This article from 2020 runs the same code on multiple clouds included self hosted for the curious https://openwhisk.blog/post/advocate/openwhisk-portable-serv....
Yeah, it doesn't seem super usable for anything that might have to deal with external resources that you cannot control, such as databases or HTTP APIs.
Will any sort of scheduled execution be possible with DO Functions? I've been looking for a way to add scheduled tasks (e.g. session cleanup) to DOAP apps.
Thanks! While I've got you here... do you have any insight into the Spaces roadmap? I've been waiting for per-Space permissions for access keys to land to enable me to migrate a bunch of S3 buckets. Thanks again.
Thank you – I'm desperate to even just isolate access to a single space, to replicate what I currently have on S3, so I can multi-tenant my clients' media storage on the Spaces platform.
Waiting for a standardized approach to serverless that lets us just write the code once and deploy to _any_ cloud provider. Right now, all of these products (aws, azure, do, etc) seem to have, at least, slight differences that would make it not possible to switch to another provider without some code changes.
Functions aren't necessarily always used in these kind of overarching structures. React frameworks like next.js use them to simply provide backend endpoints for data and logic. I think that's what they're going for, as an addition to their app platform more than anything else
Given the max execution time of 5s and the max memory of 1GB, it seems like that is exactly what this is. Some endpoints to fetch e.g. data off the database or some processing tasks for a frontend framework, like the functions Vercel or Netlify offer.
The maximum execution duration of 5 seconds seems incredibly short!
The only time I've used "cloud functions" in the past has been for executing complex jobs that may take up to several minutes. For this, cloud functions has been very useful and easy to scale.
Functions through app platform are fully managed and deployed with zero downtime and offer roll backs as well. Deployments from the CLI are fast enough you can enable watch-mode and continuously deploy as you code in your IDE.
Cold starts depend on runtime and size of the function and an area of continuous improvement (for all cloud providers).
-- "Serverless Business Unit at DigitalOcean" -- i see a lot of "enterprise lingo" around digital ocean these days - are they still the best "individual developer focused" provider? --
I'd say Yeah. I use and pay for their Apps platform for a few personal projects. Its cheap (like $5/mo/app). It reminds me enough of Heroku that I'm happy. The built-in CI is kind of slow. But it just works and requires relatively low configuration, especially when compared to AWS/GCP/Azure.
There are simpler, more specialized products, but I think DO strikes a really good balance. For example, I've hosted static sites on Cloudflare Pages, which is a solid product, but its also rather unconfigureable; I was running into issues with their built-in CI even using a static site generator which wasn't on their supported list.
Yeah, seems like they changed a lot recently (since they're on NYSE). I feel like they are transitioning away from the "for developers" cloud, to more like a "to be" Heorku or AWS/Azure/GCP cloud.
Welllllllll... don't forget that Linode had grown very stagnant, and had no desire to cut prices, until DigitalOcean came along and forced the issue. Once DO showed up, Linode suddenly had to produce nice tooling and $5/mo VM's.
I don't think that would have happened otherwise, and I'd be really surprised if Linode doesn't follow DO's price increases within a few months.
Not really saying this as a DigitalOcean evangelist or anything. It's just that business is business.
Absolutely agree! Never put a company on a pedestal! But IIRC Linode has had a long history of decreasing prices by adding better specs to existing plans, not sure how that will change with their acquisition. Just keep in mind to build portable apps and avoid lock in.
Serverless has been kinda out of reach of non-enterprise but has a lot of promise for individual developer experience. There's no add'l vendor lock in if you use serverless platforms for typical (mini-)monolith deployments such as django+postgres
I am a DO customer despite the cost being a little higher for my purposes than AWS. I like their UI, their email reminders, their pricing transparency, and their support.
I switched to DO from Linode a long time back for something that was relatively minor in hindsight, but I've never not been happy with the change.
A handful of firms now doing this, same sort of serverless/workers thing, makes me hesitant to be bullish on certain players like CF, Netlify, Vercel, whatever other sort of 'up n comers'. If they're all offering it, the value of one over another goes down drasically. Yeah yeah, vendor lock in, it's fine, people have options and will stay where they want, but some of the big value propositions from these firms over the last year or so has been heavily focused on this aspect of the service feels like. Is it just a case of 'there's lots of business to go around' maybe?
Serverless computing is the future of cloud computing with more and more infrastructure management shifted to the provider rather than internal infra and ops teams. It isn't to say it's all or nothing, and it is a long enduring transition which is why the DigitalOcean integration between Functions and App Platform is differentiated related to some of the other vendors you mention. You don't have to choose between serverfull (containers, servers, kubernetes even) and serverless -- functions, and entirely managed services like CDNs, load balancers, containers that scale from 0 to N, SSL cert management, automatic build and deploys, rollbacks, API gateways, object storage ... and managed serverless key-value stores and databases.
So functions is really table stakes for a cloud, as are events, scheduled and background functions. You've seen this play out with every cloud provider since the arrival of AWS Lambda. Our goal is to make it scale, make it cheap, and make it secure with DigitalOcean developer simplicity and so you are right, a corner stone of this endeavor is the developer experience and integration with cloud services because a cloud application consumes all of these services. As these become core competencies for a cloud, the integrations between all the services only get better and deliver more value to the customer.
I shared a few details above - with the implementation backed by a mature open source project, there are lots of details available already. Thanks for bringing this up though so we can focus on the parts of interest to the community as we roll out more technical documents on the product.
I recently learn about this term, so can someone be kind enough to explain to me ELI5 serverless usage[0], advantages over "traditional" servers and why I should/could care?
[0] by usage I mean, I still deploy my monolithic app, or just one function per route?
Some people go monolithic app but best practice is usually one function per route.
Traditional servers come with management overhead (e.g. defining/managing/monitoring scaling) and by using Serverless servers you avoid that overhead and optimize for good engineers which are almost always your bigger cost center.
With traditional server you keep your webserver running all the time and keep paying for the underlying infrastructure whether irrespective of actual usage.
You can still spawn more instances/containers on demand and autoscale but you need to think about provisioning and how that affects your cost.
With serverless the costing maps directly to usage and scaling is (ostensibly) taken care of for you.
If you have long running workloads that anyways need preallocated infrastructure and forward planning, you likely don't gain much from serverless. If your work can be split into smaller units of executions that can be invoked on-the-fly independently, you will likely benefit from serverless pricing.
We use AWS lambda for running slower background tasks triggered from a user action on a website (eg. generating a report, clearing and rebuilding a cache, etc...).
We deploy our full monolithic app to lambda (as a docker image) and then just have a wrapper entrypoint script that dispatches the request to the appropriate module and function.
There are benefits to keeping each lambda function small but we like the benefit of deploying one lambda and being able to call any function within the monolith.
To a certain extent, serverless actually delivers on the "No sysadmins required" promise that EC2 doesn't really enable (someone still has to manage your EC2 herd's configuration, even if you call that person a "devops engineer").
The lock-in part is increasingly untrue. Esp. if you are on gcloud, your functions are not tied to their infra at all. Eg. For nodejs you are just writing express middlewares with no real gcloud infra dependency. You can also use their build packs to run and test the functions locally. gcloud serverless infra is also built on knative so if you have teams with k8s familiarity you can run them on in-house infrastructure.
For AWS lambda I believe it was initially true, but now I believe they also support running arbitrary containers.
The costs more part is very much subject to nature of use case. If you have a lot of small services that are invoked once in a while you can benefit from serverless pricing.
The code for the functions is vendor agnostic. Vendor lock-in comes from the integrations the code that runs in the cloud ends up consuming, and the developer experience one acquires. The nature of cloud development is that one invariably becomes an expert in a cloud or stack, and that's the real lock in / why it's expensive to move in practice.
Digital Ocean is great for spammers because Digital Ocean does not care to be a good internet citizen. Being a good internet citizen would be too expensive, so DO just throws up its hands and does nothing about its spamming customers.
Uhm, you just sounded like an add for DO here: "DO won't randomly shut down your account because they guess you might be doing something fishy like spamming"
...and don't tell me you don't get "spam" from AWS users. Only GCP is doing more policing, but as a dev I'd be wary of using them of fear of being labeled "suspicious" because some weirder scraping usage patterns or whatever.
The subject here is Digital Ocean. Yes, I get spam from seemingly all providers. However, AWS takes action and DO does not. DO will simply pass my complaint on to the spammer and my problem becomes worse.
I've setup a rule to simply drop mail from DO IP addresses, no legit mail ever comes from DO.
Sending a spam complaint to DO will do nothing more than verify to spammers that you are a good target.
If DO wants a better reputation then they can earn one.
> DO will simply pass my complaint on to the spammer
Again, as a DO customer I want to be able to see any complains fired against me. Point in plus for them from the perspective of a potential customer.
...you seem to misunderstand what the desired attributes of a cloud provider are. Besides at most having marginally more spam in the world, how you seem to say the ideal cloud provider should behave is really worse for everyone. You're playing a "oh but think of the children" argument but with "spam" recipients instead of the children so it's hard to have any sympathy for such malicious reasoning.
Shrug. So anyway, since most of us use 3rd party services to send emails, using DO is perfectly fine. Whatever.
(And if the extra profit they get from hosting spammers results in slightly lower prices for me then I'm glad to profit. It's about sending spam, not firing missiles or dropping bombs. Again, whatever.)
> (And if the extra profit they get from hosting spammers results in slightly lower prices for me then I'm glad to profit. It's about sending spam, not firing missiles or dropping bombs. Again, whatever.)
Its fine if you want to watch the world burn for your own benefit. Not all of us do care to see that.
Obviously there are tradeoffs involved in using containers. But aside from that, they also don't typically get you platform independence by themselves unless you also choose not to use any other cloud features (e.g. object storage, queues, IaaS, "serverless" features like DO Functions or Lambdas, key management services, IAM-type services, etc.).
In my experience, it's building for the cloud as a platform vs targeting a pre-cloud infra that ties you to a particular cloud. You can obviously DIY all of that in your own containers, but then you're making a choice to invest in infra instead of buying it.
Arm Price $0.0000133334 for every GB-second $0.20 per 1M requests
DO $0.0000185/GB-second So basically a little higher price for each GB/s but no cost pr request.
AWS free tier provides 400,000 GB-s and 1 million free requests per month
DO free tier 90,000GB-seconds of usage for free per month
So cheaper in some respects compared to AWS. Google and Azure is roughly the same as AWS. Also DO include egress which is expensive on AWS (it does not say it cost anything).