8 ms·

Saving Hundreds of Hours with Google Compute Engine Per-Minute Billing

138 points by izzym 11y ago

gegtik 11y ago
Wait till you try per-100ms billing on AWS Lambda
- jdcarr 11y ago
  We don't know their memory usage but if they use 1.5GB then they'll get 70 hours/month free from Amazon when using lambda [1], and it gets better from there depending on their usage. But seeing as most of their work last less than an hour, I wonder how well they'd done to take advantage of the spot market. Does anyone know of any tools that take advantage of the spot market? I know that Spark does [2]. [1] https://aws.amazon.com/lambda/pricing/ https://aws.amazon.com/lambda/pricing/ [2] http://spark.apache.org/docs/latest/ec2-scripts.html http://spark.apache.org/docs/latest/ec2-scripts.html
  - manishsharan 11y ago
    I have always been curious as to how to use the spot market. If I were to get a Ec2 on the spot market, how do I ensure that my task gets completed before being prempted? Mt batch jobs take anywhere between 10 ~ 20 minutes. I there a minimum guaranteed time that I could buy? For my solution , I ended up using Google cloud and its minute billing.
    - vosper 11y ago
      I lot of my infrastructure runs on the spot market. If you launch an individual machine there's no guarantee that at any time it won't be pre-empted (terminated). You do a little time to handle graceful shutdown of your code before the machine goes away, so it's not like the plug was pulled out at the wall. If you're using Spot Fleets (a new feature) AWS will take a spec of the compute capacity you want and find it for you, across different instance types and availability zones, which makes it more likely you'll get the capacity you want. In practice spot machines are pretty stable. We run hundreds across several different instance types and they're often up for weeks at a time. So unless your batch job absolutely must not be delayed you might give spots a go. We used to run critical analytics EMR (Hadoop) jobs on spots and it saved us a a fortune - probably hundreds of thousands of dollars. Very occasionally we would switch them to on-demand (automatically) if we couldn't get spots at the price we wanted.
      - vgt 11y ago
        Have you looked at Google's Preemptible VMs? The big difference is that it's a flat 70% off fee, rather than a volatile market, and Google has relatively few but versatile VM types, which makes it easier to architect infrastructure (ex. no need for a high-IO VM or a high-network VM.. just attach a high-IO disk to a regular VM and networking is world-class).
        vosper 11y ago
        We're heavily integrated into the rest of the AWS system, it wouldn't be worth the engineering effort. Also, the spots don't make up a large enough portion of our overall AWS spend, if we wanted to save money there are other things we could do that would let us stay on AWS (which we like).
    - zbjornson 11y ago
      You can do block request for one hour or more of guaranteed run time, but you pay for that guaranteed minimum run time. Otherwise you have to build in checkpointing and recovery. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#fixed-duration-spot-instances http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requ...
    - darkr 11y ago
      AWS launched spot blocks last year that does just this. It's not as cheap as regular spot instances, but you do get a guarantee that your instance will be around for a configurable period between 1 and six hours (you pay more as you approach the six hour mark), after which time it will be automatically terminated. I guess this is useful for longer-running batch jobs (longer than the 2 minute warning you get of termination on regular spots) of a relatively known duration. https://aws.amazon.com/blogs/aws/new-ec2-spot-blocks-for-defined-duration-workloads/ https://aws.amazon.com/blogs/aws/new-ec2-spot-blocks-for-def...
      - boulos 11y ago
        Combined with per-minute billing and our lower on-demand pricing, regular GCE instances often end up being cheaper. For example, a fixed duration m3.medium is currently $.037/hr for 1 hour and $.047/hr at 6 hours. GCE's equivalent n1-standard-1 is $.05/hr all the time (and automatically triggers sustained use discounts). If you ask for a 4-hour block and only use 3.2 hours you pay the same 16 cents as you would have on GCE. As I tell my friends, if you want a cheap, guaranteed VM just use GCE on-demand; if you're locked into AWS though, check out Spot! Disclaimer: I work on Compute Engine (and Preemptible VMs specifically), so I'm clearly biased.
