The CF console is opaque, slow and worst of all lazy evaluates. This is exacerbated when doing anything docker service related. If you make a mistake it can be three hours before an update timeout is triggered, then another three hours for a rollback to complete.
The other _really_ annoying thing is that TF gets the features first. For example its not possible with CF to use SSM variables in environment vars. But as TF uses the AWS API, it can.
I dislike TF because I've not used it overly much, and it makes me have horror flashbacks of puppet.
However, what you say about the lambda is basically spot on. They are much simpler and easer, "true" serverless if you will. Or more likly /cgi-bin/lambda, if you are old enough.
How is it opaque? It’s a wizard that lets you upload a template from a file or S3. Most of the time though it’s part of my CodePipeline anyway. I don’t use the console in day to day use.
For a quick and dirty I use the CLI.
The other _really_ annoying thing is that TF gets the features first. For example its not possible with CF to use SSM variables in environment vars. But as TF uses the AWS API, it can.
Yes you can....
https://aws.amazon.com/blogs/mt/integrating-aws-cloudformati...
But there is one benefit to CloudFormation if you have the business support plan - AWS’s chat support is excellent.
The one that got me this week was that CF cannot define global Dynamo tables, you have to find an alternative way to turn them on.
https://github.com/kspurrier/cfn-dynamodb-global-table/blob/...
Our experience also shows that custom resources can go into a 3 hour timeout cycle if you don’t handle error cases in your lambda perfectly, making them a sub-par development experience.
But in the case of "global" tables, they are by definition cross region and CloudFormation stacks are per region.
Looking at the code from the link...
for region in event['ResourceProperties']['ReplicationGroupList']:
replication_group.append({ 'RegionName': region})
However the new feature where you just dump in the SSM name in the environment variable and it unencrypts at execution is not supported in CF yet.
It was the same ECS/fargate/batch task creation for a long time.
As for the CF Console, its the same data in the CLI or on the web, the data comes from the same point.
1) it lazy evaluates, so it gets 90% of the way through a deploy only to find that there is a spelling mistake. That is inexcusable.
2) yes you can download the template via S3, but if you have a circular dependency, it won't tell you the line numbers. It won't even tell you the occurrences that are causing it to be over constrained.
3) It won't tell you the order in which your stuff will come up.
1) there are cloud formation linters.
2) It will tell you the resource name
3) it creates a dependency graph. It only knows when things come up based on when the underlying API call returns. How else would it know until execution time?
True, but that gets very expensive very quickly. We keep all our config for each environment in SSM pretty cheaply. (we have >1000 config items, most of which aren't and don't need encryption)h
We basically treat SSM like Vault from hashicorp
1) We have a linters in the CI pipeline, they help but are not perfect.
2) true, but not where the references are, thats the killer bit. If you have > two people working on a script, and they each put in a !Ref or !GetAtt, its exceptionally difficult to debug.
3) once you have a dependency graph, you know the order in which things come up. You need to generate the graph before you start calling APIs.
For example, you have a a property that you've spelt wrong, isn't the right data type, or isn't valid for that type of config. All of those can be evaluated when the dependency graph is generated. However, they are not, they are differed to when the API is called.
This gets very tedious if you are using anything ECS/fargate/rds, as the debug loop can be > 3 hours. This can be mitigated if you use uniquely named items, allowing multiple stacks.
Even when using CF, I have to aggressively use DependsOn to keep multiple calls to the Parameter Store API from being called in parallel. We gave up and used DynamoDB for configuration for non sensitive parameters and created a custom resource to create Config values.
Yeah but the Secrets Manager at $0.25/month per secret is expensive.
There are linter plug ins for Visual Studio Code and other editors. There is also the new CDK which is suppose to be able to do checks based on the real stars of your environment like whether a specified subnet exists. I haven’t used it yet.
For example, you have a a property that you've spelt wrong, isn't the right data type, or isn't valid for that type of config. All of those can be evaluated when the dependency graph is generated. However, they are not, they are differed to when the API is called.
Some things CF could be more intelligent about knowing, but for the most part, each service does its own validation when you call the underlying API.
Not related to CF but for instance the CloudWatch GetMetricData API has what seems like dozens of generic vslidations. The parameter store only allows certain formats for the keys. How would CF know that you specified an invalid key? Can you imagine how much slower Cf would be if it had to call some type of prevalidare API on each resource before it created it? To get an idea, think of how slow the new drift detection feature is and it is only doing read operations.
pro level startup: set it manually and use cloudformer.
+1 on the comments regarding wiring and lambda in non-vpc vs vpc context
also, if you want K8s, there is this thing called EKS.
Alas, that never really works with multi account setups. Its sometimes useful for seeing which magic line one is missing, but the level of incorrect boilerplate out there on github is staggering.
I probably could have figured it out, but why bother when we are paying for the business support plan?
I agree that It can be confusing as f for a newcomer. This is definitely an opportunity for training courses/labs/moocs to figure out how to make the learning curve less steep.
also, compared to terraform, cloudformation is state-of-the-art when it comes to actually bringing shit up
Which is absurdly overpriced. $1,728/yr just to run an empty cluster.
- using Terraform instead of cloud formation
- not using the default create a VPC wizard like anyone new would.
- he said if we wanted to use lambda functions he would still have to setup networking. It depends on what he was doing. If he used a regular database, yes he would have had to setup a subnet for his RDS cluster, but if he used DynamoDB, he wouldn’t need to do that. But even then, the default VPC wizard that most people would have used would have been good enough. But either way, that has nothing to do with K8s vs Fargate.
No even when you run a lambda “inside your VPC”, you don’t get more security. The lambda is never running inside your VPC. It is running inside an AWS VPC and connecting to your VPC via a network interface (ENI).
- If he were to use lambda, he would not have had to worry half as much. He wouldn’t have needed a load balancer. Also, he was using a third party ssl certificate when he could have had a free one that was automatically managed by AWS with Amazon Certificate Manager. Using API Gateway and just using a lambda proxy would have done the same thing. No, there is no “lock-in” from using lambda and a lambda-proxy interface. You write your same C#/WebAPI, Node/Express, Python/Django code just like you always would and add the proxy on top of it.