메뉴 건너뛰기

이 문서는 다음 링크의 글을 일부 번역했습니다.

https://blog.appdynamics.com/engineering/is-noops-the-end-of-devops-think-again/


제일 앞 부분의 DevOps와 NoOps 운동에 대한 논란은 관심있으신 분은 직접 링크를 따라가며 읽어보시면 좋을 것 같습니다. 위 링크를 통해 본문을 보시면, 5개 글이 링크되어 있습니다.

번역하지 않은 앞부분을 요약하면, DevOps의 수준을 높여 어플리케이션의 완벽한 배포와 모니터링 그리고 관리 자동화가 이루어져 개발자와 운영자 간의 소통의 필요성이 없는 환경(NoOps)으로 변모한다는 NoOps 운동에 대한 5년 여의 논란에 대한 짧은 소개와 이 글의 필자는 DevOps가 사라지는 것이 아니라 진화하는 것이라는 취지의 글임을 밝히고 있습니다.


문서가 길어서 분할하여 게시합니다.


(0) IT Operation, DevOps, NoOps의 간략한 역사

(1) DevOps가 사라지지 않는 7가지 이유

(2) 결론


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


A brief history of IT Operations, DevOps, and NoOps

전통적인 IT조직에서 개발자와 운영자는 서로 상반되는 목표를 가지고 있었습니다. 개발자의 가장 큰 관심사는 기능을 구현하는 데에 있고, 운영자의 가장 큰 관심사는 가용성, 안정성 그리고 성능 및 보안을 보장하는 일입니다. 개발과 운영을 대표하는 이해의 장벽은 오랜 기간동안 서로 간의 불신과 불화, 무의미한 긴장과 소모, 고객의 당혹스러움과 비즈니스 실패로 이어져왔습니다.

1980년대 후반, IT Infrastructure Library (ITIL) 이 대두되며 좋은 IT조직이 공통적으로 갖고 있는 표준 및 모범 사례에 대한 관심이 높아졌습니다. ITIL을 실천하면서 성공율을 높이고 소프트웨어 배포와 관련된 재난을 어느정도 방지할 수 있었지만, 속도가 느려지는 단점이 있었습니다. 수동 제어 및 복잡한 결재 절차에 의존하여 워크플로우가 느려졌습니다.

그러는 동안, 소프트웨어 개발 커뮤니티에서는 신속한 개발을 위한 자체적인 모범 사례를 만들어내는 데에 몰두했습니다. 2001년 한 저명한 소프트웨어 회담에서 애자일 매니페스토가 발표되면서 애자일 개발운동이 본격적으로 실시되었습니다. 애자일 원칙은 소수인원의 팀이 능력을 발휘하여 종전과는 다른 방식으로 보다 더 높은 품질의 소프트웨어를 만들 수 있게 했습니다.

1990년대의 인터넷의 보급은 보다 빠르고 정교한 소프트웨어에 대한 수요를 가중시키는 촉매제였습니다. 프로세스의 개선 외에도 버전컨트롤, CI, 구성 관리 및 가상화와 같은 기술의 발전이 이루어졌습니다.

2006Amazon Web Services가 공개되면서 더 나은 프로세스와 도구가 필요해졌습니다. 클라우드 컴퓨팅의 출현으로 소프트웨어 팀은 더 이상 물리적 인프라를 온프레미스 형태로 갖추지 않아도 클라우드 공급자를 통해 소싱하고 대신 API를 통해 가상의 인프라 리소스를 관리할 수 있게 되었습니다. 이러한 Infrastructure as a Service(IaaS) 모델을 기반으로 한 인프라스트럭처는 개발 팀의 속도를 향상시켰고, 새로운 하드웨어를 주문하고 관리할 필요가 없어졌습니다.

1년 후 Heroku, CloudFoundry와 같은 Platform as a service (PaaS) 솔루션은 플랫폼에서 커밋부터 디플로이까지의 과정을 자동화함으로써 운영 경험이 없는 개발자가 직접 확장 가능한 웹 응용 프로그램을 단기간에 만들 수 있게 되었습니다.

 The day the earth stood still

DevOps 역사상 가장 중요한 순간은 바로 John AllspawPaul Hammond 2009Velocity Conference에서 발표한 프리젠테이션일 것입니다. 하루에 10번 이상의 배포 : Flickr 개발과 운영의 협업(10+ Deploys Per Day : Dev and Ops Cooperation at Flickr) 라는 제목의 프리젠테이션을 통해 복잡한 소프트웨어를 쓰는 기업이 하루에 몇 번씩이나 성공적으로 배포할 수 있었다는 것을 알게 된 것은 IT 커뮤니티에 충격적인 반향을 일으켰습니다.

09년도 Velocity 컨퍼런스의 기세를 타고 Patrick Debois는 벨기에의 겐트에서 첫 번째 Devopsdays 컨퍼런스를 주최했습니다. Devopsdays는 개발자, 시스템 관리자 그리고 여러 소프트웨어 전문가들이 자신의 이야기와 아이디어, 사례를 가지고 공유하는 로컬 조직 컨퍼런스의 세계 투어 형태였습니다. Devopsdays에서 논의된 몇 가지 공통주제로는 공동체 문화와 협업 문화, 비난 없는 사후 평가 그리고 애자일 프랙티스와 lean 원칙 등이었습니다.

첫번째 Devopsdays를 시작으로 이 운동은 더 많은 성공 사례를 축적하며 아래와 같은 기술이 널리 채용되고 있습니다.

  • Docker – 대규모 PaaSDIY로 구축할 수 있는 오픈소스 컨테이너 관리 플랫폼

  • Kubernetes – 컨테이너 오케스트레이션 프레임워크

  • AWS Lambda – 기능을 동작하기 위해 서버가 지속적으로 실행될 필요 없이 필요에 따라 실행되는 서버리스 컴퓨팅의 대표적인 예


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 Views435
    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 Views322
    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 Views430
    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 Views428
    Read More
  10. No Image

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

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