Recommended
More Related Content
What's hot
What's hot (20)
Similar to Adopting AWS in your organization - ITPalooza 2015
Similar to Adopting AWS in your organization - ITPalooza 2015 (20)
More from CloudHesive
More from CloudHesive (20)
Recently uploaded
Recently uploaded (20)
Adopting AWS in your organization - ITPalooza 2015
- 1. Adopting Amazon Web Services (AWS) in your organization Presented by Patrick Hannah VP of Engineering, CloudHesive
- 2. Introduction • Who am I? • What’s my background? • What do I hope to get out of the presentation? • How am I using cloud services? • Why did I pick the cloud services that I am using?
- 3. What are we going to talk about? • My philosophy on moving to AWS • Brief overview of AWS • A typical migration strategy – How to start the move to AWS with an existing application – How to enhance the application to leverage AWS’ abstracted services – Conclusion
- 4. Why move to AWS? • Is it cost savings? • Is it because it’s infinitely scalable? • Is it a shiny object?
- 5. 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
- 6. 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
- 7. Scalability • 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. Overview of AWS • Regional footprints, some with special use cases (GovCloud, China) • Access to services via a Web Based Console (customizable via AWS Service Catalog) or Programmatically (CLI/API/SDK) using credentials with granular role assignment (Identity & Access Management) • Access to E-Mail, Chat and Phone support via AWS Support and proactive recommendations via Trusted Advisor • Access to third party products and services via AWS Marketplace • Access to itemized billing via AWS Billing and Cost Management • Access to infrastructure monitoring via Amazon CloudWatch • Access to an audit trail via AWS CloudTrail and configuration change history via AWS Config
- 9. Overview of AWS Infrastructure Services • Networking – Amazon VPC – Software Defined Network – AWS Direct Connect – Dedicated Connectivity – Elastic Load Balancing – Load Balancing – Amazon Route 53 – DNS – Amazon CloudFront – Content Delivery Network • Compute – Amazon EC2 – Virtualized Servers • Storage & Content Delivery – Amazon S3 – Object Storage – Amazon EBS – Block Storage – Amazon EFS – NFS Storage – Amazon Glacier – Long Term Object Storage – AWS Import/Export/Snowball – Bulk Import/Export of data via Disk • Database – Amazon RDS – Managed RDBMS – Amazon DynamoDB – NoSQL – Amazon ElastiCache – Managed In Memory Cache – Amazon Redshift – Managed Data Warehouse – Amazon Elasticsearch Service – Managed ElasticSearch – Amazon EMR – Managed Big Data platform – Amazon CloudSearch – Managed Indexer
- 10. Overview of AWS Enterprise, Security and Automation Services • Enterprise Applications – Amazon AppStream – Managed Application Publishing – Amazon WorkSpaces – Managed Desktop Publishing – Amazon WorkDocs – Managed Document Sharing – Amazon WorkMail – Managed Enterprise E-Mail – Amazon SES – Managed SMTP Gateway – AWS Directory Service – Managed Directory Service (Active Directory Compatible) • Security & Identity – AWS CloudHSM – Dedicated HSM Appliances – AWS KMS – Managed Data-At-Rest Encryption – Amazon Inspector – Managed Application Security Scanner – AWS WAF – Managed Web Application Firewall – AWS IAM – User Credential Management • Automation – Auto Scaling – Managed Infrastructure Scaling – AWS Elastic Beanstalk – Managed Application Deployment – AWS CloudFormation – Infrastructure Configuration Management – AWS CodeCommit – Managed Repository – AWS CodeDeploy – Managed Software Deployment – AWS CodePipeline – Managed Continuous Delivery Service – AWS OpsWorks – Infrastructure + Software Configuration Management
- 11. Overview of AWS Managed (Abstracted) Services • Amazon EC2 Container Service – Managed Docker Container Deployment • Amazon API Gateway – Managed API Gateway • AWS Lambda – Managed Application Container • Amazon Cognito – Data Persistence for Mobile Devices • Amazon SNS – Managed Notification Service • Amazon Elastic Transcoder – Managed Transcoding Service • Amazon SQS – Managed Queue Service • Amazon SWF – Managed Workflow Service • Amazon Kinesis – Managed Data Pipeline (Streaming) • AWS Data Pipeline – Managed Data Pipeline (Bulk)
- 12. 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
- 13. The Strategy • Pick an Application to Migrate • Document the Application • Review the AWS service offerings • Take a look at the Reference Architectures published by AWS • Take a look at the AWS Marketplace • Do the work
- 14. The Application • Located in multiple datacenters globally • Large amounts of power, network gear, and time • Hardware needs to be refreshed • Issues with storage scalability and supporting business growth
- 15. Spot the Difference Older On Premise Deployed on AWS
- 16. Application Technical Overview • All servers are running Microsoft Windows – Some services offer active/passive failover – Some services offer n+1 scalability • Data can be persisted one of two ways: – Microsoft SQL Server, Clustered and Replicated – Windows File Server (via FTP) • Various Windows services communicate with each other using a proprietary bus – Runs in Private/Production Network (Shared Infrastructure) • Agent and Supervisor Java client connects to a J2EE Application running on Oracle Weblogic – Runs in DMZ Network (Shared Infrastructure) – Load Balanced on (Shared Infrastructure) • E-Mail is handled through corporate Mail Server (Shared Infrastructure) • There are shared infrastructure services as well (Active Directory, Monitoring, etc.)
- 17. The Strategy • Pick an Application to Migrate – Done • Document the Application - Done • Review the AWS service offerings - Done • Take a look at the Reference Architectures published by AWS - Done • Take a look at the AWS Marketplace - Done • Do the work !!!
- 18. Shared Infrastructure (Base) • Let’s first setup our shared Infrastructure • This use case is very basic, but these are the AWS services we would start with: – VPC – IAM – CloudTrail – Config – CloudWatch
- 19. Shared Infrastructure (Application) • We started with a basic concept of shared infrastructure but let’s not forget the shared infrastructure the application currently relies on: – Active Directory – E-Mail
- 20. Initial Deployment • Let’s move on to our initial deployment • This use case is very basic, but these are the AWS services we would start with: – EC2 – Auto Scaling – Elastic Load Balancing – EBS – KMS – RDS – CloudFormation
- 21. Ongoing Enhancements • How can we enhance our application to leverage AWS? • Use Abstracted Services with the goal of eliminating the Windows servers • Some hypothetical scenarios: – SQS – S3 – ElastiCache – ElasticSearch – CloudFront – SES
- 22. Conclusion and Some Advice • Plan out your migration • Know the application you are migrating • Be open to new ideas • Utilize the vast AWS knowledge sources • Define success criteria and benchmarks • AWS Adoption is an on-going process
- 23. Further Learning • Getting Started: https://aws.amazon.com/getting-started – $75 Gift Card !!! Come by our booth • 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
- 24. Florida Meetups • http://www.meetup.com/South-Florida-Amazon- Web-Services-Meetup/ • http://www.meetup.com/awsflorida/ • http://www.meetup.com/aws-user-group-miami/ • http://www.meetup.com/AWS-User-Groups-of- Florida-Jacksonville/ • http://www.meetup.com/Miami-AWS-Users-Group/
- 25. THANK YOU! Want a copy of this presentation? sales@cloudhesive.com http://www.cloudhesive.com
Editor's Notes
- 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). I’ve drawn on experience in both spaces in this presentation. 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.
- 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 take a real world application, explore the nuances of how it operates, determine which AWS services are a good fit for immediate use and which AWS services we can implement overtime, as the application evolves. 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 pointers around a successful migration.
- 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. 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). You provision, decommission and manage your infrastructure like a software product; 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)
- 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
- 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.
- 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.
- This is not necessarily complete and has been resorted to suit this presentation. A key point to note is when I refer to infrastructure I refer to building blocks and when I refer to abstracted I refer to a managed service to solve a specific requirement (like SES, SQS, etc.)
- One of pieces of information we will use in our migration is the reference architecture and marketplace.
- Pick an Application Ask yourself What Challenges do you have today? What problems would moving to AWS solve? Document the Application Infrastructure Hosting the Application The components that comprise the Application Dependencies the Application may have in your Infrastructure Security controls Review the AWS service offerings What services can you immediately take advantage of What services can you leverage in the future? Take a look at the Reference Architectures published by AWS Maybe the leg work has already been done for you? Take a look at the AWS Marketplace Is the product or a component supporting the product already there? Do the work Start with Shared Infrastructure Components Move on to the Application
- This is the application we will be migrating, which is a Contact Center platform I’m quite familiar with, you would traditionally find hosted on-premise and would be a great use case for moving to AWS End users (customers) – not depicted send an E-Mail to the company’s customer service E-Mail Address Agents handle E-Mail requests through a Java client Supervisors monitor the agent activity through a Java client Statistical information on the interaction is saved to the database Servers running a Windows application - basically a workflow engine (E-Mail, IM, ACD, Stats) that tie it all together Chat transcripts are saved to a file server
- Lets look at the infrastructure hosting this application today and an example of what the infrastructure might look like using one of the AWS Reference Architectures What differences do you notice about the two diagrams? Of course they depict the application from two different perspectives BUT this is a key differentiator. On AWS hardware infrastructure is managed by AWS, not your organization and instead of access to a datacenter, KVM, etc. you are provided with an interface (an actual interface or an API) where you can provision, decommission and configure services. Services can be any number of things; something as basic as a virtual server (EC2 Instances), that you alone manage the software on or something more abstracted like a Load Balancer (ELB) where scalability and availability is handled by AWS.
- The key note is there are components that are dedicated to this application and components this application shares with other applications (not depicted) What we can conclude is that there is no current Reference Architecture or AWS Marketplace offering for this application or its components, so we will build it from scratch (This is just an example – you can run Linux, Windows and almost any piece of Software that runs on these Operating Systems).
- Pick an Application Ask yourself What Challenges do you have today? What problems would moving to AWS solve? Document the Application Infrastructure Hosting the Application The components that comprise the Application Dependencies the Application may have in your Infrastructure Review the AWS service offerings What services can you immediately take advantage of What services can you leverage in the future? Take a look at the Reference Architectures published by AWS Maybe the leg work has already been done for you? Take a look at the AWS Marketplace Is the product or a component supporting the product already there? Do the work Start with Shared Infrastructure Components Move on to the Application
- VPC – create a network topology, firewall rules, connectivity to Internet and on-premise (Direct Connect optional) IAM – authenticate users and services to AWS infrastructure, in simple terms each Administrator of Infrastructure will get his/her own credentials (and not “all access”) CloudTrail – audit the requests made by users and services Config – create point in time snapshots of the configuration of AWS services CloudWatch – monitor the hardware infrastructure
- How and why we would do this…
- EC2 – the basic server, storage and network functionality provided by AWS Auto Scaling – we would use autoscaling on the application tier to handle an influx of requests (typical of a contact center application during peak periods – like Black Friday or Cyber Monday) Elastic Load Balancing – our on-premise load balancer would stay behind and be replaced with ELB EBS – our block storage needs would be fulfilled by EBS KMS – we would encrypt our EBS volumes using KMS RDS – our Microsoft SQL Cluster would be moved to RDS, using the Multi-AZ (Mirroring) functionality CloudFormation – once we have modeled out or application environment we can template it and redeploy it procedurally (Bonus points) – Code Commit and Code Deploy
- (Fast forward) Now that you’ve deployed your application you can start thinking about ways you can leverage AWS to enhance or optimize your environment AWS has a concept of abstracted services; services that are built on AWS services where AWS handles some level of management around the software, scale or reliability (like ELB mentioned earlier) Some hypothetical scenarios: Replace the service bus with SQS or even some of the services with SWF Store chat transcripts on S3 (with archival to Glacier) Use a caching layer (ElastiCache) to lesson the load on the persistence layer Index the contents of the chat transcripts in ElasticSearch Implement a CDN (CloudFront) Implement SES to handle inbound and outbound E-Mail A number of other solutions around serverless infrastructure (API Gateway, Lambda), Analytics, Mobile, and Data Warehousing. In short, your entire application can be converted to eliminate the need to run on an actual server.
- Have a thorough understanding of the requirements of the application. What was the best solution to a technical problem 10 years ago is not the best solution now. You don’t need to be an expert of everything AWS has to offer; their services are well documented, supported and there is a large community and partner ecosystem willing to provide support (us!). Define benchmarks to not only measure the performance but also the success of the project – use data and facts to drive conversations. AWS adoption is an ongoing activity with benefits gained along the way.
- Come by our booth and learn how to get 75$ in AWS Credit! 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
- CloudHesive sponsors 5 Meetups in Florida; 4 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 (especially Jacksonville)