Introduction to AWS July

Editor's Notes

• #3: 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 5 years, prior to that Contact Center Architecture and Operations for over 8 years (SaaS but we didn’t call it that). 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?
• #4: The primary focus of this presentation is around how mid-sized companies can take advantage of AWS by migrating their existing applications, otherwise known as “lift and drop”. It doesn’t end there; over time AWS customers can enhance their application to leverage more abstracted AWS services (which we will talk about shortly), removing dependencies on traditional network, server and storage infrastructure and solving your business challenges around security, availability and reliability. We will also discuss the business strategy around migrating to AWS, some of the differences between traditional on-premise infrastructure and AWS, and some high level recommendations on how to best leverage AWS.
• #5: 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)
• #6: 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)
• #8: 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.
• #9: 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.
• #10: 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
• #14: Discuss concept of minimally viable product Discuss cloud scale, fault domains, distributed computing Discuss how AWS builds their own services on top of AWS
• #21: Account/Billing Management Alerts – alerts when a predefined threshold has been met Reports – granular reporting + forecasting Contacts – granular contacts for security, operations and billing Marketplace Often, products traditionally deployed on-premise can be found on the AWS Marketplace in pre-build appliance images or CloudFormation Templates 35 Categories 2300 Listings 800 ISVs 143M EC2 Instance Hours CloudWatch In addition to metrics and alarms now supports logs, dashboards, events and actions Tagging Manage your tags from one place using the Tag Editor Billing Tags for cross charging CloudFormation Automation of AWS components Reference Architectures/Marketplace are a great place to start OpsWorks Automation of AWS components and Configuration Management on the OS layer and above Elastic Beanstalk Automation of application deployments
• #22: Consider how people and things connect to you? IP Address Is it an Elastic IP? DNS Pointing towards an instance? Pointing (incorrectly) towards an IP Address of an ELB? Using Route53? What happens if an instance dies? Prevent user error: enable termination protection Recover from the failure of host hardware with CloudWatch Actions Auto Scaling Group + ELB VPC Peering between VPCs (in the same region) without deploying an EC2 based solution NAT Gateway without deploying an EC2 based solution Multiple CGWs with the same Peer IP Address + NAT + Stronger Encryption/Hashing VPC Logs Tenancy options have expanded Dedicated instances Dedicated hosts EC2 Run Command Remote commands to Windows or Linux instances
• #24: IAM What about instance roles? Problems with a policy? Use the Policy Simulator Is someone over permissioned? Use Access Advisor Is someone actually using the user/role? Use the Credential Report Active Directory Directory service comes in three flavors now AD Connector Lightweight Directory Service Full Active Directory Workspaces Easy Bastion (if you are a Windows shop)
• #26: 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
• #33: 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
• #34: CloudHesive sponsors 6 Meetups in Florida; 5 in the South Florida-Tri-County Area and one in North Florida We are always looking for ideas on topics, as well as attendees and speakers