메뉴 건너뛰기



7 Reasons DevOps Is Not Dying

이제 DevOps의 시작에 대해 알았으니 본래의 질문으로 돌아가봅시다. NoOpsDevOps의 종착역일까요?

그렇지 않습니다!


 1. DevOps is a journey

어떤 Devopsdays에 참석하더라도 “DevOps is a journey, not a destination” 이라는 글귀를 쉽게 접하게 되실 것입니다. DevOps의 간략한 역사에서도 알 수 있듯이 기술과 실천사례는 DevOps가 나타나기 훨씬 오래전부터 발전하고 있었습니다. 사실 첫번째 NoOps 솔루션이 DevOps 가 명명되기 훨씬 전부터 사용되고 있었습니다. 그러나 7년이 넘는 기간동안 DevOps운동은 점점 더 막강해지고 있습니다.


is-noops-the-end-of-devops-002.jpg


2. DevOps adoption is growing

RightScale의 조사 2016 State of the Cloud Servey 따르면, 80퍼센트 이상의 엔터프라이즈 조직, 70% 이상의 작은 비즈니스 조직이 DevOps 프랙티스를 받아들이고 있습니다. 많은 회사에서 DevOps에 대해 점차 더 많은 투자를 하고 있고, Puppet2016 State of DevOps Report에서 나타나듯이 투자의 성과 역시 나타나고 있습니다. DevOps를 수행하는 IT조직에서 2,500배의 리드타임 단축(idea로부터 실제 운영되는 소프트웨어가 탄생하기까지의 시간), 3배 이상의 실패율 감소, Mean time to recovery (MTTR) 24배 향상, 10퍼센트 미만의 저품질 보완을 위한 재작업을 기록했습니다. 말할 것도 없이 DevOps는 앞으로가 더 기대되는 운동입니다.


3. NoOps is not one-size-fits-all


만일 비즈니스가 모두 DevOps의 장점을 취한다면 왜 DevOps를 건너뛰고 NoOps로 가지 않을까요? 우선 NoOpsPaaS에 적합한 어플리케이션으로 제한됩니다. 많은 기업들은 대량의 업그레이드와 PaaS로 전환하기 위한 작업이 필요한 레가시 모노리스 어플리케이션을 유지하고 있습니다. 또한 적절한 NoOps 솔루션이 없는 새로운 기술이 나타나게 될 것입니다. 일부에서 이야기 하듯이 NoOps는 진정으로 DevOps의 다음 단계이기 때문에 우리는 DevOps의 원칙과 기술을 토대로 NoOps를 새로이 구현해야 합니다.

 

4. NoOps fits within the three ways of DevOps

Gene Kim 등이 쓴 The DevOps Handbooks에서는 모든 DevOps 패턴을 파생시키는 세 가지에 대해 다룹니다. 첫번째는 Flow입니다. CI 파이프라인을 통한 왼쪽으로부터 오른쪽으로의 정방향 쉬프트입니다. NoOps 솔루션은 마찰을 제거하고 파이프라인의 flow를 통한 가치전달에 초점을 맞춥니다. , NoOps는 성공적인 DevOps입니다.

두 번째는 Feedback입니다. 파이프라인의 오른쪽에서 왼쪽으로의 쉬프트로서 피드백은 NoOps를 통한 defect 등록으로, 각 스테이지 별로 자동화하여 defect을 발견하고 조기에 조치하는 것입니다. 오늘날의 소프트웨어 어플리케이션의 규모에서는 사소한 defect도 큰 비즈니스 영향을 미칠 수 있습니다.

세 번째는 지속적인 학습과 개선입니다. NoOps는 마찰없는 소프트웨어 배포에 관한 다년간의 학습과 개선의 결과물입니다. NoOps는 지속적인 협업을 통한 새로운 도구와 기술 그리고 아이디어의 축적물입니다. NoOpsDevOps의 종착역이라고 하는 것은 더 이상 학습/개선할 것이 없다고 이야기하는 것과 같습니다.


