DevOps in Practices document provides an overview of DevOps practices and microservice architecture. It discusses that DevOps aims to reduce the time between introducing changes to a system and deploying those changes in a production environment. Microservices architecture breaks applications into smaller, independent services that are built around business capabilities. Netflix is highlighted as an example that pioneered this approach at a large scale using AWS. Key aspects of DevOps like continuous integration, infrastructure as code, and automated testing are explained in the context of enabling faster delivery with microservices.
5. Definition
DevOps 는 높은 품질을 유지하면서 시스템에 대한 변경 사항의 적용과 그 변경사항을 일
반적인 생산 환경에 적용되는 동안의 필요한 시간을 줄이기 위한 일련의 실천 방법
(practices)이다.
- from SEI Series “DevOps: A Software Architect’s Perspective”
DevOps라는 합성어는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합
을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개발과 IT 운영간의 상호 의존관계에
대한 산물이다.
DevOps 는 조직에서 소프트웨어 상품과 서비스를 신속히 생산하는 것에 도움이 되는 것을
목적으로 한다.
- from Wikipedia
6. Code Build Test ReleasePlan Deploy Operate
Agile Development
Continuous Integration
Continuous Delivery
Continuous Deployment
DevOps
7. 10+ Deploys per Day:
Dev and Ops Cooperation at Flickr (2009) :
• 51 total employees
• 10 deploys per day
https://www.youtube.com/watch?v=LdOe18KhtT4
Patrick Debois decided to organize an event in Ghent, Belgium, called DevOpsDays.
The name "DevOpsDays" struck a chord, and the conference has become a recurring
event. DevOpsDays was abbreviated to "DevOps" in conversations on Twitter and
various Internet forums.
11. Hey Ops - Here’s
our code...good luck!
• “Code is written...it’s your problem now”
12. 갑자기 알 수 없는 장애가
일어나기 때문에
어느 누구도 어떤 얘기도
해준게 없기 때문에
그들은 언제나 어떤 변화
에 대해서도 “No”
Ops Stereotype
• “They say no all the time”
13. Developer :
I want change!
Operations:
I want stability!
내 시스템이 아니라
당신 코드가
문제라고!
내 코드가 아니라
당신 시스템이
문제라고!
Dev and Ops
14. 새로운 기능을
추가하기 위한 목표
Dev (개발) Ops (운영)
DevOps
빠르고
안정된 시스템을
유지 하기 위한 목표
새로운 목표:
새로운 기능 추가 뿐만 안정적이면서
빠르고 가용성 있는 시스템 운영
15. Increased Agility
• Increase frequency of
releases
Increased Quality
• To Increase end-
user satisfaction
Improved Innovation
• To Increase Innovati
on cycles
Reduced Outage
• Upto 80% outages
are change-related
Focused on Speed, Agility and Time to Market
20. 논의존중
남탓
안하기
“완료” =
서비스
릴리즈
• Dev respect for ops
• Ops respect for dev
• Don’t stereotype
• Don’t just say “no”
• Don’t hide things
• Ops should be in dev discussions
• Dev should be in ops discussions
• Shared runbooks/escalation plans
• Ops should give devs access to
systems
• No fingerpointing!
• Dev’s responsibility
does not end when
it’s in production
• “Throwing it over
the wall” is dead
23. Base Image
Install Binaries
Configure Software
Make Software Work Together
Patch/Push Config Changes
Step 1
Pick a Tool
Step 2
Script your environment
Step 3
Run your scripts against all hosts
서버 구성환경을 코드로 저장 관리
24. 단일 서버를 이용한 코드 및
빌드 산출물 관리 (Single
Source of Truth)
소스코드가 Commit될 때마다,
또는 적어도 일단위 빌드 + 자
동화된 테스트 수행
트렁크를 이용한 개별 소스코
드저장
Flags을 이용하여 기능 활성화
25. 매뉴얼 build/deploy
스케줄 기발 빌드 - 일/주/
월 단위 빌드
코드 체크인시 자동 빌드
테스트 자동화 및 오류
리포팅
26. Image 기반의 배포 페러다임
Infra에 문제가 발생시, 수정
하지 않고, Re-Deploy
CM(Configuration
Management) Tool을 이용하
여, 쉽고 빠르게 신규 환경 구
성
클라우드 기반 PaaS/IaaS에서
쉽게 구현
In each cluster’s [of 10,000 servers] first year, it’s typical
that 1,000 individual machine failures will occur;
thousands of hard drive failures will occur; one power
distribution unit will fail, bringing down 500 to 1,000
machines for about 6 hours; 20 racks will fail, each time
causing 40 to 80 machines to vanish from the network; 5
racks will “go wonky,” with half their network packets
missing in action; and the cluster will have to be rewired
once, affecting 5 percent of the machines at any given
moment over a 2-day span, Dean said. And there’s about
a 50 percent chance that the cluster will overheat, taking
down most of the servers in less than 5 minutes and
taking 1 to 2 days to recover.
Jeff Dean, Fellow, Google
Immutable Infrastructure
29. Micro Services
A collection of smaller applications all working together to deliver a t
otal experience to the end user.
Increased efficiency
• Splitting your services gives you the ability to scale o
nly the parts of the site that is slow
• Less wastage of service resource
• More cost efficient
• An individual slow performing service doesn’t slow all
services
• Less user frustration
30. Micro Services
A collection of smaller applications all working together to deliver a t
otal experience to the end user.
Easier Updates
• Updating a smaller code base is easier
• Less likely to have a regression issue
• Less likely to push a feature that isn’t ready from
another team
• Disable or slowly fail users over to the new version
• You don’t put any other part of the service at risk
• Easier roll back if the update fails
31. Micro Services
A collection of smaller applications all working together to deliver a t
otal experience to the end user.
Increased stability
• Gracefully fail parts of the site
• If one service fails the rest of the site still operates
• Clever use of JS calls to services can detect failures
and mask it from the end user
• Much better end user experience
32. User Interface
Application
Datastore
Infrastructure
Resulting SoftwareTypical Enterprise Organization Structure
Head of IT
Head of
Operation
Head of DBAs
Head of
Infrastructure
Head of App
Dev
Head of UI
Head of
Development
An Enormous Monolith
Conway’s Law: Software reflects the structure of the
organization that produced it
33. Build small product-focused teams – strict one team
to one microservice mapping
Many Small Microservices
Resulting SoftwareMicroservices Organization Structure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
Product Lead
Project Manager Sys Admin DBA
JavaScript Devel
oper
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager Sys Admin DBA
JavaScript Devel
oper
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager Sys Admin DBA
JavaScript Devel
oper
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager Sys Admin DBA
JavaScript Devel
oper
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
34. Requirements for Microservices Implementation
Microservices
Security ScalingMonitoring
Eventing LoggingMessaging
Service Discovery ConfigurationSecurity
Service Registry API GatewayAPI Load Balancer
Generally
Recommended for
Microservices
37. Leader in subscription internet tv service
Hollywood, indy, local
Growing slate of original content
86 million members
~190 countries, 10s of languages
1000s of device types
Microservices on AWS
38. Netflix DVD Data Center - 2000
Linux Host
What microservices are not
Apache
Tomcat
Javaweb
STORE
LoadBalancer
BILLING
HTTP
JDBC
DB Link
HTTP/S
Monolithic code base
Monolithic database
Tightly coupled architecture
39.
40. • Buy vs. Build
– Use or contribute to OSS technologies first
– Only build what you have to
• Services should be stateless*
– Must not rely on sticky sessions
– Prove by Chaos testing
First Principles
41. • Scale out vs. scale up
– If you keep scaling up, you’ll hit a limit
– Horizontal scaling gives you a longer runway
• Redundancy and Isolation for Resiliency
– Make more than one of anything
– Isolate the blast radius for any given failure
• Automate destructive testing
– Simian Army
– Started with Chaos Monkey
First Principles
46. Device Service B
Service C
Internet EdgeZuul
Service A
ELB
FIT
Fault Injection Testing (FIT)
Enforced throughout the call path
47.
48. Wrap up
DevOps & Microservices bring great value to development
velocity, availability and other dimensions
DevOps & Microservices at scale require organizational
change and centralized infrastructure investment
Be aware of your situation and what works for you
50. • 2012년에 비슷한 시기에 서로 다른 사람이 용어를 사용하기 시작했다.
• ThoughtWorks의 Jame Lewis가 Micro Service : Java, the Unix way : goo.gl/PS7BYK
• Fred George “Micro Service Architecture – A Personl Journey to Discovery : goo.gl/dgd8Ya
• 2013년 1월 : Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA"
• 2014년 3월 James Lewis와 Martin Fowler가 Microservices라는 타이틀로 패러다임을 정립한 기사를 발표
• 독립적이고 단순한 서비스로 전체 서비스를 구성
• 데이터, 거버넌스, 아키텍처등에 있어서 완전한 독립
• 독립적인 팀이 각 서비스의 개발과 운영을 담당
• 책임과 권한에 있어서 완전한 독립을 추구
Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA", pioneered the style at web
scale, as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan Bottcher and
Graham Tackley
From wikipedia
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Dallas Fort Worth
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits.
4.1 Increased Agility
Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality.
4.2 Increased Quality
Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level.
4.3 Improve Innovation
Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed.
4.4 Reduced Outages
As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits.
4.1 Increased Agility
Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality.
4.2 Increased Quality
Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level.
4.3 Improve Innovation
Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed.
4.4 Reduced Outages
As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits.
4.1 Increased Agility
Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality.
4.2 Increased Quality
Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level.
4.3 Improve Innovation
Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed.
4.4 Reduced Outages
As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits.
4.1 Increased Agility
Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality.
4.2 Increased Quality
Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level.
4.3 Improve Innovation
Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed.
4.4 Reduced Outages
As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
Immutable : 불변의
* If you do not defend against failure at each level then you have what is essentially a distributed monolith – if any microservice fails then they all fail
* Calls start failing, retries make it worse, thread pools become saturated, lack of isolation leads to full cascading failure