Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

컨테이너

글로벌 칼럼 | 컨테이너 기반 통합 테스트의 이점

완벽한 소프트웨어를 가진 행성이 어딘가에 있을 수 있지만, 구글의 오픈소스 책임자 크리스 디보나의 말처럼 우리가 사는 행성은 그런 행성이 아니다. 따라서 개발자에게는 2가지 길이 있다. 소프트웨어를 신중하고 엄격하게 테스트해 발생할 수 있는 모든 문제를 배포 전에 찾아내거나, 테스트를 줄이고 배포 속도를 높여 프로덕션 환경에서의 오류를 감내하는 것이다.   전자는 의료 및 금융 같은 규제 산업에서 일하는 개발자가 주로 택하는 길이며, 후자는 “개발한 사람이 운영까지 한다(You build it, you run it)”라는 AWS CTO 베르너 보겔스의 유명한 격언에 동의하는 개발자가 선택하는 길이다.  이처럼 소프트웨어 테스트와 배포 속도 사이의 균형은 개발자의 생산성과 관련한 대표적인 논쟁거리다. 테스트 어느 단계에 있든, 소프트웨어 테스트를 위한 단일화된 솔루션은 없다. 때문에 개발자는 변화하는 요구사항에 맞춰 올바른 테스트 방법을 지속해서 모색해야 한다. 동시에 개발자는 사용할 테스트 방법을 습관으로 만들기 위해 느리거나 복잡하지 않으면서 주요 문제를 해결하는 가장 효율적인 방식을 찾아야 한다. 최근 필자는 ‘유닛 테스트’에서 효율적인 방식을 발견했다. 유닛 테스트는 독립적으로 진행하는 가장 작은 단위의 소프트웨어 테스트다. 소프트웨어가 의도에 따라 동작하는지 확인할 수 있을 뿐 아니라 다른 개발자가 작성한 코드 베이스의 일부를 추론할 수도 있다. 유닛 테스트는 오래 전부터 사용하던 방법이지만, 최근 들어 자동화가 사용자 경험을 실제 사용성까지 단순화하면서 깊숙이 자리 잡았다. 유닛 테스트와 유사한 다른 형태의 테스트 방법도 있다. 수십 년 동안 개발 중인 방법이지만, 이제서야 본질적인 문제를 해결하고 단순화된 접근에 적절한 추상화 수준을 제공하며 효율적인 방식을 찾아가고 있는 ‘통합 테스트’다.  개발자의 역할은 ‘조립’에 있다 전통적인 3계층 아키텍처 시스템은 데이터베이스 1개와 상호작용할 수 있는 API를 1...

컨테이너 도커 통합테스트 2022.01.18

"쿠버네티스 보급률 증가, 서버리스는 소폭 하락"…클라우드 네이티브 컴퓨팅 재단 연구

쿠버네티스 컨테이너 오케스트레이션 시스템은 개발자 사이에서 전기를 맞았다. 그러나 클라우드 네이티브 컴퓨팅 재단(CNCF)의 연구 결과에 따르면 서버리스 아키텍처의 보급은 오히려 줄어들었다. 12월 20일 공개된 클라우드 네이티브 개발 현황(The State of Cloud Native Development) 조사는 2020년 11월부터 2021년 2월까지 조사업체 슬래시데이터(SlashData)가 155개국 1만 9,000여 명의 개발자를 대상으로 이루어졌다. 조사 대상 중 3,800명 이상의 참가자가 백엔드 서비스와 사용 기술 개발 관련 질문에 응답했다.  이 연구는 2021년 1분기 쿠버네티스를 사용하는 개발자가 560만 명으로 1년 전인 2020년 1분기 390만 명보다 67% 증가했다는 내용을 담고 있다. 쿠버네티스는 모든 백엔드 개발자의 31%가 사용하고 있었고, 이 수치는 1년 동안 4% 증가했다. 엣지 개발자 사이에서의 쿠버네티스 사용률은 11% 늘어난 63%로 조사됐다. 엣지 기술은 조사 대상인 기술 부문 가운데 가장 높은 보급률을 기록했다.   그러나 서버리스 아키텍처에 종사하는 개발자 비율은 27%에서 24%로 소폭 하락했다. 서버리스 컴퓨팅은 AWS 람다 같은 서비스를 통해 연산 주기를 동적으로 배치하는 기술이다. 서버리스 컴퓨팅의 최신 경향이 ‘약세’로 나타난 이유는 특정 업체에 종속되는 것을 우려하는 현상, 그리고 서버리스 솔루션의 유연성 부족으로 관측됐다. 구글 클라우드 런의 지지율이 높아지고 있지만 여전히 AWS 람다가 서버리스 개발자 53%가 사용하는 서비스로 나타났다. 지역적으로는 북미, 동유럽, 중동, 아프리카 백엔드 개발자 사이의 클라우드 네이티브 기술 사용이 줄었다는 점이 특징이다. 보고서에 따르면, 클라우드 네이티브 개발자는 30만 명 가량 늘어난 680만 명이었고, 컨테이너 오케스트레이션 도구 사용 개발자가 460만 명, 서버리스 플랫폼 사용자가 400만 명, 둘 다를 사용하는 개발자가 180...