- zbjornson 11y ago
  Except Lambda is quite expensive. Compared to equivalent EC2 t2 instances, Lambda is 4.6x the cost of on-demand, or ~20x of spot instances. I really don't understand why anyone would use it for a high-volume web app. For low-volume sites you have the advantage of not paying for idle time, but the inflection point is somewhere around 13 minutes per hour.
  - fndrplayer13 11y ago
    Lambda is great though at handling services that see unpredictable spikes of traffic throughout the day where its difficult to provision quickly. Its also really good at reducing machine-management issues where your software doesn't utilize resources very well on a given machine. While its a bandaid on writing well-designed scalable software, it does allow you in the interim to take somewhat inflexible software and scale parts of it independently of physical machines. edit: To clarify, I mean if you're running software that does something on a given set of physical machines and you cant get job throughput higher than some number, n, on a given machine it can be prohibitively expensive to scale machines ahead of time or during load. With Lambda we have the option to run a ton of independent processes on theoretically independent machines to vastly increase throughput while we slog through improving our design to improve per-machine throughput on our legacy EC2 infrastructure. Lambda allows you to isolate your scale problem to 1 job per container at a time instead of looking at machines as capable of only `n` jobs at a time.
mark_l_watson 11y ago
The author makes a good point. Many years ago I was crunching (doing NLP analysis) on parts of the Twitter firehose (or sometimes just the garden hose) on Amazon Elastic Map Reduce. EMR was a fantastic service that made getting work done much easier. However, I was always trying to game the system by having my runs end in just less than one hour, which was a nuisance. Per minute billing would have made my life easier.
obulpathi 11y ago
Google Cloud wins big on simplicity and ease of use. That can save lot of developer time. Here is the article that I am writing on "Ease of use comparing Google vs AWS": https://docs.google.com/document/d/1B5XUiQUClxdoFpl2Md5MZOv642StuOW0ULvfIkgOE1I/edit?usp=sharing https://docs.google.com/document/d/1B5XUiQUClxdoFpl2Md5MZOv6... Any feedback is welcome. Citing from OP on ease of use with Google Cloud: > Over the past couple of years, I’ve never struggled to grasp or understand any of the GCE offered services. The predefined machine types are also very clear, shared core, standard, high memory and high CPU, I know them all by heart now with their memory configurations and pricing to some extent. I clearly understand the difference between the IOPS for a standard disk and an SSD disk and how the chosen size impacts their performance. There is no information overload, disk pricing and other information is kept separate, it’s simple and easy to understand. Now compare this with EC2 VMs, it’s overwhelming, current/previous, etc… generation VMs. Disk information and network configurations all lumped together with VM configurations, paragraphs and paragraphs of different price configurations. For me, it was painful just trying to understand which VM type is suitable for my needs. My first encounter with SSD configurations and maximum provisioned IOPS for AWS RDS was one of pain. Instead of spending time working on my project, I found myself spending valuable time trying to select which IaaS offerings best fit my needs. Things like trying to figure out if low to moderate or high network connectively is best for my needs!. No wonder I still hear many say they find Cloud offerings confusing!, I think this is no more with GCP.
- izzym 11y ago
  Very structured and lots of meaningful analogies. I didn't know that AWS had so many storage services!. And you are right AWS console feels like a marketing dashboard, so far I've only ever clicked on 3 icons, never looked at the other 30 or so
- gcb0 11y ago
  i think it's mostly historical baggage. as soon as gce gets as old as aws, the offering variations they have to offer for historical contacts and what so ever will be as confusing as aws today
  - 11y ago
scott_s 11y ago
This is a great analysis, but I'm missing some basic background. Do all of the other cloud providers charge per-hour? Do people typically design their applications around this pricing model, or ignore it and eat the cost?
- zbjornson 11y ago
  AWS rounds up to the nearest hour. Azure is by the minute. Not sure about the other smaller providers.
homageyellow 11y ago
Awesome.
nickbauman 11y ago
Can anyone spot a dateline on this article?
- AnkhMorporkian 11y ago
  Well, the URL signifies that it was published today.
