마이크로소프트랑 대화를 하실 때 enterprise 자격으로 하신건가요 아니면 individual로 하신건가요? Individual 자격으로 하신거면 마이크로소프트라는 회사가 참 대단하네요, 그렇게 큰 기업이 개인 소비자의 feedback에 그렇게 친절하게 반응을 해주니... 제가 생각한게 맞는건가요?
매번....은 아니지만 재밌게 잘 보고 있습니다 :) 이번 강좌에서 AWS Lambda에서는 .net이 지원 안된다고 하셨는데요. 현재 C#을 정식 지원하고 있습니다. 근데 이게 .net core에 대한 이야기라서 C#을 전부 지원한다고 보기가 어려운데요. .net core에 대한 이야기를 다룰 생각이 혹시 있으신가요?
람다는 동일한 의견이예요. 저는 람다보다는 azfunc쪽을 주로 사용해서 그쪽에 조금씩의 개선이 있다는 건 알고 있지만 생각보다 마이크로서비스를 해야할곳이 많지 않고.. 두 프로그램이 통신을 시작하는 순간 신경써야할 외부적 요소가 너무 많아져서(그리고 그에 대응하는 가장 효율적인 방법이 리트라이 큐라....) 필요한 경우가 아니라면 그냥 모노 서버에 머물러 있으라고 말합니다
Docker는 Immutable Infrastructure의 구현체로 알고있습니다. (구현체가 먼저 나오고 이런 이야기들이 나왔는지, 반대인지는 확실하지 않습니다.) Immutable Infrastructure 관련하여 제가 이해한 내용을 간략히 이야기 드리자면, 인프라가 필요할 땐 만들어서 쓰고, 필요 없으면 버리자. 그리고 수정이 필요할 땐 기존의 이미지를 수정하여 사용하는 것이 아니라 새로 만들어서 사용하자는 것으로 알고있습니다. 여기서 말하는 인프라는 아마도 서버를 이야기 하는 것 같아요. 관리적인 면을 강조하고 있다는 느낌이 많이 드네요. 그래서 이미지화 하여 배포하고 필요없으면 이미지만 삭제하면 되니 관리적인 부분에서 이점을 많이 가져갈 수 있다고 생각드네요. 관리적인 이점을 가져가면, 성능과는 거리가 멀어지는 경우가 많아서 Docker의 성능이 VM보다 반드시 좋다고 생각하는덴 무리가 있을 수 있으나, 절차적으로 생각해보면 Docker의 성능이 좋지 않을까 생각합니다. VM의 경우 운영체제 위에 또 운영체제가 올라가는 모양이 되는데, 명령들을 CPU에서 바로 실행이 가능한 매커니즘을 제공한다고 해도 다수의 운영체제를 돌려야 한다면 실제 어플리케이션의 명령들을 실행할 시간에 VM에 올라간 운영체제의 명령을 처리해야 하는 부분이 생길 수 있다고 생각되네요. CPU가 VM에서 운영체제의 명령을 처리하는 시간에, Docker에서는 실행되는 어플리케이션이 CPU의 시간을 더 많이 할당 받을 수 있다면 성능이 더 좋다고 생각됩니다. (다른 요소들을 따져봐야겠지만요. 단순 CPU 타임만 봤을 경우입니다.)
Docker 는 애초에 어플리케이션 실행환경을 격리하고자 시작한 것이고, Virtual Machine 과 시작이 아예 달라서 LXC 로 리눅스의 실행 환경을 격리시키는 개념이라 어플리케이션이 실행되는 레이어 자체가 달라서 VM 보다 배포하기 편하고 관리상 이점이 많습니다.
stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container 퍼포먼스는 저는 이러한 글들을 많이 봐서 드리는 말씀이었는데, 좀 과도한 단어를 사용한 것 같네요. 저는 사용해본적이 없지만 말씀하신 것 같은 .net 과 같은 이미 격리된 배포 환경이라면 말씀하시는 것처럼 굳이 사용할 필요는 없다는데는 동의합니다. 도커의 또다른 장점이면 프로세스 관리하기가 좋고, start/stop 이 빠른건데 이건 알고 계실 것 같네요. 글은 부적절한것 같아 수정했습니다.
제가 관심있는 분야라서 댓글 써봐요. 저같은 경우 Docker 의 유용성은 Auto-scaling보다는 배포에서 이점이 있다고 생각합니다. 그래서 말씀하신 AWS (Beanstalk) vs Docker 구도에선 성능상 큰 이점이 없어보이는 게 사실입니다. 저도 포프님의 의견에 동의합니다. 그래서 오히려 Docker는 Jenkins, ansible, vargrant 같은 배포, 인프라 자동 설정 제품군과 비교해볼때 유용하지 않나 생각합니다. 쉬운 배포야말로 백엔드 개발자 입장에선 매우 중요한 문제인데요. 긴급한 버그 수정이나 새로운 API 도입시 무중단 배포 및 실수없는 배포를 위해서 Docker의 특성이 유용하다고 생각합니다. 특히 docker image 가 마치 git처럼 형상관리가 되므로 과거 기록도 볼 수 있구요. 로컬에서도 서버와 동일한 격리환경에서 테스트 해볼 수 있게 되구요. (물론 서버 운영시 각종 DB 및 2차캐쉬(Redis, memcached), 메시지큐 등등 연동 문제가 있을 수 있겠지만요.) 사실 AWS에서 Docker를 사용하려고 하면 결국 EC2(vm) 위에 docker를 올려야 합니다. AWS ECS 서비스를 하려면 결국 EC2를 필요로 하니 1. AWS vs Azure vs Docker 구도 보다는 2. AWS vs Azure 구도에서 이 위에 Docker 패키지배포 vs 스크립트배포 방식의 서비스 로 생각하시면 Docker 의 유용성이 보이지 않을지 싶습니다. 그러나 MS제품군을 쓰는경우, Docker 기술 자체가 Linux 의 LXC에 종속되어있는 상태이기 때문에 Docker 기술 도입이 힘들거나 의미가 없을 것 같습니다.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
아, 매번 꼬박꼬박 구독하면서 보는데 킾 해뒀다가 다시보다보니 좋아요도 있다는걸 깨달앗네요!
이제 꼬박꼬박 좋아요도 눌러야겠습니다.
팬레터까지 써드리는 수준에는 못미쳤지만(ㅠㅠ) 개발커리어를 시작하면서 부터 늘 멘토로 삼고 있습니다!
늦었지만 새해 복 많이 받으시고 화이팅입니다!
오늘도 좋은 지식 얻어갑니다. 감사합니다.
알기 쉽게 이야기 해주시네요.
마이크로소프트랑 대화를 하실 때 enterprise 자격으로 하신건가요 아니면 individual로 하신건가요? Individual 자격으로 하신거면 마이크로소프트라는 회사가 참 대단하네요, 그렇게 큰 기업이 개인 소비자의 feedback에 그렇게 친절하게 반응을 해주니... 제가 생각한게 맞는건가요?
영상 항상 잘 보고있습니다.
관심 분야입니다, 많은 도움이 되었습니다.
매번....은 아니지만 재밌게 잘 보고 있습니다 :) 이번 강좌에서 AWS Lambda에서는 .net이 지원 안된다고 하셨는데요. 현재 C#을 정식 지원하고 있습니다. 근데 이게 .net core에 대한 이야기라서 C#을 전부 지원한다고 보기가 어려운데요. .net core에 대한 이야기를 다룰 생각이 혹시 있으신가요?
조심스럽게... 좋아요를 누르고 갑니다... :P
지금 시점에서 바라보시는 aws의
ECS, EKS 서비스들과
각종 cncf 인큐베이팅, 그레듀에이티드 프로젝트들에 대한
현재 포프님의 시선도 궁금하네요...
제가 고1때 이 영상을 봤으면 참 좋았을 텐데
왜 나가 놀기만 했을까 흑흑
람다에 대한 얘기도 정말 좋네요
람다 관련해서도 지금시점에서의 시선도 들어보고 싶습니다 🥺
제가 요즘 나오는 클라우드 서비스들로 크게 뭘 만들어본적이 없고 자세히 살펴보지도 않아서 시선이라 할만한 게 없습니다.
간단히 요약하면 "잘 모르는 내용입니다!" 😅
따라서 당장은 이에 대한 비디오를 만들기는 힘들고요 나중에 보게 될 일이 있으면 그때 만들게요~
람다는 동일한 의견이예요. 저는 람다보다는 azfunc쪽을 주로 사용해서 그쪽에 조금씩의 개선이 있다는 건 알고 있지만 생각보다 마이크로서비스를 해야할곳이 많지 않고.. 두 프로그램이 통신을 시작하는 순간 신경써야할 외부적 요소가 너무 많아져서(그리고 그에 대응하는 가장 효율적인 방법이 리트라이 큐라....) 필요한 경우가 아니라면 그냥 모노 서버에 머물러 있으라고 말합니다
@@포프티비 넵 답변 너무 감사해요 ㅠㅠㅠ
정말 존경합니다
Docker는 Immutable Infrastructure의 구현체로 알고있습니다. (구현체가 먼저 나오고 이런 이야기들이 나왔는지, 반대인지는 확실하지 않습니다.)
Immutable Infrastructure 관련하여 제가 이해한 내용을 간략히 이야기 드리자면, 인프라가 필요할 땐 만들어서 쓰고, 필요 없으면 버리자. 그리고 수정이 필요할 땐 기존의 이미지를 수정하여 사용하는 것이 아니라 새로 만들어서 사용하자는 것으로 알고있습니다. 여기서 말하는 인프라는 아마도 서버를 이야기 하는 것 같아요.
관리적인 면을 강조하고 있다는 느낌이 많이 드네요. 그래서 이미지화 하여 배포하고 필요없으면 이미지만 삭제하면 되니 관리적인 부분에서 이점을 많이 가져갈 수 있다고 생각드네요.
관리적인 이점을 가져가면, 성능과는 거리가 멀어지는 경우가 많아서 Docker의 성능이 VM보다 반드시 좋다고 생각하는덴 무리가 있을 수 있으나,
절차적으로 생각해보면 Docker의 성능이 좋지 않을까 생각합니다.
VM의 경우 운영체제 위에 또 운영체제가 올라가는 모양이 되는데, 명령들을 CPU에서 바로 실행이 가능한 매커니즘을 제공한다고 해도 다수의 운영체제를 돌려야 한다면 실제 어플리케이션의 명령들을 실행할 시간에 VM에 올라간 운영체제의 명령을 처리해야 하는 부분이 생길 수 있다고 생각되네요.
CPU가 VM에서 운영체제의 명령을 처리하는 시간에, Docker에서는 실행되는 어플리케이션이 CPU의 시간을 더 많이 할당 받을 수 있다면 성능이 더 좋다고 생각됩니다. (다른 요소들을 따져봐야겠지만요. 단순 CPU 타임만 봤을 경우입니다.)
Docker 는 애초에 어플리케이션 실행환경을 격리하고자 시작한 것이고, Virtual Machine 과 시작이 아예 달라서 LXC 로 리눅스의 실행 환경을 격리시키는 개념이라 어플리케이션이 실행되는 레이어 자체가 달라서 VM 보다 배포하기 편하고 관리상 이점이 많습니다.
stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container
퍼포먼스는 저는 이러한 글들을 많이 봐서 드리는 말씀이었는데, 좀 과도한 단어를 사용한 것 같네요. 저는 사용해본적이 없지만 말씀하신 것 같은 .net 과 같은 이미 격리된 배포 환경이라면 말씀하시는 것처럼 굳이 사용할 필요는 없다는데는 동의합니다. 도커의 또다른 장점이면 프로세스 관리하기가 좋고, start/stop 이 빠른건데 이건 알고 계실 것 같네요. 글은 부적절한것 같아 수정했습니다.
제가 관심있는 분야라서 댓글 써봐요. 저같은 경우 Docker 의 유용성은 Auto-scaling보다는 배포에서 이점이 있다고 생각합니다. 그래서 말씀하신 AWS (Beanstalk) vs Docker 구도에선 성능상 큰 이점이 없어보이는 게 사실입니다. 저도 포프님의 의견에 동의합니다.
그래서 오히려 Docker는 Jenkins, ansible, vargrant 같은 배포, 인프라 자동 설정 제품군과 비교해볼때 유용하지 않나 생각합니다.
쉬운 배포야말로 백엔드 개발자 입장에선 매우 중요한 문제인데요. 긴급한 버그 수정이나 새로운 API 도입시 무중단 배포 및 실수없는 배포를 위해서 Docker의 특성이 유용하다고 생각합니다. 특히 docker image 가 마치 git처럼 형상관리가 되므로 과거 기록도 볼 수 있구요. 로컬에서도 서버와 동일한 격리환경에서 테스트 해볼 수 있게 되구요.
(물론 서버 운영시 각종 DB 및 2차캐쉬(Redis, memcached), 메시지큐 등등 연동 문제가 있을 수 있겠지만요.)
사실 AWS에서 Docker를 사용하려고 하면 결국 EC2(vm) 위에 docker를 올려야 합니다. AWS ECS 서비스를 하려면 결국 EC2를 필요로 하니
1. AWS vs Azure vs Docker 구도 보다는
2. AWS vs Azure 구도에서 이 위에 Docker 패키지배포 vs 스크립트배포 방식의 서비스 로 생각하시면 Docker 의 유용성이 보이지 않을지 싶습니다.
그러나 MS제품군을 쓰는경우, Docker 기술 자체가 Linux 의 LXC에 종속되어있는 상태이기 때문에 Docker 기술 도입이 힘들거나 의미가 없을 것 같습니다.
Beanstalk은 몰라도 azure app service는 docker 기반인데..
컨테이너!
지금은 컨테이너가 훨씬 빠른게 맞겠죠?
느리죠. 뭐든간에 베어 메탈이 제일 빠릅니다.
4.. 4...
오늘 느낀건데 톨발즈 닮으셨네요... avatars3.githubusercontent.com/u/1024025?v=3&s=400
조심스럽게... 2등.
3