Introduction to AWS and Docker on ECS

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?
• #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 more importantly outcomes. You manage the lifecycle of your infrastructure like a software product and with that you have unprecedented access to automate these activities and eliminate resource sucking 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. There is a tradeoff as well – don’t think of cloud computing the same way as you would managed hosting, or colocation. You have cattle not pets. Your servers, if you are using them, should ideally be designed with ephemerality in mind (of course you can move your systems as-is, but this should not be the end game) 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)
• #7: Imagine you gave everyone in your company the ability to buy whatever they needed to do their job from Amazon prime. They may have your company’s best interest in mind but they have day jobs – no one is holistically watching the spend, attributing the spend to output, negotiating bulk discounts and ensuring that overbuying is not happening. The same applies to AWS. Most organizations start slow, and rapidly ramp up their costs to a point where the savings (in dollars) no longer applies. It’s important that the right governance be put into place to manage cost and avoid being a detractor from the cloud. Further to that, I might not even need to buy a “server” anymore, I might just need to run a piece of code. That’s even cheaper, but we will talk more about that later.
• #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. You may eventually even break up your application into smaller services (microservices), which will allow for even more scale (again, not in the traditional sense but the people sense as well). 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: 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 than their own premise operations. When it comes to security in your own organization, consider how many full time employees you have that are dedicated to security. What aspect of your business are they responsible for? Now, consider AWS, who has a growing list of Certifications, Attestations, Laws, Regulations, Privacy, Alignments and Frameworks their services support (next slide) as well as services geared entirely towards security (which we will cover further in the presentation) and a partner ecosystem to fill the chasm Shared Responsibility model. Compared to traditional managed hosting strategies where roles/responsibilities around security responsibilities or relating to security are not well defined, the Shared Responsibility Model aims to clearly define at what layer of the solution you, the customer, are responsible for and at what layer the public cloud provider (in this case AWS) is responsible for. In most cases AWS provides you with services to address areas in the shared responsibility model that you would be responsible for, such as AAA and encryption 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. With both of these out of the way you are eliminating part of the human factor, which is a rather large challenge to security Finally, know that you are not the first of your kind to use AWS and those before you have paved the way
• #12: What good is power without the ability to manage it? Public cloud, specifically AWS, provide a unified interface to provision, change and decommission services, via an API or web based console. Further, the output of these services is captured and available for interrogation via the same interfaces. Additionally, management capabilities can be delegated out to users with as restrictive policies as are necessary eliminating the need to have a single group be responsible for the entire infrastructure and moving from a shared services model to empowering product owners to manage their destiny. Of course, most users have a full time job already, and this is where the partner ecosystem and marketplace come into play where a number of off the shelf solutions and design patterns are ready to launch or a consultant or managed services provider is ready to assist where needed.
• #13: Despite the popularity of the public cloud, many organizations are replacing traditional infrastructure with solutions capable of providing public cloud capabilities in a private cloud (on-premise format). That might be good for finding a new home for old hardware but in very rare circumstances Public cloud, in one form of another might have been the better choice. Very few organizations operate infrastructure as the core of their business and are unable to achieve the same economies of scale as public cloud provider. Hybrid is a good middle ground and a well supported use case on the public cloud, through connectivity options, design patterns and the marketplace ecosystem for solutions that are designed to bridge the gap (WAN optimization, storage, etc.)
• #14: 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 Some Advice: 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.
• #16: See: https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519
• #18: Discuss concept of minimally viable product Discuss cloud scale, fault domains, distributed computing Discuss how AWS builds their own services on top of AWS
• #25: 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
• #26: 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
• #28: 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)
• #30: 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 and can go Serverless (which is made easier with a Microservices architecture, to be expored later) – consider Lambda or ECS instead
• #35: Virtualization versus Containerization -Full Hardware versus Handles Container Image -Size and Layering and Optimization Can be built using -Base and customized at launch and committed/exported -Dockerfile -Docker-Build -Gradle Artifacts -Registry (REST), TAR file Microservices means a lot of containers doing a lot of things Multi-threaded/Multi-task -Single Process, no shell -Microservices How is this done? -Docker-Machine -Swarm -Docker-Compose -ECS which does all of the above Lifetime -Microservices means purpose built -Frequent deployments and scaling = limited lifetime Resource Management -Network -Storage -CPU -Memory Bonus -Simulation at scale -Freeze states -Revert states -Revisioning
• #36: Generalizations Paraphrased from http://queue.acm.org/detail.cfm?id=2956643
• #37: ECS is nice since it’s a native AWS service but is missing: service discovery/registry and secrets management Think of it like EBS for Docker whereas EBS is for Apps. With ECS you don’t have to roll your own, much like EBS Many products in the ecosystem to augment or replace ECS: Docker-machine – central docker machine management Swarm – flattens docker machines Kubernetes, OpenShift, Helios, MesoSphere, Docker DataCenter - compare to ECS Registrator, Consul – service discovery, registry (can integrate with AWS) Missing features: namespaces, automated rollouts and rollbacks, service discovery via DNS, automated container scaling based on resource usage, and of course, the promise of a self-healing system. Well supported ecosystem for ECS
• #38: ECS is nice since it’s a native AWS service but is missing: service discovery/registry and secrets management Think of it like EBS for Docker whereas EBS is for Apps. With ECS you don’t have to roll your own, much like EBS Many products in the ecosystem to augment or replace ECS: Docker-machine – central docker machine management Swarm – flattens docker machines Kubernetes, OpenShift, Helios, MesoSphere, Docker DataCenter - compare to ECS Registrator, Consul – service discovery, registry (can integrate with AWS) Well supported ecosystem for ECS
• #40: Let’s see a demo (which won’t do the power of Docker, Microservices and ECS justice)
• #46: 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
• #47: 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