지난 XNUMX년간의 기술 살펴보기

메모. 번역: Medium에서 인기를 끌었던 이 기사는 프로그래밍 언어 세계 및 관련 기술 생태계(Docker 및 Kubernetes에 특히 초점을 맞춰)의 주요 변화(2010~2019)에 대한 개요입니다. 원저자는 개발자 도구 및 분산 시스템을 전문으로 하는 Cindy Sridharan입니다. 특히 그녀는 "Distributed Systems Observability"라는 책을 집필했으며, 특히 클라우드 네이티브 주제에 관심이 있는 IT 전문가들 사이에서 인터넷 공간에서 꽤 인기가 있습니다.

2019년이 끝나가면서 저는 지난 XNUMX년간 가장 중요한 기술 발전과 혁신에 대한 제 생각을 공유하고 싶었습니다. 또한 저는 미래를 좀 더 내다보고 향후 XNUMX년의 주요 문제와 기회에 대해 간략하게 설명하려고 노력할 것입니다.

이 글에서는 데이터 과학과 같은 분야의 변화를 다루지 않는다는 점을 분명히 하고 싶습니다. (데이터 과학), 인공 지능, 프론트 엔드 엔지니어링 등은 개인적으로 충분한 경험이 없기 때문입니다.

유형화의 역습

2010년대의 가장 긍정적인 추세 중 하나는 정적으로 입력된 언어의 부활이었습니다. 그러나 이러한 언어는 결코 사라지지 않았지만(C++와 Java는 오늘날 수요가 많으며 2005년 전에는 지배적이었습니다), 2009년 Ruby on Rails 운동이 등장한 이후 동적 유형 언어(동적)의 인기가 크게 증가했습니다. . 이러한 성장은 XNUMX년 Node.js의 오픈 소스로 최고조에 이르렀고, 이를 통해 서버에서 Javascript를 현실화했습니다.

시간이 지남에 따라 동적 언어는 서버 소프트웨어 제작 분야에서 매력을 잃었습니다. 컨테이너 혁명 중에 대중화된 Go 언어는 병렬 처리를 통해 리소스 효율적인 고성능 서버를 만드는 데 더 적합해 보였습니다. 동의하다 Node.js의 창시자 자신).

2010년에 소개된 Rust에는 다음과 같은 기능이 향상되었습니다. 유형 이론 안전하고 형식화된 언어가 되기 위해 노력하고 있습니다. XNUMX년대 전반기에는 Rust에 대한 업계의 반응이 다소 미온적이었지만, 후반기에 그 인기가 크게 높아졌습니다. Rust의 주목할만한 사용 사례에는 다음과 같은 용도가 포함됩니다. Dropbox의 Magic Pocket, AWS의 폭죽 (우리는 그것에 대해 이야기했습니다 이 기사 - 대략. 번역), 초기 WebAssembly 컴파일러 루셋 Fastly(현재 bytecodealliance의 일부) 등. Microsoft가 Windows OS의 일부를 Rust로 다시 작성할 가능성을 고려하고 있는 상황에서, 이 언어는 2020년대에 밝은 미래를 가지고 있다고 말해도 무방합니다.

동적 언어에도 다음과 같은 새로운 기능이 있습니다. 선택적 유형 (선택형). 이는 입력된 코드를 생성하고 이를 JavaScript로 컴파일할 수 있는 언어인 TypeScript에서 처음 구현되었습니다. PHP, Ruby 및 Python에는 자체 선택적 입력 시스템(마이피, 마구 자르기), 성공적으로 사용되었습니다. 생산.

SQL을 NoSQL로 반환

NoSQL은 XNUMX년대 말보다 XNUMX년대 초반에 훨씬 더 인기를 끌었던 또 다른 기술입니다. 여기에는 두 가지 이유가 있다고 생각합니다.

