where do you keep the ECS service/task specs and how do you mutate them across your stacks?
How long does it take to stand up/decomm a new instance of your software stack?
How do you handle application lifecycle concerns like database backup/restore, migrations/upgrades?
How have you supported developer stories like "I want to test a commit against our infrastructure without interfering with other development"?
I recognize these can all be solved for ECS but I'm curious about the details and how it's going.
I have found Kubernetes most useful when maintaining lots of isolated tenants within limited (cheap) infrastructure, esp when velocity of software and deployments is high and has many stakeholders (customer needs their demo!)
Not sure if this is a rhetorical question but I'll bite :-)
> where do you keep the ECS service/task specs and how do you mutate them across your stacks?
It can be defined in CloudFormation, then use CloudFormation Git sync, some custom pipeline (ie. github actions) or CodePipeline to deploy it from github
You can also use CodeDeploy to deploy from Git or even a AWS supplied github action for deploying a ECS task.
> How long does it take to stand up/decomm a new instance of your software stack?
It really depends on many factors, ECS isn't very fast (I think it's on purpose to prevent thundering herd problems).
> How do you handle application lifecycle concerns like database backup/restore, migrations/upgrades?
From what I learned from AWS is that ECS is a compute service and you shouldn't persist data in ECS.
Run your database in RDS and use the supplied backup/restore functionality
> How have you supported developer stories like "I want to test a commit against our infrastructure without interfering with other development"?
If it's all defined in CloudFormation you can duplicate the whole infrastructure and test your commit there.
Yeah, that doesn't really answer the question at all...
Do you just have a pile of cloudformation on your desktop? point and click? tf?
And then none of the actual questions like
> How do you handle application lifecycle concerns like database backup/restore, migrations/upgrades?
There is no difference between cloudformation, clicking, terraform, boto, awscli, pulumi, or whatever else. The platform at the other end of those tools is still ECS.
Backing up databases isn't the job of the container-running platform (ECS), especially not in AWS-world where databases are managed with RDS.
The rest of the questions were "how do I run containers on ecs?" in various forms. The answers to all of them is "by asking ecs to run containers in various forms."
In so many wayswe don't own the technology we buy anymore, and playing with someone else's toys doesn't invite the same enthusiasm, especially long term where ecosystems are involved.
In the thread: bunch of tech workers acting like 19th century small farmers. The story here is that chemistry is a blunt tool and in 50 years we won't need it for agriculture. Biocontrols will have totally taken over. In the meantime anything we can do to remove incumbent chemical technologies and create economic room for their replacements is.. important. Why? cause we're gonna need those biocontrols anyway to keep farming at current yields under an evolving pest/weed regime.
We got through the 20th century without sustainable farming. I'm OK with that, it led to things like me existing. Now it's time to focus a little more effort on doing the job properly.
Biocontrols have potential, but they have certainly not taken over. We will always use a combination of herbicides, genetic engineering, RNAi, and biocontrols. The key will be finding a balance between these technologies.
metallic taste == nutritionally available iron. Also rust is trivial. We once put our cast iron through an oven clean cycle by accident. It rusted all to hell, turned solid orange, but re-seasoning returned it to better-than-ever condition.
Eating a meal always implies eating your cookware and packaging. I don't want to eat chromium and friends, or PFAS. Non-stick is gonna get banned eventually, mark my words.
What's the latest science on whether more iron is a good thing?
If a person is already near optimal iron levels, could cast iron push them over into just a bit unhealthy territory? Maybe not enough that people complain, but what would a sensitive study show?
where do you keep the ECS service/task specs and how do you mutate them across your stacks?
How long does it take to stand up/decomm a new instance of your software stack?
How do you handle application lifecycle concerns like database backup/restore, migrations/upgrades?
How have you supported developer stories like "I want to test a commit against our infrastructure without interfering with other development"?
I recognize these can all be solved for ECS but I'm curious about the details and how it's going.
I have found Kubernetes most useful when maintaining lots of isolated tenants within limited (cheap) infrastructure, esp when velocity of software and deployments is high and has many stakeholders (customer needs their demo!)
reply