서버리스 쿠버네티스 컨테이너 2021.12.23

경쟁력 있는 엣지 컴퓨팅 구축을 위한 컨테이너 전략

클라우드의 도입은 이제 시장에서 대세로 자리잡았지만(쿠버네티스는 조직이 현대적인 컨테이너 기반 애플리케이션을 수용하는 것과 같은 방식 지향), 차세대 지능형 기술을 지원하는 성공적인 클라우드 전략을 위해서는 새로운 요소를 고려해야 합니다. 본 e-book에서는 스케일에 따라 컨테이너 기반 애플리케이션을 구축, 관리, 유지하기 위해 적합한 쿠버네티스 플랫폼을 선택하는 방법을 소개합니다. Linux 애플리케이션의 기반, 하이브리드 멀티클라우드 전략의 가치, 보다 안전한 환경에서 빠른 속도와 유연성을 제공하는 Red Hat의 입증된 오픈소스 접근 방식과 같은 주제를 살펴봅니다. <18p> 주요 내용 - 쿠버네티스의 기반 - 멀티클라우드 접근 방식을 요구하는 하이브리드 환경 - 쿠버네티스 지원 컨테이너 플랫폼의 가치 - Red Hat과 함께 미래의 비즈니스 설계

컨테이너 엣지컴퓨팅 멀티클라우드 2021.12.07

'도커 이전과 도커 이후' 세상이 확연히 달라진 이유

2013년 도커는 화제의 ‘바로 그’ 회사였다. 컨테이너가 주류로 부상하는 데에 결정적 역할을 하면서 신문 1면을 장식했고, 많은 분야에서 PaaS를 밀어내고 당대 최고의 인기 기술로 자리잡았다(헤로쿠(Heroku)를 기억하는 사람이 지금도 있을까?). 그리고 이제 도커는 유료 요금제 방식의 도커 데스크톱(Docker Desktop) 모델로 다시 언론의 주목을 받고 있다. 이번 발표에 대한 격렬한 반응을 보면, 도커로 인해 현재 널리 사용되는 주류 모델인 컨테이너의 인기가 얼마나 높아질 수 있었는지 다시금 상기하게 된다.   도커는 컨테이너를 발명한 곳이 아니라, 오픈소스 도구와 재사용 가능한 이미지로 컨테이너 기술의 접근성을 높인 회사다. 도커를 사용하면 개발자는 소프트웨어를 한 번만 만들어서 로컬 또는 프로덕션 서버에서 실행할 수 있다.     도커 명령줄 도구가 몇 년 동안 사용된 화려한 웹 인터페이스를 밀어냈다는 사실은 개발자가 진정으로 원하는 것이 무엇인지를 잘 보여주는 사례일 것이다. 그러나 도커가 미친 영향을 제대로 이해하기 위해서는 도커 컨테이너 기술이 등장하기 직전의 상황을 되짚어보는 것이 중요하다.   그 다음 혁신에 대한 갈증 2009년은 가상화에서 얻는 가치가 널리 인식되고, 구현도 폭넓게 이루어진 시기다. 대다수 조직이 이미 가상화의 혜택을 얻었거나 그런 수준에 이르기 위한 로드맵을 두고 있었다. 가상화 이야기를 질리도록 들은 사람들은 IT와 소프트웨어 개발의 다음 혁신에 목말라 있었다. 그때 등장한 것이 헤로쿠다. 일반적인 PaaS와 헤로쿠는 큰 인기를 얻었다. 마치 PaaS가 세상을 정복할 듯한 분위기였다.   당시 헤로쿠는 대단했다. 헤로쿠 포털에서 앱을 개발하고 바로 서비스로 제공한다? 그걸 마다할 이유가 있을까? 헤로쿠에서 앱을 개발하지 않을 이유는 전혀 없는 것만 같았다.   그런데 시간이 지나고 보니, 헤로쿠 같은 PaaS 플랫폼을 사용하지 않을 만한 이유가 몇 가지 있...