- ranit 11y ago
  Archives -> March 2016(1) links to this article http://omerio.com/2016/03/ http://omerio.com/2016/03/
vgt 11y ago
When it comes to Big Data, per-minute billing + rapid startup is significant. When you can have a 10,000-core Hadoop cluster in 45 seconds, you stop thinking about it in terms of clusters and start thinking about it in terms of jobs. Before: Start cluster > submit many jobs to the cluster > manage resources Now: Submit a job to Dataproc > Start a cluster for each job > shut down the cluster And, of course, BigQuery gives you the equivalent of per-second billing and 0-second scaling to thousands of cores: https://cloud.google.com/blog/big-data/2016/02/understanding-bigquerys-rapid-scaling-and-simple-pricing https://cloud.google.com/blog/big-data/2016/02/understanding...
- izzym 11y ago
  BigQuery is well and truly amazing, zero upfront setup or infrastructure. You ur Query & BigQuery that is it
- chimerasaurus 11y ago
  In addition, you can also use preemptibles and custom VM machine types (specify the exact ratio of CPU/RAM you want for master + workers) for your clusters. This gives even more control for cost vs resources. Disclaimer - I work at Google, on Cloud Dataproc (and we are passionate about making the Spark/Hadoop ecosystem both super fast, but also extremely cost effective) :)
fpgaminer 11y ago
Wow, I never realized that Google offers per-minute billing. We have a video decoding, encoding workload, and it has been a major pain point handling it on AWS. Decoding/Encoding 4K video requires quite a bit of beef, with a hefty minimum memory requirement on the order of 3+ GB for h264 encoding. Less if you use ultrafast preset, but then you pay for larger files and larger egress. So, we can spin up a beefy EC2 (c4.8xlarge or larger) for each video, and get them handled quickly, but we get charged for the full hour which is quite expensive. All the machines we would target for spot instances have had very rocky pricing lately, so that often doesn't save much. We could spin up less beefy instances, trying to encode/decode in ~1 hour so as to maximize economy, but then, obviously, each video takes much longer to process. Lambda would be an okay solution, approximately double the price of equivalent EC2 solutions, while providing two very big wins: granularity and 5 minute encoding/decoding time regardless of video size/length. That second point is pretty insane; we could process an entire 4K movie in 5 minutes by unleashing a swarm of Lambdas on it. The problem is that Lambdas have a max memory of 1.5GB which isn't enough for 4K encoding (h264). Also they have limited disk space, so it's challenging to get frames and video in-out (and no FUSE module in the kernel :/). We're still experimenting, but even if we do get it to work it will probably be with the ultrafast preset, which is non-ideal. Elastic Transcoder doesn't handle decoding/encoding, only transcoding, so its a no-go. We thought to use it in a larger pipeline, like have lambdas sew frames up into a lossless codec, then hand that to Elastic Transcoder to be compressed. But ET won't encode 444 formats, and it incurs the cost of both a lambda swarm and ET, so that's not great. Per-minute billing would be ideal. Now I have to consider whether it's worth it to port everything over to Google. Oh how I wish these companies didn't use ludicrous egress pricing to enforce vendor lock-in.
- vgt 11y ago
  Your story is exactly the story of Atomic Fiction: https://cloudplatform.googleblog.com/2015/10/Atomic-Fiction-walks-The-Walk.html https://cloudplatform.googleblog.com/2015/10/Atomic-Fiction-...
- dookahku 11y ago
  > and no FUSE module in the kernel FUSE typically has a lot of latency for context switches, or so I under stood it. Is it possible to make a native driver?