5. Operations happens before production

DevOps에서 기존의 전통적인 IT 오퍼레이션 대부분은 프로덕션으로 넘어가기 전에 이루어집니다. 모든 릴리즈에는 개별 커밋에 대해 모니터링, 로깅, A/B테스트, CI/CD 파이프라인을 통한 유닛테스트, 보안스캔, 정책 제크를 포함합니다. 배포는 자동으로 수행됩니다. 제어, 작업 그리고 비기능적 요건은 실제 장애나 중단의 원인이 되기 전에 모든 릴리즈 전에 구현됩니다. 시스템관리자와 감시자, 보안 담당자와 QA테스트 그리고 주요 비즈니스 이해관계자가 초기 단계에서부터 연계되어 자동화 된 작업과 컨트롤을 통해 적시적소에 효과적으로 배포할 것입니다.


6. DevOps is people

DevOps에서 무엇보다도 중요한 것은 도구나 기술이 아닌 문화입니다. DevOps는 무에서 창조되지 않습니다. DevOps는 개발자와 시스템관리자가 그들의 아이디어와 경험을 공유하고 공통된 목적을 향해 협력할 때 시작합니다. 시간의 흐름에 따라 커뮤니티는 모든 비즈니스 현업과 QA, 보안, 마케팅, 재무까지 각 분야의 전문가를 포함하는 것이 더 나은 소프트웨어를 만드는 데에 도움이 된다는 점을 알게 될 것입니다. 이들은 모임, 온라인 포럼, 블로그 및 오픈소스 소프트웨어를 통해 아이디어를 공유함으로써 발전해나갑니다. 이런 DevOps 문화의 중요성을 잊는다면 아무리 많은 이점을 얻었다고 하더라도 엔트로피 법칙에 의해 점점 침식당할 것입니다.


7. DevOps requires continuous learning and improvement

DevOps의 주요 가치는 지속적인 학습과 개선에 있습니다. 실패가 있는 경우 성숙한 문화는 비난하지 않는 사후 검증을 통해 실패로부터 살아있는 학습을 만들어 냅니다. 팀의 사기를 꺾고 근본 문제를 해결하지 못하는 데에 대한 처벌과 제재를 하기보다는 먼저 실패가 발생하도록 만든 시스템과 프로세스를 파악하고 개선해야 합니다.

학습과 개선은 실패로부터만 발생하는 것은 아닙니다. 모든 사람들은 일상 업무를 개선하기 위해 노력해야 하며, 조직은 개인이 발견한 내용을 보다 넓은 범위의 조직과 공유할 수 있도록 장려해야합니다. 오늘날의 IT비즈니스는 비즈니스 성공의 핵심 동력으로서, 조직은 일당백의 엔지니어를 영입하는 것보다 조직원이 두 배의 효율을 갖게 되는 것이 보다 현실적이고 효과적임을 깨달아야 합니다.


Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr

Atachment
첨부 '1'
?

 


  1. 3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자

    3. 앱 로드타임을 2초 내로 줄여 좋은 첫인상을 주자 크래시율과 더불어 app load time은 매우 중요한 지표입니다. App load time은 고객유치에 매우 밀접한 메트릭이자 모바일 앱에 접근하는 중요한 시간정보입니다. 연구에 따르면 app load time은 50%의 ...
    Date2018.02.19 ByNeO Reply0 Views531
    Read More
  2. 2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자

    2. 주요 3 Userflow의 크래시율을 0.25%미만으로 유지하자 앞서 Best Practice #1의 방법으로 top 10 크래시를 수정한다면, 0.25% 이하의 크래시율을 유지하는 데에 매우 큰 도움이 될 것입니다. 전체 크래시율을 낮추는 것 외에도 주요 Userflow의 크래시...
    Date2018.02.05 ByNeO Reply0 Views406
    Read More
  3. 1. 매 스프린트에서 Top 10 크래시를 잡자

    1. 매 스프린트에서 Top 10 크래시를 잡자 모바일 앱을 모니터링할 때 가장 중요한 지표 중 하나는 전체 크래시율입니다. 크래시율이란 전체 세션 대비 크래시가 발생한 비율을 의미합니다. 앱의 품질을 평가하는 데에 크래시율은 전체 릴리즈 프로세스에...
    Date2018.01.30 ByNeO Reply0 Views434
    Read More
  4. No Image

    모바일앱 최적화를 위한 7가지 (0)

    본 문서는 다음 문서를 번역한 글입니다. http://www.apteligent.com/white_paper/7-best-practices-optimizing-mobile-app-experience/ 이 문서를 게시하기 전에 모바일앱 모니터링 툴의 종류와 특성에 대한 개요를 작성하고자 하였으나, 많은  mAPM이나 ...
    Date2018.01.29 ByNeO Reply0 Views340
    Read More
  5. Is NoOps the End of DevOps? Think Again (2) 결론

    In conclusion, DevOps is forever DevOps의 완성형이라고 일컬어짐에도 불구하고 NoOps는 DevOps의 종착역은 아닙니다. 사실 NoOps는 DevOps를 통해 달성할 수 있는 혁신의 시작이라고 볼 수 있습니다. DevOps가 이름을 갖기 훨씬 전부터 시작된 NoOps...
    Date2018.01.02 ByNeO Reply0 Views321
    Read More
  6. Is NoOps the End of DevOps? Think Again (1) DevOps가 사라지지 않는 7가지 이유

     7 Reasons DevOps Is Not Dying 이제 DevOps의 시작에 대해 알았으니 본래의 질문으로 돌아가봅시다. NoOps가 DevOps의 종착역일까요? 그렇지 않습니다!  1. DevOps is a journey 어떤 Devopsdays에 참석하더라도 “DevOps is a jo...
    Date2018.01.02 ByNeO Reply0 Views371
    Read More
  7. Is NoOps the End of DevOps? Think Again (0) IT Operation, DevOps, NoOps 의 간략한 역사

    이 문서는 다음 링크의 글을 일부 번역했습니다. https://blog.appdynamics.com/engineering/is-noops-the-end-of-devops-think-again/ 제일 앞 부분의 DevOps와 NoOps 운동에 대한 논란은 관심있으신 분은 직접 링크를 따라가며 읽어보시면 좋을 것 같습...
    Date2018.01.02 ByNeO Reply0 Views429
    Read More
  8. Monoliths - Module, Allocation, Runtime Monolith

    이 문서는 다음 링크의 글을 번역했습니다. http://www.codingthearchitecture.com/2014/11/19/what_is_a_monolith.html 모노리스와 대비하여 마이크로서비스를 이야기하는 강한 트렌드가 있습니다. 그리고 모노리스를 마이크로서비스로 나누는 방법에 대...
    Date2017.12.13 ByNeO Reply0 Views540
    Read More
  9. No Image

    Microservices, Monoliths and Self-Contained Systems (3) Self-contained system과 결론

    Self-Contained System Self contained system은 모노리스와 마이크로서비스 중간쯤에 있는 블록형 아키텍처입니다. 여러 개의 마이크로서비스를 하나의 엔티티로 나타내면서도 모노리스보다는 작은 규모를 가지는 형태입니다. 만일 매우 연관성이 높아 ...
    Date2017.12.13 ByNeO Reply0 Views427
    Read More
  10. No Image

    Microservices, Monoliths and Self-Contained Systems (2) Microservices

    Microservices 상대적으로 마이크로서비스는 많은 장점을 가져다 주는 반면 단점이 적은 편입니다. 마이크로서비스는 커다란 어플리케이션의 일부분이라고 할 수 있으며 독립적인 어플리케이션이라고 할 수 있겠습니다. 예를 들어 웹 상에 스토어를 운영...
    Date2017.12.13 ByNeO Reply0 Views234
    Read More
Board Pagination Prev 1 2 3 Next
/ 3