도커 컨테이너 2021.11.18

마이크로서비스 아키텍처를 사용해야 하는 이유

현재 운영 중인 애플리케이션은 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

마이크로서비스 아키텍처 컨테이너 2021.11.16

IDG 블로그 | 컨테이너로 추상화된 네이티브 서비스가 공통 서비스가 되는 이유

퍼블릭 클라우드 서비스 업체 네이티브 서비스의 첨단 기능은 확실한 이점을 제공한다. 대부분 기업은 이제 새로운 애플리케이션을 개발할 때 클라우드 네이티브 패턴을 이용하며, 기존 애플리케이션을 마이그레이션할 때도 이 패턴을 점점 더 많이 활용하고 있다. 하지만 한편으로는 특정 클라우드 서비스 업체에 종속되는 것을 최소화하고자 한다. 사실 특정 클라우드 서비스 업체의 네이티브 서비스를 이용하면, 해당 서비스는 다른 클라우드로 옮기지 못한다.   컨테이너가 메가트렌드가 된 이유는 바로 여기에 있다.  IT 부서는 보통 컨테이너는 괜찮은 아이디어로 고려한다. 모두가 사용하고 있으며, 개발 생태계를 만들어 낸 주류의 흐름을 따르는 이점이 있기 때문이다. 또한 컨테이너는 쿠버네티스 같은 클러스터 관리자와 오케스트레이션 서비스를 이용해 확장할 수 있다. 그리고 마지막으로 컨테이너는 애플리케이션을 기반이 되는 네이티브 서비스로부터 추상화하는 괜찮은 방법이기 때문이다. 애플리케이션을 이 클라우드에서 저 클라우드로 이식하기 쉬워진다. 또한 컨테이너는 애플리케이션을 추상화하지 않을 때보다 특정 퍼블릭 클라우드의 특징이나 기능을 덜 생각해도 된다. 그렇다면, 컨테이너는 단점이 없을까? 컨테이너 자체와 컨테이너 생태계의 모든 좋은 점은 여러 퍼블릭 클라우드에 걸쳐 동작하는 공통 플랫폼으로 자리잡고 있다. 오늘날의 개발자와 애플리케이션 아키텍트는 더 이상 스토리지와 컴퓨팅 서비스를 특정 클라우드 서비스 업체의 조건에 맞춰 생각하지 않는다. 보통은 스토리지와 컴퓨팅 서비스를 추상화된 개념으로 생각한다. 이 개념은 컨테이너를 사용하는 특정 네이티브 서비스로 해석될 수 있으며, 이들 자원을 공통 서비스라고 부르고 여러 클라우드에 걸쳐 동일한 것으로 취급한다. 애플리케이션과 개발자에게 네이티브 서비스는 이제 퍼블릭 클라우드 플랫폼과는 독립적으로 운영되는 공통 서비스이다. 퍼블릭 클라우드 서비스 업체가 제안하는 구체적인 가치는 성능 문제나 서비스 장애가 발생하지 ...

네이티브서비스 컨테이너 추상화 2021.11.15

'시스템 속 보안 취약점' 컨테이너가 악몽이 되는 순간