ak217 11y ago
Amazon should definitely be feeling the pressure from Google on this. Per-hour billing has always been a pain to manage for offline/batch workloads. If you're interested in leveraging advanced cost-saving techniques on AWS compute and storage, we're currently building something in the cloud HPC space that does exactly this. Nothing public yet, but email in my profile for more. Our system automatically manages elastic fleets of instances and right-sizes instances to their workloads (including spot and lambdas), and also makes it easy to reduce TCO on storage. It's agnostic in terms of deployment (hosted vs. bring-your-own-VPC).
jedberg 11y ago
I'm seeing a lot of folks here talking about how to-the-minute billing would save them so much money on Amazon, but I think you're not thinking about the problem correctly. If you want to build for scalability, then it's best to separate the jobs from the machines. Having one job per machine isn't granular enough. It's best to have a farm of machines that can take jobs and process them, and then scale the farm if the jobs aren't processed fast enough. (Incidentally this is what Lambda does for you) If you do that, then once you have enough jobs to fill a single machine, to-the-minute billing doesn't really save you much money, if any, and you're then on a path to much better future scalability.
- chimerasaurus 11y ago
  I think it depends on the use case and service. As a disclaimer, I work for Google on Cloud Dataproc - a managed Spark and Hadoop service. So, I am passionate and focused on Spark clusters from 3 CPUs/3GB ram to 5k+ CPUs and TBs+ of RAM. If you are running Spark (or Hadoop, Pig, Hive, Kafka, etc.) jobs than per-minute billing can save you quite a bit. Unless you can seperate your jobs over time (and balance them) to keep n clusters saturated, you're probably paying for an idle Spark/Hadoop cluster to sit around. Moreover, in terms of Cloud Dataproc (only) that's why you can scale clusters up/down, use preemptibles, and custom machine types. You can custom shape your clusters and pay for exactly what you use (disclaimer - there is a 10 minute minimum like most Google Cloud services.) As a practical example, if you have a 100 node Spark cluster and only use 25 minutes of it, you can stand to save considerably in a given year. Yes, you can possibly rebalance your work internally to saturate a cluster at the optimal n minutes but at that point, you're paying to do the engineering work for it. :)
  - Eugr 11y ago
    ... and with some use cases you just can't saturate the cluster 24/7. For instance, if you have to run ad-hoc computational jobs. Not every use case revolves around customer-facing websites or processing streaming data...
    - chimerasaurus 11y ago
sergioocon 11y ago
I would love to see how you automate the full cycle, not only spinning new instances
jononor 11y ago
Heroku charges per second of compute, with no minimum. Using AMQP with https://github.com/the-grid/guv https://github.com/the-grid/guv our average server stays up for just couple of minutes, directly in proportion to current demand

138 points by izzym 11y ago

gegtik 11y ago

Wait till you try per-100ms billing on AWS Lambda

