Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to AWS ECS Microservices: Docker Deployment
Similar to AWS ECS Microservices: Docker Deployment (20)
More from CloudHesive
More from CloudHesive (20)
Recently uploaded
Recently uploaded (20)
AWS ECS Microservices: Docker Deployment
- 1. Introduction to AWS and Docker on ECS: Microservice Deployment on Amazon EC2 Container Service 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 • Introduction to AWS • Overview of AWS Services • Docker on ECS: Microservice Deployment on Amazon EC2 Container Service • Q&A
- 4. Introduction to Amazon Web Services and Cloud Computing
- 5. Why move to the Cloud? • Is it cost (dollars and hours) savings? • Is it because it’s massively scalable? • Is your CxO bugging you about it? • Is it a shiny object?
- 6. Cost Savings • Minimize/eliminate up front investment in hardware, software, support, connectivity, etc. (CapEx vs. OpEx) • Minimize/eliminate complexities in cross charging for shared services • Achieve higher economies of scale • “With great power there must also come great responsibility”
- 7. Scalability / Agility • 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 • Security First • Shared Responsibility security model across your cloud environment • Each host becomes its own security zone • Infrastructure lifecycle management no longer has a physical component • Administrative activities are done with automation in mind • You are not alone
- 11. Manageability • Configurable • Interrogatable • Granular permissions assignment • Ecosystem
- 12. What about on-premise? • Private Cloud • Hybrid Cloud • Can you achieve the same economies of scale? • Are you in the Cloud Infrastructure business?
- 13. Where to go next? • 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 or outsource it – you can get PoC dollars to prove out concepts
- 15. Gartner Magic Quadrant for Cloud Infrastructure as a Service, Worldwide
- 16. AWS’ Rapid Pace of Innovation AWS has launched a total of 522 new features and/or services to-date* in 2015, for a total of 1,696 new features and/or services since inception in 2006. 2011 82 159 2012 280 2013 516 2014 * As of 8 Oct 15
- 17. AWS’ History of Innovation AWS has been continually expanding its services to support virtually any cloud workload, and it now has more than 60 services that range from compute, storage, networking, database, analytics, application services, deployment, management and mobile. 2009 Amazon RDS Amazon VPC AWS Auto Scaling AWS Elastic Load Balancing 2010 Amazon SNS AWS Identity & Access Management Amazon Route 53 2011 Amazon ElastiCache Amazon SES AWS CloudFormation AWS Direct Connect AWS Elastic Beanstalk GovCloud 2012 Amazon SWF Amazon Redshift Amazon Glacier Amazon Dynamo DB Amazon CloudSearch AWS Storage Gateway AWS Data Pipeline 2013 Amazon CloudTrail Amazon CloudHSM Amazon WorkSpaces Amazon Kinesis Amazon Elastic Transcoder Amazon AppStream AWS OpsWorks 2014 AWS KMS Amazon Config Amazon Cognito Amazon Mobile Analytics Amazon EC2 Container Service Amazon RDS for Aurora Amazon Lambda Amazon WorkDocs AWS Directory Service AWS CodeCommit AWS CodePipeline 2015 Amazon EFS Amazon API Gateway Amazon WorkMail Amazon Machine Learning AWS Device Farm AWS WAF Amazon Elasticsearch Service Amazon QuickSight AWS Import/Export Snowball Amazon Kinesis Firehose Amazon RDS for MariaDB Amazon Inspector AWS Database Migration Service AWS IoT Amazon EC2 Container Registry Amazon Kinesis Analytics AWS Mobile Hub * As of 8 Oct 15 AWS EMR Amazon CloudWatch Amazon FPS AWS Import/Export Trusted Advisor AWS Service Catalog AWS CodeDeploy Amazon CloudWatch Logs
- 22. AWS Services
- 23. AWS Services
- 24. Managability • Interfaces – AWS Management Console – AWS CLI, Tools, Tookits, SDKs and Mobile SDKs – AWS Billing and Cost Management – AWS Support – AWS Marketplace/Quick Starts – AWS Training & Certification – AWS Documentation • Management – Amazon CloudWatch – AWS CloudTrail – AWS Config – AWS Service Catalog – Trusted Advisor • Provisioning – AWS CloudFormation – AWS OpsWorks – AWS Elastic Beanstalk – Auto Scaling
- 25. Infrastructure • Network – Amazon Route 53 – AWS Direct Connect – Amazon VPC – Elastic Load Balancing • Compute – Amazon EC2 – Amazon EC2 Container Registry – Amazon EC2 Container Service – AWS Lambda • Storage – Amazon EBS – Amazon EFS – Amazon S3 – Amazon Glacier – AWS Storage Gateway – Amazon CloudFront
- 26. Abstracted Services • Database – Amazon RDS – Amazon Redshift – Amazon DynamoDB – Amazon ElastiCache • Analytics – Amazon Elasticsearch Service – Amazon CloudSearch – Amazon EMR – Amazon Machine Learning • Pipelines – AWS Data Pipeline – Amazon SQS – Amazon Kinesis
- 27. Enterprise • Security – AWS WAF – Amazon Inspector – AWS Certificate Manager – Identity & Access Management – AWS KMS – AWS CloudHSM – AWS GovCloud (US) • Enterprise – AWS Directory Service – Amazon AppStream – Amazon WAM – Amazon WorkDocs – Amazon WorkMail – Amazon WorkSpaces • Migration – AWS Application Discovery Service – AWS Database Migration Service – AWS Import/Export – AWS Schema Conversion Tool
- 28. Development • Tools – AWS CodeCommit – AWS CodeDeploy – AWS CodePipeline • Services – Amazon SES – Amazon SNS – Amazon SWF – Amazon API Gateway – Amazon Elastic Transcoder – Amazon Cognito • Mobile/Game/IoT – AWS Mobile Hub – Amazon Mobile Analytics – AWS Device Farm – Amazon Lumberyard – Amazon GameLift – AWS IoT
- 29. 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)
- 30. AWS Docker on ECS: Microservice Deployment on Amazon EC2 Container Service
- 31. Key Concepts • OMG so many terms • Why use Docker compared to other solutions? • Why use ECS when I can roll my own solution? • Why leverage a Microservices design pattern?
- 32. Docker Terminology • Images – A stateless image of a file system containing all dependencies • Containers – A runtime instance of a Docker image • Repository – A set of docker images • Tag – A label used to distinguish one image from another • Registry – A hosted collection of repositories
- 33. ECS Terminology • ECS – Elastic Container Service • Container Agent – Responsible for communicating between Container Instances and ECS • Container Instances – An EC2 instance running the container agent • Clusters – A group of container instances • Task Definitions – Instance start/container runtime parameters • Services – Quantity of task definitions to run1 • Tasks and Scheduling – When to run a task definition (which could be all the time, scheduled, etc.)
- 34. How does Docker compare with traditional solutions? • Virtualization versus Containerization • Disk Image + Configuration Management versus Container Image • Artifact Creation versus Container Image Creation • Artifact Repository versus Image Repository and Registry • Provisioning + Configuration Management versus Orchestration and Scheduling • Use of Multi-threaded/Multi-task versus Multi-threaded/Single-task • Lifetime of Hours to Months versus Minutes to Days • Resource Management • Bonuses
- 35. What’s a Microservice? • Small and serve a specific purpose (for example, user authentication) • Easy to replace/modular • Platform agnostic/independent (one service can be Node, another can be Go) • Self contained and eliminates the need for coordinated deployments (for example, a deployment of a new version of the user authentication service does not disrupt the functionality of services dependent on it) • Integrates with other microservices through an API, rather than through shared services (database, cache, filesystem, shared memory, etc.) • Eliminates the need to have intimate or extensive knowledge of the entire application or other team’s services
- 36. What’s ECS offer that I’d otherwise have to do on my own? • Management Interfaces – Console – CloudWatch – CLI – API • Logging – CloudWatch – CloudTrail – Console – Local • Integration with other AWS services – ELB/ALB – Autoscaling – CloudFormation – EC2/EBS/VPC
- 37. What’s ECS offer that I’d otherwise have to do on my own? • Purpose Built AMI (can use your own, Rancher, CoreOS, Suse as well) – Amazon Linux – ECS Agent – Docker – Initialization Scripts – 30 GB of storage (can increase) • Image Registry (other registries, like Docker Hub and private are supported) – AWSified • Scheduler – ELB/ALB – AutoScaling – Self Healing • Task specific IAM Roles – More granular than instance roles
- 38. Interacting with ECS • Standing up an ECS Cluster – Console (Wizard - /getStarted) – CloudFormation – API – Third Party • Deploying into an ECS Cluster – Console (Wizard - /getStarted) – CloudFormation – API – Third Party (CI) • Updates to an ECS Cluster – Console – CloudFormation – API – Third Party (CI)
- 39. Demo of ECS in the Console and Q&A
- 40. Question 1 • How does Docker change the Software Development Lifecycle?
- 41. Question 2 • What AWS Service or Services can allow you to automate deployment of “Infrastructure” on AWS?
- 42. Question 3 • What is one approach you can take to make an application or service on EC2 more resilient?
- 43. Question 4 • What advantage does ECS have over rolling your own EC2 instances to act as Docker hosts?
- 44. Question 5 • What IAM capability allows an application access to AWS services without the burden of hardcoded and manually managed credentials?
- 45. 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
- 46. Florida Meetups • http://www.meetup.com/aws-user-group-miami/ • http://www.meetup.com/Miami-AWS-Users-Group/ • http://www.meetup.com/South-Florida-Amazon- Web-Services-Meetup/ • http://www.meetup.com/awsflorida/ • http://www.meetup.com/AWS-User-Groups-of- Florida-Jacksonville/ • http://www.meetup.com/AWS-Users-Group-of- Florida-Palm-Beach-Gardens
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). 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 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)
- 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.
- 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.
- 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.
- 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
- 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.
- 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.)
- 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.
- See: https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519
- Discuss concept of minimally viable product Discuss cloud scale, fault domains, distributed computing Discuss how AWS builds their own services on top of AWS
- 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
- 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
- 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)
- 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
- 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
- Generalizations Paraphrased from http://queue.acm.org/detail.cfm?id=2956643
- 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
- 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
- Let’s see a demo (which won’t do the power of Docker, Microservices and ECS justice)
- 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 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