컨테이너, 특히 퍼블릭 클라우드에서 운영하는 컨테이너는 이제 오래전부터 보편화했다. 이들 셀프 컨테이너 방식의 가벼운 소프트웨어 패키지는 자체 런타임 환경을 포함하고 있어 여러 플랫폼을 옮겨 다니며 이식할 수 있다. 일반적으로는 이 과정에서 코드를 크게 수정할 필요도 없다. 실제로 컨테이너에는 애플리케이션은 물론 그 애플리케이션을 독립적으로 실행하는 데 필요한 라이브러리와 오래된 바이너리, 설정 파일 등이 모두 포함돼 있다.   컨테이너는 가장 널리 사용하는 애플리케이션 개발 방법론의 하나다. 컨테이너 내에 이미 존재하는 애플리케이션의 래핑도 지원한다. 문제는 컨테이너에 내재한 결점과 보안 취약점이다. 이는 곧 클라우드 보안 전문가에게 가장 두려운 것이고, 동시에 사이버 범죄자가 선호하는 공격 경로이기도 하다. 컨테이너 보안 취약점 문제의 핵심은 클라우드로 컨테이너를 공개하는 순간 컨테이너와 연결된 다른 시스템과 애플리케이션, 데이터 등이 함께 노출될 수 있다는 사실이다. 이들 컴포넌트를 식별할 수 있다는 것은 공격자에게 시스템 제어권은 물론 이 시스템이 다루는 민감한 데이터에 대한 통제권이 넘어갈 수 있다는 의미이기도 하다. 그렇다면 컨테이너 보안 취약점을 감지하는 가장 좋은 방법은 무엇일까. 더 근본적으로, 컨테이너를 꼭 사용해야 하는 이들이 보안 취약점 문제의 위험을 최소화하기 위해 무엇을 해야 할까. 이 물음에 대한 대답은 크게 2가지다. 보안 취약점을 스캔하고, 취약점을 피하는 개발방식을 활용해야 한다는 것이다. 먼저 스캐닝부터 살펴보자. 스캐닝은 가장 일반적인 보안 취약점 검출 방법이다. 지속적 통합/지속적 배포(CI/CD) 파이프라인에 포함된 과정이기도 하다. 스캐닝을 통해 코드를 만들어 테스트하고 리뷰하고 배치하는 것은 물론 운영할 때도 보안 문제를 찾을 수 있다. 자동화된 스캐닝 과정을 이용해 보안 취약점을 식별할 수 있고, 때에 따라서는 개발자 개입 없이 자동으로 수정까지 할 수 있다. 레지스트리 스캐닝 또는 여러 리포지...

컨테이너 보안 취약점 2021.11.03

“IT 혁신의 목적지, 비즈니스 혁신의 출발점” 애플리케이션 현대화의 4대 요소와 실행 전략 - IDG Tech Dossier

비즈니스 혁신을 뒷받침해야 하는 기업의 IT 환경은 개발부터 인프라, 심지어 조직 문화까지 전방위적인 변화가 일어나고 있다. 변화의 핵심은 애플리케이션 개발을 더욱 신속하게 진행하고 업데이트 빈도를 늘리는 동시에 품질을 높이고 비즈니스 요구에 더욱 민첩하게 대응하는 것, 즉 애플리케이션 현대화이다. 애플리케이션 현대화의 4가지 핵심 요소인 컨테이너와 컨테이너 오케스트레이션, 클라우드 네이티브와 마이크로 서비스 아키텍처, 데브옵스과 CI/CD, 서버리스 컴퓨팅의 개념과 기본 구성 및 방법론을 살펴보고, 레드햇이 제안하는 구축 방안과 핵심 솔루션을 소개한다. 주요 내용 - 애플리케이션 현대화 기반 다지기 - 클라우드만큼의 민첩성과 효율성 구현하기 - 개발과 운영의 융합으로 지연없는 앱 개발 - 극한의 자원 최적화 구현하기 - 준비된 애플리케이션 현대화 솔루션 레드햇 오픈시프트

컨테이너 쿠버네티스 클라우드 2021.09.15

쿠버네티스 보안 강화를 위한 NSA/CISA 가이드 분석

