Thread by @QuinnyPig

This evening I'm going to attempt to get @awscloud Fargate working in a sandbox account.

My overly ambitious task: to run the hello-world container from Docker hub inside of Fargate. How hard could it be?

Oh and I'm using the web console.

We begin with a primer on wtf the terminology all means.

We'll select "custom."

Attempt 1. We'll see how it goes. I clicked into "Advanced container configuration" and realized that it made the EC2 console look like LightSail for Kids by comparison. Yikes. Let's NOPE out of there.

It's created some defaults for me that I can edit.

The task definition name of 'first-run-task-definition' is at least 80th percentile as far as @awscloud naming goes.

I 've given it a better name.

The network mode is awsvpc or awsvpc, but it's presented as if I can change it.

Same story with the Task Execution Role and Compatibilities.

Next we get to define the service. Note the borderline-error message at the bottom, because to the folks who build the AWS console anything that isn't a webapp is a bug.

The webapp they've built is a distributed system of bugs.

Now I have to name a "cluster" which in Fargate I don't manage.

I can't wait to see how @awscloud manages to shove sixteen Managed NAT Gateways into this somehow.

And now we wait as if for a CloudFront distribution update.

Unlike a CloudFront distribution update, we're already done.

I'd like to use the remaining space in this tweet to point out that Black lives matter. If that bothers you, or you feel the need to "well but" in response, do me a favor and block me immediately.

Okay, and now I'm gazing into something complicated. Let's poke around.

There is a cluster, containing a service.
That cluster isn't really modifiable in any real way.

Inside of that service, there is a task.

That task uses Fargate 1.3.0. Knowing little else about Fargate, I know that the current version is 1.4.0 because of course it is. I choose to suppress this knowledge for my own sanity.

Despite this being the simplest possible use case for Fargate, there are no running tasks. I look at Stopped tasks looking to see this task and I see it.

Eight separate times.

The bright red STOPPED looks an awful lot like an error.

We click into one to explore further. Yeah, that looks error-like.

This isn't exactly a tiny screen, but the entire word "STOPPED" can't be expanded apparently.

Wait. There's a LOT of "not configured" nonsense there--but exit code 0 means it's reporting as having exited correctly.

Where is the output, then? I can think of a host of places I would like and expect it to be, so let's go to the absolute last one on my list and click the "View logs in Cloudwatch" link.

I'm trained by now to ignore the "try our latest CloudWatch thing / redesign / feature" banner--and there we have it. It's working as expected.

It's continuing to run every minute. It takes less than a second to run, but each invocation is billed for a full minute because somebody at @awscloud wants a bigger boat.

A cursory exploration of the console shows no obvious way to say "run once. When it exits 0, stop it."

I open a ticket with @awscloud to solve this.

If you were to do this, you would click to the support tab and fill out a form. It would get escalated after a bit, and you'll get a response. The @awssupport folks are incredible, but I hate process.

Here's what I do instead.

Hey @mndoci! How the heck do I tell Fargate that when a task completes successfully, that's it; show's over; go home? Seems like it should be a lot simpler than it is...

Now, Deepak is the @awscloud VP of Compute Services. He didn't build this, and the answer is going to come from someone within his org.

The difference is that while you open a ticket and wait for escalation, I annoy the VP and get a delegation instead. Obnoxious, but faster.

While I await his pager to go off ("SEV 2! THAT TWITTER BOZO IS AT IT AGAIN!"), let's talk about what I would change about this process.

The entire point of Fargate, from my mind, is to abstract infrastructure away. Referencing this as "a cluster" is adding needless complication to the first run experience. Yes, there are oh so very many knobs and dials I can turn--maybe put them in an "advanced mode?"

There we go. I told you my way was faster! @awscloud VPs don't sleep; they wait.

https://twitter.com/mndoci/status/1266572559685791744?s=20

I delete the service, then edit the task definition. It warnss me that I need to change it from "Capacity Provider strategy" to "launch type."

I have to manually select a subnet, then I whack "Run Task."

It provisions, runs, and ends. Okay--awesome! This is what I was after!

Unlike those slackers over at the Fargate competitor CodeBuild, Fargate has a "scheduled task" option.

Oh my stars they even have a DEFAULT of "how often to run this" instead of "how's your cron syntax, jackwagon?"

Part of me wants to think it's customer obsession, but the darker part of my nature understands that instead it's to avoid having to use CloudWatch Events to invoke a Lambda function. The Container partisans will cede no ground to the Serverless heretics in this war!

Now, how would I fix this to avoid having to bug people of vast but not limitless patience?

First, I freely admit to having read no docs. That makes me a bad Quinnypig, but an incredibly typical customer. You can hate me, but I'm everywhere.

Secondly, back here in the FirstRun walkthrough of sorts? All four of those definitions look like webapps--but an awful lot of things I and real customers run aren't.

Giving an option to go down that path, or even explicitly stating in that diagram that the Service is an option, not a requirement, would be a big win.

"Just give the docker syntax for `library/hello-world` and the public Docker hub will work" was a bit of a gamble. It paid off, fortunately.

At every step I felt like I was skating on the edge of disaster. Not going to lie: it made me feel stupid, and that in turn made me feel defensive and angry.

If it were me, I'd capture a free-range user somewhere and bundle them to a user experience lab. This experience is covered in the fingerprints of "the people who built the onboarding are *too* familiar with the product."

As is a perennial request, I'd love it if this would also spit out "here's the CloudFormation / Terraform / CLI to build the thing you just stumbleclicked your way through."

Now to hunt down what needs to be deleted. In a welcome change of pace, check this out:

That CloudFormation stack contains all of the subnets, VPCs, security groups, etc. that this system created. It doesn't leave its detritus scattered across the account.

I really, really like this.

This is an excellent point.

The problem that brought me to this thread tonight is "I have a task in a container that needs to run once a day. For various reasons Lambda isn't suited to it."

Maybe my issue isn't what Fargate has in mind?

https://twitter.com/ThatSMP/status/1266577277510471681?s=20

Other minor things: I already complained about the pricing bits. I'd love it if everything this CloudFormation stack (and task definition, etc) built also had optional tags that could be propagated throughout. There's no Fargate free tier; I want to know what this cost.

Maybe there's a simpler angle to Fargate that doesn't go through the EKS / ECS path. "Orchestration" means a lot of things that go far beyond "take this container and run it once a day with the following execution role."

Same primitives, streamlined onramp for the use case.

Oh ho ho we're not done.

The @AWSCloudFormer team wants in on this punchfest!

At least it gives me a link. Now let's see what broke.

Oh AWS networking.

Going in and manually deleting the VPC took less time than writing this tweet did.

Other things I'd want to do:

* Pass parameters to a task from Parameter Store to invoke the Docker container with different arguments
* Task retry logic. "Run this thing three times, then DLQ it for me."