DigitalOcean Functions: A powerful serverless computing solution
digitalocean.com
digitalocean.com
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).
or is this so much more convenient to pay a bit more and stay on DO?
Free tier is 100 000 requests per day
Here's the pricing page: https://workers.cloudflare.com/#plans
Not much of a room here it seems. AWS still offers more generous CPU time.
In fact any price move by new entrants can be countered by AWS going forward.
So AWS users benefit from not moving. Simply wait for others to reduce their prices and expect AWS to do the same.
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.
Last I checked I think our median is 6ms (against a limit of 50 IIRC) on Workers Bundled.
> 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].
[1]: https://developers.cloudflare.com/workers/platform/limits/
[2]: https://developers.cloudflare.com/workers/platform/pricing/
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.
Also, they may be charging their best profitable/break-even rate right now, working on the product to get cheaper over time or with scale.
Basically, I challenge the implication that one should not enter a market unless they are cheaper than the competition.
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.
Congrats on the work anyways, and let's hope they put out a Container as a Service soon too.
5 second max function duration? Cloudflare is unlimited and AWS is 15 minutes.
https://docs.digitalocean.com/products/functions/details/lim...
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.
Nothing to build serious architectures with.
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.
I hope DO can consider increasing this limit.
How long does it take to deploy an update? Are updates rolling/zero-downtime?
Cold starts depend on runtime and size of the function and an area of continuous improvement (for all cloud providers).
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.
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.
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.
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.
Will you be transparent about how it works, such as when a function is frozen? This is something I miss with many Aws services
[0] by usage I mean, I still deploy my monolithic app, or just one function per route?
2. It locks you in to a certain vendor
3. It costs more
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.
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.
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.
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.
...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.
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.
(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.
You should take a look at Verizon's 2022 Data Breach Investigation Report. https://www.verizon.com/business/resources/reports/dbir/2022...
https://www.verizon.com/business/resources/reports/dbir/2022...
"82% of breaches involved a human element"
"66% of breaches involved Phishing, Stolen credentials and/or Ransomware."
So glad to hear that you want to support Business Email Compromise. https://www.fbi.gov/scams-and-safety/common-scams-and-crimes...
We'll see how much you shrug when it happens to you.
> 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.
Single infrastructure code dies and the author can't usually save it
Ask a heroku fan how they're feeling right now before moving forward with any single host approach
Having all your code platform agnostic isn't really a viable option unless you've got budget to spare.
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.
Of course it is
Just fine? Fly.io has a fairly seamless automated migration at https://fly.io/launch/heroku ; my Heroku apps are quite portable.
https://www.digitalocean.com/community/conceptual_articles/h... shows a pretty similar approach to Lambda - they just invoke a function with a handler. You could run the same handler on AWS Lambda or Cloudfront's workers, probably without any changes.