Dev tools are cool (AWS UG Dublin)

Transcript

1. Tools are cool. A mostly random and unordered diatribe, brought to you by ”too much time on planes” Abby Fuller, AWS @abbyfuller
2. Work smarter, and safer, not harder. #thoughtleadership
3. In other words, how can we (but mostly me) do less work (safely)?
4. Short answer: I get by with a little help from my friends (tools).
5. Safety first.
6. For AWS, this means all types of roles.
7. Identity and access management In other words, how you can, and your services perform action securely? All types of IAM roles: • Service roles • Controls what the service can access on your behalf (for example, access to DynamoDB) • https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html • User roles • Represent a person, and what they can access. For example, a role “abby” with administrator access. • https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html • Groups • Logical groupings of IAM Users with shared permissions
8. I have secrets. • Storing secret keys and passwords is worth a whole talk on its own. A few words of advice: • Rotate your keys, don’t share them between a) services, b) humans • Go for “principle of least access” • Where possible, store your keys somewhere else, and then control access (for example, store keys in KMS, and control access with IAM/service roles) • There are also third party tools out there (lots): for example, Vault: https://www.vaultproject.io/
9. The key here (pun intended) is that you’re not managing artisanal, handcrafted secrets yourself. You delegate to a role, or service, and then control access.
11. Just show me cool stuff.
12. Local environments
13. Good development starts locally • Standardized, easy to set up local environments help eliminate “well it worked on my machine” • Some common approaches to this: Vagrant and/or VirtualBox, EC2 box with local access • Any approach should have a few things in common: shared configuration between team members (i.e., running the environment uses the same versions of packages), and is as close as possible to the production environment.
14. Some tools that might help you out • Vagrant: https://www.vagrantup.com/intro/index.html • AWS Cloud9: • Cloud development environment that integrates a shell, AWS resources, and an editor • https://aws.amazon.com/blogs/aws/aws-cloud9-cloud-developer-environments/ • https://aws.amazon.com/cloud9/ • There are also service or language specific tools to help you out, like SAM Local: https://github.com/awslabs/aws-sam-local
16. But Abby, all my is in the
17. You can still use local tools! • Beyond local environments, you also want a staging or test environment. This lets you test as closely as possible to real life. • There are also tools that will help you simulate your AWS environment: • https://github.com/localstack/localstack • A nice compilation of tools: https://medium.com/@takezoe/how-to-develop-aws- based-application-in-the-local-environment-3e36eb705adf • You can also write your own: stubs and mocks can simulate service responses
18. Then automate your AWS
19. Cloudformation (duh) • Common language for describing, creating, and deleting AWS resources. • Created and maintained by Amazon. • Free to use, just pay for the resources created. • For more info: • aws.amazon.com/cloudformation
20. Looks something like this
21. Trendier: Terraform • Created by Hashicorp • Open source! • Not through AWS, so sometimes takes a bit to catch up with new services • For more info: • https://www.terraform.io/ • https://github.com/hashicorp/terraform
22. Here’s an example
23. So what do I use? • Either one: both focus on resource management. • Cloudformation: planning and execution in one step. Meaning, just executes. • Terraform: planning and execution in two steps (terraform plan, terraform apply)
24. You’ve automated your resources: now what about code? Tests?** Deployments? **Unless you don’t write tests, I guess. Shame on you, though.
25. Pipelines are your friends • Lots of options: • Jenkins, TravisCI, CircleCI, Shippable… • With AWS: • Code*: CodeCommit, CodePipeline, CodeBuild, CodeDeploy • Or, pick and choose and integrate your favorite 3rd party tool
26. Why CI/CD? • Manually building, testing, and deploying one service is fine. Doing it for 10, 25, 50, 100 services is…not fine. • Creating a strong pipeline helps with this! Tests that run automatically are good tests. Automatic builds, that then run tests, and then deploy if tests pass are even better.
27. Building complete pipelines with Code* CodeCommit: managed source control for Git repositories CodePipeline: continuous integration and delivery service. Build, test, and deploy every time there is a code change in your source respository. CodeBuild: managed build service to compile, test, and package code. CodeDeploy: automated deployments to any type of instance, like EC2.
28. You’ve automated everything- congrats! But your work doesn’t stop there.
29. Observability • Keep looking for ways to improve performance. That could be something like Amazon X-Ray (aws.amazon.com/xray)
30. Or, something like Honeycomb.io • Answer hard questions like “why are reads slow?” • https://honeycomb.io
31. Finally, don’t underestimate a good CLI
32. A CLI is your most powerful friend for automation • Beyond just aws-cli! • For ECS: • ecs-cli, • coldbrew-cli • fargate-cli • For Lambda: • Serverless • aws-sam-local And tons more.
33. Your best resource is the community
34. Learn from (and teach) your peers • Events like this! • twitch.tv/aws, twitch.tv/awsugn_dublin • #awswishlist on twitter • AWS evangelists on Twitter • Slack groups, forums • If you have a question, let us know!
35. I’ll leave you with (as always), words of wisdom from my spirit animal, Charity Majors: “There’s no such thing as the “best” tool: there is only the tool that best fits your needs.”