AWS CloudFormation now supports blue/green deployments for Amazon ECS
aws.amazon.com
aws.amazon.com
The only option teams that need CI/CD for their cloud resources & want to use cloudformation for most of it is to have a side chain process for handling resources that can't be expressed with Cloudformation. (not at all insurmountable but shouldn't be necessary)
It'll suss out eventually but not soon.
Start telling your teams to do what I said above and if anyone tells you "but we want to use one tool" tell them they must grow out of that.
CF is extensible through Lambda (which AWS uses itself for the Serverless Application Model), which if you are going to use CF for this is probably what you bought to do to let you use it for everything, rather than having a “side-chain process”.
This launched nearly 3 years ago. https://aws.amazon.com/blogs/compute/bluegreen-deployments-w...
Same with Config.
It may turn out that the tools that CloudFormation team provides don't make integration easy, especially if the operation takes longer than 15 minutes (meaning they can't implement support via a single lambda invocation as an under-the-hood custom resource).
But it’s hard to believe if the team responsible for the blue green deployment functionality developed an API endpoint to do it, they couldn’t just hand it to the CF team to call. At the end of the day that’s all CF does. Call APIs based on the different lifestyle events as far as how it actually creates resources.
Intentional or not, I'm going to start using this. :P
Someone higher up should enforce it. I've been in teams, where if something isn't in cloudformation it doesn't exist and that attitude is totally understandable, having to do some operations by hand seriously hurts IaC efforts.
When considering Terraform vs CloudFormation I certainly took that into account and that's why I don't use CloudFormation for anything.
I wonder if there are any killer features of CloudFormation I missed when I looked into this (years ago now).
- The ability to configure everything about a lambda and export the template.
- Serverless Application Model tooling
- Quick Create Links - you can give out a link to developers that let them create infrastructure by using CF and just enter parameters. You can restrict them to only being able to create a stack that you specify.
For Workspaces it took them something like 2-3 years to release to the public API what you could do with Cloudformation
[0] https://aws.amazon.com/about-aws/whats-new/2019/11/now-exten...
It seems like a really obvious move to me?
This is despite the obvious role of CloudFormation as a productivity multiplier inside the AWS world
Of course, AWS could be doing the same for Cloudwatch, but apparently they're not bothered.
But honestly, I think the reason that Cloudformation support isn't as widespread or a top level priority is that it simply exposes the poor architecture and behavior of many of AWSs second tier services and teams. There are many services that simply do not behave well when managed by Cloudformation, but are also completely janky on their own and I'm betting it's far easier to cover up for poor architecture in the console than expose all the services dirty laundry with a Cloudformation integration.
Additionally, there are a lot of service teams that probably don't have a lot of customers using Cloudformation, so don't prioritize it or half-ass it completely. I'm looking at you DMS, and your terrible turd of a Cloudformation integration.
I'd say nearly the same thing about IAM and service teams inability to implement it well. I still do not understand why AWS has not mandated all services need to support both tag and resource based policies and predictable IAM semantics (looking at you Glue with your little fu of love called the write action "glue:GetMapping").
Cloudformation and IAM are, to me, the two of the most killer services from AWS, neither of which I've seen replicated at other providers.
It's also very old with some odd decisions in there - I can't go into the specifics. And it's practically impossible for the IAM team to deprecate those impossible corners
Has the GUI been fixed to be somewhat useful? Did they migrate from their god awful JSON crap? Can I embed simple infrastructure logic, like automatically adding a group of nodes to a Route53 zone?
As I understand it, the three cloud providers differ in this way:
1. Microsoft Azure releases template/API first - no features can be released unless an Azure Resource Manager template can access it. I think they use ARM templates for their integration testing, as well, but I'm not sure. (If you're an Azure 'softie, please chime in!).
2. Google Cloud Platform releases APIs first - no features are released without extensively being tested via API integrations. They do have a CloudFormation/Azure RM template offering now called Deployment Manager so that my change. (This means that Terraform-like tools can target features quickly, and I have no experience with Deployment Manager but I suspect it does as well.)
3. Amazon AWS releases to the web console first. You might say, "Whoa, what about Bezos' service oriented architecture email?"[1] As far as I know, that's true for internal features. But all user features are exposed through the web console, then wrappers around those APIs are exposed, then, sometimes years later, CloudFormation gains the ability to target those APIs.
For this reason, I trust Microsoft and Google Cloud a lot more to maintain parity between what I can do in Terraform/Pulumi/native template tools and in their web consoles.
[1] - https://gist.github.com/chitchcock/1281611, per Bezos: "All teams will henceforth expose their data and functionality through service interfaces."
At least, I haven't found any documentation for it other than the template they say to copy in the linked user guide for this feature. Definitely not supported in CDK.
Good to see that they're working on it, but I don't know why they don't fix the underlying paradigm instead of making it Cloudformation exclusive.
EDIT: I should mentioned that we are using AWS CDK for all of this. All it does is register a new task as the default task for a service and ECS/ALB does the rest.
I just want a cluster that scales in and out to the amount of memory my tasks need, I'm not very concerned about CPU. Until capacity providers it was more or less impossible to do so without having a bunch of excess capacity provisioned. Even with capacity providers, I can't seem to get a cluster to scale in to 0 instances when no tasks are needed.
I have one ECS service that requires an EBS volume mount, which means that when the task definition is updated, I need the service to stop, so that the new task can mount the same volume. This deployment model is essentially impossible without implementing a custom deployment strategy.
Fargate makes things a bit easier, and now that you can use EFS volumes with it it might make more sense. But overall, everything in ECS just seems poorly designed, clunky and hacky, like many AWS products.
https://gist.github.com/guillaumesmo/4782e26500a3ac768888daa...
There are so many - Elastic Beanstalk, ECS, EKS, ECS-on-Fargate, EKS-on-Fargate..and of course the huge marketing push for Serverless.
They could have the sensible way out and built EKS as the foundation of everything - makes total sense given the massive ecosystem around kubernetes. ECS and Fargate should be killed off.
https://cdk8s.io/ replaces Elastic Beanstalk ....but still basically runs on top of EKS.
The pairing of CDK8S and EKS are fundamentally enough for all usecases that AWS basically sells.
There is probably some tension between ECS and k8s - AWS built a container orchestration platform based on what they think the world (and Amazon) needs and then k8s became madly popular. And it's not clear that AWS was wrong because k8s is essentially too complex for many use cases. It makes total sense that they would support both fully.
IMO K8s will become akin to Linux Kernel. Almost no one uses bare mainline Linux kernels, you choose a distro based on your needs. Companies like RedHat and Canonical will pop up and provide their own packaged "distros" of K8s and you will choose which philosophy best suits your needs.
ECS predates EKS, and is better integrated than EKS with their other services. If you want a painless container experience on AWS, ECS for Fargate is what'll you'll want to use today. So both existing folks who use ECS today as well as new customers are going to keep using ECS.
Folks who like K8, perhaps from prior experience, are going to use EKS despite it having some rough corners.
See, Amazon is perfectly happy to support everything under the sun as long as there are paying users. See their database offering for very much the same strategy, and it would be silly to say that they should drop DB x since they now offer DB y.
And my whole point is that AWS is on the path to fix kubernetes UX and give you exactly the mental model you want...but run it on k8s.
Think of it as ECS, Beanstalk, Fargate on top of EKS.
You won't be asked to adopt the complexity of k8s
Same goes for Fargate, except that it’s now offered by EKS to, what possible reason would they have too turn it off?
image: !subst “image:${Tag}”There are basically three ways to do it:
Min less than max, max is 100.
Max greater than min, min is 100.
Some combination of the two.
For the first you take down running tasks first and then backfill with new (green) tasks.
For the second you add green tasks and once stable take down blue.
Make sure that if you only have two tasks that min/max move in 50% increments: I.e you can’t scale up/down to 125%/75% but can to 150%/50%.
Why would you when terraform exists?
Sorry I'm not familiar with Cloudformation but that's how I would approach it with Terraform.
I’m not sure I’d use either of these tools to roll out new code though.
CF roll-backs are on by default and will revert changes. Sometimes it can fail and be a real pain, but it’s overall been more of a help for myself than harm.
terraform is not the tool for the later, an ansible stack would be better suited for it
In a lot of situations infrastructure deployment and configuration management is deeply coupled in the AWS ecosystem (DB changes, Serverless technically is changing your infrastructure definition as application changes).
then terraform is probably not the right tool and cloudformation is a better suited solution
It has some nice things that terraform just doesn't have out of the box:
- Its a managed service, I don't need to setup a state bucket (or similar), I upload my template and it handles it. CI itself is not running CloudFormation, it just tells CF to do its thing. I could achieve this with other services with TF, but its not something I have seen out of the box.
- Drift Detection
- Stack Sets, the ability to deploy easily deploy a cloudformation stack to multiple AWS Accounts
- How sharing outputs works in CF between deployed stacks. There are protections in place if you have a stack that relies on a value your stack creates, you cannot modify or delete it without first changing your other stacks. I wish AWS could instead trigger a downstream change in any of those stacks, but it does not. (This is not for nested stacks, but for 2 completely separate stacks that just happen to need to share something)
However even without these, I struggle to see the point of going with Terraform if we are all in for AWS anyways. Especially when there are templates that we may want to use, so why not keep everything in the same place.
CloudFormation Drift Detection is very limited currently: it only supports a small subset of resources that you can create with CloudFormation. If your needs are covered by it, great, but it doesn't take much to go beyond its bounds. Also, it detects drift, but won't correct it.
Terraform both detects and corrects drift on almost every resource, on every application. Sometimes there are limitations. This does result in extra work, as you can't just ignore drift without capturing that in code (via ignore_changes), but to me this is absolutely a desirable thing.
We use CloudFormation to actually create the state resources to store Terraform state.
Terraform can share outputs between different states using the terraform_remote_state data source, though there isn't any restriction on what can be done there (no requirement to update other stacks/states).
Despite being an AWS-only shop, we've found the multi-provider support in Terraform to be really useful. For example, as part of our environment configuration, we store resources in Consul, create Pingdom checks, etc all from the same set of Terraform code.
With Terraform (unless there is functionality I am unaware of) you need the repo where the terraform is stored to be able to perform that check. Then you need to setup the system that does the periodic checks (yes I know a cron in CI is barely any work if thats your desire).
Ultimately like a lot of things, CloudFormation VS Terraform is a long list of tradeoffs. I just would not personally write off CloudFormation depending on I actually need.
TF actually doesn't have much edge over CF. When TF was released it fixed many pain points of CF, but since then CF fixed those problems.
The supposedly killer feature that you can use TF with multiple clouds is not that killer, since each cloud architecture is different so you can't just reuse your code.
With CF you have extra benefits:
- built in, no extra tool necessary
- integral part of AWS, so no need to worry about being discontinued
- available within AWS support
- no need to worry about synchronizing state between people
- import / export functionality, you can expose various variables, which following stacks can build on top of
- ability to implement custom states with lambda
- uses YAML or JSON, which means you can use existing tooling to generate config programmatically.
Haven't used yet, but it appears that CDK is built on top of that, and that's much more powerful than terraform.
If that's the case,I don't see how CDK stands a chance against Terraform or Pulumi.
And I'm not talking about multi cloud support, but just about the fact that an AWS-managed product, CloudFormation, keeps lagging behind for YEARS for such a core feature of a core AWS service.
Also too bad that it’s still CloudFormation.