Managing Your Cloud Assets
•
0 j'aime•1,405 vues
Cost is often the conversation starter when customers think about moving to the cloud. AWS helps lower costs for customers through its “pay only for what you use” pricing model, frequent price drops, and pricing model choice to support variable & stable workloads. In this session, you will learn about the financial considerations of owning and operating a traditional data center or managed hosting provider versus utilizing AWS. We will detail our TCO methodology and showcase cost comparisons for some common customer use-cases. We’ll also cover a few AWS cost optimization areas, including Spot and Reserved Instances, EC2 Auto Scaling, and consolidated billing. Presenter: Amit Sharma, Solution Architect, Amazon Internet Services Krishnenjit Roy, Director IT Operations, Freshdesk
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (18)
Similaire à Managing Your Cloud Assets
Similaire à Managing Your Cloud Assets (20)
Plus de Amazon Web Services
Plus de Amazon Web Services (20)
Dernier
Dernier (20)
Managing Your Cloud Assets
- 1. Bangalore
- 2. Managing Your AWS Cloud Assets Automate Infrastructure and Code Deployment Amit Sharma Solutions Architect
- 3. Agenda • Why should you care – Key Tenets • How do you automate – Elastic Beanstalk – CloudFormation – OpsWorks • Fresh Desk
- 4. Why should you care to automate • Because that is the holy grail
- 5. Henry Ford – Invented Assembly Lines
- 6. Assembly lines worked great… • Created a commodity product out of a luxury • Dropped prices • Standardized, mass produced and easy repairs
- 7. Assembly lines worked great, but… • A failure in one part of the process blocks everything else after it • Lots of room for human error • Lots of room for variation in quality due to human workmanship • Maybe not as fast as they could be • Takes a lot of time to retrain and retool humans • Only Black
- 8. Fast forward about 100 years • Fewer humans. • A lot more of these
- 9. Smart Senior Coworker #1 UPSIDE DOWN SERVER Smart Senior Coworker #2 Ugh, Humans
- 10. Cloud - Been there done that ? Key Tenets….. • Use APIs • Commodity Hardware - De-couple the code from infrastructure • Just-in-time provisioning • Rip-n-replace - don’t repair • SSH-less • Stateless – no local sessions/ storage Code your Infrastructure
- 12. Elastic Beanstalk (EB) Managed standard containers • Your code deployed into a container of your choosing • Infrastructure deployed and managed by EB – but you still maintain complete control • Supports these platforms:
- 13. Under the hood Your code Application Service HTTP Service Language Interpreter Operating System Host
- 14. App Versions & Environments Environments Configurations Save these for easy duplication for A/B testing or non-disruptive deployments Application Versions All versions stored durably in Amazon S3. Code can also be pushed from a Git repository!
- 15. Deployment Options 1. Via AWS Console 2. Via Git / EB CLI $ git aws.push 1. Via AWS Toolkit for Eclipse and Visual Studio IDE
- 16. Deployment Configuration Single Instance Load Balanced with auto-scaling Region Stack (container) type Database (RDS) 01 02 03 04 OR Optional Your code
- 17. Load Balanced/Auto-scaling Architecture • EB deploys the load balancer, web/app servers + code, and backend database (optional) • Creates S3 buckets for logs • Configures Route53 and gives you a unique domain name Yourapp.elasticbeanstalk.co m^ you can use your own domain too
- 18. CLI Deployment Pre-requisites 1. AWS Account – your access and secret keys 2. EB CLI • Linux/Unix/Mac : Python 2.7 or 3.0 • Windows : Powershell 2.0 3. A credential file containing info from 1. 4. Git 1.66 or greater (optional)
- 19. Zero Downtime Deployments 1. Create a new environment for an existing application 1. Deploy your updated application code to the new environment 1. Then use the “Swap URLs” feature to transition users to the new production environment
- 20. What is the cost of using Elastic Beanstalk ?
- 21. There’s no additional charge for Elastic Beanstalk
- 22. CloudFormation • Infrastructure as code, suitable for change management in version control (git, svn, and so on) • Define an entire application stack (all resources required for your application) in a JSON template file • Define runtime parameters for a template (EC2 Instance Size, EC2 Key Pair, and so on) • Generate templates from running environments with CloudFormer
- 23. CloudFormation Amazon Route 53 Elastic Load Balancer CloudFront Distribution S3 Bucket Web Servers App App Web Servers Web ASG Elastic Beanstalk Master Standby RR 1 RR 2 RR 3 RR 4 ElastiCache Cluster This is a stack
- 24. CloudFormation This is a template file describing the stack
- 25. CloudFormation Git Subversion Mercurial
- 26. CloudFormation Git Subversion Mercurial Dev Test Prod
- 27. CloudFormation - Anatomy { "Description" : "Create an EC2 instance.”, "Resources" : { "Ec2Instance" : { "Type" : "AWS::EC2::Instance", "Properties" : { "KeyName" : “my-key-pair”, "ImageId" : "ami-75g0061f”, “InstanceType” : “m1.medium” } } } }
- 28. CloudFormation - Anatomy "UserData": { "Fn::Base64": { "Fn::Join": [ "", [ "#!/bin/bash -exn", "yum -y install git-coren", "yum -y install php-pearn", "pear install Crypt_HMAC2-1.0.0n", "pear install HTTP_Request-1.4.4n", "pear install aws/sdkn",
- 29. AWS OpsWorks • Integrated application management solution for ops-minded developers and IT admins • Model, control and automate applications of nearly any scale and complexity • Management Console, SDKs, or CLI • No additional cost
- 30. OpsWorks - Application Management Challenges • Your app’s reliability and scalability are really important. • The operational tasks needed to keep it running smoothly take time… • Provision • Deploy • Configure • Monitor • Scale • Secure • As your app grows, routine operational tasks can become even more time-consuming and error-prone. • Don’t want to tradeoff control or flexibility for ease of use.
- 31. Improve reliability Check in – Build & Test Tests pass – Deploy Git Jenkins OpsWorks Code Build Test Provision Deploy Monitor
- 32. Software Config & Deployment Options Your Code Tomcat Apache Struts Hibernate JEE Linux Your Code Tomcat Apache Struts Hibernate JEE Linux Your Code Tomcat Apache Struts Hibernate JEE Linux Chef
- 33. Terminology A stack represents the cloud infrastructure and applications that you want to manage together. A layer defines how to setup and configure a set of instances and related resources. Then deploy your app to specific instances and customize the deployment with Chef recipes. Decide how to scale: manually, with 24/7 instances, or automatically, with load-based or time-based instances.
- 34. What is Chef and how does OpsWorks use it • Chef is an open-source framework that automates software deployment and configuration. • Whenever a change happens on your stack, or upon request, all instances are notified and recipes are run. Lifecycle Events Recipes Metadata
- 35. OpsWorks Agent communication 1. Instance connects with OpsWorks service to send keep alive heartbeat and receive lifecycle events 2. OpsWorks sends lifecycle event with pointer to configuration JSON (metadata, recipes) in S3 bucket 3. Download configuration JSON 4. Pull recipe and other build assets from your repo 5. Execute recipe with metadata 6. Upload Chef log 7. Report Chef run status EC2 Instance OpsWorks Service “Deploy App” Your repo, e.g. GitHub
- 36. AWS Application Management Services Higher-level Services Do it yourself Elastic Beanstalk OpsWorks CloudFormation EC2 Convenience Control
- 38. Bangalore
- 39. Freshdesk Journey on AWS Presenter Krishnenjit Roy
- 40. Freshdesk • The Challenge – In the age of social, customer interactions with the companies are ubiquitous, cross-channel and increasingly real-time – For brands and service providers, one-to-many customer interaction model no longer holds – consumers as a collective drive narrative on service and brand – Cloud sets the expectation that vendors offer easy to setup, affordable and flexible solution that scales
- 41. Life Before AWS • We were on AWS ( Engine Yard ) before we moved to AWS • New Technologies adoption – New technology were not being supported and we had to wait for new releases before we could migrate • Control – Direct access to our environments were not allowed – Engine Yard use to manage our environment and we had limited access and control • Support Cost – Our Support Costs were Sky high • Premium Pricing – As we scaled our Pricing was starting to get more expensive
- 42. Getting our Feet Wet on AWS • Why we didn’t move to AWS from the beginning ? – We started with 6 people team most of them were App Developers – We didn’t have a dedicated DevOps or Infrastructure team • Selective movement of Services to AWS – Redshift for reporting – RDS for MSQL and used API’s to balance shards in simple and effective manner – SQS to process high volume social chats • We got hooked to AWS – Easy deployment using OPSWorks by writing custom chef recipes – Rapid Scalability – High Availability using AZ’s • We started building our own DevOps Team – Senior Development Member “Kiran Darisi “ ( Also part of our Founding team ) transformed into our best DevOps resource
- 43. We are “all in” to AWS • Started moving existing Freshdesk services from Engine Yard directly on to AWS – All our new platform were now being deployed on AWS • Real Kicker – RI’s – With reserved instance we could reduce our cost by 75% • We are now completely on AWS – If AWS fails we are out of business – More than 300 Instances on AWS • DDOS attack on our Website – Our Website were bombarded by DDOS attack in mid 2014 – We moved our static website to AWS – Using AWS support we could rapidly scale and suppress the attack • Enterprise Support – With enterprise support we can now optimize our deployment and cost as well as get dedicated prioritized support
- 44. Future Roadmap with AWS • Datacenters in Europe – Support our EU Customers – Data Locality Restrictions • Use SAAS offerings – Elastic Beanstalk
Notes de l'éditeur
- CloudFormation basically is infrastructure as code. It’s a set of instructions that not only include how to spin up EC2 instances, but the entire application stack. A common question is how to get started using CloudFormation—especially if you already have a functional system running in AWS. There’s a tool, CloudFormer, that can help: http://aws.amazon.com/developertools/6460180344805680.
- How does CloudFormation work? Let’s take a look at a system built in AWS. This entire system is considered the stack.
- CloudFormation is this stack distilled into a template file.
- This template file is a text file, so you can use source control systems to store and track changes on it.
- This template file makes it easy to launch the entire stack into different environments, such as Development, Test, and Production.
- We developed OpsWorks for you. Opsworks is an integrated application mgmt solution that brings together the a la carte solutions offered by AWS. It brings together all the tools you need to manage your application. Perhaps best of all, you only pay for the resources you use – OpsWorks itself is free.
- OpsWorks is a devops application management solution. If you develop or manage apps, you know they can be complex. And not just to code; there are operational responsibilities, too. These tasks need to be predictable – there’s nothing worse than trying to diagnose operational problems in your live app. You want to be able to configure and control any aspect of your app. You need a tool that’s powerful and flexible enough to support a wide range of application architectures. And you also want something that’s easy to use. <<Getting all of this right is important because if you develop or manage apps, you know operational responsibilities can be complex.>> Apps are complex Configurations change quickly Lots of moving parts Managing in the cloud adds complexity Getting started is hard – concepts are different than traditional IT Dynamic environment requires new tools (e.g., scale up/down) Alternatives require tradeoffs build it yourself takes time from core dev activities
- The third use case is integrating their development pipeline to improve reliability. You can automate your entire build process – first deploying into a staging environment that mirrors production, and then when your integration tests pass, deploy to production. You can easily spin up parallel production environments and migrate traffic incrementally so that it’s easy to roll back if there are problems. Pick your favorite source repo – we’re going to show Git When new code is checked in, kick off the build process using something like Jenkins. When build is done, run through automated tests. Then use the OpsWorks CLI to change the app’s version and deploy to prod. Or clone your stack, deploy to the new stack, and flip DNS when ready
- It’s probably worth covering the AWS deployment options so that you understand what OpsWorks provides. Each option provides a choice of flexibility, speed, and control… AMIs are fast to boot, but take more time to “bake” changes Beanstalk lets you take advantage of preconfigured ami and dynamically update your code And OpsWorks lets you build from a base AMI … and layer on your changes.
- We’re going to model our application, starting with a stack that contains all the resources we’re going to use. Next, we’ll create a layer – it’s a blueprint for how we configure ec2 instances. We’ll create a PHP layer for our PHP app. We’ll create some instances and then deploy our application. Now our app, like many, needs to connect to a database for persistence. How can we create and configure the database, and then make sure our app connects to the database? The old way is we create the database table by hand, and then bake the connection info into the code. This is error prone because you can miss a step or later forget what you did when you need to recreate it. We really want configuration information such as the database table creation, user creation and all the metadata about the database to be managed like our source code. That way we can roll back changes. Fortunately, Chef gives us a way to do this.
- Opsworks triggers events during the application lifecycle, such as when an instance is provisioned or an application is deployed. This lets you perform specific configuration tasks using Chef recipes that are attached to those events. Metadata is automatically generated by OpsWorks for such information as the instances running in each layer and layer-specific parameters. You can also specify metadata yourself that is passed into the recipes. Let’s take a look at an example.
- https://w.amazon.com/index.php/TeamCharlie/Architecture/InstanceAPI
- Opsworks is one of a few ways you can deploy apps on AWS. I’ll briefly introduce the other app management services and describe how OpsWorks is different. It really comes down to the level of convenience and control you need… AWS Elastic Beanstalk is an easy-to-use solution for building web apps and web services with popular application containers such as Java, PHP, Python, Ruby and .NET. If you want to upload your code and go, and don’t need to customize your environment, Beanstalk may be for you. AWS CloudFormation is a building block service that lets you provision and manage almost any AWS resource via a domain specific language. It is powerful, but requires you to author templates in a domain-specific language and doesn’t provide out of the box application functionality like deployments, etc. AWS OpsWorks is a powerful end-to-end solution that gives you an easy way to manage applications of nearly any scale and complexity without sacrificing control. It features an integrated experience for managing the complete application lifecycle, including resource provisioning, configuration management, application deployment, software updates, monitoring, and access control.