쿠버네티스는 컨테이너 오케스트레이션을 위한 사실상의 표준이다. 기업의 88%가 컨테이너 오케스트레이션에 쿠버네티스를 사용하고, 그중 74%가 프로덕션 환경에 사용한다는 조사 결과도 있다. 그러나 보안은 여전히 중대한 우려 사항으로, 기업의 94%가 지난 12개월 사이 쿠버네티스 환경에서 한 번 이상 보안 사고를 겪은 것으로 나타났다.    조직이 안전하게 쿠버네티스를 사용하기 위해서는 쿠버네티스를 도입할 때 업계 베스트 프랙티스와 가이드를 따르는 것이 중요하다. 미국 국가안전국(NSA)과 사이버 보안 인프라 보안국(CISA)이 최근 발행한 쿠버네티스 강화 가이드(Kubernetes Hardening Guidance)는 좋은 참고 자료다.  그 외에 쿠버네티스를 위한 유용한 보안 가이드와 서적으로는 인터넷 보안 센터(CIS) 쿠버네티스 벤치마크, 미국 국방부 쿠버네티스 보안 기술 구현 가이드(STIG), 그리고 아쿠아 시큐리티(Aqua Security)의 리즈 라이스와 마이클 하우젠블라스가 쓴 쿠버네티스 보안(Kubernetes Security)이 있다.  쿠버네티스 보안 강화 가이드는 쿠버네티스 보안 위험의 일반적인 발생지를 세 가지로 분류한다. 공급망 위험, 악성 위협 행위자, 내부자 위협이다. 또한 위협 모델링, 쿠버네티스 포드 보안, 네트워크 분리 및 강화, 인증과 권한 부여, 로그 감사, 업그레이드, 애플리케이션 보안 베스트 프랙티스와 같은 중요 영역에 걸쳐 세부적인 내용을 제공한다.  가이드의 도입부에는 쿠버네티스의 핵심 아키텍처 구성요소에 대한 설명이 나와 있다. 중심에는 클러스터가 있고 제어 플레인, 노드, 노드에 위치하는 포드와 같은 클러스터의 핵심 구성요소가 포함된다. 쿠버네티스가 어떻게 기능하고 구성요소가 어떻게 상호작용하며, 궁극적으로 이를 어떻게 보호해야 하는지를 이해하려면 이와 같은 핵심 구성요소를 이해해야 한다.    제어 플레인(Control Plane)&nb...

쿠버네티스 컨테이너 오케스트레이션 2021.08.25

"컨테이너 혁명을 주도하는" 도커의 의미와 장단점

도커(Docker)는 컨테이너에 기반해 애플리케이션을 구축하는 소프트웨어 플랫폼이다. 컨테이너는 운영체제 커널을 공유하지만, 그 외의 경우 서로 격리되어 실행되는 작고 경량의 실행 환경이다. 컨테이너는 리눅스와 유닉스에서 상당 기간 사용됐다. 그러나 2013년 시작된 오픈소스 프로젝트인 도커가 컨테이너 기술을 보편화하는 데 기여했다. 도커에 의해 개발자가 소프트웨어를 패키징 해 ‘한번 구축하면 어디서나 실행할 수 있는(build once and run anywhere)’ 것이 어느 때보다 더 쉬워졌다.     도커의 역사 요약  2008년 솔로몬 하익스가 프랑스 파리에서 닷클라우드(DotCloud)라는 이름으로 설립한 도커는 원래 서비스 플랫폼(platform as a service, PaaS)로서 시작했다. 이후 2013년 플랫폼이 실행되는 기저의 소프트웨어 컨테이너를 보편화하는 것으로 초점이 변화했다.   하익스는 2013년 3월 파이콘(PyCon)에서 도커를 처음 선보였다. 하익스는 도커가 닷클라우드 플랫폼(서비스 플랫폼)을 구동할 기저 기술에 대한 개발자들의 끊임없는 요구를 반영해 개발됐다고 설명했다. 그는 “이 기저 기술이 있다면 리눅스 컨테이너로 무엇이든 할 수 있다. 자체적인 플랫폼을 만들 수 있다. 이게 우리가 하고 있는 것이다”라고 말했다.  그래서 도커가 탄생했다. 이 오픈소스 프로젝트는 개발자들을 신속히 끌어들였고 유명한 IT 업체인 마이크로소프트, IBM, 레드햇 등이 관심을 보였다. 그리고 벤처 투자자들은 이 혁신적인 스타트업에 수백만 달러를 투입할 용의가 있었다. 이렇게 컨테이너 혁명이 시작됐다.  컨테이너란 무엇인가?  하익스가 파이콘에서 설명한 것처럼 컨테이너는 ‘독립형 소프트웨어 단위(self-contained units of software)’로서 서버로부터 서버, 노트북으로부터 EC2, 베어-메탈 자이언트 서버로 전달될 수 있다. 그리고 이는 프로세스 수준에...

도커 Docker 컨테이너 2021.08.04

쿠버네티스 배포를 위한 10가지 고려 사항

