|
|
|
|
|
|
by frazbin
505 days ago
|
|
|
If I may ask, just to educate myself 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!) |
|
|
> 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.