첫째, 스키마, 트랜잭션이 부족하고 일관성 보장이 약한 NoSQL 모델은 SQL 모델보다 구현하기가 더 어려운 것으로 나타났습니다. 안에 블로그 게시물 "가능한 경우 강력한 일관성을 선호해야 하는 이유"라는 제목으로 (가능한 경우 강력한 일관성을 선택해야 하는 이유) 구글은 다음과 같이 씁니다:

Google에서 배운 것 중 하나는 엔지니어가 기존 스토리지를 사용하여 복잡한 트랜잭션을 처리하고 데이터를 순서대로 유지할 수 있으면 애플리케이션 코드가 더 간단해지고 개발 시간이 단축된다는 것입니다. 원본 Spanner 문서를 인용하면 "우리는 프로그래머가 트랜잭션 부재를 염두에 두는 것보다 병목 현상이 발생할 때 트랜잭션 남용으로 인한 애플리케이션 성능 문제를 처리하는 것이 더 낫다고 믿습니다."

두 번째 이유는 "스케일 아웃" 분산 SQL 데이터베이스(예: 클라우드 스패너 и AWS 오로라) 공용 클라우드 공간 및 CockroachDB와 같은 오픈 소스 대안 (우리는 그녀에 대해서도 이야기하고 있습니다 писали - 약. 번역.), 이는 기존 SQL 데이터베이스의 "확장 불가"를 야기한 많은 기술적 문제를 해결합니다. 한때 NoSQL 운동의 전형이었던 MongoDB도 이제는 제공 분산 트랜잭션.

여러 문서(하나 이상의 컬렉션)에 걸쳐 원자성 읽기 및 쓰기가 필요한 상황의 경우 MongoDB는 다중 문서 트랜잭션을 지원합니다. 분산 트랜잭션의 경우 트랜잭션은 여러 작업, 컬렉션, 데이터베이스, 문서 및 샤드에서 사용될 수 있습니다.

전체 스트리밍

Apache Kafka는 의심할 여지없이 지난 2011년간 가장 중요한 발명품 중 하나입니다. Kafka의 소스 코드는 XNUMX년 XNUMX월에 공개되었으며 수년에 걸쳐 Kafka는 기업의 데이터 작업 방식에 혁명을 일으켰습니다. Kafka는 스타트업부터 대기업까지 제가 일했던 모든 회사에서 사용되었습니다. 제공하는 보증 및 사용 사례(pub-sub, 스트림, 이벤트 기반 아키텍처)는 데이터 저장부터 모니터링 및 스트리밍 분석에 이르기까지 금융, 의료, 공공 부문, 소매업 등

지속적인 통합(및 그 이하의 지속적인 배포)

지속적인 통합은 지난 10년간 나타나지 않았지만 지난 XNUMX년 동안 이 정도로 퍼졌다, 이는 표준 워크플로의 일부가 되었습니다(모든 끌어오기 요청에 대해 테스트 실행). 코드를 개발하고 저장하기 위한 플랫폼으로 GitHub를 구축하고, 더 중요하게는 GitHub를 기반으로 하는 워크플로를 개발합니다. GitHub 흐름 이는 마스터에 대한 풀 요청을 수락하기 전에 테스트를 실행하는 것이 단 하나의 지난 XNUMX년 동안 경력을 시작한 엔지니어들에게 친숙한 개발 워크플로입니다.

지속적인 배포(각 커밋이 마스터에 도달할 때마다 배포)는 지속적인 통합만큼 광범위하지 않습니다. 그러나 배포를 위한 다양한 클라우드 API, Kubernetes(배포를 위한 표준화된 API 제공)와 같은 플랫폼의 인기 증가, 그리고 Spinnaker(표준화된 API를 기반으로 구축됨)와 같은 다중 플랫폼, 다중 클라우드 도구의 출현으로 인해 API), 배포 프로세스가 더욱 자동화되고 간소화되었으며 일반적으로 더욱 안전해졌습니다.

컨테이너