컨테이너 개발을 통해 클라우드에서 이식성과 확장성을 독보적인 수준으로 확보할 수 있습니다. 뿐만 아니라 DevOps 개발 및 문화 프랙티스로 비즈니스 가치와 대응력을 향상시킬 수도 있습니다. 그러나 본격적인 컨테이너 개발 프로젝트를 시작하기에 앞서 스스로 물어보아야 할 질문들이 몇 가지 있습니다. 어떤 운영 체제를 사용해야 하는가? 쿠버네티스 플랫폼을 구축해야 하는가, 구입해야 하는가? 새로운 방향으로의 전환이 조직에 어떠한 영향을 미칠 것인가? 등이 바로 그것 입니다. 다음의 10가지 고려 사항을 확인하여 쿠버네티스 배포를 통해 현재 및 향후 엔터프라이즈 환경을 지원해 보세요. <2p> 주요 내용 - 컨테이너는 리눅스, 쿠버네티스 기반 - 기존 환경의 재구성과 DIY 방식 구현 - 클라우드 간 이식성 지원 - 지속적으로 발전하는 쿠버네티스와 적합한 파트너

컨테이너 쿠버네티스 클라우드 2021.07.29

자동화된 엔터프라이즈 : 구성원 및 프로세스를 통합하는 자동화 플랫폼

환경의 복잡성 수준이나 현재 IT 현대화 단계에 관계없이 IT 운영 자동화 전략은 기존의 프로세스 개선에 도움이 될 수 있습니다. 자동화를 통해 시간 절약, 품질 향상, 직원 만족도 개선, 조직 전반의 비용 절감을 실현할 수 있습니다. Red Hat은 조직이 비즈니스 민첩성, 혁신, 가치를 향상시킬 수 있도록 자동화 플랫폼 및 전문 지식을 제공합니다. 본 e-book에서는 자동화의 개념과 대상, 주요 이점과 함께 기업이 조직 전반에 자동화를 도입하는 데 필요한 전략과 주요 활용 분야를 알아보고, 자동화 배포에 필요한 모든 요소를 담고 있는 Red Hat Ansible Automation Platform과 주요 성공 사례를 소개합니다. <20p> 주요 내용 - 성공 = 구성원 + 프로세스 + 플랫폼 - 조직 전반에 자동화를 도입하기 위한 전략 수립 - 활용 사례 : 인프라, 네트웤, 보안, DevOps, 하이브리드 멀티클라우드 - 자동화된 엔터프라이즈를 위한 적합한 기반 선택 - 우수 고객 성공 사례: 마이크로소프트, 지멘스, SBB

자동화 모범사례 컨테이너 2021.07.27

관리형 Kubernetes 플랫폼이 디지털 변혁을 앞당긴다 : 451 리서치

클라우드 네이티브 기술과 현대의 애자일 개발 방식은 불확실성과 싸우고 급변하는 시장 조건에 대응하기 위한 무기로 사용되면서 진행 중인 디지털 변혁을 지원하는 미래 지향적 인프라를 제공합니다. 관리형 서비스는 고객이 운영 복잡성과 종속성에서 벗어나 애플리케이션 개발과 구현에 집중할 수 있게 해줍니다. 451 리서치는 컨테이너와 쿠버네티스, 그리고 관리형 서비스의 주요 트렌드와 비즈니스에 미치는 영향, 향후 전망의 핵심을 정리했습니다. <2p> 주요 내용 -    향후 2년간의 IT 워크로드 관리 목표 -    비즈니스에 미치는 영향 -    전망  

쿠버네티스 컨테이너 매니지드서비스 2021.07.15

2020년 3분기 멀티클라우드 컨테이너 개발 플랫폼 평가 : Forrester Wave

Forrester Research는 고객 분석 기술에 대한 29가지 기준 평가에서 가장 뛰어난 8개 업체(Canonical, D2iQ, Google, Mirantis, Platform9 Systems, Rancher, Red Hat-IBM, VMware)를 선정하고, 이들 업체를 연구 및 분석한 후 점수로 평가했습니다. 이 보고서는 각 공급업체를 측정한 방법을 설명하고 인프라 및 운영 전문가가 요구 사항에 맞는 업체를 선정할 수 있도록 지원합니다. <15p> 주요 내용 - 선두를 달리는 Red Hat-IBM, Google, Rancher - 주요 차별점: 개발 경험, 분산 운영 및 에코시스템 통합 - 공급업체 제품 및 프로필 - 평가 개요 : 공급업체 포함 기준  

멀티클라우드 컨테이너 포레스터 2021.07.15

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.