I'm using AWS Toolkit for Eclipse (https://aws.amazon.com/eclipse).<p>How do you work when you need to develop new things? What is your workflow?
When I'm trying out a new AWS service I start using it through the web console. Once I gain some familiarity with the service and settle into a pattern of manual operations, I translate the manual operations into CLI commands. The most commonly run CLI commands I throw into a shell script.<p>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.<p>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.
I've experimented with a few different things and there really are lots of valid ways to work depending on context.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Edit: not ever used ansible to modify AWS infrastructure. We keep infrastructure separate with a configuration management separate from setting up the infrastructure.
At work, the workflow is largely this: developers hand-create resources in the DEV environment, get things working, work out kinks, then the DevOps team comes in and translates everything into their Terraform automation setup, and then deploys to other environments use Terraform.<p>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.
"Sandbox" accounts where devs have admin access to go figure out how services work and fit together.<p>Once they're ready to go into actual dev environment it's Terraform.<p>We also have a service catalog for standing up ec2 instances that are fully managed like in the datacenter and cloudfoundry.<p>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.
When developing new things, I always used Terraform and Jenkins.<p>The reason is because:<p>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)<p>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<p>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.
Console to figure out a new service (it’s a quick way to see all the different configuration options). CLI for some actions not supported by the console.<p>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).<p>We briefly considered Terraform but the learning curve seemed steep - should we give it another shot?
I use the serverless framework CLI (<a href="http://serverless.com/" rel="nofollow">http://serverless.com/</a>) 80% of the time. Does all my config + deployment for me.
Every client has different requirements so it varies. CloudFormation is common but strongly prefer Terraform when possible for creating infrastructure, and use Ansible or chef-solo for config management, pre-baked AMI method and deploying to ASG Launch Config for deployment. Use Python and Lambda for scripting out things like backups and common security tasks or anything else that may need to be scripted out.
Well, cfndsl allows us to write our cloudformation templates in YAML instead of JSON. Those can also get easily checked into git.<p>We are also trying out some stuff with serverless.<p>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.<p>And we are particularly uninterested in anything based on kubernetes.