컨테이너는 아마도 2010년대 가장 과장되고, 논의되고, 광고되고, 오해받는 기술일 것입니다. 반면에 이는 지난 XNUMX년간 가장 중요한 혁신 중 하나입니다. 이 모든 불협화음의 원인 중 하나는 우리가 거의 모든 곳에서 수신하고 있는 혼합 신호에 있습니다. 이제 과대광고가 다소 사그라들었고, 몇 가지 사항이 더욱 명확해졌습니다.

컨테이너가 인기를 얻은 것은 글로벌 개발자 커뮤니티의 요구 사항을 충족하는 애플리케이션을 실행하는 가장 좋은 방법이기 때문이 아닙니다. 컨테이너는 완전히 다른 문제를 해결하는 특정 도구에 대한 마케팅 요청에 성공적으로 부합했기 때문에 인기를 얻었습니다. Docker는 다음과 같이 밝혀졌습니다. 환상적인 긴급한 호환성 문제를 해결하는 개발 도구입니다("내 컴퓨터에서 작동").

더 정확하게는 혁명이 이루어졌다. 도커 이미지, 환경 간의 패리티 문제를 해결하고 애플리케이션 파일뿐만 아니라 모든 소프트웨어 및 운영 종속성에 대한 진정한 이식성을 제공했기 때문입니다. 이 도구가 본질적으로 매우 낮은 수준의 구현 세부 사항인 "컨테이너"의 인기를 불러일으켰다는 사실은 아마도 지난 XNUMX년 동안의 주요 미스터리로 남아 있습니다.

서버리스

"서버리스" 컴퓨팅의 출현은 온디맨드 컴퓨팅의 꿈을 현실로 만들기 때문에 컨테이너보다 훨씬 더 중요하다고 장담합니다. (온 디맨드). 지난 XNUMX년 동안 저는 새로운 언어와 런타임에 대한 지원을 추가하여 서버리스 접근 방식의 범위가 점차 확장되는 것을 보았습니다. Azure 내구성 함수와 같은 제품의 출현은 상태 저장 기능 구현을 향한 올바른 단계인 것 같습니다(동시에 결정적인 몇 가지 문제FaaS 제한과 관련됨). 나는 이 새로운 패러다임이 앞으로 어떻게 발전할지 관심을 갖고 지켜볼 것입니다.

오토메이션

아마도 이러한 추세의 가장 큰 수혜자는 운영 엔지니어링 커뮤니티일 것입니다. 이를 통해 IaC(Infrastructure as Code)와 같은 개념이 현실화될 수 있기 때문입니다. 또한 자동화에 대한 열정은 보다 소프트웨어 중심적인 운영 접근 방식을 취하는 것을 목표로 하는 "SRE 문화"의 부상과 동시에 발생했습니다.

범용 API화

지난 XNUMX년간의 또 다른 흥미로운 특징은 다양한 개발 작업의 API화였습니다. 훌륭하고 유연한 API를 통해 개발자는 혁신적인 워크플로와 도구를 만들 수 있으며, 이는 결과적으로 유지 관리에 도움이 되고 사용자 경험을 향상시킬 수 있습니다.

또한 API화는 일부 기능이나 도구의 SaaS화를 향한 첫 번째 단계입니다. 이러한 추세는 마이크로서비스의 인기 증가와도 일치합니다. SaaS는 API를 통해 액세스할 수 있는 또 다른 서비스가 되었습니다. 이제 모니터링, 결제, 로드 밸런싱, 지속적인 통합, 경고, 기능 전환과 같은 영역에서 사용할 수 있는 SaaS 및 FOSS 도구가 많이 있습니다. (기능 신고), CDN, 트래픽 엔지니어링(예: DNS) 등이 지난 XNUMX년 동안 번성했습니다.

관찰 가능성

