Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a AWS 101 - An Introduction to the Amazon Cloud
Semelhante a AWS 101 - An Introduction to the Amazon Cloud (20)
Mais de CloudHesive
Mais de CloudHesive (20)
Último
Último (20)
AWS 101 - An Introduction to the Amazon Cloud
- 1. AWS 101 An Introduction to the Amazon Cloud Presented by Patrick Hannah VP of Engineering, CloudHesive
- 2. Introduction • Who am I? • What’s my background?
- 3. What are we going to talk about? • Introduction to Cloud Computing • Where do I start? • Introduction to AWS • AWS Services
- 5. Why move to the Cloud? • Is it cost (dollars and hours) savings? • Is it because it’s (near infinitely) scalable? • Is it a shiny object?
- 6. Cost Savings • Minimize/eliminate up front investment in hardware, software, support, connectivity, etc. • Adopt a OpEx (versus CapEx) cost model, which might align well with your business model. • Minimize/eliminate complexities in cross charging for shared services • Achieve higher economies of scale
- 7. Scalability • Resource + People + Business (Increased Agility and Speed to Market for less) • Someone else now pays to maintain that excess hardware capacity • Automation allows for the horizontal scale up/scale down of infrastructure • Abstracted services eliminate the guesswork in scaling of storage and other services
- 8. Availability • Without physical constraints replacement of failed infrastructure occurs faster • Applications leverage abstracted services where the availability characteristics aren’t your problem • Human error is minimized with automation
- 9. Security • Each host becomes its own security zone • Infrastructure lifecycle management no longer has a physical component • Administrative activities are done with automation in mind • Shared Responsibility security model across your cloud environment
- 10. AWS - WHERE DO I START?
- 11. Where do I start? Knowledge • Documentation available from AWS – Documentation – Community/Meetups/Github – Wizards/Targeted E-Mails – Reference Architecture/Quickstarts – Ecosystem/Marketplace/Partners – Best Practices/Trusted Advisor/PHD/Targeted E-Mails – AWS Support – AWS Training & Certification • Interacting with AWS – AWS Console Console – AWS CLI, Tools, Tookits, SDKs and Mobile SDKs – AWS Billing and Cost Management • Keep Up to Date – Blogs – Whats New
- 12. Where do I start? Key Concepts • AWS Regions and Availability Zones • AWS Services generally build on one another • Categories of Services Offered by AWS – IaaS • Building Blocks, Comparable to On-Premises virtualization technologies – PaaS • Managed or Abstracted, Typically in support of IaaS – SaaS • Enterprise Aligned, Ready out of the box but can be enhanced with PaaS
- 14. AWS in the Gartner Magic Quadrant for Cloud Infrastructure as a Service, Worldwide
- 15. AWS Global Infrastructure 16 Regions 42 Availability Zones 63 Edge Locations
- 16. AZ A AZ B Asia Pacific (Singapore) US West (OR) AZ A AZ B AZ C GovCloud (US) AZ A AZ B US EAST (OH) AZ A AZ B AZ C US East (VA) AZ A AZ B AZ C AZ D AZ E EU (Ireland) AZ A AZ B AZ C Asia Pacific (Tokyo) AZ A AZ B AZ C EU (Frankfurt) AZ A AZ B AWS Regions China (Beijing)* AZ A AZ B China (Bejing) AZ A AZ B Asia Pacific (Seoul) AZ A AZ B AZ C AZ A AZ B AZ C S. America (Sao Paulo) Asia Pacific (Sydney) Asia Pacific (Mumbai) AZ A AZ B US West (CA) AZ A AZ B AZ C EU(London) AZ A AZ B Canada AZ A AZ B AWS Regions and Availability Zones
- 17. TECHNICAL & BUSINESS SUPPORT Account Management Support Professional Services Solutions Architects Training & Certification Security & Pricing Reports Partner Ecosystem AWS MARKETPLACE Backup Big Data & HPC Business Apps Databases Development Industry Solutions Security MANAGEMENT TOOLS Queuing Notifications Search Orchestration Email ENTERPRISE APPS Virtual Desktops Storage Gateway Sharing & Collaboration Email & Calendaring Directories HYBRID CLOUD MANAGEMENT Backups Deployment Direct Connect Identity Federation Integrated Management SECURITY & MANAGEMENT Virtual Private Networks Identity & Access Encryption Keys Configuration Monitoring Dedicated INFRASTRUCTURE SERVICES Regions Availability Zones Compute Storage O b j e c t s , B l o c k s , F i l e s Databases SQL, NoSQL, Caching CDNNetworking PLATFORM SERVICES App Mobile & Web Front-end Functions Identity Data Store Real-time Development Containers Source Code Build Tools Deploymen t DevOps Mobile Sync Identity Push Notifications Mobile Analytics Mobile Backend Analytics Data Warehousing Hadoop Streaming Data Pipelines Machine Learning Service Breadth & Depth
- 21. AWS SERVICES
- 22. AWS Services – Page 1 • Compute – EC2 – EC2 Container Service – Lightsail – Elastic Beanstalk – Lambda – Batch • Storage – S3 – EFS – Glacier – Storage Gateway • Database – RDS – DynamoDB – ElastiCache – Amazon Redshift • Networking & Content Delivery – VPC – CloudFront – Direct Connect – Route 53
- 23. AWS Services – Page 2 • Migration – AWS Migration Hub – Application Discovery Service – Database Migration Service – Server Migration Service – Snowball • Developer Tools – CodeStar – CodeCommit – CodeBuild – CodeDeploy – CodePipeline – X-Ray • Management Tools – CloudWatch – CloudFormation – CloudTrail – Config – OpsWorks – Service Catalog – Trusted Advisor – Managed Services • Security, Identity & Compliance – IAM – Inspector – Certificate Manager – Directory Service – WAF & Shield – Artifact – Amazon Macie – CloudHSM
- 24. AWS Services – Page 3 • Analytics – Athena – EMR – CloudSearch – Elasticsearch Service – Kinesis – Data Pipeline – QuickSight – AWS Glue • Artificial Intelligence – Lex – Amazon Polly – Rekognition – Machine Learning • Internet of Things – AWS IoT – AWS Greengrass • Game Development – Amazon GameLift • Mobile Services – Mobile Hub – Cognito – Device Farm – Mobile Analytics – Pinpoint • Application Services – Step Functions – SWF – API Gateway – Elastic Transcoder
- 25. AWS Services – Page 4 • Contact Center – Amazon Connect • Messaging – Simple Queue Service – Simple Notification Service – Simple Email Service • Business Productivity – WorkDocs – WorkMail – Amazon Chime • Desktop & App Streaming – WorkSpaces – AppStream 2.0
- 26. SUPPLEMENTARY
- 27. Themes • Design for failure and nothing fails • Build security in every layer • Leverage different storage options • Implement elasticity • Think parallel • Loose coupling sets you free • Don’t fear constraints
- 28. Well Architected Framework 5 Pillars of Design, Development and Operations • Security • Reliability • Scalability • Predicable Performance • Cost Control
- 29. Cloud Adoption Framework • Business Perspective • Platform Perspective • Maturity Perspective • People Perspective • Process Perspective • Operating Perspective • Security Perspective
- 30. Typical stack utilizing mix of Infrastructure and Managed Services • Route53 (DNS) – feature rich • CloudFront (Content Delivery Network) • S3 (Object Storage, ideal for Static Content) – 3 flavors • ELB (Load Balancing) • ASG (Auto Scaling) • EC2 (Virtual Servers) • RDS (Managed Database) – numerous flavors • ElastiCache (Managed Cache) • SES (SMTP Gateway)
- 31. Virtual Machines, Containers, Functions • Virtual Machines – AMI – Patching – Multi-threaded/Multi-task – Hours to Months – Per VM/Per Hour • Containers – Container File – Versioning – Multi-threaded/Single-task – Minutes to Days – Per VM/Per Hour • Functions – Code – Versioning – Single-threaded/Single-task – Microseconds to Seconds – Per Memory/Second/Per Request (Free Tier)
- 32. AWS Reference Architectures/AWS Marketplace • Simplified PDFs depicting, at a high level, an application use case • Deployment Guides provide detailed information around deploying a specific application • CloudFormation Templates provide deployment templates to alleviate much of the manual work • Often, products traditionally deployed on-premise can be found on the AWS Marketplace in pre-build appliance images or CloudFormation Templates
- 33. Partner Ecosystem Products/Services • Thousands of products/services available on the AWS Marketplace to support DevOps needs. • Some delivered as services, some delivered as stacks. • Our approach is to partner with “one of each”, which helps augment AWS’ offering and expand our capabilities (many customers are already invested in a solution.
- 34. Migration • AWS Application Discovery Service – Agent based application discovery • AWS Database Migration Service – Migration and replication of same/disparate database platforms • AWS Import/Export – BYOD “sneakernet” migration • AWS Migration Hub – Ties Application Discovery and Server Migration together • AWS Server Migration Service – VMWare integrated server migration + replication • AWS Schema Conversion Tool – Migration of same/disparate database schemas • AWS Snowball – 80 TB hardened storage device for “sneakernet” migration • vmimport + vCenter Addon – VM Image or ISO import as an EBS Snapshot or AMI
- 35. Approaches for architecting for AWS • Deploy existing apps in AWS with minimal re-design • Good strategy if starting out on AWS, or if application can’t be re- architected due to cost or resource constraints • Primarily use core services such as EC2, EBS, VPC Lift-and-shift • Evolve architecture for existing app to leverage AWS services • Gain cost and performance benefits from using AWS services such as RDS, SQS, and so on Cloud-optimized • Architect app to be cloud-native from the outset • Leverage the full AWS portfolio • Truly gain all the benefits of AWS (security, scalability, cost, durability, low operational burden, etc) Cloud-native architecture
- 36. Leverage Many Storage Options One size does NOT fit all • Amazon S3 – large objects • Amazon Glacier – archive data • Amazon CloudFront – content distribution • Amazon DynamoDB – simple non-relational data • Amazon EC2 Ephemeral Storage – transient data • Amazon EBS – persistent block storage with snapshots • Amazon RDS – Automated, managed MySQL • Amazon Redshift – Data warehouse workloads
- 37. Q&A • Questions?
- 38. Further Learning • Getting Started: https://aws.amazon.com/getting-started • General Reference: http://docs.aws.amazon.com/general/latest/gr • Global Infrastructure: https://aws.amazon.com/about-aws/global- infrastructure/ • FAQs: https://aws.amazon.com/faqs • Documentation: https://aws.amazon.com/documentation/ • Architecture: https://aws.amazon.com/architecture • Whitepapers: https://aws.amazon.com/whitepapers • Security: https://aws.amazon.com/security • Blog: https://aws.amazon.com/blogs • Service Specific Pages: https://aws.amazon.com/service • SlideShare: http://www.slideshare.net/AmazonWebServices • Github: https://github.com/aws and https://github.com/awslabs
- 39. Community (Meetups) • Boca Raton: https://www.meetup.com/awsflorida/ • Doral: https://www.meetup.com/AWSUserGroupDoral/ • Fort Lauderdale: https://www.meetup.com/South- Florida-Amazon-Web-Services-Meetup/ • Jacksonville: https://www.meetup.com/AWS-User- Groups-of-Florida-Jacksonville/ • Miami: https://www.meetup.com/aws-user-group- miami/ • Orlando: https://www.meetup.com/Orlando-AWS- Users-Group/ • Palm Beach Gardens: https://www.meetup.com/AWS- Users-Group-of-Florida-Palm-Beach-Gardens/ • Tampa: https://www.meetup.com/Tampa-AWS-Users- Group/
Notas do Editor
- Who are you? Patrick Hannah, CloudHesive (where I’m a co-founder and the VP of Engineering) What’s your background? Architecture, Security and Operations on AWS for 6 years, prior to that Contact Center Architecture and Operations for over 8 years. What do you hope to get out of the presentation? I want to help folks get as the same out of AWS as I have. I’d also like to see how others are using AWS – as with just about any thing in technology there are multiple ways to do something right (or wrong). How are you using cloud services? At CloudHesive, we provide consulting services to customers who wish to, or who are, leveraging AWS and we also use a number of AWS services to host our managed services customers (and the back-office systems supporting them). Why did you pick the cloud services that you are using? AWS is at the forefront of Cloud; their service catalog can support most traditional on-premise software use cases (infrastructure) but they also offer more abstracted services for software built on the cloud (such as SQS, which is one of my favorite) that negate the need to manage server infrastructure – on premise or on cloud. What about you?
- Before we talk about how we do it let’s talk about why. Cost savings may come to mind; Scalability may come to mind; You may be getting asked by your customers or your management team. I think a better reason why is you are creating a paradigm shift in your organization – and this is where the true value is: The acquisition, deployment and management of hardware infrastructure has changed; you are no longer purchasing goods (servers, storage, network), you are purchasing services (IaaS, PaaS, SaaS) and outcomes. You provision, decommission and manage your infrastructure like a software product and with that you have unprecedented access to automate these activities by eliminating time consuming, manual tasks and uncertainty around the state of infrastructure. The only hardware you will care about is the endpoints and connectivity to the services you are consuming. The methodologies that you might have used for ensuring the security, availability and scalability of infrastructure no longer apply. Organizations can take advantage of these capabilities in a methodical approach overtime; starting with a “lift and drop” and implementing new features in their applications to take advantage of abstracted services (PaaS, etc.) Moving a single application to AWS is a great start but with some work you can drive change throughout your organization. Over the next few slides I’ll discuss some of the key benefits of moving to AWS (Yes, the cloud is more than iTunes and Amazon doesn’t just sell books)
- Hardware stops becoming the solution to your problems; whether you are trying to solve a problem with application performance or are clamoring for more hardware to scale due to a business event. You change your way of thinking; capacity planning stops becoming reactionary, you stop overbuilding and can better support the volume peaks and valleys of your application. Scale is no longer achieved by finding the largest server to run your application on; Scale is instead achieved by breaking your application up into multiple functional components. These components can now run on appropriately sized servers, and even multiples servers (in an N+1 configuration) to allow for limitless scalability and support your resiliency objectives. Data persistence has changed as well; You are no longer limited to two technologies for data persistence (filesystem/block and OLTP database). Your options are much more use case specific.
- Now that you’ve gone “hands off” on infrastructure half of the availability problem is solved – when an infrastructure component fails you bring up a replacement with minimal effort. You design your software to be robust enough to survive an infrastructure failure – and you use abstracted services (more on both later) - A modern application should be componentized, designed to be stateless and distributed and with a persistence layer, limiting the impact of the failure of an infrastructure component and eliminating infrastructure component uniqueness and allowing it to be thrown away. With a hands off approach you’ve also eliminated the human error factor – no one wants to talk about it but it’s a common cause impact to availability.
- Servers are no longer grouped in physical networks (Private, DMZ, etc.); these networks are now logical and are extended to individual servers by way of Host or Hypervisor based Security. Resources (such as servers) are hands off; Provisioning, Change and Decommissioning is done out of band and in an automated fashion where infrastructure and applications come from a known, version controlled source. The same approach is applied to break/fix activities as well; Why log into a server to view operational (log and event) data or verify a configuration/file version when you now know, without a doubt, what was deployed AND your operational data is centrally available. A common preconception is that the public cloud is insecure but in my experience I am seeing more and more security offers cite the public cloud as being more secure. One of these reasons is the Shared Responsibility model
- When I first started using AWS, I did what most folks might do, went to the AWS website, read about cloud on Wikipedia, etc. Mostly what I got out of it was the cloud was about Mashups (composite panels of information comprised of multiple data sources) and AWS had a service called EC2 that acted like an on-premise VM might, except the data was not persistent. At the time I wasn’t necessarily a VM Advocate either; most of the workloads I was running were latency sensitive and VM technology (and practices) at the time were not ideal. My initial reaction was that of being underwhelmed. This was over 6 years ago, and a lot was changed, both in my understanding, the capabilities and the adoption of AWS and Public Cloud in general. Since today’s audience is a mix of business and technical users, users who may have experience with AWS, another public cloud provider like Azure or GCE, or on premise cloud solutions like VMWare, or are just getting started, I will try to maintain a balance between the basics and diving deep into services. Feel free to ask questions along the way – if there are specific areas you would like to dive into, I aloted time at the end of the presentation to do so.
- The key concept is: if you are consuming an IaaS service, you have more responsibility for the care and feeding of that service than if you were consuming a PaaS or SaaS Service (which is the norm)
- A common fallacy is that AWS (which came about in July 2002) was a way to sell unused capacity on the amazon.com side of the business. Quite the opposite is true. What is more accurate is a lot of amazon.com talent and technologies came to form AWS (in the form of SQS, S3 and EC2) out of a need to consume infrastructure and platform services programmatically. Amazon.com only moved to AWS in November 2010. As we talk about AWS, try not to think too much about it in terms of datacenters, but the output or characteristics of the services provided. Yes, it is true, AWS does operate datacenters but the scale at which AWS operates precludes the use of many traditional datacenter management techniques, which supports scale but also other operational requirements such as security (at scale you are more likely to implement separation of duties). (And for what it’s worth AWS has never gone down – there have been outages, which are isolated to singular regions, but more typically specific availability zones.
- AWS serves hundreds of thousands of customers in more than 190 countries. Amazon CloudFront and Amazon Route 53 services are offered at AWS Edge Locations
- You can choose to deploy and run your applications in multiple physical locations within the AWS cloud. Our data center footprint is global, spanning 5 continents with highly redundant clusters of data centers in each region. Amazon Web Services are available in geographic Regions that are independent and separate as much as possible for data sovertenty and as much as possible offer the same services. When you use AWS, you can specify the Region in which your data will be stored, instances run, queues started, and databases instantiated. Within each Region are Availability Zones (AZs). Availability Zones are distinct locations that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. By launching instances in separate Availability Zones, you can protect your applications from a failure (unlikely as it might be) that affects an entire zone. Regions consist of one or more Availability Zones, are geographically dispersed, and are in separate geographic areas or countries. The Amazon EC2 service level agreement commitment is 99.95% availability for each Amazon EC2 Region. Our footprint is expanding continuously as we increase capacity, redundancy and add locations to meet the needs of our customers around the world. AWS maintains Regions, which are major geographic areas, and Availability Zones (AZ), which are individual data centers, or clusters of data centers that make up a Region. Independent and separate that as much as possible offer the same services. But they have isolation as much as possible for data sovertenty. Today, AWS operates 9 Regions around the world. Each Region has a minimum of 2 Azs (separate power, flood planes, etc) to allow customers to set up high availability architectures and data redundancy. An abstraction of a datacenter with fault isolation but close enough to build high availability architectures. In addition to Regions, AWS maintains edge locations that supporting Route 53 DNS and Amazon CloudFront (CDN) points of presence.
- AWS has developed the broadest collection of services available from any cloud provider. Our approach to regions, availability zones, and POPs provides global coverage for high availability, low latency applications. Foundation services across compute, storage, security, and networking offer customers flexibility in their architecture. We have a full spectrum of options to meet most price-to-performance scenarios. We offer the capability for both managed and unmanaged database options. The offerings for Analytics and Application Services enable advanced data processing and workloads. AWS Redshift, our cloud-based data warehouse, is the fastest growing service in the history of AWS. Our management tools offer a lot of insight and flexibility to let you manage your AWS resources through either our tools or the management tools you’re already familiar with. Recent expansion into enterprise applications has been entirely driven by customer feedback on where they’d like us to deliver value.
- Older AWS deployments may be leveraging their own solutions, running on EC2 to handle a number of services that are now offered as managed or abstracted services Newer AWS deployments might not even need EC2 – consider Lambda or ECS instead
- One of pieces of information we will use in our migration is the reference architecture and marketplace.
- Each service has it’s own site and set of documentation The SlideShare presentations can be an invaluable resource when it comes to diving into the details The GitHub repositories have excellent examples of applications you can build on AWS