Cloud, Why So Difficult?

> Assuming you're being serious, the advantage of the cloud is scalability, avoiding managing hardware, reliable power, and reliable network.

Or in reality, it's weird transient failures you can't debug, and unexpected bills for some asanine reason. And scalability sure seems like something to avoid until you actually need it (as in the demand on the site is large enough, not that your performance is so bad you can't handle traffic).

Obviously I can be more cavalier with my uptime, as it is a personal server.

While I don't disagree entirely, I feel like you're misrepresenting what they're offering. Their language is an attempt at simplifying orchestration and application code. The diagram you're showing only proves that point - that's an AWS diagram, and the code on the same page is what creates it:

    bring cloud;

    let queue = new cloud.Queue(timeout: 2m);
    let bucket = new cloud.Bucket();
    let counter = new cloud.Counter(initial: 100);

    queue.addConsumer(inflight (body: str): str => {
      let next = counter.inc();
      let key = "myfile-${next}.txt";
      bucket.put(key, body);
    });

If they can deliver on their promise, it's actually promising. (I haven't evaluated it; just taking things at face value)

We decided to use DynamoDB as a cache for our expensive-to-compute statistics from the data warehouse so we can show them to users without putting a big read load on the data warehouse. DynamoDB scales really well right? And big statistics tables don't belong in the main app database. I'll build the statistics in our postgres data warehouse and use a little ruby script I wrote to push them from postgres to Dynamo with batch_write_item, shouldn't take long.

After spending a couple of days in terraform (I'm no infra expert) creating roles to assume, cross account permissions, modifying my script to assume those roles, figuring out the ECS run-task api syntax and some other things I'd rather forget about I kicked off the jobs to copy the data and left for the weekend. Sunday cost alert email put that thought out of my head: I just spent 8k USD on writing 2 billion rows to two tables because I misunderstood how Dynamo charges for write units. I thought I was going to spend a few hundred (still a lot, but our bill is big anyway) because I'm doing batch write requests of 25 items per call. But the dynamodb pricing doesn't care about API calls, it cares about rows written, or write capacity units, or something. OK, so how do we backfill all the historical data into Dynamo without it costing like a new car for two tables?

Apparently you can create new dynamodb tables via imports from S3 (can't insert into existing tables though) for basically no money (the pricing is incomprehensible but numbers I can find look small). Now I just need to write my statistics to line delimited dynamodb-flavored json in S3 (statements dreamed up by the utterly deranged). You need to put the type you want the value to have as the key to the value you see. A little postgres view with some CTEs to create the dynamodb-json and use the aws_s3.query_export_to_s3 function in RDS Postgres and I had a few hundred GB of nice special-snowflake json in my S3 bucket. Neat!

But the bucket is in the analytics account, and I needed the dynamo tables in the prod and staging accounts. More cross account permissions, more IAM. Now prod and staging can access the analytics bucket, cool! But they aren't allowed to read the actual data because they don't have access to the KMS keys used to encrypt the data in the analytics bucket.

OK, I'll create a user managed KMS key in analytics and more IAM policies to allow prod and staging accounts to use them to decrypt the data. But the data I'm writing from RDS is still using the AWS managed key, even after I setup my aws_s3_bucket_server_side_encryption_configuration in terraform to use my own managed key. Turns out writes from RDS to S3 always use the S3 managed key, no one cares about my aws_s3_bucket_server_side_encryption_configuration. "Currently, you can't export data (from RDS) to a bucket that's encrypted with a customer managed key.". Great. So I need to manually (yes I could figure out the aws api call and script it I know) change the encryption settings of the files in S3 after they've been written by RDS to my own custom key. And now, 4 hours of un-abortable dynamodb import jobs later, I finally have my tables in prod and staging in DynamoDB.

Now I just need to figure out the DynamoDB query language to actually read the data in the app. And how to mock that query language and the responses from dynamo.

At least I'm learning a lot...

Downvoted? Really?

I don’t think you deserve a downvote but I can give you my take having worked at a lot of places that did their own infra as well as cloud.

You don’t need to physically rack servers, lots of systems integration vendors and remote hands will gladly put servers together for you. Most colos will gladly help you figure out connectivity. And there are lots of vendors, like Cisco, who will deliver a rack to your datacenter with virtualization software installed and everything, plug and play..

My point is there isn’t an either/or choice of using the cloud or building the universe from scratch, there are so many available options in-between. And while those options aren’t available conveniently behind an API and might require a few old school phone calls, you can save millions of dollars, get access to better performing hardware, have better control over data sovereignty, and 90%less lock-in if you choose to go down that road. It’s not for everyone but a /lot/ of workloads that people are running in the cloud can be done better elsewhere.