오늘날 우리가 액세스할 수 있다는 점은 주목할 가치가 있습니다. 훨씬 더 발전된 그 어느 때보다 애플리케이션 동작을 모니터링하고 진단하는 도구입니다. 2015년에 오픈소스로 인정받은 프로메테우스 모니터링 시스템은 아마도 '프로메테우스 모니터링 시스템'이라고 부를 수 있을 것 같습니다. 최고 내가 함께 일했던 사람들의 모니터링 시스템. 완벽하지는 않지만 상당수가 정확하게 올바른 방식으로 구현됩니다(예: 측정 지원). [차원성] 측정항목의 경우).

분산 추적은 OpenTracing(및 후속 OpenTelemetry)과 같은 이니셔티브 덕분에 2010년대에 주류로 편입된 또 다른 기술이었습니다. 추적은 여전히 ​​적용하기 매우 어렵지만 최신 개발 중 일부는 2020년대에 추적의 진정한 잠재력을 발휘할 수 있다는 희망을 줍니다. (참고: 저희 블로그에서 "라는 기사 번역도 읽어보세요.분산 추적: 우리가 모두 잘못했습니다"같은 작가의 작품입니다.)

미래를 바라보며

불행하게도 앞으로 XNUMX년 동안 해결을 기다리는 문제점이 많이 있습니다. 다음은 그것들에 대한 나의 생각과 그것들을 제거하는 방법에 대한 몇 가지 잠재적인 아이디어입니다.

무어의 법칙 문제 해결

Dennard의 스케일링 법칙이 끝나고 무어의 법칙이 뒤처지는 현상에는 새로운 혁신이 필요합니다. 존 헤네시 그의 강의 문제 중독자가 왜 문제인지 설명합니다. (도메인별) TPU와 같은 아키텍처는 무어의 법칙에 뒤처지는 문제에 대한 해결책 중 하나일 수 있습니다. 다음과 같은 툴킷 MLIR Google의 제안은 이미 이 방향으로 좋은 진전을 이룬 것으로 보입니다.

컴파일러는 새로운 애플리케이션을 지원하고, 새로운 하드웨어로 쉽게 이식되어야 하며, 동적 관리 언어부터 벡터 가속기 및 소프트웨어 제어 저장 장치에 이르기까지 여러 추상화 계층을 연결하는 동시에 자동 조정을 위한 고급 스위치를 제공해야 합니다. 기능 측면에서는 시간, 진단, 스택 전반에 걸쳐 시스템의 기능 및 성능에 대한 디버깅 정보 배포를 수행하며 대부분의 경우 수동으로 작성한 어셈블러에 가까운 성능을 제공합니다. 우리는 이러한 컴파일 인프라의 개발 및 공개 가용성에 대한 비전, 진행 상황 및 계획을 공유할 계획입니다.

CI / CD

CI의 부상이 2010년대 가장 큰 트렌드 중 하나가 되었지만 Jenkins는 여전히 CI의 표준입니다.

이 공간은 다음 영역에서 혁신이 절실히 필요합니다.

• 사용자 인터페이스(인코딩 테스트 사양을 위한 DSL)
• 진정으로 확장 가능하고 빠르게 만들 수 있는 구현 세부 사항
• 보다 발전된 형태의 테스트를 구현하기 위해 다양한 환경(스테이징, 프로덕션 등)과 통합합니다.
• 지속적인 테스트 및 배포.

개발자 도구

업계로서 우리는 점점 더 복잡하고 인상적인 소프트웨어를 만들기 시작했습니다. 그러나 자체 도구를 사용하면 상황이 훨씬 더 좋아질 수 있습니다.

협업 및 원격(ssh를 통한) 편집은 어느 정도 인기를 얻었지만 새로운 표준 개발 방식이 되지는 못했습니다. 만약 당신이 나처럼 그 생각 자체를 거부한다면 필요 단지 프로그래밍을 하기 위해 인터넷에 영구적으로 연결해야 한다면, 원격 시스템에서 SSH를 통해 작업하는 것은 적합하지 않을 것입니다.

