DevOps on AWS

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 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?
• #5: This is the definition straight from Wikipedia. In my experience, there is no single agreement as to what DevOps is, and much like Cloud was a trending word when it first came into the public eye, I see the same for DevOps. To me, DevOps is solving the problem of siloed Development and Operations teams, and one of the main areas this is solved is by folks in Operational roles enabling folks in Development roles the ability to operate more autonomously and visa versa. This might involve using certain tools, this might involve certain processes. I’d consider it a flexible framework or concept. DevOps existed before the popularity of AWS, but AWS has been a strong enabler of it, initially through programmatic and instant access to infrastructure and now providing tooling and best practices in support of DevOps. I have a few slides that speak to DevOps in general terms, but will try to move quickly through them as most of the audience is familiar with DevOps and likely has an opinion on it already 
• #6: I consider DevOps to be in it’s third generation In the second generation, the programmatic creation of infrastructure resources afforded by AWS enables this. Heavy emphasis is placed on configuration management (Puppet, Chef, Ansible, etc.) In the third generation, less emphasis is placed on configuration management (it’s still important) and more placed on the discovery and orchestration of pre-configured containers. Both second and third generations leverage abstracted services (ELB, etc.) and take advantage of them, but do not necessarily require them (keeping in mind all infrastructure is accessed via an API so from a development perspective it doesn’t matter (operationally, it does, though)
• #7: DevOps, as you can imagine, is a concatenation of Development and Operations, it doesn’t imply the involvement of Developers and Operations folks, though. DevOps can start as an initiative by either party, or even a different group but everyone benefits. The business is (hopefully) the beneficiary of reduced operational costs, happier customers and faster time to market. Security (especially now with SecOps or DevSecOps) is (hopefully) the beneficiary of a stronger security footprint (automation = less cooks in the kitchen, for example) Every aspect of the organization will have some benefit and role to play.
• #8: You’ve seen this slide before, I’m sure. All of these services play a role in DevOps, whether it’s supporting it (infrastructure), making it easier to build infrastructure (primatives/abstracted/managed services) or being directly part of the pipeline. The next few slides will talk about each of these in varying details
• #9: CodeStar Ties many of these services together in a painless, easy to use interface CodeCommit/EC2 Container Registry Git + Docker repository CodeBuild Build engine CodeDeploy Deployment engine (see also SSM) CodePipeline Pipeline
• #10: “Things that run code” Starting at the highest level, we have Lambda and at the lowest level, EC2 In between, we have services leveraging EC2, that provide varying degrees of configurability, all intended to automate the configuration and operations of infrastructure Lightsail is very interesting as it doesn’t expose an EC2 instance but is basically providing one with a generous bandwidth allocation Of most interest is ECS, which we will discuss on the next few slides
• #11: 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
• #12: 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
• #16: Metric Description ChildHealthCheckHealthyCount For a calculated health check, the number of health checks that are healthy among the health checks that Amazon Route 53 is monitoring. Valid statistics: Average (recommended), Minimum, Maximum Units: Healthy health checks ConnectionTime The average time, in milliseconds, that it took Amazon Route 53 health checkers to establish a TCP connection with the endpoint. You can view ConnectionTimefor a health check either across all regions or for a selected geographic region. Valid statistics: Average (recommended), Minimum, Maximum Units: Milliseconds HealthCheckPercentageHealthy The percentage of Amazon Route 53 health checkers that consider the selected endpoint to be healthy. You can view HealthCheckPercentageHealthy only across all regions; data is not available for a selected region. Valid statistics: Average, Minimum, Maximum Units: Percent HealthCheckStatus The status of the health check endpoint that CloudWatch is checking. 1 indicates healthy, and 0 indicates unhealthy. You can view HealthCheckStatus only across all regions; data is not available for a selected region. Valid statistics: Minimum Units: none SSLHandshakeTime The average time, in milliseconds, that it took Amazon Route 53 health checkers to complete the SSL handshake. You can view SSLHandshakeTime for a health check either across all regions or for a selected geographic region. Valid statistics: Average (recommended), Minimum, Maximum Units: Milliseconds TimeToFirstByte The average time, in milliseconds, that it took Amazon Route 53 health checkers to receive the first byte of the response to an HTTP or HTTPS request. You can view TimeToFirstByte for a health check either across all regions or for a selected geographic region. Valid statistics: Average (recommended), Minimum, Maximum Units: Milliseconds Metric Description ActiveConnectionCount The total number of concurrent TCP connections active from clients to the load balancer and from the load balancer to targets. Statistics: The most useful statistic is Sum. ClientTLSNegotiationErrorCount The number of TLS connections initiated by the client that did not establish a session with the load balancer. Possible causes include a mismatch of ciphers or protocols. Statistics: The most useful statistic is Sum. HealthyHostCount The number of targets that are considered healthy. Statistics: The most useful statistics are Average, Minimum, and Maximum. HTTPCode_ELB_4XX_Count The number of HTTP 4XX client error codes that originate from the load balancer. Client errors are generated when requests are malformed or incomplete. These requests have not been received by the target. This count does not include any response codes generated by the targets. Statistics: The most useful statistic is Sum. Note that Minimum, Maximum, and Average all return 1. HTTPCode_ELB_5XX_Count The number of HTTP 5XX server error codes that originate from the load balancer. This count does not include any response codes generated by the targets. Statistics: The most useful statistic is Sum. Note that Minimum, Maximum, and Average all return 1. HTTPCode_Target_2XX_Count,HTTPCode_Target_3XX_Count,HTTPCode_Target_4XX_Count,HTTPCode_Target_5XX_Count The number of HTTP response codes generated by the targets. This does not include any response codes generated by the load balancer. Statistics: The most useful statistic is Sum. Note that Minimum, Maximum, and Average all return 1. IPv6ProcessedBytes The total number of bytes processed by the load balancer over IPv6. Statistics: The most useful statistic is Sum. IPv6RequestCount The number of IPv6 requests received by the load balancer. Statistics: The most useful statistic is Sum. Note that Minimum, Maximum, and Average all return 1. NewConnectionCount The total number of new TCP connections established from clients to the load balancer and from the load balancer to targets. Statistics: The most useful statistic is Sum. ProcessedBytes The total number of bytes processed by the load balancer over IPv4 and IPv6. Statistics: The most useful statistic is Sum. RejectedConnectionCount The number of connections that were rejected because the load balancer had reached its maximum number of connections. Statistics: The most useful statistic is Sum. RequestCount The number of requests received by the load balancer. This includes requests over IPv4 and IPv6. Statistics: The most useful statistic is Sum. Note that Minimum, Maximum, and Average all return 1. RulesEvaluated The number of rules processed by the load balancer given a request rate averaged over an hour. Statistics: The most useful statistic is Sum. TargetConnectionErrorCount The number of connections that were not successfully established between the load balancer and target. Statistics: The most useful statistic is Sum. TargetResponseTime The time elapsed, in seconds, after the request leaves the load balancer until a response from the target is received. This is equivalent to thetarget_processing_time field in the access logs. Statistics: The most useful statistics are Average and pNN.NN (percentiles). TargetTLSNegotiationErrorCount The number of TLS connections initiated by the load balancer that did not establish a session with the target. Possible causes include a mismatch of ciphers or protocols. Statistics: The most useful statistic is Sum. UnHealthyHostCount The number of targets that are considered unhealthy. Statistics: The most useful statistics are Average, Minimum, and Maximum. Metric Description EstimatedCharges The estimated charges for your AWS usage. This can either be estimated charges for one service or a roll-up of estimated charges for all services.
• #22: 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