How do you work when you need to develop new things? What is your workflow?
For instance, I started using AWS Lambda by manually uploading the lambda code .zip file through the web console. Later on I wrote a shell script that invokes an AWS CLI command to do the same.
TIP: when using AWS CLI, set the parameter '--output json' to get pretty, readable output. It's much better than the default output text format.
> What about using Serverless or a framwork for Lambda stuff?
If you're using other parts of AWS than Lambda, is there a benefit to using serverless? If I still need to know aws cli for the other services I use, what's the point in learning a specialized tool that only works for one service?
Terraform: at some point you will probably end up here. It gives you so much control, it's fast and (mostly) easy to work with. It gives you a good idea of what it is doing and why.
Cloudformation: mostly I've used this embedded in some other tool. For example we have a fairly small Elastic Beanstalk app which uses SQS and SNS - nice to be able to extend the basic infrastructure easily inline with your app definition. Similar situation with serverless.
Awless: this is a really nice (scriptable!) CLI alternative. Nothing wrong with the normal AWS CLI but this does some things simpler/nicer. If what you are doing is simple enough you can script infrastructure with these tools.
Console: I really use this alongside the other things as I'm building automation or to explore some new service I've not used before.
Ansible: for configuration management (post terraform apply) we are using ansible. So far we set up an admin box inside the infrastructure and run ansible from there. We've experimented with having ansible build the inventory but currently looking at a bash/jq/awless combo to build it dynamically.
Edit: not ever used ansible to modify AWS infrastructure. We keep infrastructure separate with a configuration management separate from setting up the infrastructure.
Personally, when working in DEV, I do most of my work through the AWS Console, combined with some use of the AWS Java API. I rarely if ever use the AWS command line tools.
Once a product works in dev, I use terraform to automate production deployments.
Once they're ready to go into actual dev environment it's Terraform.
We also have a service catalog for standing up ec2 instances that are fully managed like in the datacenter and cloudfoundry.
Personally I tend to use a mix of terraform, boto3 and CLI for the vast majority of things, and log into the console when I need to go look at things occasionally.
The reason is because:
1. Terraform You can abstract the deployment logic and requirements into single unit because developers ideally should spend more time building products rather than dealing with the deployment and cloud stuff. Furthermore, this will be one source of truth for any deployment configuration and documentation, that will be super worthed in onboading as well especially when you're working with big engineering team (> 50 engineers)
2. Jenkins We actually can run terraform from our local computer, but with Jenkins we can standardize the way people update and create the resource in consistent way. Also, by using Jenkins we can track all deployment that happened
My future plan is for combining this workflow with management configuration tools like Ansible since Terraform is not only for creating cloud resource, not for manage configuration. Currently, I'm ussing bash command which obviously won't be easily scalable and understandable by engineers.
Then once we’ve figured out how we want to use the service, we script the deployment with CloudFormation and put it in an Ansible playbook. This allows us to rebuild everything from scratch, and that’s actually what we do for each deployment. Also makes it super easy to set up a new environment (e.g. to onboard a new team member).
We briefly considered Terraform but the learning curve seemed steep - should we give it another shot?
I found the cloud-agnostic claim to be a bit of an exaggeration, plus most clients are happy to stick to one provider. Sure, CloudFormation is a bit slow, and the JSON is awful, but with YAML it's okay. And I don't need yet another tool. What am I missing?
In Terraform you're able to create modules that you can use to setup uniform infrastructure. For example, you could have an RDS module that aside from setting up the database it also sets up a replica, a dedicated KMS encryption key, IAM policies, security groups, parameter groups, etc. So instead of setting all of this up for every database you have, you can just reuse a custom module that does all of this for you. These modules can also be versioned such that you can upgrade and change them as needed without breaking all your current infrastructure.
If you do choose to learn and implement Terraform however, you gain the knowledge of a tool that can support many cloud providers and can even manage environments that span multiple providers. e.g. CloudFlare + AWS, etc. In addition, you can package up your solutions as modules and share them with others.
I chose Terraform because I have services running on multiple clouds and I also prefer to use tools that have value outside of a single ecosystem.
We are also trying out some stuff with serverless.
But we are an AWS-only shop, so terraform and other cross-cloud tools are not of interest. And we are also not interested in anything that can’t take full advantage of everything AWS offers.
And we are particularly uninterested in anything based on kubernetes.
It's way nicer than JSON, especially w.r.t. functions. It's also compatible, so you can load JSON templates into e.g. a Python script and serialize them to YAML. I did this to all our templates pretty much as soon as it came out.
I have used cfndsl and loath it. If I need more complex variables than CloudFormation supports, I rather use a simple templating engine like Jinja2 or ERB than a Ruby-based DSL.
