From simple rolling updates to complex canary pipelines come learn all the ways you can be deploying your services both to the cloud and on premises.

1. Deploying
Microservices
Deploying Microservices Russell Perkins
5/4/2017

2. About
Kenzan
Core offerings
Application Development, Platform as a service,
cloud virtualization, platform engineering,
consulting services and business transformation.
Primary Clients
Multi billion dollar companies and media/content
providers such as Thompson Reuters, Charter &
Cablevision
Locations
Providence (RI), New York (NY), Denver (CO), Los
Angeles (CA), and a London presence
Founded in 2004.
We are a software engineering and digital
consulting firm that has been helping
clients Make Next Possible for over a
decade:
Full Service Consulting Firm
Architecture, front and back end development,
business analysis and DevTest.
Cloud Virtualization Experts And Enablers
AWS, Netflix stack, enterprise architecture and
beyond.
DevOps Leadership
Platform builds, continuous delivery and scalable
resourcing.
Veterans of the Media Industry
Migrations, enterprise wide solutions, digital experts
and thought leaders.
Employee focused
Collaboration, communication and culture are key.

3. Agenda
● What is CI/CD
● Deployment types
● On prem physical servers
● Calculating health against SLO’s and SLA’s
● Canary Deployments
● Common causes of outages

4. Continuous Integration
Continuous Deployments
Of course..But how?

5. Deployment Pipelines
Central code repository
Automated builds
Self-testing
Automated deployment

6. Deployment Pipelines
Simple
Git Push Unit Tests Elastic Beanstalk

7. Deployment Pipelines
Complex
Unit Tests Integration Tests
End to End Tests
Stress Tests
Test AWS account
Git Push
Stable AWS
account
Manual Judgment Production

8. Cattle Not Pets
Pets:
Servers or server pairs that are treated as indispensable or unique systems that
can never be down. Typically they are manually built, managed, and “hand fed”.
Cattle:
Arrays of more than two servers, that are built using automated tools, and are
designed for failure, where no one, two, or even three servers are irreplaceable.
Typically, during failure events no human intervention is required as the array
exhibits attributes of “routing around failures” by restarting failed servers or
replicating data through strategies like triple replication or erasure coding.

9. Types of
Deployments

10. Rolling Deployment

11. Red / Black Deployment
A/Z, Blue/Green

12. On-Premise
Physical Servers

13. Cattle Not Pets
(again)
Seriously

14. Kubernetes

15. Cloud Bursting
Cloud bursting is an application deployment model in which
an application runs in a private cloud or data center and
bursts into a public cloud when the demand for computing
capacity spikes.

16. Hybrid Cloud Models

17. Pilot Light
Design:
● Images (AMI’s, containers, ect) are copied to the cloud
● Auto Scale Groups update to use latest image
● Cluster sizes set to 0
Benefits:
● Low overhead costs
● Can be activated fairly quickly.

18. Warm Standby
Design:
● Images (AMI’s, containers, ect) are copied to the cloud
● Auto Scale Groups update to use latest image
● Cluster sizes set to a reasonable number, no less than 2.
Benefits:
● Can be activated instantly

19. Multi-Site
Design:
● Images (AMI’s, containers, ect) are copied to the cloud
● Auto Scale Groups update to use latest image
● Cluster sizes set to a reasonable number, no less than
2.
● Some traffic is always directed to the cloud servers.
Benefits:
● Always active
● Far away regions can use the cloud for reduced latency.

20. Uptime with
SLO’s and SLA’s

21. Service Level Objectives
&
Service Level Agreements
SLO:
SLOs are specific measurable characteristics of the SLA
such as availability, throughput, frequency, response time, or
quality.
SLA:
The SLA is the entire agreement that specifies what service
is to be provided, how it is supported, times, locations, costs,
performance, and responsibilities of the parties involved.

22. Uptime and Automation
99.9% 8 hrs 45 mins
99.99% 52 mins
99.999% 5 mins
Uptime Percentage Acceptable yearly outages

23. Traditional Uptime Monitoring

24. Monitoring via logs
Logging Tools:
● AWS CloudWatch
● GCP StackDriver
logging
● Graylog
● ELK Stack
Metrics to track:
● HTTP status codes
● CPU Usage
● Memory
● DiskSpace
● Network

25. Canary
Deployments

26. Slow is better
We want to make sure our software works in the real world.
But...
Users are both predictable and unpredictable
Different regions and devices may behave differently
Some issues (memory leaks) only appear overtime.

27. Canary Watcher
Simple script run every 10 mins and monitors health / logs.
Keeps track of the deployment state (10%, 50%, ect)
Automatically remove from LB if an SLO is missed.
Can be run ad hoc

28. Real Time
Applications can be self aware.
Alerts can trigger removal from a LB or auto rollback

29. Common Causes
of Outages

30. Common Causes of Outages
● Overload
● Retry Spikes
● Pets
● Monitoring Gaps
● Scaling Boundaries
● Bad Configuration
● Lengthy Startup Times

31. Want to learn more?
Follow us!
@kenzanmedia
www.linkedin.com/company/kenzan-media
techblog.kenzan.com
www.facebook.com/kenzanmedia/