특히 대규모 서비스 지향 아키텍처를 작업하는 엔지니어에게는 로컬 개발 환경이 여전히 어려운 문제입니다. 일부 프로젝트에서는 이 문제를 해결하려고 노력하고 있으며, 주어진 사용 사례에서 가장 인체공학적인 UX가 어떤 모습일지 알고 싶습니다.

또한 "이식 가능한 환경" 개념을 버그 재현(또는 불안정한 테스트) 특정 조건이나 설정에서 발생합니다.

또한 의미론적 및 상황에 맞는 코드 검색, 생산 사고를 코드베이스의 특정 부분과 연관시키는 도구 등과 같은 영역에서 더 많은 혁신을 보고 싶습니다.

컴퓨팅(PaaS의 미래)

2010년대 컨테이너와 서버리스에 대한 과대광고에 이어 지난 몇 년 동안 퍼블릭 클라우드 공간의 솔루션 범위가 크게 확장되었습니다.

이것은 몇 가지 흥미로운 질문을 제기합니다. 우선, 퍼블릭 클라우드에서 사용 가능한 옵션 목록이 지속적으로 늘어나고 있습니다. 클라우드 서비스 제공업체는 오픈 소스 세계의 최신 개발 상황을 쉽게 따라잡을 수 있는 직원과 리소스를 보유하고 있으며 "서버리스 포드"(단순히 자체 FaaS 런타임을 OCI 호환으로 만드는 것으로 의심됨) 또는 기타 이와 유사한 제품을 출시합니다.

이러한 클라우드 솔루션을 사용하는 사람들은 부러워할 수밖에 없습니다. 이론적으로 Kubernetes 클라우드 제품(GKE, EKS, Fargate의 EKS 등)은 워크로드 실행을 위해 클라우드 공급자 독립적인 API를 제공합니다. 유사한 제품(ECS, Fargate, Google Cloud Run 등)을 사용하고 있다면 서비스 제공업체가 제공하는 가장 흥미로운 기능을 이미 최대한 활용하고 있을 것입니다. 또한 새로운 제품이나 컴퓨팅 패러다임이 등장하면 마이그레이션이 간단하고 스트레스 없이 진행될 수 있습니다.

이러한 솔루션의 범위가 얼마나 빨리 진화하고 있는지를 고려하면(가까운 미래에 몇 가지 새로운 옵션이 나타나지 않으면 매우 놀랄 것입니다), 소규모 "플랫폼" 팀(인프라와 관련되고 온프레미스 플랫폼을 만드는 책임을 맡은 팀) 워크로드를 운영하는 기업)은 기능, 사용 용이성 및 전반적인 안정성 측면에서 경쟁하기가 매우 어려울 것입니다. 2010년대에는 Kubernetes를 PaaS(Platform-as-a-Service) 구축을 위한 도구로 보았기 때문에 대중에게 제공되는 것과 동일한 선택, 단순성 및 자유를 제공하는 Kubernetes 위에 내부 플랫폼을 구축하는 것이 전혀 무의미해 보입니다. 클라우드 공간. 컨테이너 기반 PaaS를 "Kubernetes 전략"으로 구성하는 것은 클라우드의 가장 혁신적인 기능을 의도적으로 피하는 것과 같습니다.

사용 가능한 것을 보면 오늘 컴퓨팅 기능을 갖춘다면 Kubernetes만을 기반으로 한 자신만의 PaaS를 만드는 것은 자신을 궁지로 몰고 가는 것과 다름없다는 것이 분명해졌습니다(아주 미래 지향적인 접근 방식은 아니죠?). 지금 누군가가 Kubernetes에 컨테이너화된 PaaS를 구축하기로 결정하더라도 몇 년 후에는 클라우드 기능에 비해 낡아 보일 것입니다. Kubernetes는 오픈소스 프로젝트로 시작되었지만 그 조상이자 영감은 내부 Google 도구입니다. 그러나 원래 컴퓨팅 환경이 완전히 다른 2000년대 초중반에 개발되었습니다.