jdcarr 11y ago
We don't know their memory usage but if they use 1.5GB then they'll get 70 hours/month free from Amazon when using lambda [1], and it gets better from there depending on their usage. But seeing as most of their work last less than an hour, I wonder how well they'd done to take advantage of the spot market. Does anyone know of any tools that take advantage of the spot market? I know that Spark does [2]. [1] https://aws.amazon.com/lambda/pricing/ https://aws.amazon.com/lambda/pricing/ [2] http://spark.apache.org/docs/latest/ec2-scripts.html http://spark.apache.org/docs/latest/ec2-scripts.html
- manishsharan 11y ago
  I have always been curious as to how to use the spot market. If I were to get a Ec2 on the spot market, how do I ensure that my task gets completed before being prempted? Mt batch jobs take anywhere between 10 ~ 20 minutes. I there a minimum guaranteed time that I could buy? For my solution , I ended up using Google cloud and its minute billing.
  - vosper 11y ago
    I lot of my infrastructure runs on the spot market. If you launch an individual machine there's no guarantee that at any time it won't be pre-empted (terminated). You do a little time to handle graceful shutdown of your code before the machine goes away, so it's not like the plug was pulled out at the wall. If you're using Spot Fleets (a new feature) AWS will take a spec of the compute capacity you want and find it for you, across different instance types and availability zones, which makes it more likely you'll get the capacity you want. In practice spot machines are pretty stable. We run hundreds across several different instance types and they're often up for weeks at a time. So unless your batch job absolutely must not be delayed you might give spots a go. We used to run critical analytics EMR (Hadoop) jobs on spots and it saved us a a fortune - probably hundreds of thousands of dollars. Very occasionally we would switch them to on-demand (automatically) if we couldn't get spots at the price we wanted.
    - vgt 11y ago
      Have you looked at Google's Preemptible VMs? The big difference is that it's a flat 70% off fee, rather than a volatile market, and Google has relatively few but versatile VM types, which makes it easier to architect infrastructure (ex. no need for a high-IO VM or a high-network VM.. just attach a high-IO disk to a regular VM and networking is world-class).
      - vosper 11y ago
        We're heavily integrated into the rest of the AWS system, it wouldn't be worth the engineering effort. Also, the spots don't make up a large enough portion of our overall AWS spend, if we wanted to save money there are other things we could do that would let us stay on AWS (which we like).
  - zbjornson 11y ago
    You can do block request for one hour or more of guaranteed run time, but you pay for that guaranteed minimum run time. Otherwise you have to build in checkpointing and recovery. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#fixed-duration-spot-instances http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requ...
  - darkr 11y ago
    AWS launched spot blocks last year that does just this. It's not as cheap as regular spot instances, but you do get a guarantee that your instance will be around for a configurable period between 1 and six hours (you pay more as you approach the six hour mark), after which time it will be automatically terminated. I guess this is useful for longer-running batch jobs (longer than the 2 minute warning you get of termination on regular spots) of a relatively known duration. https://aws.amazon.com/blogs/aws/new-ec2-spot-blocks-for-defined-duration-workloads/ https://aws.amazon.com/blogs/aws/new-ec2-spot-blocks-for-def...
    - boulos 11y ago
      Combined with per-minute billing and our lower on-demand pricing, regular GCE instances often end up being cheaper. For example, a fixed duration m3.medium is currently $.037/hr for 1 hour and $.047/hr at 6 hours. GCE's equivalent n1-standard-1 is $.05/hr all the time (and automatically triggers sustained use discounts). If you ask for a 4-hour block and only use 3.2 hours you pay the same 16 cents as you would have on GCE. As I tell my friends, if you want a cheap, guaranteed VM just use GCE on-demand; if you're locked into AWS though, check out Spot! Disclaimer: I work on Compute Engine (and Preemptible VMs specifically), so I'm clearly biased.
zbjornson 11y ago
Except Lambda is quite expensive. Compared to equivalent EC2 t2 instances, Lambda is 4.6x the cost of on-demand, or ~20x of spot instances. I really don't understand why anyone would use it for a high-volume web app. For low-volume sites you have the advantage of not paying for idle time, but the inflection point is somewhere around 13 minutes per hour.
- fndrplayer13 11y ago
  Lambda is great though at handling services that see unpredictable spikes of traffic throughout the day where its difficult to provision quickly. Its also really good at reducing machine-management issues where your software doesn't utilize resources very well on a given machine. While its a bandaid on writing well-designed scalable software, it does allow you in the interim to take somewhat inflexible software and scale parts of it independently of physical machines. edit: To clarify, I mean if you're running software that does something on a given set of physical machines and you cant get job throughput higher than some number, n, on a given machine it can be prohibitively expensive to scale machines ahead of time or during load. With Lambda we have the option to run a ton of independent processes on theoretically independent machines to vastly increase throughput while we slog through improving our design to improve per-machine throughput on our legacy EC2 infrastructure. Lambda allows you to isolate your scale problem to 1 job per container at a time instead of looking at machines as capable of only `n` jobs at a time.

mark_l_watson 11y ago

The author makes a good point. Many years ago I was crunching (doing NLP analysis) on parts of the Twitter firehose (or sometimes just the garden hose) on Amazon Elastic Map Reduce. EMR was a fantastic service that made getting work done much easier. However, I was always trying to game the system by having my runs end in just less than one hour, which was a nuisance. Per minute billing would have made my life easier.

obulpathi 11y ago