또한 매우 넓은 의미에서 기업은 Kubernetes 클러스터 운영 전문가가 될 필요도 없고 자체 데이터 센터를 구축하고 유지 관리할 필요도 없습니다. 안정적인 컴퓨팅 기반을 제공하는 것이 핵심 과제입니다. 클라우드 서비스 제공업체.

마지막으로, 우리는 업계 측면에서 약간 퇴보한 것 같습니다. 상호작용 경험 (UX). Heroku는 2007년에 출시되었으며 여전히 가장 인기 있는 서비스 중 하나입니다. 사용하기 쉬운 플랫폼. Kubernetes가 훨씬 더 강력하고 확장 가능하며 프로그래밍 가능하다는 사실은 부인할 수 없지만 Heroku를 시작하고 배포하는 것이 얼마나 쉬운지 그리워합니다. 이 플랫폼을 사용하려면 Git만 알면 됩니다.

이 모든 것이 다음과 같은 결론에 이르게 합니다: 작동하려면 더 나은, 더 높은 수준의 추상화가 필요합니다(특히 다음과 같은 경우에 해당됩니다). 최고 수준의 추상화).

최고 수준의 올바른 API

Docker는 동시에 우려 사항을 더 효과적으로 분리해야 하는 필요성을 보여주는 좋은 예입니다. 최고 수준 API의 올바른 구현.

Docker의 문제는 (적어도) 처음에는 프로젝트의 목표가 너무 광범위했다는 것입니다. 모든 것은 컨테이너 기술을 사용하여 호환성 문제(“내 컴퓨터에서 작동”)를 해결하기 위한 것이었습니다. Docker는 이미지 형식, 자체 가상 네트워크가 있는 런타임, CLI 도구, 루트로 실행되는 데몬 등이었습니다. 어쨌든 메시지 교환은 더 "경량 VM", cgroup, 네임스페이스, 수많은 보안 문제 및 기능은 말할 것도 없고 "어디서든 모든 애플리케이션을 구축, 제공, 실행"하라는 마케팅 요구와 혼합되어 혼란스럽습니다.

모든 좋은 추상화와 마찬가지로 다양한 문제를 서로 결합할 수 있는 논리적 계층으로 나누는 데는 시간(그리고 경험과 고통)이 필요합니다. 불행하게도 Docker가 비슷한 성숙도에 도달하기 전에 Kubernetes가 경쟁에 뛰어들었습니다. 과대광고 주기를 너무 독점했기 때문에 이제 모두가 Kubernetes 생태계의 변화를 따라잡으려고 노력했고, 컨테이너 생태계는 부차적인 지위를 차지했습니다.

Kubernetes는 Docker와 동일한 문제를 많이 공유합니다. 멋지고 구성 가능한 추상화에 대한 모든 이야기에 대해서는 다양한 작업을 레이어로 분리 잘 캡슐화되지 않았습니다. 핵심은 다양한 머신의 클러스터에서 컨테이너를 실행하는 컨테이너 오케스트레이터입니다. 이는 클러스터를 운영하는 엔지니어에게만 적용되는 상당히 낮은 수준의 작업입니다. 반면 쿠버네티스도 마찬가지다. 최고 수준의 추상화, 사용자가 YAML을 통해 상호 작용하는 CLI 도구입니다.

Docker는 과거에도 그랬고 지금도 그렇습니다. 시원한 모든 단점에도 불구하고 개발 도구입니다. 모든 "토끼"를 한 번에 따라잡기 위해 개발자는 올바르게 구현했습니다. 최고 수준의 추상화. 가장 높은 수준의 추상화란 내 말은 부분 집합 대상 사용자(이 경우 대부분의 시간을 로컬 개발 환경에서 보낸 개발자)가 실제로 관심을 갖고 즉시 훌륭하게 작동하는 기능.

Dockerfile 및 CLI 유틸리티 docker 좋은 "최고 수준의 사용자 경험"을 구축하는 방법의 예가 되어야 합니다. 일반 개발자는 복잡한 사항에 대해 전혀 모르더라도 Docker 작업을 시작할 수 있습니다. 운영 경험에 기여하는 구현네임스페이스, cgroup, 메모리 및 CPU 제한 등 궁극적으로 Dockerfile을 작성하는 것은 셸 스크립트를 작성하는 것과 크게 다르지 않습니다.

Kubernetes는 다양한 대상 그룹을 대상으로 합니다.

• 클러스터 관리자;
• 인프라 문제를 해결하고 Kubernetes의 기능을 확장하고 이를 기반으로 플랫폼을 만드는 소프트웨어 엔지니어
• 최종 사용자는 다음을 통해 Kubernetes와 상호작용합니다. kubectl.

Kubernetes의 "모든 것에 적합한 하나의 API" 접근 방식은 확장 방법에 대한 지침 없이 캡슐화되지 않은 "복잡성의 산"을 나타냅니다. 이 모든 것이 정당화될 수 없을 정도로 장기간의 학습 궤적을 초래합니다. 어떻게 기록 Adam Jacob, “Docker는 그 어느 때보다도 획기적인 사용자 경험을 선사했습니다. K8을 사용하는 사람에게 처음처럼 작동하고 싶은지 물어보세요. docker run. 대답은 '예'입니다.":

나는 오늘날 대부분의 인프라 기술이 너무 낮은 수준(따라서 "너무 복잡"하다고 간주됨)이라고 주장하고 싶습니다. Kubernetes는 상당히 낮은 수준에서 구현됩니다. 분산 추적 현재 형태 (트레이스뷰를 형성하기 위해 함께 스티치된 많은 범위)도 너무 낮은 수준에서 구현됩니다. "최고 수준의 추상화"를 구현하는 개발자 도구가 가장 성공적인 경향이 있습니다. 이 결론은 놀랄 만큼 많은 경우에 적용됩니다(기술이 너무 복잡하거나 사용하기 어려운 경우 해당 기술에 대한 "최고 수준의 API/UI"가 아직 발견되지 않은 경우).

현재 클라우드 네이티브 생태계는 낮은 수준의 집중으로 인해 혼란을 겪고 있습니다. 업계로서 우리는 올바른 수준의 "최대, 최고 추상화"가 어떤 것인지 혁신하고 실험하고 교육해야 합니다.

소매

2010년대에도 디지털 소매 경험은 크게 변하지 않았습니다. 한편으로는 온라인 쇼핑의 용이성이 기존 소매점에 강타했어야 했지만, 다른 한편으로는 온라인 쇼핑은 근본적으로 지난 XNUMX년 동안 거의 변하지 않았습니다.

저는 이 산업이 향후 2030년 동안 어떻게 발전할 것인지에 대해 구체적으로 생각하지 않지만, 2020년과 같은 방식으로 XNUMX년에도 쇼핑한다면 매우 실망스러울 것입니다.

저널리즘

나는 글로벌 저널리즘의 상황에 점점 더 환멸을 느끼고 있습니다. 객관적이고 세심하게 보도하는 편견 없는 뉴스 매체를 찾는 것이 점점 더 어려워지고 있습니다. 뉴스 자체와 뉴스에 대한 의견 사이의 경계가 모호해지는 경우가 많습니다. 일반적으로 정보는 편향된 방식으로 제공됩니다. 이는 역사적으로 뉴스와 의견이 분리되지 않았던 일부 국가에서 특히 그렇습니다. 지난 영국 총선 이후 발표된 최근 기사에서 가디언(The Guardian)의 전 편집장인 앨런 루스브리저(Alan Rusbridger)는 다음과 같이 말했습니다. 기록:

요점은 수년 동안 미국 신문을 보면서 뉴스에 전적으로 책임이 있고 논평을 완전히 다른 사람들에게 맡기는 그곳의 동료들에 대해 안타까움을 느꼈다는 것입니다. 그러나 시간이 지나면서 동정심은 시기심으로 바뀌었습니다. 나는 이제 모든 영국 전국 신문이 뉴스에 대한 책임과 논평에 대한 책임을 분리해야 한다고 생각합니다. 불행하게도 일반 독자, 특히 온라인 독자가 그 차이를 구별하는 것은 너무 어렵습니다.