Google Cloud wins big on simplicity and ease of use. That can save lot of developer time. Here is the article that I am writing on "Ease of use comparing Google vs AWS": https://docs.google.com/document/d/1B5XUiQUClxdoFpl2Md5MZOv642StuOW0ULvfIkgOE1I/edit?usp=sharing https://docs.google.com/document/d/1B5XUiQUClxdoFpl2Md5MZOv6... Any feedback is welcome. Citing from OP on ease of use with Google Cloud: > Over the past couple of years, I’ve never struggled to grasp or understand any of the GCE offered services. The predefined machine types are also very clear, shared core, standard, high memory and high CPU, I know them all by heart now with their memory configurations and pricing to some extent. I clearly understand the difference between the IOPS for a standard disk and an SSD disk and how the chosen size impacts their performance. There is no information overload, disk pricing and other information is kept separate, it’s simple and easy to understand. Now compare this with EC2 VMs, it’s overwhelming, current/previous, etc… generation VMs. Disk information and network configurations all lumped together with VM configurations, paragraphs and paragraphs of different price configurations. For me, it was painful just trying to understand which VM type is suitable for my needs. My first encounter with SSD configurations and maximum provisioned IOPS for AWS RDS was one of pain. Instead of spending time working on my project, I found myself spending valuable time trying to select which IaaS offerings best fit my needs. Things like trying to figure out if low to moderate or high network connectively is best for my needs!. No wonder I still hear many say they find Cloud offerings confusing!, I think this is no more with GCP.

izzym 11y ago
Very structured and lots of meaningful analogies. I didn't know that AWS had so many storage services!. And you are right AWS console feels like a marketing dashboard, so far I've only ever clicked on 3 icons, never looked at the other 30 or so
gcb0 11y ago
i think it's mostly historical baggage. as soon as gce gets as old as aws, the offering variations they have to offer for historical contacts and what so ever will be as confusing as aws today
- 11y ago

scott_s 11y ago

This is a great analysis, but I'm missing some basic background. Do all of the other cloud providers charge per-hour? Do people typically design their applications around this pricing model, or ignore it and eat the cost?

zbjornson 11y ago
AWS rounds up to the nearest hour. Azure is by the minute. Not sure about the other smaller providers.

homageyellow 11y ago

Awesome.

nickbauman 11y ago

Can anyone spot a dateline on this article?

AnkhMorporkian 11y ago
Well, the URL signifies that it was published today.
ranit 11y ago
Archives -> March 2016(1) links to this article http://omerio.com/2016/03/ http://omerio.com/2016/03/

vgt 11y ago

When it comes to Big Data, per-minute billing + rapid startup is significant. When you can have a 10,000-core Hadoop cluster in 45 seconds, you stop thinking about it in terms of clusters and start thinking about it in terms of jobs. Before: Start cluster > submit many jobs to the cluster > manage resources Now: Submit a job to Dataproc > Start a cluster for each job > shut down the cluster And, of course, BigQuery gives you the equivalent of per-second billing and 0-second scaling to thousands of cores: https://cloud.google.com/blog/big-data/2016/02/understanding-bigquerys-rapid-scaling-and-simple-pricing https://cloud.google.com/blog/big-data/2016/02/understanding...

izzym 11y ago
BigQuery is well and truly amazing, zero upfront setup or infrastructure. You ur Query & BigQuery that is it
chimerasaurus 11y ago
In addition, you can also use preemptibles and custom VM machine types (specify the exact ratio of CPU/RAM you want for master + workers) for your clusters. This gives even more control for cost vs resources. Disclaimer - I work at Google, on Cloud Dataproc (and we are passionate about making the Spark/Hadoop ecosystem both super fast, but also extremely cost effective) :)

fpgaminer 11y ago

Wow, I never realized that Google offers per-minute billing. We have a video decoding, encoding workload, and it has been a major pain point handling it on AWS. Decoding/Encoding 4K video requires quite a bit of beef, with a hefty minimum memory requirement on the order of 3+ GB for h264 encoding. Less if you use ultrafast preset, but then you pay for larger files and larger egress. So, we can spin up a beefy EC2 (c4.8xlarge or larger) for each video, and get them handled quickly, but we get charged for the full hour which is quite expensive. All the machines we would target for spot instances have had very rocky pricing lately, so that often doesn't save much. We could spin up less beefy instances, trying to encode/decode in ~1 hour so as to maximize economy, but then, obviously, each video takes much longer to process. Lambda would be an okay solution, approximately double the price of equivalent EC2 solutions, while providing two very big wins: granularity and 5 minute encoding/decoding time regardless of video size/length. That second point is pretty insane; we could process an entire 4K movie in 5 minutes by unleashing a swarm of Lambdas on it. The problem is that Lambdas have a max memory of 1.5GB which isn't enough for 4K encoding (h264). Also they have limited disk space, so it's challenging to get frames and video in-out (and no FUSE module in the kernel :/). We're still experimenting, but even if we do get it to work it will probably be with the ultrafast preset, which is non-ideal. Elastic Transcoder doesn't handle decoding/encoding, only transcoding, so its a no-go. We thought to use it in a larger pipeline, like have lambdas sew frames up into a lossless codec, then hand that to Elastic Transcoder to be compressed. But ET won't encode 444 formats, and it incurs the cost of both a lambda swarm and ET, so that's not great. Per-minute billing would be ideal. Now I have to consider whether it's worth it to port everything over to Google. Oh how I wish these companies didn't use ludicrous egress pricing to enforce vendor lock-in.

vgt 11y ago
Your story is exactly the story of Atomic Fiction: https://cloudplatform.googleblog.com/2015/10/Atomic-Fiction-walks-The-Walk.html https://cloudplatform.googleblog.com/2015/10/Atomic-Fiction-...
dookahku 11y ago
> and no FUSE module in the kernel FUSE typically has a lot of latency for context switches, or so I under stood it. Is it possible to make a native driver?

ak217 11y ago

Amazon should definitely be feeling the pressure from Google on this. Per-hour billing has always been a pain to manage for offline/batch workloads. If you're interested in leveraging advanced cost-saving techniques on AWS compute and storage, we're currently building something in the cloud HPC space that does exactly this. Nothing public yet, but email in my profile for more. Our system automatically manages elastic fleets of instances and right-sizes instances to their workloads (including spot and lambdas), and also makes it easy to reduce TCO on storage. It's agnostic in terms of deployment (hosted vs. bring-your-own-VPC).

jedberg 11y ago

I'm seeing a lot of folks here talking about how to-the-minute billing would save them so much money on Amazon, but I think you're not thinking about the problem correctly. If you want to build for scalability, then it's best to separate the jobs from the machines. Having one job per machine isn't granular enough. It's best to have a farm of machines that can take jobs and process them, and then scale the farm if the jobs aren't processed fast enough. (Incidentally this is what Lambda does for you) If you do that, then once you have enough jobs to fill a single machine, to-the-minute billing doesn't really save you much money, if any, and you're then on a path to much better future scalability.

chimerasaurus 11y ago
I think it depends on the use case and service. As a disclaimer, I work for Google on Cloud Dataproc - a managed Spark and Hadoop service. So, I am passionate and focused on Spark clusters from 3 CPUs/3GB ram to 5k+ CPUs and TBs+ of RAM. If you are running Spark (or Hadoop, Pig, Hive, Kafka, etc.) jobs than per-minute billing can save you quite a bit. Unless you can seperate your jobs over time (and balance them) to keep n clusters saturated, you're probably paying for an idle Spark/Hadoop cluster to sit around. Moreover, in terms of Cloud Dataproc (only) that's why you can scale clusters up/down, use preemptibles, and custom machine types. You can custom shape your clusters and pay for exactly what you use (disclaimer - there is a 10 minute minimum like most Google Cloud services.) As a practical example, if you have a 100 node Spark cluster and only use 25 minutes of it, you can stand to save considerably in a given year. Yes, you can possibly rebalance your work internally to saturate a cluster at the optimal n minutes but at that point, you're paying to do the engineering work for it. :)
- Eugr 11y ago
  ... and with some use cases you just can't saturate the cluster 24/7. For instance, if you have to run ad-hoc computational jobs. Not every use case revolves around customer-facing websites or processing streaming data...
  - chimerasaurus 11y ago

sergioocon 11y ago

I would love to see how you automate the full cycle, not only spinning new instances

jononor 11y ago

Heroku charges per second of compute, with no minimum. Using AMQP with https://github.com/the-grid/guv https://github.com/the-grid/guv our average server stays up for just couple of minutes, directly in proportion to current demand