윤리와 관련하여 실리콘 밸리의 다소 모호한 평판을 감안할 때 저는 기술이 저널리즘을 "혁명"시킬 것이라고 결코 믿지 않을 것입니다. 즉, 공정하고, 사심 없고, 신뢰할 수 있는 뉴스 소스가 있다면 저(그리고 제 많은 친구들)는 기뻐할 것입니다. 그러한 플랫폼이 어떤 모습일지는 모르겠지만, 진실을 식별하기가 점점 더 어려워지는 시대에 정직한 저널리즘의 필요성이 그 어느 때보다 크다고 확신합니다.

Социальные сети

소셜 미디어와 커뮤니티 뉴스 플랫폼은 전 세계 많은 사람들의 주요 정보 소스이며, 일부 플랫폼의 정확성이 부족하고 기본적인 사실 확인조차 꺼리므로 대량 학살, 선거 간섭 등과 같은 재앙적인 결과가 초래되었습니다. .

소셜 미디어는 또한 지금까지 존재했던 가장 강력한 미디어 도구이기도 합니다. 그들은 정치적 관행을 근본적으로 변화시켰습니다. 그들은 광고를 바꿨습니다. 그들은 대중 문화를 변화시켰습니다(예를 들어, 소위 취소 문화 발전에 주요한 기여를 했습니다) [배척의 문화 - 대략. 번역] 소셜 네트워크가 기여합니다). 비평가들은 소셜 미디어가 도덕적 가치의 빠르고 변덕스러운 변화를 위한 비옥한 기반임이 입증되었지만, 소외된 집단의 구성원들에게 이전에는 결코 갖지 못했던 방식으로 조직화할 수 있는 기회도 제공했다고 주장합니다. 본질적으로 소셜 미디어는 XNUMX세기 사람들이 의사소통하고 자신을 표현하는 방식을 변화시켰습니다.

그러나 나는 또한 소셜 미디어가 최악의 인간 충동을 가져온다고 믿습니다. 대중성을 위해 배려와 사려 깊음을 등한시하는 경우가 많으며, 특정 의견과 입장에 대해 이성적인 불일치를 표현하는 것이 거의 불가능해집니다. 양극화는 종종 통제할 수 없게 되어 대중이 단순히 개인의 의견을 듣지 못하는 반면 절대주의자들은 온라인 예절과 수용성 문제를 통제하게 됩니다.

더 나은 품질의 토론을 촉진하는 "더 나은" 플랫폼을 만드는 것이 가능한지 궁금합니다. 결국, 이러한 플랫폼에 주요 이익을 가져오는 것은 바로 "참여"를 주도하는 것입니다. 어떻게 기록 New York Times의 Kara Swisher는 다음과 같이 말했습니다.

증오와 편협함을 유발하지 않고 디지털 상호작용을 발전시키는 것이 가능합니다. 대부분의 소셜 미디어 사이트가 유독해 보이는 이유는 콘텐츠와 정확성보다는 속도, 입소문, 관심을 위해 구축되었기 때문입니다.

수십 년 안에 소셜 미디어의 유일한 유산이 공개 담론의 뉘앙스와 적절성의 침식이라면 정말 불행한 일이 될 것입니다.

번역가의 추신

블로그에서도 읽어보세요.

• «Docker 변환: Docker Enterprise를 Mirantis로 판매 및 업데이트된 경로";
• «Kubernetes의 Docker 및 기타 컨테이너 런타임의 과거, 현재, 미래";
• «컨테이너, 클라우드 네이티브 및 Kubernetes에 대한 새로운 CNCF 통계";
• «지속적인 통합이 필요하지 않다고 생각하는 개발자는 몇 명입니까?".

출처 : habr.com