
English: 
Please welcome Joshua McKenty, Head of Global
Ecosystem Engineering at Pivotal.
>> [APPLAUSE] >> Thank you, really happy to
be here.
I put this talk together as a bit of a mix
tape which Belle and Sebastian have helped
to organize the All Tomorrow's Parties events.
And I was a child in the 80s and I loved this
feeling that you get where you listen to all
these different songs on a mix tape and you
don't really understand how they're related
to each other but you get to the end and you
kind of know what the story was about.
And sometimes I feel that way about Cloud

Chinese: 
大家一起欢迎
Pivotal公司
全球生态系统工程部主管
Joshua McKenty
>> [掌声]
>> 谢谢，
很开心可以来到这里。
我把这次演讲弄成杂集，
Bella和Sebastian帮我组织了
《所有明日的派对》的活动。
在80年代我还是一个小孩子的时候，
我很喜欢一种感觉，
就是你拿到一盒合集磁带，
可以听到不同的歌曲，
你不知道这些歌
是怎样相互之间联系起来，
但是你能够听出结局来，
听到这是一个怎样的故事。
有时候Cloud Foundry
给我的感觉就是这样的，
它好像是云原生软件的
一个合集。
当然，
我们在Pivotal的征途，
和大企业一起工作，
也是这样的一种感觉。
他们知道当他们开始播放磁带的时候，
他们就好像踏上了骑行之路，
他们不确定自己要去哪里，
但是他们让自己专注在这个过程。

Japanese: 
Pivotalのグローバル エコシステム
エンジニアリング部門長
ジョシュア・マックケンティー氏を
温かい拍手でお迎えください
>> [拍手]
>> ありがとうございます
ご招待いただき光栄です
今日はBelle & Sebastianが
All Tomorrow's Partiesの
イベントで作った
ミックステープのように
お話ししていきたいと思います
80年代の少年時代に
ミックステープの
色んな曲を聴く
雰囲気が好きでした
複数の曲が
どう混ざり合うのか
分からないながら
最後まで聞くと
どんなストーリーか分かるような
時々Cloud Foundryも
クラウドネイティブソフトウェアの
ミックステープのようなもので
似たようなものだと感じるんです
私たちがPivotalで
大企業と協働していく旅も
それと似たようなところが
あります
テープが展開をしていくことは
分かるものの
実際にどこに向かっているかは
定かではなくて
ただ何かに向かって
走り続ける認識だけはあるのです

Chinese: 
請歡迎Joshua McKenty,
Pivotal全球生態
系統工程主管
>> [鼓掌]
>> 謝謝，
非常高興來到這裡。
我做的這個演講有點像
集錦磁帶，一如Belle
和Sebastian幫忙組織
“所有明日派對”活動。
80年代我還是小孩的時候，
我喜愛能在
一盒集錦磁帶上聽到
所有不同歌曲的感覺
你不知道它們
彼此之間有何聯繫，
但是聽到最後，
您就似乎知道了
故事在說什麼了。
有時我對Cloud Foundry
也有這種感覺，
它就像一盒雲原生
軟體的集錦磁帶。
無疑，我們在
Pivotal的歷程中，
與大企業協作
也有點象集錦磁帶。
他們知道在開始播放
磁帶後，他們將開始某種
旅程，而他們並
不很確定將前往何方，
但他們依然堅決地
繼續走下去。

Russian: 
Поприветствуем
Джошуа Маккенти,
Главу разработки
глобальных экосистем в Pivotal.
>> [АПЛОДИСМЕНТЫ]
>> Спасибо,
очень рад, что пригласили.
Моё выступление
будет своеобразным «сборником».
Его помогали собирать
Белль и Себастиан
во время выступлений
All Tomorrow's Parties.
В 80-е, когда я был ребёнком,
мне так нравилось слушать
сборники различных песен -
не очень понятно,
как они связаны между собой,
но когда дослушиваешь
до конца,
становится понятна
эта общая канва.
Иногда такое же впечатление
возникает от Cloud Foundry,
оно похоже на сборник облачного
программного обеспечения.
Вся наша работа в Pivotal,
взаимодействие с крупными
компаниями, построена на этом.
Когда работа только начинается,
конечная цель
не до конца понятна,
но участники усиленно
вкладываются в процесс.

Korean: 
환영해 주세요
Pivotal사의
Global Ecosystem Engineering
본부장인 Joshua McKenty입니다
>> [박수 갈채]
>> 감사합니다
이 자리에 함께 하게 되어
정말 행복합니다
저에게는 이번 대화가
Belle와 Sebastian이
All Tomorrow's Parties
행사를 조직할 수 있게
도와 준 믹스 테잎의
일부로 여겨집니다
80년대에 저는 아이였는데,
믹스 테입에 있는
이러한 서로 다른 모든 음악을 듣고
서로 간에 어떻게 연결되어 있는지
사실 이해하지도 못하면서
끝까지 듣고 그 이야기가
무엇에 대한 것인 지를 알게 되는
이런 느낌을 좋아했습니다
그리고 때때로
저는 Cloud Foundry에 대한 그 방법이
클라우드 네이티브 소프트웨어의
믹스 테잎인 것처럼 보입니다
그리고 분명 Pivotal에서
대기업들과 협력하고 있는
우리의 여정도 그것과
유사했습니다
그들은 테이프를 시작할 때
자신들이 올라타게 될 것을 알때
어디에서 올라타게 될 것인지
정말로 확신하지 못하지만
그들은 그 과정에 전념하고 있습니다

English: 
Foundry, like it is the mix tape of cloud
native software.
And certainly our journey at Pivotal, working
with large enterprises has been a bit like
that.
They know when they start the tape they're
going on some kind of ride, and they're not
really sure where they're going to get to,
but they kind of commit themselves to that
process.
So I'm really excited to be at Open Dev today,
and really I want to talk about something
that happened recently that was pretty big
moment in the cloud native community really
which is that Microsoft joined the Cloud Foundry
Foundation.
And we've been involved obviously with Cloud
Foundry since the very beginning at Pivotal,
since we spin out of the End-ware where it
was born.
But Microsoft getting involved really is taking
our relationship with them and our partnership
with them to the next level.
So I thought I would cover sort of how we
think about openness at Pivotal.
And how we think about openness in our partnership

Russian: 
Я очень рад, что оказался
здесь, на Open Dev,
и хочу рассказать
о недавнем событии,
которое произвело фурор
в среде облачной разработки:
Microsoft присоединился
к Cloud Foundry Foundation.
Мы, очевидно, сотрудничаем
с Cloud Foundry
с момента его создания в Pivotal,
потому что непосредственно
разрабатывали его.
Но сотрудничество
с Microsoft переводит
наши партнерские отношения
на совершено новый уровень.
Так что я решил рассказать
про политику открытости
компании Pivotal.
Открытости и безопасности
во взаимодействии с Microsoft.
Открытость часто путают
со вседозволенностью,
как при социализме.
Я, как канадец, говорю вам,
что всё может
очень быстро пойти не так.
Но что такое
«открытый» в хорошем смысле,
без излишней доступности?
В разработке,
особенно в сфере ИТ,

Chinese: 
所以，今天来到Open Dev，
我真的挺兴奋的，
想在这里谈谈最近发生的一件事，
这件事对云原生社区来说
是挺重大的一个时刻，
就是微软宣布加入
Cloud Foundry 基金会。
从Pivotal公司
很早期的时候开始，
从我们脱离Piviotal的诞生之本
End-ware开始，
我们就很积极
与Cloud Foundry基金会联系。
但是微软加入进来，
真正把我们之间的关系，
我们的合作关系，
提升到另一个层次。
所以我觉得我可以谈谈
在Pivotal我们是怎么看待
开放性的。
还有我们是怎么看待
我们和微软的合作关系中的开放性，
还有安全地开放这个想法，
对吗？
所以开放总是被定义为
人人都可以做他们想做的事，
或者我们都是社会主义者，
而我是加拿大人，
这件事会以这些不同的形式
出岔子。
但是如果开放是一件正面的事情，
又没有采取过于放任的态度的话，
开放意味着什么呢？

Korean: 
따라서 저는 오늘 Open Dev에서
여러분과 함께 하게 되어 정말 기쁩니다
저는 최근에 일어 났던 어떤 일에
대해서 이야기하고 싶습니다
클라우드 네이티브 커뮤니티에서는
매우 커다란 사건인데,
바로 Microsoft가
Cloud Foundry 재단에 참여한 것입니다
Pivotal은 명백히 초기부터
모태가 되었던 End-ware에서
분사했던 때 이래로
Cloud Foundry에 관여해 왔습니다
하지만 Microsoft가 참여하게 되면
그들과 우리의 관계 및 제휴를
다음 번 수준으로
끌어 올려줄 것입니다
따라서 저는 Pivotal에서의
우리가 개방성에 대해
어떻게 생각하는지 말씀드리고 싶습니다
그리고 Microsoft와의
제휴에 있어서의 개방성과
보안에 대해 개방이라는 아이디어에 대해
어떻게 생각하는지를 다루실 거죠?
그러니까 개방은
누구나 원하는 어떤 것이나 할 수 있다
또는 우리가 모든 종류의
사회주의자라는 것과 관련되는데
제가 캐나다인이라는 점에서
이 모든 상이한 방식에서 틀릴 수 있습니다
하지만 과도하게 방임되지 않고
긍정적인 경우
개방은 무엇을 의미할까요?

Chinese: 
因此我今日來到Open Dev
感到十分興奮，我真的
很想談下最近發生
的一些事情，
是雲原生社區的大事件，就是
微軟加入Cloud
Foundry Foundation.
自Pivotal創立伊始，
即我們從它所誕生的End-ware
（應為“VMware”?)脫離時起，
我們就已積極參與Clould Foundry。
但微軟參與進來確實將我們
與他們的關係以及我們與
他們的合作關係帶到新的水準。
所以我想我會說下
我們在Pivotal對開放的
看法。
以及我們如何看待與
微軟合作關係中的開放
和開放的安全，好不好？
開放常常和任何人
能做想做的任何事，
或者說我們都是社會主義者
混為一談，我是加拿大人，
這可能在所有方面都出問題。
但開放意味著什麼，
讓它既是一個正面的事物，
又不會變得過於自由？

Japanese: 
今日OpenDevでお話できることを
大変光栄に思っています
最近MicrosoftがCloud Foundry
Foundationに参画したという
クラウドネイティブコミュニティで
起こった大きな出来事について
お話ししたいと思います
私たちはEnd-wareから
スピンアウトし
Pivotalとして立ち上げた
初期の段階から
Cloud Foundryで
活動をしていますが
Microsoftの参画は
私達のパートナーシップを
次のステップに導きました
その時Pivotalでの
オープンネスについてや
Microsoftとの
パートナーシップでの
オープンネスについて
考えました
セキュリティのある
オープンネスのあり方についてです
オープンネスとは誰でも
なんでもできると誤解されがちですが
私は社会主義者だ
私はカナダ人だというやり方だと
間違った方向に行く
可能性もあります
悲観的になりすぎない
ポジティブな場合の
オープンの意味とは？

Korean: 
그러니까 소프트웨어와
특히 IT에서는
일종의 3가지 축으로
열려 있습니다, 맞죠?
어떤 언어를 사용할 수 있습니까?
우리는 기업의 개발자로서
역사적으로
Java 또는 .NET으로 작성할 것인지
아니면 COBOL로 작성하게 된다는
말을 듣게 되고,
그게 우리가 듣는 모든 것이었습니다
여러분의 재량권에 COBOL만 있다면
정말 제약적입니다
따라서 지난 10년 동안
특히 정말 지난 5년 동안
무수히 일어났던 일들은
언어의 개방성이라는
여러 언어 통용으로의 움직임이었습니다
우리는 이제 Python으로
또는 Node.js나 GO로
또는 Java와 .NET의 혼합으로
작성할 수 있고
이들 응용프로그램들은 중요하지 않고
정말 중요한 응용프로그램 아키텍처들이
언어 선택보다 높이 대두되었습니다
개방성에 대한 두 번째 아이디어는
내 앱이 실제로 어디에서 실행되는가입니다
저는 작업하는 동안 해당 앱을
제 노트북에서 실행하고 싶습니다

Chinese: 
在軟體方面，尤其是在IT領域，
我認為我們在三個
方面開放了，對嗎？
我允許使用什麼語言？
作為企業開發者，
以往我們會被要求說，
你應該用Java寫，
或者應該用.NET，
或者應該用COBOL，只能如此。
只能使用COBOL限制性真的很大。
所以過去10年發生了很多事情，
但尤其是過去5年
向語言的開放邁進。
現在我們可以用Python
或者Node.js或者GO或
Java和.NET結合，那些
應用程式並不在乎，
應用程式架構提升到
語言選擇之上，這一點非常重要。
第二個開放的想法是
我們的應用在哪裡運行？
當我在筆記本上工作時，
它能我的筆記型電腦上運行，

Japanese: 
ソフトウェアの場合
特にITの世界では
3つの軸を基本として
オープンネスを考えます
どんな言語を使うことが
できるのか
企業の開発者として
かつてはJavaや
.NETができるか
もしくはCobolができるか
よく聞かれたものです
そしてCobolだけだと
かなり制限された環境になる
そんな状況がこの10年
沢山ありました
ただこの5年で
複数言語への解放に
向かっています
現在はPythonでもNode jsでも
GOでも書くこともできるし
Java と.NETを
組み合わせることもできる
アプリケーションは
言語にこだわっていません
アーキテクチャーが言語以上に
重要な役割を担っています
第2のオープンネスについて言うと
どこでアプリケーションを実行するかです
例えば作業中は
ラップトップで実行して

Chinese: 
所以在软件上，
尤其是IT上，
我觉得从三个层面来看
我们已经开放了，对吗？
允许我
用什么语言？
作为一位企业开发者，
在过去，总是告诉我们，
你应该用Java来编写，
或者你应该用 .NET来编写，
或者你应该用COBOL来编写，
然后这就是你全部得到的东西。
如果供你使用的只有COBOL的话，
真的非常受限。
所以过去十年发生的事情，
尤其是
过去五年发生的事情，
都是围绕
多语言编程的语言开放性。
现在我们可以用Python编写，
或者用Node.js 、用Go语言编写，
或者混合Java语言和.NET平台来编写，
有这些应用程序不是我们真正关心的，
让应用程序架构高于语言选择，
这才是真的重要的。
关于开放性的第二个想法是
我的App会在哪里运行？
我希望我在用笔记本电脑工作的时候，
可以运行这个App。

Russian: 
открытость рассматривается
в трёх направлениях:
на каком языке стоит писать?
Разработчикам корпоративных
приложений обычно говорят:
«Эй, пиши-ка на Java»,
или «пиши на .NET»,
максимум, «используй COBOL»,
и всё, вариантов нет.
Один язык сильно
ограничивает возможности.
Но за последние 10 лет
многое изменилось,
особенно в последние 5,
всё идёт к развитию
полиглоссии, открытости языков.
Сейчас можно писать на Python,
или на Node.js, или на GO,
или на смеси Java и .NET, и
приложения не зависят от этого,
архитектура приложений
вышла за рамки
исходного языка,
это очень важно.
Второе направление открытости -
где приложение запускается?
Я хочу видеть его на лэптопе
в процессе разработки,

English: 
with Microsoft and the idea of open with security,
right?
So open is often conflated with just well
anyone can do anything that want or we're
all sort of socialists, and I'm Canadian,
and this can go wrong in all these different
ways.
But what does open mean when it's a positive
thing, without getting overly permissive?
So in software, and particularly in IT, I
think we've opened in terms of sort of three
axes, right?
What language am I allowed to use?
As an enterprise developer, historically we
were told hey, you shall write in Java, or
you shall write in .NET, or you shall write
in COBOL, and that's all you get.
And only having COBOL at your disposal is
really limiting.
And so a lot of what’s happened in the last
ten years, but really particularly in the
last five has been around this move towards
polyglot of the openness of languages.
We can write now in Python or in Node.js or

Russian: 
хочу запустить его
в среде разработки,
удобной для моей команды
или вида бизнеса.
Хочу запускать его
в любом открытом облаке,
или в любой системе
обработки данных
по всему миру.
Так что свобода запуска
приложения в различных средах,
вне зависимости
от «точки сборки» -
это важный момент.
Последнее направление -
какими сервисами
я могу пользоваться?
Обычно в большой корпорации
мы оказываемся привязаны
к одной базе данных,
одной системной очереди.
«Да воспользуетесь вы
серверами в подсобке,
не отступитесь вы от базы,
и доступных на ней сервисов.»
Но мы уже выросли
из этих ограничений
и хотим удобств
SQL вместе с удобствами NoSQL.
Хочу Q Services,
хочу In-memory, Cache.
Сегодня мне удобен Redis, а
завтра - GemFire в паре с Mongo.
И Cassandra, и Бог его знает,
что мне ещё понадобится.

Japanese: 
チーム内やビジネスラインで
協働する時は
Dev環境で実行したい
場合によっては
パブリッククラウドで実行したい
また世界各地のプロダクションの
データセンターで
実行したい時もあるでしょう
どこで構築させたかにかかわらず
アプリケーションを
様々なロケーションで実行できる自由は
とても重要な違いと
なってきます
最後のオープンネスについては
何のサービスを使うのかです
大企業では従来型の
単一のデータベースや
単一のキューシステムに
固定されていて
地下室のデータベースの
ラックを使えとか
メインフレームを使えとか
これに合うサービスを使え
と言われます
この時代からは
かなり進歩しました
現在はSQやNoSQLを
使いたいとか
Qサービスやキャッシュや
インメモリーを使いたいと言えます
今日はRedisで
明日はGemFireと
MongoとCassandraという風にもです

Korean: 
저는 제 팀이나 제 사업부 전용의
개발 환경에서 실행하고 싶습니다
그리고 제가 원하는 경우
공용 클라우드에서 실행하고 싶고
가능한 경우 전 세계에 있는
서비스 데이터 센터에서도
실행하고 싶습니다
따라서 제 응용프로그램이
어디에서 제작되었든
서로 다른 장소에서 실행할 수 있는
자유를 갖는 것은
정말 중요한 분리입니다
개방성에 대한 마지막 의미는
어떤 서비스를 이용할 수 있는가입니다
그리고 다시,
대기업에서의 전통은
우리가 단일 데이터베이스나
단일 대기열 시스템에 종속되는 것이었습니다
너는 지하에 있는
데이터베이스 랙을 사용해야 한다
너는 그것과 호환되는
메인 프레임과 서비스를 이용해야 한다
우리는 이제 그것 이상으로 성장하여
나는 SQL의 풍미와 NoSQL의
풍미를 원한다고 말할 수 있습니다
나는 Q 서비스를 원해요,
나는 인 메모리, 캐시를 원해요
아마 그것은 오늘날 Redis이고,
내일은 GemFire, Mongo일 수 있습니다
그리고 Cassandra와
제가 원하는 어떤 서비스일 수 있습니다

Chinese: 
我想能在專用於
我的團隊或我的業務
的開發環境中運行。
我想能在我選擇的公有雲中運行，
也能在也許全世界的生產資料中心
運行。
所以，無論我的應用在那裡創建，
我都有在不同地方運行它
的自由，這是一個很重要的
分離。
最後一個有關開放的觀念是，
我能用什麼服務？
同樣地，傳統上在大企業中，
我們被限制於
也許單一資料庫或者單一佇列系統。
你應該使用地下室的資料庫架。
你應該用配套的
主機和服務。
我們現在已經有所突破，
例如我可以用SQL，也可以不用SQL。
我要用Q服務，
我要用In-memory, Cache。
也許今日用Redis，明天用
GemFire和Mongo。
還有Cassandra，
和我想用的任何服務。

Chinese: 
我希望可以在可能供我的团队专用，
或者供业务范围专用的Dev环境下
运行这个App。
然后我希望可以
在我选择的公共云上，
以及也许在全世界的
生产数据中心里，
运行这个App。
所以，不管我是在哪里搭建的这个App，
我都有自由，在不同的地方
去运行我的App，
这两项分隔开非常重要。
开放性的最后一个意义是，
我可以用到什么服务？
然后再一次，
一般在大型企业，
我们可能受限于单个数据库
或者单个队列系统。
你应该使用在底层的
那堆数据库。
你应该用
和这些数据库兼容的
主框架和服务。
现在，我们远远
超越这个层次了，
我想要SQL语句风格，
NoSQL语句风格。
我想要队列服务,
我想要内存数据库、缓存。
或许，今天是Redis，明天是GemFire，
还有Mongo。
还有Cassandra和
其他我想要的服务。

English: 
in GO or in a mix of Java and .NET and have
those applications not really care, have the
application architecture elevated above the
language choice, that's really important.
The second idea of openness is really where
is my app running?
I wanna be able to run it on my laptop when
I'm working on it.
I wanna be able to run it in a dev environment
dedicated maybe to my team or my line of business.
And I wanna be able to run it in the public
cloud of my choice, as well as in production
data centers possibly all over the world.
So having freedom to run my application in
different locations regardless of where I
built it is really an important separation.
This last sense of openness is, what services
can I use?
And again, traditional at a large enterprise,
we're pinned to maybe a single database or
a single queue system.
Thou shalt use the rack of databases in the
basement.
Thou shalt use the mainframe and the services
that go along with it.
And we've really grown beyond that now, to

Japanese: 
アプリケーションを
実行するスペースに
どんなサービスが使えるのかを
考えることなく
好きなサービスを何でも使って
アプリケーションを
構築することができます
これだけオープンな環境には
課題もあります
例えば細かい点については
考えが及びません
SQLで動作すると思って
実行できたけど
特定のデータベースに行った時に
SQL機能がうまく動かなかった
他には例えば
キューを使ってスイッチをさせて
同じテクノロジーを使っている時
ラップトップでRedisを
使っていた時はうまくいったのに
クラウドで使ったらうまくいかない
この現象の正式な名称は
驚き最小の原則
といいます
人々が期待するような
動き方をすべき
ということで
この話題については
また後で戻ってきます
開発者は一つのクラスの
人間ばかりではありません
一様に揃えられたものではなく
魚と似ています
大きい魚
小さい魚

Korean: 
저는 제 응용프로그램을
아무런 생각 없이 해당 서비스로
가져오고 싶어서 묻습니다.
이것을 이 곳에서 실행하고 싶으면
어떤 서비스를 이용할 수 있습니까?
그러한 것들을 완화하십시오
다라서 개방성과 관련하여
이만큼 어려움이 있습니다
세부에 있어서는
놓칠 수 있는 것들입니다
여러분은 다음과 같이 말할 것입니다
저는 SQL이 이런 식으로 동작할 것이라고
생각했는데
제가 이 다른 데이터베이스로
옮겨 간 것만 빼고 정말 그랬습니다
그러한 SQL 기능은
동작하지 않았습니다
또는 저는 이 대기열을 사용하고 있었는데
그 다음에 전환하여
동일한 기술을 사용하고 있었습니다
제가 Redis를 제 노트북에서
실행할 때는 동작하고
클라우드에서 Redis를 끈 상태로
시작했을 때는 실패하는 이유는 뭘까요?
알겠습니다.
공식적으로 이 법칙은
최소 놀람의 법칙이라고 합니다
모든 것은 그것을 사용하는 사람이
동작하기를 바라는 방식으로
동작해야 합니다
그리고 저는 진행하면서 원칙으로
되돌아가려고 합니다
개발자들은 단일 등급의
인간들이 아닙니다, 맞죠?
이것은 물고기라고 말하는 것처럼
획일화된 것이 아닙니다
모든 물고기는 비슷합니다
큰 물고기가 있고 작은 물고기가 있고

English: 
say hey I want flavors of SQL and flavors
of NoSQL.
I want Q Services, I want In-memory, Cache.
And maybe it's Redis today and GemFire tomorrow
and Mongo.
And Cassandra and what ever service I want.
I want to able bring my application to those
services without thinking about, hey if I
am running it in this place, what services
do I have available to me?
Decouple those things.
So, there's a challenge with this much openness,
which is you can get lost in the details.
You can say, well I sort of thought that SQL
would work this way and it did, except that
I went to this other database and those SQL
functions didn't work.
Or I was using this queue and then I switched
and I was using the same technology.
Why is it when I was using Redis on my laptop
it worked and then when I started using Redis
off in the cloud it failed?
All right, so this principle if you want to
be formal about it is called the principle
of least astonishment.
Things should work for people the way that

Chinese: 
我希望可以不用去想
如果我在这里运行这个App，
有哪些可用的服务，
就可以让我的App
提供这些服务。
把这些东西分隔开。
所以，这种开放性
存在一个挑战，
就是你会迷失在细节里面。
你可以说，
嗯，我认为SQL语句可以以这种方式运行，
而且事实上也真的可行了，
除了在另一个数据库运行的时候
这些SQL功能没有发挥作用。
或者我在用这个队列，
然后我换用另一个，
而我用的是同一项技术。
为什么我在我的笔记本电脑
可以用Redis，
然后想在云端用Redis
就不行了呢？
好，所以如果
你想要弄得正式一点的话，
这个原则就叫做
最小惊讶原则。
事物应该
按照使用它们的人
所预想的方式
来展开。
然后之后我会再回到
原则这个话题，可以吗？
开发者不是单独的
一类人群，是吗？
也不是统一的事物，
比如说鱼，
所有的鱼都是相类似的。
嗯，有大鱼，
有小鱼，

Chinese: 
我要將我的應用帶到那些服務中，
而不用考慮，如果我在這裡運行它，
我有什麼服務可用？
分離那些東西。
所以，要達到這個開放的
程度是有挑戰性的，
你可能在細節中迷失。
你可以說，
我認為SQL這樣行得通且確實成功了，
但我連接其他資料庫時，
那些SQL功能卻不能工作了。
或者我使用這個佇列，當我切換後，
我在使用相同的技術。
為什麼我在筆記型電腦上
用Redis時可以工作，
在雲中開始用Redis時
卻不能工作了？
如果要正式地說，這個原則
就是最小意外原則。
系統應該能按使用者
所期待的方式工作。
後面我會再回顧這個原則，好嗎？
開發者並非只有一類人，對吧？
這不是統一的東西，例如魚。
所有魚都是類似的。
好吧，有大魚和小魚，

Russian: 
Я хочу переносить мои
приложения в эти сервисы,
не задумываясь: «Так, новая
среда разработки,
чем я смогу
здесь воспользоваться?»
Отказ от «привязки» сервиса.
Проблема подобной
степени открытости
в том, что можно
легко потеряться в мелочах.
Получится:
«Ой, я думал, SQL
сработает вот так,
а потом я
переключил базы данных,
и список функций не сработал».
Или: «Я работал вот здесь,
потом переключился,
используя ту же
самую технологию...
Когда работал с Redis
на ноутбуке, всё работало,
а с облачной копией Redis
- перестало?»
Так, если формулировать
этот принцип,
его можно назвать «Правилом
наименьшего удивления».
Поведение элементов
должно быть
наиболее ожидаемым
со стороны пользователя.
Я ещё вернусь
к этому принципу позже.
Разработчики же не выделяются
в единый класс людей, так?
Они неоднородны,
как, скажем, виды рыб.
Все рыбы похожи.
Но есть большие рыбы
и маленькие рыбки,

Chinese: 
有食草的魚，有食肉的魚,
甚至有沒有鰭的魚。
開發者有點像魚。
所以邏輯上說到極端，
有喜歡作業系統的開發者，對吧？
通常他們編寫作業系統。
也許他們為微軟工作，或者
為某個Linux供應商工作。
但大型組織並不想出錢請開發者做
他們覺得有趣的事情。
他們出錢請開發者做能創造價值的
事情，這些事情通常更接近客戶。
我們要盡可能接近我們用戶
正在感受的痛苦。
我們通過擁抱選擇做到這個。
所以，我們不是建造
每一個可能的作業系統，
或每一個可能的雲，
我們就是不在乎。
我們會說我們擁抱某些服務。
某些情況下我們想固執己見、
非常在乎，
而某些情況下我們想
持不可知論、毫不在乎。
因此很重要的是給開發者一套
選擇，不要說每個人都要在
同一抽象層上寫。

Korean: 
채식 물고기가 있고
육식 물고기가 있습니다
지느러미가 없는 물고기도 있습니다
개발자들은 다소
물고기와 같습니다
따라서 그것을 논리적인 극단에
적용하면
운영 체제를 사랑하는
개발자들이 있습니다, 맞죠?
전형적으로 그들은 운영 체제를
작성합니다
아마도 그들은 Microsoft를 위해 일하거나
일부 Linux 벤더를 위해 일합니다
하지만 대기업들은 개발자들이
자신들이 재미 있다고 생각하는 것에 대해
일하는데 비용을 지불하고 싶어하지 않습니다
그들은 개발자들이
가치를 제공하는 일들에 대해 작업하도록
비용을 지불하고 싶어하는데,
보통 고객에게 더 가까이 있는 일들입니다
우리는 가능한 한 고객들이 경험하고 있는
고통에 더 가까이 가고자 합니다
그리고 우리는 의견을 받아들이는 것에 의해
그렇게 합니다
따라서 모든 가능한 운영 체제
또는 모든 가능한 클라우드를 사용하여
구축하기보다는
그냥 개의치 않으려고 합니다
그리고 우리는 특정 서비스를
수용한다고 말하려고 합니다
우리가 의견을 듣고
깊이 주의를 기울이는 사례들이 있고
우리가 회의적이고 전혀 주의를 기울이지 않는
사례들이 있습니다
따라서 개발자들에게
일단의 선택을 제공하고
모두가 동시에 동일한 수준의 추상으로
작성해야 한다고 말하지 않는 것이
중요합니다

Japanese: 
ベジタリアンの魚
肉食の魚
ひれがない魚もいます
そんな点で開発者も
魚に似ています
理論的に考えると
オペレーティングシステムが
好きな開発者がいて
彼らは普段オペレーティングシステムを
書き出しています
おそらくMicrosoftや
Linux のベンダーで働いているでしょう
大規模な企業は
開発者の楽しみのために
コストをかけたくなく
バリューを生み出す作業に
賃金を払いたいと思っていて
それは一般的に
顧客に近い所にあります
ユーザーエクスペリエンスで
苦痛と感じる
できるだけ近い所に
着手したいと思っています
それを可能な限りの
オペレーティングシステムや
クラウドを使って構築するよりも
顧客からの意見を取り入れて
取り組みます
特定のサービスを
真剣に考えるのです
こだわって
何度も試行錯誤する
ケースもあれば
深くはまたは全く気にしない
ケースもあります
誰もが同じレベルの抽象化で
書き出すのではなく
開発者に一連の選択を
与えることは
とても重要です

Russian: 
есть травоядные, есть хищные.
У некоторых рыб
даже нет плавников.
Разработчики похожи на рыб.
Если довести мысль
до логической крайности,
есть разработчики, которые
обожают операционные системы.
Обычно они их создают.
Может, они работают на Microsoft
или на одного из вендоров Linux.
Но крупные корпорации
не любят платить разработчикам
за то, что они любят делать.
Платят за разработку вещей,
которые приносят прибыль,
и более понятны потребителям.
Мы же хотим максимально
ощутить трудности,
с которыми сталкиваются наши
потребители.
Это возможно, если
рассмотреть все возможности.
Мы не будем разрабатывать на
базе всех операционных систем
или облачных решений,
мы проигнорируем их.
Мы будем использовать
несколько сервисов.
Есть кейсы,
которые важны для нас,
и мы хотим получить отклик,
есть проходные кейсы,
на которые нам плевать.
Важно дать разработчикам
несколько вариантов
и не заставлять всех
писать на одинаковом
уровне абстракции.

English: 
the people that use them expect them to work.
And I'm gonna come back to principle as we
go, all right?
Developers are not a single class of human,
right?
This is not a uniformed thing like saying
fish, all fish are similar.
Well there are big fish and small fish, there
are vegetarian fish, there are carnivorous
fish, there are fish that don't even have
fins.
Developers are a bit like fish.
So if you take that to it's logical extreme
there are developers that love operating systems,
right?
Typically they write operating systems.
Maybe they work for Microsoft or they work
for some Linux vendor.
But large organizations don't want to pay
developers to work on things they find fun.
They wanna pay developers to work on things
that provide value, which is typically closer
to the customer.
We want to get as close to the pain that our
users are experiencing as possible.
And we do that by embracing opinions.
So rather than building using every possible
operating system or every possible cloud we're

Chinese: 
有草食类的鱼，
有肉食类的鱼，
有没有鱼鳍的鱼。
开发者就有点像鱼。
所以你推类至尽的话，
就会发现很爱操作系统的开发者了，
对吗？
一般来说，
他们编写操作系统。
或许他们在微软工作，
或者在一些Linux供应商工作。
但是大部分机构
都不愿意给开发者钱，
让他们去做
他们认为有趣的事情。
它们给开发者钱，
让他们去把精力
放在可以带来价值的事情上，
一般是更接近消费者的事情上。
我们希望能够尽可能
靠近我们的用户
所经历的痛苦。
我们通过集思广益来完成这件事。
所以，并不是搭建、使用
每一个我们并不在乎的
操作系统或云端。
而是说我们包含了
某一些服务。
在一些情况下，
我们想要固执己见
给予深切的关注，
在另一些情况下，
我们是不可知论者，毫不关心。
所以，给到开发者
多个选择，
非常重要，
而不是说每个人
都要在某个相同的抽象水平上
进行编写。

Chinese: 
从现在开始，
你不需要关注服务去进行编写了。
所以在Pivotal，我们信奉我们称之为
4大抽象概念的东西。
我们把编写看作是
一种无关服务的代码，
你只需要关注你的功能，
你甚至不需要关注
App其余的东西。
或者降一个层次来说，
我们在编写应用程序，
同时也关注互相联系交流的
一些服务或者微服务，
但是不关注它们在哪里运行
以及具体的拓扑。
现在我们的确看到存在一些情形，
就是开发者想要在一个水平上
弄得更加细致，
他们希望可以定义这组容器，
还有要把这些容器放在哪里，
来使得他们相互之间产生联系。
我们也把这个东西公开出来。
甚至，再进一步，
你希望能对虚拟机
进行处理，
对关键基础架构进行处理，
给你自己的服务下定义，
那些存储持久、储存状态生命周期复杂的
服务。
所有这四大抽象概念
都非常重要，
但是正如我前面所说，
开发者就好像鱼一样。
所以，如果我们希望我们的开发者
可以保持快乐的心状态，

Chinese: 
從現在開始你們都要
以“無伺服器”方式編碼。
在Pivotal我們採用
稱為“四個抽象”的觀念。
我們考慮編寫某種無伺服器的代碼,
其中你只需關心功能，
甚至不用關心應用的其餘部分。
或者在我們編寫應用
的地方再下一層，
我們關心互相通訊的
一套套服務或微服務，
而不是它們在哪裡
運行及特定的拓撲。
現在我們確實看到
某些情況下甚至開發者
都想到達有更多
細節的一層，他們
想定義一套容器以及
它們所處的相對位置。
我們也揭露這一點。
然後，甚至更進一步，
當你想和虛機、基礎設施
打交道時，可以
定義你自己的服務，
擁有永久儲存和
複雜的狀態生命週期。
這4個抽象都非常重要，
我前面說過，開發者就像魚。
要讓我們的開發者保持高興，

Japanese: 
今後はサーバーレスなものを
書いていかなければなりません
Pivotalでは「4つの抽象化」を
大切にしています
サバーレスなコードを書く場合
機能について考慮するだけで
残りのアプリケーションについては
考えなくていいのです
または一歩下がって
アプリケーションを書いて
連携するサービスやマイクロサービスの
組み合わせに気を使い
実行する場所や特定のトポロジーは
考えなくていいのです
実際に開発者が
もう一段階深いレベルに
取り組みたい
ユースケースがあります
コンテナのセットの定義や
リレーションシップの
配置場所などです
私たちはそれを露出しています
さらにもう一段階踏み込んで
仮想マシンや
キーインフラストラクチャーの場所や
永続的なストレージや
ステートのための
複雑なライフサイクルなど
独自サービスを定義します
この4つの抽象化は
非常に重要ですが
先ほどお話したように
開発者は魚のようでもあります
開発者は一人ひとり違っていて

Russian: 
Всем придётся писать
без опоры на сервер.
В Pivotal мы используем
так называемые «4 абстракции».
Рассматривая разработку
как код без опоры на сервер,
когда ты работаешь
над своей функцией
и не заботишься
об остальном приложении.
Или шагнём назад:
при создании приложений
мы думаем о комплектах сервисов
или микросервисов,
и их взаимодействии,
а не о средах
или особенностях топологии.
Встречаются рабочие кейсы,
когда разработчики
хотят сами выбирать,
определять набор модулей
и принципы их взаимодействия.
И это мы тоже раскрыли.
Если шагнуть ещё дальше,
во взаимодействие с
виртуальными машинами,
ключевыми инфраструктурами,
собственным набором сервисов
с постоянным хранилищами
со сложным жизненным циклом.
Все четыре уровня
очень важны,
но, как я уже говорил,
разработчики, они как рыбы.
Если они не все уникальны,

English: 
just gonna not care.
And we're gonna say we embrace certain services.
There are cases where we wanna be opinionated
and we care deeply and there are cases where
we wanna be agnostic and care not at all.
And so it's important to give developers a
set of choices, and not say everyone has to
write it at the same level of abstraction.
You all have to write serverless from now
on.
So at Pivotal we embrace what we call the
4 Abstractions.
We think about writing kind of serverless
code, where you're just caring about your
function and you don't even care about the
rest of the application.
Or maybe a layer down from that we're writing
applications, and we care about sets of services
or microservices that talk to each other but
not where they run and the specific topology.
Now we do see use cases where even developers
wanna be at one level more detail, and they
wanna define the set of containers and where
they'll be placed in relationship to each
other.
And we expose that as well.
And then even one step further, where you
wanna deal with Virtual Machines, key infrastructure,

Korean: 
여러분 모두 지금부터
서버리스를 작성해야 합니다
따라서 Pivotal에서는
소위 4가지 추상을 받아 들입니다
우리는 일종의 서버리스 코드를
작성하는 것에 대해 생각하는데,
이 경우 여러분은 기능에 대해서만
주의를 기울이고
응용프로그램의 나머지에 대해서는
신경쓰지 않습니다
아니면 우리가 응용프로그램을 작성하고 있는
총보다 한 층 더 내려가
서로에게 이야기하는 일단의 서비스와
마이크로 서비스에 대해 주의를 기울이지
그것들이 실행되는 곳이나 특정 토폴로지에 대해
주의를 기울이지 않습니다
이제 우리는 심지어 개발자들이
한 수준 더 자세히 작성하고 싶어하고
컨테이너 세트들을 정의하고 싶어하고
서로에 대한 관계 안에 놓이게 되는
사용 사례를 목격하고 있습니다
게다가 우리는 그것을
노출시키기도 합니다
그런 다음 한 단계 더 나아갑니다
바로 가상 머신,
핵심 인프라, 즉, 영구 스토리지를 가지고 있는
자체 서비스 정의와
상태에 대한 복잡한 수명 주기를
다루고 싶은 경우입니다
따라서 이들 네 가지 추상들은
정말로 중요하지만, 제가 전에 말씀드렸 듯이
개발자들은 물고기와 같습니다
따라서 개발자들을 계속 행복하게 하고 싶은 경우,
그들은 모두 특이하지 않고

Chinese: 
而他們是各不相同的，
他們致力於不同的抽象。
我們必須給他們提供不同的工具
和不同的技術。
讓我們從Spring開始說起。
我們已經在Java社區中工作了很長時間，
幾年前我們提出這個稱為“Spring Boot”
的技術，如今已非常成功。
我想全部新Java專案中有大約85%
在Spring Boot中開始。
它提供了一個非常特定的框架
用於在Java中創建應用。
它其實可以理解為一套觀點。
如果你是Java開發者，
你不想仔細考慮細節，
我怎樣連接兩個字串？
棒極了，Spring有辦法做到。
它有辦法讓應用中的
不同服務互相通訊。
它有辦法處理向外擴展、平衡
和服務發現，它創建一套確定的選擇。
你不是一定要使用Spring，但
它是我們解決那個問題的方式之一。
開放的感覺就是，
如果你要這種語言，這就是一個框架。
我們沒有和SQL體系
中包括微軟在內

Korean: 
그들은 서로 다른 추상을 향해
작업하고 있습니다
우리는 그들을 서로 다른 도구들과
서로 다른 기술에 노출시켜야 합니다
Spring부터 시작합시다
우리는 Java 커뮤니티에서 작업해 온
오랜 이력이 있고
몇 년 전에 Spring Boot라고 하는
이 기술을 선보였는데
이 기술은 현재 광범위하게 성공적이
되었습니다
저는 모든 새로운 Java 프로젝트들의 85%가
Spring Boot로 시작되는 것으로 추정합니다.
그리고 그것은 응용프로그램을
Java에서 구축하기 위한
매우 구체적인 프레임워크를 제공합니다
그것은 여러분이 원하는 경우
일단의 견해입니다
여러분이 Java 개발자이고
세부 정보에 대해 자세히
생각하고 싶지 않은 경우,
두 개의 스트링을 어떻게
연결하고 싶을까요?
훌륭합니다. Spring은
그것을 할 수 있는 방법이 있습니다
응용프로그램 안에 있는
상이한 서비스들이
서로에게 이야기할 수 있는
방법이 있습니다
확장 및 균형과 서비스 발견을
다룰 수 있는 방법이 있고
일단의 견해가 있는 선택을
할 수 있게 해줍니다
Spring을 사용해야 할 필요는 없지만
그것과 개방성의 의미를 우리가 이야기하는
방법들 중의 하나입니다
이 언어를 원하시는 경우
여기에 프레임워크가 있습니다
우리는 동일한 프로그램이
.NET에 대해서도 잘 동작하게 만들기 위해

Russian: 
просто работают на разных
уровнях,
и нам нужно,
чтобы все были довольны,
Нужно предложить им различные
инструменты и технологии.
Начнём со Spring.
У нас долгая история
работы с Java,
и несколько лет назад
мы разработали эту технологию,
под названием Spring Boot,
она сейчас очень популярна.
Примерно 85%
новых проектов на Java
запускаются в Spring Boot.
В нём принципы
создания приложений на Java
поставлены в строгие рамки.
Это своеобразный
«набор условий».
Если вы пишете на Java
и не хотите размышлять
над условиями,
например, объединения строк,
Spring имеет
прописанный алгоритм.
Он умеет настраивать
взаимодействие
различных сервисов
в вашем приложении.
Есть возможность
настройки баланса
и обнаружения сервисов
путём выбора из списка.
Необязательно
использовать Spring,
но это наш способ
добиться открытости.
Хотите использовать этот язык,
вот вам база.
Мы работам с партнёрами
в системе SQL,

Japanese: 
それぞれ違う抽象化に向かって
作業しているので
開発者をハッピーにしたい場合
あらゆるツールやテクノロジーを
活用していく必要があります
Springについてお話しましょう
私たちは Java のコミュニティで
長い歴史があります
このSpring Bootと名づけた
テクノロジーのアイディアは
数年前に持ち上がり
今では大きな成功を収めています
新しいJavaのプロジェクトの85%は
Spring Boot から
始められてると見積もります
Javaでのアプリケーション構築に
非常に特定のフレームワークを
用意しています
もしあなたがJavaの開発者だったら
どうやって2つのストリングを
繋げたいか
細かいところまで
考えたくないでしょう
その時スプリングが
それを繋いでくれます
あなたのアプリケーションの中で
あらゆるサービスに対応し
お互いコミュニケートさせて
スケールアウトやバランシング
サービスの検索に対応し
独断的な選択セットをつくります
Springを使う必要はありませんが
ある言語を使いたくて
フレームワークがある場合
課題に対処する
オープンネスの方法ではあります
Microsoftを含む
SQLシステムの他のパートナーと協力して

Chinese: 
明白到他们并不是全部都那么独特，
在往不同的抽象概念去奋斗。
我们需要让他们
接触到不同的工具，
不同的技术。
让我们从Spring谈起。
我们过去有很长的一段时间
是在Java语言圈子里面工作，
然后在几年前，
我们就开发了这个技术，
叫Spring Boot，
现在已经十分成功了。
我想估计85%的
Java项目
都是在Spring Boot里启动的。
它给用Java语言
搭建应用程序
提供了非常具体的框架。
如果你喜欢的话，
它也可以是一组观点。
如果你是Java开发者，
并且你也不想去思考一些细节，
比如说
怎样连接两个字符串？
那好，
Spring可以帮到你。
它帮忙解决了
你的应用程序有不同的服务，
服务之间又相互联系的情况。
它帮忙解决了
向外拓展、平衡和服务挖掘，
又提供了一些固执的选择。
你不一定要用Spring，
但是Spring是我们解决
那些问题的方法之一，
开放性的意义就是，
如果你想要这个语言，这里有框架。
我们没有和SQL系统的
其他拍档一起合作，

English: 
kind of define your own services that have
persistent storage and complex life cycle
for state.
And so all four of those abstractions are
really important but, as I said before, developers
are like fish.
So if we wanna keep our developers happy and
they're not all unique, and they're working
towards different abstractions.
We have to expose them different tools and
different technologies.
Let's start with Spring.
We have a long history of working in the Java
community, and we came up with this technology
a few years ago called Spring Boot, which
has now become wildly successful.
I think the estimate is 85% of all new Java
projects are started in Spring Boot.
And it gives a very specific framework for
building applications in Java.
It's a set of opinions if you like.
If you're a Java developer and you don't wanna
think about the details of well, how do I
wanna concatenate two strings?
Great, Springs got a way to do that.
It's got a way to deal with Having different
services in your application, talk to each
other.

English: 
It's got a way to deal with scaling out and
balancing and service discovery and it makes
a set of opinionated choices.
You don't have to use Spring, but it's one
of the ways we address that and the sense
of openness is, if you want this language,
here's a framework.
We're not working together with other partners
in the SQL system including Microsoft to make
the same approach as work well with .NET.
So you can have your best of class .NET applications
also be open source, also be taking advantage
of micro services and still run them anywhere.
Let's talk about opinions one layer deeper,
let's talk about that abstraction of infrastructure.
So Bosh has always been a part of Pivotal's
technology stack, we think of it as sort of
the secret sauce behind Cloud Foundry.
And if you think of what we all used to do
years ago with Bosh scripting or Perl scripting

Chinese: 
其他夥伴合作來
創建一個適用於.NET
相同方案。
你能將你同類中最好的.NET應用
開源，也充分利用微服務而
繼續在任何地方運行。
我們談下更深一層的觀念。
我們談下基礎設施抽象。
Bosh一直是Pivotal
技術堆疊的一部分，
我們將它視為
Cloud Foundry背後的
秘制醬料。
回憶下多年前我們都使用
Bosh腳本或Perl腳本或Python或
任何語言來協調基礎設施，
Puppet、Chef、
Ansible、Salt、Juju，
它們和Bosh正好相反。
它解決相同的問題，但反其道而行。
它事實上是一套步驟，
運行這個腳本來達到某種狀態。
Bosh則說，忽略這些步驟，
定義你想要的狀態，
我就設法給你實現並
讓你永遠保持那個狀態。

Chinese: 
包括微软，
去弄一样的方法，
因为跟.Net合作也挺顺利。
所以你可以让你一流的.Net应用程序
也成为开放的源码，
也去利用微服务的好处，
人们也仍然可以
在任何地方运行你的App。
让我们谈谈
更深一个层次的观点，
谈谈基础架构的
抽象化。
所以BOSH总是Pivotal
技术堆栈的其中一个部分，
我们把它看作是
Cloud Foundry背后的
杀手锏。
然后如果你想到的是
多年前我们都通过BOSH脚本编写
或者通过Perl脚本编写，
或者通过Python来做的事情，
或者其他关于协调基础架构的事情，
Puppet、Chef，
Ansible、Salt、Juju，
这些都是和BOSH相反的。
解决的是同一个问题，
但是解决的途径是相反的。
所以在这里
有必要讲讲，
运行这个脚本到某个状态，
需要的几个步骤。
BOSH提倡忽略步骤，
定义你自己想要的状态，
然后我会告诉你怎样
才可以实现这个东西，
帮助你一直做这个事情。

Russian: 
включая Microsoft,
чтобы этот подход
работал так же и с .NET.
Чтобы самые лучшие
приложения .NET
тоже получили открытый код,
использовали преимущества
микросервисов
и могли запускаться где угодно.
Поговорим о возможностях
следующего слоя,
абстракции
уровня инфраструктуры.
Технология Bosh всегда
использовалась компанией Pivotal
это своего рода «секретный
ингредиент» Cloud Foundry.
Если вспомнить,
что мы делали ранее,
используя скрипты Bosh,
или Perl, или Python
и любые другие для настройки
инфраструктур Puppet, Chef,
Ansible, Salt, Juju, - они все
не такие как Bosh.
Решают тот же вопрос,
но работают абсолютно иначе.
Тут написан список шагов:
запусти скрипт, получишь итог.
Bosh позволяет игнорировать это:
«Скажи, что тебе нужно,
я вычислю, как этого добиться
и поддержу итоговое состояние».
Это переходы состояний.
Я называю это «узконаправленной

Japanese: 
.NETでうまくいく
同じアプローチを作ろうとは
思っていません
なので最高クラスの
.NETアプリケーション持つことができて
オープンソースがあって
マイクロサービスのメリットを活用して
どこでも実行できるのです
もう一歩踏み込んだ意見を
お話ししていきましょう
インフラの抽象化についてです
Boshは常にPivotalの
テクノロジースタックの一部にあります
Cloud Foundryの
ある種の秘密ソースの
ようなものです
Bash scriptingや
Perl ScriptingやPythonなど
インフラをオーケストラするようなもの
Peppet　Chef　Ansible
Salt　Juju　など
数年前に使っていたものと
Boshは反対にあります
なので同じ問題を解決するのですが
反対のやり方で実行します
こちらがスクリプトを実行して
ステートに手に入れるための
ステップ一覧です
Boshはステップは無視をして
手に入れたいステートを定義すれば
どうすればいいかを解決し
その状態を永遠に維持してくれます

Korean: 
Microsoft를 포함한 다른 파트너들과
SQL 시스템에 대해
협력하고 있지 않습니다
따라서 여러분은 최고 클래스의 .NET
응용프로그램도
오픈 소스로 가질 수 있고,
마이크로 서비스를 활용하고
어디에서든 여전히 실행할 수 있습니다
견해에 대해 한 층 더 깊이
이야기해 봅시다
인프라에 대한 추상에 대해
이야기해 봅시다
그러니까 Bosh는 항상
Pivotal의 기술 스택의 일부였는데
우리는 그것을
Cloud Foundry 배후의
일종의 비밀 소스로 생각합니다
그리고 여러분이 우리가 2년 전에
Bosh 스크립팅 또는 Perl 스크립팅
또는 Python 또는
인프라, Puppet, Chef, Ansible,
Salt, Juju를 가지고
우리가 하곤 했던 일들을 생각하면,
그것은 Bosh의 반대입니다
그것은 동일한 문제를 해결하며
반대 방식으로 동작합니다
따라서 그것은 여기에
일부 상태로 이 스크립트를 실행하기 위한
일단의 단계가 있습니다
Bosh는 그 단계들을 무시하,
여러분이 원하는 상태를 정의하면
거기에 어떻게 도달하여
거기에서 영구적으로 머물 수 있는 방법을
알려주겠다고 말합니다

Japanese: 
これらはステートの切り替えです
それは決定論的なインフラにおいて
「狭いAI」だと言えると思います
これが私たちの意見で
Boshが何で実行しても良く
Microsoft Azureや
別のパブリッククラウドかもしれないし
OpenStackやV Sphereの
プライベートクラウドかもしれません
Boshには関係なく
あなたのシステムを希望の
ステートに変え維持します
基礎インフラによって
提供されているサービスを
気にしないということではなく
最後のOpen Service Broker AIPまで
対応してくれます
これはもともとPivotalから始まり
それがオープンソースとなり
今やKubernetesコミュニティや
Google その他のパートナーによって
運営されているオープンコミュニティ
プロジェクトに
なっています
アプリケーションを
サービスへつなぐ
スタンダードなやり方があると言われ
ステートのない世界から
ステートに満ちた世界に繋ぎます
そこでは3種のオープンネスの軸を
基本としています
言語　ロケーション
サービスの自由さ
こちらはクレイジーな画像ですが

Chinese: 
這些是狀態過渡。
我希望將這個稱為
確定性基礎設施
的弱人工智慧。
這就是我們的觀點，
這是我們為什麼說
不管Bosh在什麼上面運行，
可能是微軟Azure，
可能是另一個公有雲，
可能是一個私有雲，
它由Open Stack驅動，
或者由V Sphere驅動。
Bosh並不在乎，它只會
將你的系統帶到所要的狀態
並保持在那裡。
那並非說你不用
關注底層基礎設施
提供的服務。
然後是我們的最後一塊，
Open Service Broker API。
這最初由Pivotal提出。
現在已轉變為一個
開源、開放社區項目，
受到Kubernetes社區、Google
和其他合作夥伴支持。
它事實上是一個
將應用連接到服務的
標準方式。
將無狀態的世界
連接到充滿狀態的世界。
很酷的一點是它依然支持上面三個
開源社區，支援任何語言、任何地點、
任何服務，這種情況有點古怪，

Russian: 
ИИ-детерминированной
инфраструктурой».
Это наш вариант
Bosh может работать
над любой структурой,
как над Microsoft Azure,
другое открытое облако,
так и частное облако
на Open Stack или V Sphere.
Bosh не грузит,
он приводит вашу систему
в нужное состояние.
Но это не значит, что вам
плевать на сервисы
встроенные во внутренние
инфраструктуры.
Это приводит нас
к последнему элементу -
Open Service Broker API.
Его изначально запустил Pivotal.
Сейчас это проект с открытым
исходным кодом,
над ним работают
Kubernetes, Google,
и другие.
Это стандартизированный
путь подключения
сервисов к приложениям.
Соединение хаоса с порядком.
Что здорово - в нём сочетаются
все три возможности -
любой язык, любое
расположение,
любые сервисы.
Странная картинка,
но я сейчас поясню.

Korean: 
따라서 이것들은
상태 전이입니다
이것은 결정론적 인프라에 대해
제가 좁은 AI라고 부르곤 하는
것입니다
따라서 이것은 우리의 견해이고,
이것은 Bosh가 어디 위에서 실행되고 있든
우리가 말하는 방식입니다
Microsoft Azure일 수도 있고
또 다른 공용 클라우드일 수도 있고
오픈 스택 기반의
사설 클라우드가 될 수도 있습니다
Bosh는 시스템을 원하는 상태로 넣어
거기에서 유지하는 것을
신경쓰지 않습니다
이제 그것은 그러한 기반 인프라에 의해
제공되는 서비스들에 대해
여러분들이 신경쓸 필요가 없다는 것을
의미하지 않습니다
그것은 Open Service Broker API라는
이 마지막 조각으로 우리를 안내합니다
이것은 원래 Pivotal에 의해 시작되었습니다
그런 다음 오픈 소스로 변했고,
이제 Kubernetes 커뮤니티에 의해,
Google에 의해,
다른 파트너들에 의해 수용된
오픈 커뮤니티 프로젝트가 되었습니다
그리고 그것은 정말로
응용프로그램들을 서비스에
연결시키기 위한 표준 방법이 있다고
말합니다
무상태 세계를 상태로 가득 찬 세계로
연결하는 셈입니다
이것에 대해 멋진 일은
그것이 여진히 그러한 개방성의
세 가지를 받아 들인다는 것입니다
즉, 모든 언어, 장소, 서비스를 받아들이며,
이것은 일종의 미친 사진이지만

English: 
or Python or whatever to orchestrate infrastructure,
Puppet, Chef, Ansible, Salt, Juju, that's
the opposite of Bosh.
It solves the same problem, works the opposite
way.
So it really says here is a set of steps run
this script get to some state.
Bosh says ignore the steps, define the state
that you want and I will figure how to get
you there and keep you there forever.
So these are state transitions​.
This is what I like to call a narrow AI for
deterministic infrastructure.
So this is our opinion and this is how we
say hey whatever Bosh is running above, it
could be Microsoft Azure, it could be another
public cloud, it could be a private cloud
powered by Open Stack, powered by V Sphere.
Bosh doesn't care it's gonna get your system
into a desired state and keep it there.
Now that doesn't mean you don't care about
the services provided by those underlying
infrastructures.
And that takes us to this last piece, Open
Service Broker API.
This was started originally by Pivotal.
And turned into an open source, open community
project now embraced by the Kubernetes community,

Chinese: 
所以这些是状态转换。
这个我比较喜欢称之为
针对确定性架构的
狭义人工智能。
所以这就是我们的观点，
这就是我们怎么说，
不管BOSH运行在什么之上，
可以是微软Azure，
可以是其他公共云端，
可以是Open Stack支持的、
V Sphere支持的私人云端，
BOSH都不关注这些，
它只会把你的系统弄到理想的状态，
并保持在那样的状态。
现在，这不意味着，
你不关注那些底层基础架构
所提供的服务。
然后这里引申到最后一点，
开放Service Broker应用程序编程接口。
这个东西是Pivotal
最先开始的。
然后现在变成一种开放源码，
开放的社区项目，
被Kubernetes社区，
被谷歌所接受，
被其他合作伙伴所接受。
然后，真的可以说，
嘿，这里有把应用程序
连接服务的标准方式。
把无状态的世界
连接到充满状态的世界。
其中很酷炫的东西是
它仍然包含三大开放性，
包含全部语言，
全部地点，
全部服务，
这就有点像一幅疯狂的图片，

Chinese: 
但我還是要說出來。
你有某個應用在Cloud Foundry
的某個地方運行，
它其實不必在Cloud Foundry中運行，
它可以在Kubernetes中運行，
它可以綁定到，如Redis緩存。
它可以只是作為某人
運作的平臺服務，
作為Redis端點運行。
可能由Azure運作，
從而得到Azure Redis。
它可能以虛機形式啟動，
並由Bosh為你代理，
按需運行。
它可能是單租戶，或者多租戶。
應用不需要關心。
那就是我們看到的重要抽象，
就是最小意外原則。
你的開發者想說，嗨，
我的應用需要Redis，如果我
的應用在開發環境運行，它應該
只是使用我筆記型電腦上的Redis。
如果它在預生產環境運行，
它應該使用所提供的
Redis和其旁邊的虛機。
如果它在生產環境運行，
它應該用Azure Redis。
綁定和代理的分離
對於提供那種自由非常重要。
對於這個問題的開放一面，
我已經談了很多，

English: 
by Google, by other partners.
And it really says, hey, here's a standard
way of connecting applications to services.
Connecting the stateless world to the state
full world.
The cool thing about this is it still embraces
all three of those opens, it embraces any
language, any location, any services, and
this is kind of a crazy picture but I wanted
to sort of spell this out.
You've got some app running in Cloud Foundry
somewhere, it actually doesn't have to be
running in Cloud Foundry it could be running
in Kubernetes and it wants to bind to let's
say a Redis cache.
Well, that could just be running as a, sort
of, platform service operated by somebody,
as a Redis endpoint.
Could be operated by Azure, so you've got
Azure Redis.
It could be spun up as a VM, and brokered
by Bosh for you, on demand.
It could be a single tenant, or mult tenant.
The app doesn't have to care.
And that's really the important abstraction
we're seeing, is the Principle of Least Astonishment.
Your developer wants to say, hey, my app needs
Redis, if my app is running in dev it should
just be using Redis on my laptop.
If it's running in this pre-prod environment,

Japanese: 
全体図をまとめています
Cloud Foundryのどこかで
実行しているアプリケーションがあり
またはCloud Foundryで
実行している必要もないので
Kubernetesでも良いでしょう
Redisキャッシュと結びつけたい場合
誰かにより運用された
プラットフォームサービスとして
Redisのエンドポイントとして
実行することもできます
Azureによってもできます
そしたらAzure Redisを手に入れます
または VMのスパンアップとして
オンデマンドでBoshによって
ブローカーされることもできます
シングルテナントも
マルチテナントも可能です
アプリは気にする必要が無いのです
私たちが考える重要な抽象化は
「驚き最小の原則」 です
開発者は
アプリにはRedisが必要で
アプリをdevで実行する時
Redisをラップトップで使うべきで
プロダクション前の環境で
実行している時
提供されたRedisを使用して
VMを次に使いたいと言うでしょう
そしてプロダクションがオフの時には
Azure Redisを使うと
バインディングや
ブローカリングの分離は
自由度を高めるために
とても重要です
これまでオープンさについて
今までお話をしてきました

Chinese: 
但是我还是
想把它弄清楚。
你已经有一些App
是通过Cloud Foundry在某处运行了，
但是实际上，这些App
不需要一定在Cloud Foundry运行，
也可以在Kubernetes运行，
它想要绑定到
可能是Redis缓存。
嗯，可以作为一个
由某人来操作的
平台服务，
是一个Redis端点。
可以由Azure进行操作，
这样你就有了Azure Redis。
有需要的时候，
它可以迅速启动成VM，
由BOSH为你代理。
可以是单租户，
或者多租户。
这个App不需要去操心。
这就是我们所关注的
非常重要的一个概念，
就是最小惊讶原则。
你的开发者想说，
嘿，
我的App需要Redis，
如果我的App是在Dev运行中，
在我的笔记本电脑，
它应该只用Redis。
如果它是在预生产的
环境下运行，
它应该用的是提供的Redis，
以及旁边的VM。
如果在生产当中，它是关闭状态的，
那么它应该用Azure Redis。
把绑定和代理分开，
对提供这样的自由非常重要。
现在，我已经说了很多关于
开放的一面的事情，

Russian: 
Есть приложение
где-то в недрах Cloud Foundry,
но не обязательно там,
возможно, в Kubernetes
с привязкой к кэшу Redis.
Возможно, это чей-то
платформенный сервис
с конечным пунктом Redis.
Может, и Azure,
тогда вам нужен Azure Redis.
Может быть запущен на VM
с трансляцией через Bosh,
по запросу.
Может быть одно-
или многоарендная система.
Приложению это неважно.
Это важный момент
в абстракции,
правило
наименьшего удивления.
Разработчик говорит:
«Моему приложению
нужен Redis,
во время разработки
я пользуюсь Redis на лэптопе.
В фазе тестирования в среде
оно должно работать с Redis
на виртуальной машине.
В производстве
используется уже Azure Redis.»
Разделение привязки
и трансляции через посредника
очень важны
для достижения свободы.
Я много говорил
об открытости системы,
время переключиться
на другую сторону медали -

Korean: 
여기에서 그것을 분명히 설명하고
싶었습니다
Cloud Foundry의 어딘가에서
실행되고 있는 몇 가지 앱이 있는데
그것은 사실 Cloud Foundry에서
실행될 필요가 없으며
그것은 Kubernetes에서 실행될 수 있고
그것은 예를 들어 Redis 캐시에
바인딩되기를 원합니다
그것은 하나의 Redis 단말로서
누군가에 의해 운영되는
일종의 플랫폼 서비스로서
실행되고 있을 수 있습니다
Azure에 의해 실행될 수 있기 때문에,
Azure Redis가 있습니다
하나의 VM으로서 실행되어
주문에 따라
Bosh에 의해 중개될 수 있습니다
단일 테넌트 또는 멀티 테넌트가
될 수 있습니다
앱은 신경 쓸 필요가 없습니다
그것이 정말로 우리가 목격하고 있는
중요한 추상입니다
바로 최소 놀람의 법칙입니다
여러분의 개발자는
다음과 같이 말할 것입니다
내 앱은 Redis를 필요로 하기 때문에
내 앱이 개발 환경에서 실행되는 경우
제 노트북에 있는 Redis를 사용해야 해요
만일 그것이 서비스 전 환경에서
실행되는 경우
그것은 제공된 Redis와 그 옆에 있는
VM을 사용해야 합니다
그것이 서비스 외부에 있는 경우,
그것은 Azure Redis를 사용해야 합니다
바인딩과 중개의 그러한 분리는
그런 종류의 자유를 제공하는데 잇어
너무도 중요합니다
이제 나는 이것의 개방성의 측면에 대해
많이 이야기해왔지만

Chinese: 
但是我希望强调
事情的另一面，
就是安全。
然后我带来
一位顾客，
来一个炉边谈话，
说说为什么保持开放性的同时，
保持安全性，
也很重要。
但是我想要借
《蒙提·派森》做个比喻，
因为这就是我在做的事情的样子。
所以，当我想到安全，
我总会想到城堡和护城河，
那么《蒙提·派森》中
城堡和护城河的
奥秘是什么呢？
有没有人记得？
他就像，
我们已经知道其中一个奥秘了。
这个奥秘就是多租户架构技术。
他们不需要分享
他们的圣杯。
我们也不需要跟你一起
去寻找你的圣杯，
我们有我们自己的圣杯。
并且实际上，在这个电影里面，
每个人都有自己的圣杯，
虽然你从来都没有见到过。
它被妥善地保护着。
说真的，
开放世界中
关于安全的困难部分
常常都是通过修复多租户模型
得到最好的解决。
如果这项数据服务
没有很好地保护用户，

English: 
it should be using the Redis provided and
the VM next to it.
If it's off in production it should be using
Azure Redis.
That separation of binding and brokering is
so critical to providing that kind of freedom.
Now I've been talking a lot about the open
side of this, but I want to emphasize the
other side of the coin, which is security.
And I'm going to bring a customer up for a
second here a little fireside chat to talk
about Why staying secure while being open
is so important.
But I wanted to make a Monty Python reference
because that's sort of what I do.
So when I think of security I kind of think
of castles and moats and what was the secret
to the castle and the moat in Monty Python?
Does any one remember?
He was like, we've already got one.
The secret was multi-tenancy.
They don't have to share their holy grail.
We don't need to go with you to find your
holy grail, we have our own holy grail.
And in fact, everyone's got their own holy
grail in this movie although you never get

Korean: 
저는 동전의 다른 면을 강조하고 싶습니다
그것은 바로 보안입니다
고객을 모셔서
개방성을 유지하면서도
보안을 유지하기 위한
두 번째 이야기를
나눠보도록 하겠습니다
저는 그것이 제가 하는 일의 종류이기 때문에
Monty Python 참조를
하고 싶었습니다
따라서 제가 보안에 대해 생각할 때,
저는 성과 해자에 대해 생각하는데
Monty Python에서는
성과 해자에 대해
비밀은 무엇이었을까요?
기억하시는 분 계세요?
그것은 우리가 이미
가지고 있는 것 같습니다
비밀은 멀티 테넌시입니다
그들은 자신들의 성스러운 성배를
공유할 필요가 없습니다
우리는 성배를 찾기 위해
여러분과 함께 갈 필요가 없습니다
우리 자신의 성배가 있으니까요
그리고 사실, 여러분은 절대로
보지는 못하지만
이 영화에서 모두가
그들 자신의 성배를 가지고 있습니다
그것은 완벽하게 안전합니다
모두가 곁에서 놀리는 가운데
오픈 월드에서 보안에 대해
어려운 부분은 보통
멀티 테넌시 모델만 고정함으로써
가장 잘 해결됩니다
이 데이터 서비스가 사용자들을
서로로부터 잘 보호하지 못하면

Chinese: 
但我想強調下另一方面，
就是安全。
我準備請一個客戶上來，
促膝談心，談下為何
開放的同時保持安全如此重要。
但我要用《蒙特·派森》舉個例子，
我常常這樣做。
當我想到安全時，
我會想到城堡和護城河，
《蒙特·派森》裡面的城堡和護城河
有何秘密？
有沒有人記得？
他似乎在說，我們已經有一個了。
秘密在於多租戶。
他們不需要分享他們的聖杯。
我們不需要和你去找你的聖杯。
我們有我們自己的聖杯。
事實上，這部電影裡面每個人都有
自己的聖杯，儘管你從未看到過。
它是非常安全的。
拋開玩笑不說，
開放世界裡安全最難的部分通常
最好通過簡單的多租戶模型來解決。
如果這個資料服務不能很好地在

Russian: 
безопасность.
И для этого я
вызову одного из потребителей,
чтобы поболтать о том,
почему важно
быть открытым и в то же время
оставаться в безопасности.
Тут я хотел бы процитировать
«Шоу Монти Пайтона»,
потому что я его смотрел и понял.
Когда говорю о безопасности,
то представляю замки и рвы.
А в чём был секрет замка и рва
в «Монти Пайтоне»?
Кто-нибудь помнит?
«У нас уже есть один!»
Секретом была
мультиарендность.
Им не нужно было
делиться Граалем.
Нам не нужно
идти искать ваш Грааль,
у нас есть свой.
И на самом деле,
в этом фильме
у всех есть свой Грааль,
который мы не видим.
Он в безопасности.
Шутки в сторону,
сложности с защитой
данных в отрытом пространстве
лучше всего решаются
настройкой мультиарендности.
Если сервис обработки данных
плохо отделяет пользователей
друг от друга,
запустите много копий.

Japanese: 
また違う面についても
強調していきたいと思います
それはセキュリティです
ここで私たちの顧客をご紹介します
オープンネスが重要である一方で
なぜ安全を確保するのかついて
一緒にお話ししていきたいと思います
モンティパイソンを例として
いきたいと思います
セキュリティについて考える時
お城とお堀を思い浮かべます
モンティパイソンで
お城やお堀の秘密が何なのか
覚えてる方いらっしゃいますか？
彼は ゲットしたぞー
みたいな感じですね
秘密はマルチテナンシーです
聖杯を見つけるために
一緒に行く必要はないんです
自分達の聖杯があるからです
この映画では全員
それぞれの聖杯があるので
お互いのを決して目にしないですが
それは完全にセキュアな状態です
全てのジョークは置いといて
オープンな世界のセキュリティで
一番難しい点は
マルチテナンシーモデルの固定によって
最高な状態を作ること
データサービスが
お互いのユーザーを保護しない場合は

English: 
to see it.
It's perfectly secure.
All joking aside, the hard parts about security
in an open world is usually addressed best
by just fixing the multi tenancy model.
If this data service does not protect users
well from each other, just run multiple copies.
I don't want to share Radius with you.
Sorry, we're friends but we're not that good
friends.
I'll have my own Radius, you have your own
radius, that seems just fine, right?
The technical term for this, and I think it
was Snap came up with this, I should double
check that, is the limited blast Radius.
Things are going to go wrong.
They're going to go wrong in prod, they're
going to go wrong in pre-prod, they're going
to go wrong every day somewhere in the world.
And maybe it's a failure, and maybe it's a
security compromise.
The best position you can have is that the
Blast Radius of that failure is really small.
Almost infinitesimal and that there's other

Japanese: 
複数のコピーを
実行することができます
あなたとはRadiusをシェアしたくない
あなたとは友達ですが
そこまで親しくない
あなたのRadiusがあって
私のRadiusがあって
それで十分だと思いませんか
このテクニカルな用語は
スナップだったと思います
制限ある爆発の距離
という意味です
何かが間違っていると
プロダクションで上手くいかず
プリプロダクションで上手くいかず
毎日世界のどこかで不具合が出てくる
故障かもしれないし
セキュリティの問題かもしれない
あなたができるベストなポジションは
その失敗のBlast Radiusを小さく
限りなく微小にすることと
他にもステップインしてスタックを
テイクアップできる
キーストラクチャーをもつこと
そうすると沈黙があるようだけど
ケアする必要がありますか？
無視して大丈夫だよ
60秒後に戻るでしょう
その間に他の沈黙や
他のバージョンを
ケアしてとなるでしょう
テナンシーを構造から
分離することが

Korean: 
그냥 여러 사본만 실행하십시오
저는 너와 Radius을
공유하고 싶지 않아
미안해, 우리는 친구이지만
우리는 그렇게 친한 친구는 아냐
난 나만의 Radius를 가질 거고
넌 너만의 Radius를 가져
그럼 공평하지, 맞지?
이것에 대한 기술 용어는
제 생각에 그것은
이것과 함께 나온 Snap입니다
그것을 중복해서 확인해야겠지만
그것은 limited blast Radius입니다
일들은 잘못될 수 있습니다
그것들은 실제 서비스에서
잘못될 수 있습니다
그것들은 서비스 전에
잘못될 수 있습니다
그것들은 세상 어딘가에서
날마다 잘못될 수 있습니다
그리고 아마도 그것은 고장이고,
아마도 그것은 보안 침해일 수 있습니다
여러분이 가질 수 있는 최고의 위치는
그 고장의 Blast Radius가
정말 작다는 것입니다
거의 극소량이고,
들어와서 느리게 만들고,
그 과묵함이 사라지는 것에 대해
괜찮다고 말할 수 있는
다른 핵심 인프라가 있습니다
사실은 그렇지 않습니다.
그것은 60초 안에 되돌아오고
그 동안에는 다른 과묵함이 있고
다른 곳에는 타고 있는
다른 버전이 있습니다
따라서 테넌시를 구성으로부터
분리하는 것은

Russian: 
Не хочу я делиться
с тобой радиусом.
Мы не настолько
хорошие друзья.
У меня свой, у тебя свой,
и всё отлично, да?
Технический термин для этого
придумали,
кажется, в Snap, но нужно
перепроверить -
«ограниченный радиус взрыва».
Поломки будут происходить.
Они будут происходить
в продакшне,
возникать в
пре-продакшне,
всё время в мире
что-то ломается.
Это может быть технический сбой
или брешь в безопасности.
Лучше всего будет,
если «радиус взрыва» ошибки
окажется мал,
практически незначителен, и
другая ключевая инфраструктура
сможет «подхватить» место сбоя,
и как будто ничего не случилось.
Неправда, ошибка вернётся
через минуту,
и случится очередная
заминка,
и где-то ломается что-то ещё.
Так что отделение
клиента от возможностей
конфигурации -

Chinese: 
用戶之間保護好他們，
那就運行多個副本吧。
我不想和你分享半徑。
對不起，我們是朋友，
但並不是那麼好的朋友。
我會有我自己的半徑，
你會有你自己的半徑，
那樣看起來很好，對吧？
有關這個術語，
我想是Snap想到的，
我要再次確認下，
是有限爆炸半徑。
系統會出現問題。
會在生產環境中出錯，
會在預生產環境中出錯，
每天會在世界某個地方出錯。
問題可能是故障，
可能是安全入侵。
你的最好做法是讓故障的
爆炸半徑變得非常小。
幾乎是無窮小，並且
有其他關鍵基礎設施
可以介入並接替工作，
並說，好吧，沉默
消失了，我們在乎嗎？
並不在乎，它會在
大約60秒後恢復，
同時，有其他沉默和
應用的其他版本在其他地方運行。
因此租賃

Chinese: 
不受其他用户的侵害，
只是运行多个副本。
那么我不会想
跟你分享Radius。
不好意思，我们是朋友，
但是不是那么要好的朋友。
我会有我自己的Radius，
你有你自己的Radius，
大家都好好的，对吗？
用一个技术术语来表示的话，
就是有限爆炸半径，
这个术语好像是Snap提出的，
我会再确认一下是不是。
事情要出错了。
在生产阶段要出错，
在预生产阶段要出错，
每一天，他们都将要
在世界上某一个角落出问题。
也许，它是一次失败，
又或者它是安全性的一次妥协。
最好的情况就是，
这次失败的
爆炸半径真的很小。
极其微小，
还有其他核心基础架构可以替换，
来收拾残局，
然后说好吧，故障已经消失，
我们还会关心吗？
并不是这样的，在大概六十秒后
故障又会出现，
同时还有其他故障，
其他地方还存在其他类型的
问题。
所以把租户和配置分隔开，

Russian: 
очень важная часть
всей архитектуры проекта,
и речь не идёт о частных
проектах.
Так, я упомянул
много технологий,
поговорил
об архитектуре проектов,
немного упомянул проекты
с открытым кодом,
но я пропустил часть о том,
как выбрать нужное?
Все это ужасно запутано.
У меня есть масса вариантов,
любой язык,
любое расположение,
любой нужный сервис.
Как сделать выбор?
И, поскольку всё это -
открытые источники,
как выбрать нужные части
для сборки?
Что стоит просто
скачать с GitHub,
а что - купить и воспользоваться
помощью поддержки.
Раньше в Pivotal
работал Паркер Томпсон,
и он всегда говорил
что нужно обладать
мастерством отличать
одно от другого.
Милый, но абсолютно
бесполезный совет.
Так что я направился
к своему коллеге,
Клейтону Старку, и он, конечно,
не мне это говорил,
и не первым сформулировал:

Chinese: 
对于这个架构来说，
真的是非常重要的一部分，
我在这里谈的是
架构，
我没有在谈
单个项目。
好的，
我已经说过一些技术，
也谈到一点点架构，
还有讲过一点开放源码，
但是，
我跳过的是，
你怎样作出决定？
开始觉得全部东西都
真的挺复杂的。
我有那么多的选择，
全部我想要的语言，
全部我想要的地点，
全部我想要的服务。
我怎样挑选？
并且因为全部这些
都是开放源码，
我应该怎样去选择
来构造出我自己的东西？
什么东西
我要到GitHub去下载。
什么东西我真的需要去买，
获得真实的支持。
Parker Thompson之前
在Pivotal工作，
这就是他用来判断的框架，
来判断你是否真的
有区分的智慧。
这很有趣，
但不是很有用的建议。
所以我更愿意
去找我的大学老同学，
Clayton Stark，
他说，
虽然不是原话，
他说，首先，

English: 
key infrastructure that can step in and take
up the slack and say okay well that reticence
is gone,do we care?
Not really, it'll be back in sixty seconds
or so and in the mean time there's other reticence
and other versions of the out burning else
where.
So that separation of tenancy from configuration
is really an important part of this architecture,
and I'm just talking about architecture here,
I'm not really talking about individual projects.
All right, I went over a bunch of technologies,
and I talked a little bit about architecture
and I talked a little bit about OpenSource
but what I skipped was, how do you make decisions?
This all starts feeling really complicated.
I have all of these choices, any language
I want, any location I want, any service I
want.
How do I pick?
And since all of this open source, how do
I pick which things I build for myself?
Which things I just download from GitHub.
And which things I actually buy and get real
support for.
Parker Thompson used to work at Pivotal and

Korean: 
아키텍처의 정말로 중요한 부분이고
저는 단지 여기에서 아키텍처에 대해
이야기하고 있지
개별적인 프로젝트에 대해
이야기하고 있지 않습니다
좋습니다,
저는 일단의 기술들을 검토했고
아키텍처에 대해 약간 이야기했고
OpenSource에 대해
약간 이야기했지만
제가 건너 뛴 것은
우리가 어떻게 결정을 하는가입니다
이 모든 것은
정말 복잡하다고 느끼기 시작됩니다
저는 이 모든 선택,
즉, 어떤 언어를 사용하고 싶은지
어느 장소를 원하는지,
어느 서비스를 원하는지 선택해야 합니다
어떻게 고를까요?
이 모든 것이 오픈 소스이기 때문에
제 자신을 위해 어느 것을
빌드하는 것을 선택할까요?
제가 GitHub에서 어느 것을
다운로드해야 할까요?
그리고 어떤 물건을 구입하여
실제 지원을 받아야 할까요?
Parker Thompson은 Pivotal에서
일했는데
그것은 그 차이를 알 수 있는 지혜를
정말 가지고 있어야 하는지를 말할 수 있는
일종의 자신의 프레임워크였습니다
그것은 재미있지만 하나의 권고로서
매우 유용하지는 않았습니다
따라서 저는 제 오랜 동료인
Clayton Stark에게 되돌아가곤 했는데
이것은 그렇지 않았습니다
명백히 그는 나에게 말하지 않다가
우리가 믿는 신을 두고

Japanese: 
アーキテクチャで
非常に重要です
ここではアーキテクチャについて
お話しします
個々のプロジェクトについて
ではありません
数々のテクノロジーについて
カバーしてきました
少しアーキテクチャや
OpenSourceについても
お話ししましたが
スキップした点は
どうやって意思決定するかです
とても複雑なように感じますよね
あらゆる選択肢がありますからね
好きな言語　好きなロケーション
好きなサービス
ではどうやって選択していきましょう
これはオープンソースなので
自分自身の構築のために
どれを選んでいけばいいのか
GitHubからどれをダウンロード
すればいいのか
どれに実際にお金を払って
サポートを受ければいいのか悩みます
パーカー・トンプソンは
以前Pivotalで働いていました
違いを知る知恵を
本当に持っているかどうかが
彼のフレームワークでした
興味深いですが
アドバイスとしては役立ちません
それからクレイトン・スタークという
以前の同僚に連絡を取りました
これが実際に彼が言ったことでは
ないんですけれども

Chinese: 
從配置分離是這個架構中的一個
重要部分，我這裡只是在說架構。
我並沒有談到個別項目。
我回顧了一堆技術，
我談了一點架構，
我談了一點開源，
我跳過的是，你如何作出決定？
這一切開始令人覺得十分複雜。
我有所有這些選擇，
我要的任何語言，
我要的任何地點，我要的任何服務。
我怎樣選擇？
因為這些都是開源的，
我怎樣選擇哪些東西來自己構建？
哪些我應從GitHub下載。
哪些我應該購買和得到真正支持。
Parket Thomson之前在Pivotal工作，
這可以算是他的框架，說你是否
確實擁有知道其中區別的智慧。
這作為忠告有點意思，
但不是很有幫助。
所以我傾向於回去找一個老同事，
Clayton Stark。
顯然他沒有這樣跟我說，但他先說這個，

Chinese: 
我们像相信神一样
相信所有的这些东西会带来数据。
当你应该自己
去构建一些东西的时候，
尤其是当要尽可能
靠近客户的时候，
你用数据去看，
要数据告诉你，
你不希望在你所做的事情方面，
成为世界上最顶尖的那位，
而是成为世界上最一位
做这件事的那个人。
如果你从事搭建
分布式系统，
你应该在分布式系统
软件公司。
你应该来和我们一起工作。
如果你从事
搭建视频游戏，
你应该去搭建视频游戏，
Clayton就是在做这个事情，对吗？
他没有搭建
自己的分布式系统。
并且如果你每天
要处理上百万条，
上千万条，
甚至上亿条的，
有价值的金融信息，
我对每天处理量
没有什么概念。
你应该去万事达
信用卡公司工作，
我的好朋友Rick Clark
最近就是做这个事。
Rick，你可以到这里来吗？
我们一起来聊一聊。
>> [掌声]
>> [笑声]

Korean: 
처음으로 나에게 말했는데,
모든 다른 것이 데이터를 가져옵니다
데이터 보기를 사용하면
여러분이 무언가를 스스로 빌드할 때를
데이터가 알려 주는데
전형적으로 그것은 가능한 한 고객들에게
가까이 있을 때입니다
즉, 여러분은 여러분이 하는 일에서
최고가 되고 싶지 않고
여러분이 세계에서 그렇게 하는 유일한
사람이 되고 싶을 때입니다
여러분이 분산 시스템을 구축하는
사업에 종사하고 잇는 경우에는
여러분은 분산 시스템 소프트웨어
회사에 있어야 합니다
여러분은 아마도 와서
우리를 위해 일해야 합니다
여러분이 비디오 게임을 제작하는 사업에
종사하고 있는 경우라면
여러분은 가서 비디오 게임을 제작해야 하는데,
그것이 바로 Clayton이 하는 일이죠, 맞죠?
그는 자신의 분사 시스템을 제작하지 않습니다
여러분이 수백만 또는 수천만 또는
수억 건을 처리하는 사업에
종사하는 경우
실제의 가치 있는 금융 정보 중
하루에 얼마나 많은 거래가 있는지
저는 모릅니다
여러분은 아마도 MasterCard를 위해서
일해야 하는데
그것은 제 친한 친구인 Rick Clark가
최근에 했던 일입니다
Rick, 여기로 나와 주시겠어요?
잠깐 이야기 좀 해봅시다
>> [박수 갈채]
>> [웃음]

English: 
this was kind of his framework to say whether
or not you should really have the wisdom to
know the difference.
That's funny but not very helpful as a piece
of advice.
So I was inclined to go back to an old colleague
of mine, Clayton Stark and this is not, obviously
he didn't say this to me, he said this first
but in God we trust, all others bring data.
Use the data look, the data tells you when
you should be building something yourself
and typically that's when it's as close to
your customers as possible right you don't
wanna be the best in the world at what you
do you wanna be the only one in the world
at what you do so.
If you're in the business of building distributed
systems, you should be in a distributed system
software company.
You should probably come work for us.
If you're in the business of building video
games, you should go and build video games,
which is what Clayton does, right?
He does not build his own distributed system.
And if you're in the business of dealing with
millions or tens of millions or hundreds of

Russian: 
Богу верим,
от остальных требуются данные.
Используй данные, Люк,
они подскажут тебе
когда стоит собирать что-то
самостоятельно,
обычно это сегмент,
наиболее близкий к потребителю.
Вы не хотите быть лучшими
в своём деле,
вы хотите быть единственным
в том, что создаёте.
Если вы заняты постройкой
распределённых систем
Вы должны работать в компании,
создающей такие системы.
Возможно, вам стоит
работать у нас.
Если вы создаёте
видеоигры, вам стоит
идти и создавать их,
как Клейтон.
Он не создаёт собственные
распределённые системы.
А если вы работаете
с миллионами,
десятками,
даже сотнями миллионов,
короче, кучей транзакций
ценной финансовой информации,
вам стоит поработать на
MasterCard,
как недавно поступил мой друг,
Рик Кларк.
Рик, выйди к нам, пожалуйста.
Давай поболтаем.
>> [АПЛОДИСМЕНТЫ]
>> [СМЕХ]
>> Присаживайся.

Japanese: 
神でなければ
データを持ってきたまえ
データの外観を使えば
データが何かを
構築しなければならない時を知らせ
通常はそれは顧客に
近づいた時のことです
あなたが作り上げるものは
世界一ではなく
オンリーワンにしたいはずです
分散システムを構築していて
分散システムソフトウェア企業に
いる場合は
私たちと一緒に仕事するべきでしょう
ビデオゲームを構築する
ビジネスであれば
どのClaytonを使って
構築するのか考えます
Claytonは分散システムを作りません
1日のトランザクションが
数千万や数億という金融の情報を
抱えるビジネスにいるのであれば
MasterCardと一緒に
仕事をすべきでしょう
最近MasterCardに入った
リック・クラークをご紹介しましょう
こちらへ上がって
ちょっと話を聞かせてください
>> [拍手]
>> [笑]

Chinese: 
我們信賴上帝，所有其他人帶來資料。
使用資料視圖，資料告訴你
什麼時候應該自己構建某樣東西，
這就是盡可能接近你客戶
的時候。你不想成為世
界上做你所做事情
的人中最好的,而是要做
世界上唯一做這件事情的。
如果你從事分散式系統開發，
你應該在一個分散式系統軟體公司。
你可能應該來為我們工作。
如果從事視頻遊戲開發，你應該
去開發視頻遊戲，
Clayton就是這樣做的，對嗎？
他並沒有開發他自己的分散式系統。
如果你的業務要處理幾百萬、
幾千萬或幾億，
我不知道每天成交多少筆
真正有價值金融資訊的交易。
你可能應該去為萬事達卡公司工作，
我的好朋友Rick Clark最近就這樣做了。
Rick，你能上來這裡嗎？
讓我們聊一下。
>> [鼓掌]
>> [笑]

English: 
millions, I have no idea how many transactions
a day of real valuable financial information.
You should probably go work for MasterCard,
which is what my good friend, Rick Clark did,
recently.
Rick, can you come up here?
Let's have a bit of a chat.
>> [APPLAUSE] >> [LAUGH] >> So, yeah, take
a seat.
I'm actually gonna grab my water.
I don't know if you brought yours.
>> I did not.
>> All right, well I haven't opened that one
so here you go.
>> Thank you.
Here you can have it I'm fine.
>> Thank you, all right- >> [LAUGH] >> So
just for context, I introduced you you know
you're the SVP at MasterCard.
I think you own everything related to cloud,
which is- >> Digital transformation, I'd say.
Cloud is part of it.
>> Okay.
>> Very much.
>> I think, I got to know you when we were
both involved in OpenStack back in the very
early days.
So, maybe we can start with this transition,
MasterCard involved in an open source.
Is that new?
Is that a real thing?
How do you think about that?

Japanese: 
>> どうぞおかけください
お水を持ってきます
自分のお水を持って来ましたか
>> いいえ
>> これまだ開けてないんでどうぞ
>> ありがとう
私は大丈夫なのでどうぞ
>> ありがとうございます
>> [笑]
>> すこし背景を説明すると
君がMasterCardのSVPということは
説明しました
クラウド関連の全てについて
熟知している
と思います
>> デジタル
改革関連のことについてはそうですね
クラウドもその一部ですけれど
>> そうですね
>> その通りです
>> 私たちはOpenStack初期の
取り組み当時から知り合いでした
なので移行についてから
話していきたいと思います
MasterCardがオープンソースを
取り入れましたが
それは新しいことですか？
どう考えてますか？
>> 新しくはありません
働き始めてから6ヶ月しか経ってないので
6か月以上は経っていますが
>> 少なくとも
6ヶ月はやってるって事ですね
>> そうです6ヶ月です
Apache のコントリビューターを
バックアップしてるので
オープンソースを積極的に使っています
それは意思決定をする時
選択の大部分を意味するものに
なってきました

Russian: 
Я пойду возьму воды.
Ты свою не захватил?
>> Нет.
>> Я вот эту не трогал, держи.
>> Спасибо.
Держи, мне не нужно.
>>Ладно, спасибо-
>> [СМЕХ]
>>Ради контекста,
Я представил тебя как старшего
вице-президента в MasterCard.
ты занимаешься всем, связанным
с облачными сервисами.
Например...
>> Переход на
цифровые технологии.
Облако в них входит.
>> Ясно.
>> В основном.
>> Мы познакомились, когда
вместе работали
над OpenStack в самом начале.
Может, стоит начать
с этого перехода.
MasterCard участвует
в разработке открытого кода.
Это новость?
Это возможно?
Что ты думаешь
по этому поводу?
>> Это не новость, но я работаю
у них всего полгода,
они начали до меня.
>>То есть,
проекту минимум полгода.
>> Минимум полгода.
Мы поддерживаем
разработчиков на Apache,
так что можем пользоваться
открытым кодом.
Думаю, мы всё чаще
выбираем открытый код,
когда принимаем решения.

Chinese: 
>> 這樣，對，請坐下。
我其實正打算拿水喝。
不知道你有沒有帶上你的水。
>> 我沒有帶。
>> 好的，我那瓶沒有開，就給你吧。
>> 謝謝。
給你吧，我不需要。
>> 謝謝，好的。
>> [笑]
>> 先說下背景，
我介紹了你，你是萬事達卡
公司的高級副總裁。
我想你管理所有和雲有關的事務，
即... >> 我會說
數字轉化。
雲是其中一部分。
>> 對。
>> 非常對。
>> 我想，很早期我們都在OpenStack
的時候我就認識你了。
所以，也許我們可以從這個過渡開始，
萬事達卡公司參與開源專案。
這是新變化？
是不是認真的？
你有什麼想法？
>> 嗯，不是新的變化，我才到那邊6個月，
在我去之前已經開始了。
>> 所以它至少已經有6個月了。
>> 至少6個月了，我是
說我們支持了Apache的
貢獻者，所以我們積極使用開源。
我想現在我們做決策的時候，
它在選擇中的比重更大了。

Chinese: 
>> 嗯，耶，请坐。
我要先拿瓶水喝。
我不知道，
你有没有带水来？
>> 我没有。
>> 那好，这瓶我还没开，
先给你。
>> 谢谢。
你可以拿这个，没事。
>> 谢谢，好的-
>> [笑声]
>> 嗯，回到刚刚说的，
我介绍了你，
说你在担任万事达信用卡公司的高级副总裁。
我觉得你拥有了
和云端相关的所有东西，
那就是-
>> 要我说，
数字化改造。
云端是其中一部分。
>> 好的。
>> 谢谢你。
>> 我觉得，我们是在
很早期的时候
都参与到OpenStack的时候
认识的。
所以，或许我们可以
从这个转变说起，
万事达信用卡公司
参与到一个开放源码中。
那很新颖吗？
那是真的吗？
你是怎么看的？
>> 嗯，并不新颖，
我在那里只待了六个月，
在我去之前，它已经存在了。
>> 所以，
它至少已经有六个月的历史了。
>> 它至少已经有六个月的历史了,
并且我们也给贡献者在Apache上
给予了支持，
所以我们积极使用开放源码。
我觉得，现在来说，
我们在做决定的时候，
它已经占据了我们的选择的很大一部分了。

Korean: 
>> 앉아 주세요
사실 물을 좀 마시고 싶었어요
당신의 물을 가져 오셨는지 모르겠네요
>> 안 가져왔어요
>> 괜찬하요, 제가 아직 열지 않았으니
이거 받으세요
>> 고마워요
여기서 드셔도 돼요
>> 고마워요, 좋아요
>> [웃음]
>> 그러니까 맥락을 말씀드리면
저는 당신을 MasterCard의
SVP라고 소개했습니다
저는 당신이 클라우드와 관련된
모든 것을 소유하고
그것은
>> 디지털
변혁이라고 말씀드리고 싶네요
클라우드는 그것의 일부입니다
>> 알겠습니다
>> 아주 많이요
>> 제 생각에 매우 초기에
우리 둘 모두 OpenStack에 관여하고 있을 때
당신을 알게 된 것 같습니다
따라서, 아마도 우리는
MasterCard가 오픈 소스에 관여한
이 전환에서부터 시작할 수 있을 것 같습니다
그것이 새롭나요?
정말인가요?
그것에 대해 어떻게 생각하세요?
>> 글쎄요, 새롭지는 않아요.
저는 거기에서 6개월 있었는데
저보다 먼저 시작했죠
>> 그러니까 적어도 6개월 된 거죠
>> 적어도 6개월 되었는데,
우리는 Apache 기여자들을 후원해왔고
적극적으로 오픈 소스를 사용합니다
제 생각에 그것은 이제
우리가 결정을 할 때
선택의 더 큰 부분이 되고 있습니다

Russian: 
Этот критерий
встречается всё чаще и чаще,
Галочкой не обойтись.
Способ разработки кода
для нас тоже важен.
>> Ясно.
И всё же, почему ты выбрал
именно Club Foundry?
Как ты рассуждал:
это будет удачным решением
для MasterCard?
>> Причин много.
Слишком много,
чтобы рассказать обо всех.
[СМЕХ] Но главное - это то,
что уровень абстракции
работает за нас.
Цифровые технологии
быстро распространяются,
и это нельзя игнорировать.
К примеру, необходимо
переобучать сотрудников,
работающих на основе
старых проектов,
чтобы они создавали всё с нуля.
И Cloud Foundry даёт нам
уровень абстракции,
который развязывает нам руки
при переносе приложений,
сильно упрощая задачу.
Так, мы можем повышать
компетентность сотрудников
в то же время уделяя
внимание прочим вещам.
>> Вот оно что.
>> Можем создавать иерархию
уровней абстракции.
>> Верно. Своим дочерям

Korean: 
그것은 더 커다란 범주이지
단순한 체크 박스가 아닙니다
이 방식으로 오픈 소스는
우리에게는 이루어진 일이기도 합니다
>> 맞습니다
배경막으로서 그것이 있는데
왜 Club Foundry를 선택하셨습니까?
거기에서의 생각은
그것이 MasterCard에 좋은가입니다
>> 네
우리가 들어가 볼 시간이 없는
많은 이유들이 있습니다
[웃음]
하지만 주된 원인은
추상 레이어가 당사에 대해
효과가 있다는 것입니다
우리가 디지털 변환을 거칠 때
일어나야 하는 일단의 것들이 있습니다
그것들 중의 하나는
기존 분야에서 일하는 모든 사람들을
신규 분야에서 궁극적으로 일하도록
보유해야 한다는 것입니다
그리고 Cloud Foundry에 의해 제공된
추상화 레이어는
우리가 그것을 할 수 있도록
응용프로그램들을 옮기기 시작할 때
우리에게 숨실 틈을 제공합니다
따라서 우리는 직원의 지식을 증가시켜
다른 일들에 대해 작업하기
시작할 수 있습니다
>> 맞습니다
>> 그리고 서로 다른
추상화 레이어들의 더미를
아래로 내리는 것입니다
>> 맞아요.
저는 학부모인데,

Chinese: 
它變成一個越來越大的條件，
而不只是一個核取方塊。
開源工作的方式對我們也很重要。
>> 對。
那麼以此為背景，你為什麼
選擇Cloud Foundry呢？
當初這方面如何考慮，
認為這個可能有利於
萬事達卡公司？
>> 嗯，有很多
很多原因，我們沒有時間詳細說。
[笑] 但主要原因是
這個抽象層適合我們。
就是在進行數位轉化時，
有一堆事情必須做到。
其一是重新培訓所有
在傳統領域工作的員工，
以便他們最終能
在新領域中工作。
Cloud Foundry提供的這個抽象層
給了我們開始遷移應用時的喘息機會，
以便我們能做到。
這樣我們能增加員工的知識，
才能開始做其他事情。
>> 對。 >> 然後進一步深入到
不同抽象層中。
>> 對。 我是一名父親，

English: 
>> Well it's not new, I've only been there
six months and it predated me.
>> So it's at least six months old.
>> It's at least six months old, I mean we
have backed up contributors to Apache so we
actively use open source.
I think now it's becoming a larger part of
the choice when we're making decisions.
It's a bigger and bigger criteria and it's
not just a check box.
The way open source is done matters to us
too.
>> Right.
So with that as a backdrop, why did you pick
Club Foundry?
What was the thinking there to say hey, this
could be good for MasterCard?
>> Well, there are many, many reasons which
we don't have time to go into.
[LAUGH] But the primary reason is that the
abstraction layer works for us.
That when you're going through digital transformation,
there are a bunch of things that have to happen.
One of which is you have to retrain all the
people who are working on brown field to eventually
work on the new green field stuff.

Japanese: 
ただのチェックボックスではなく
大きな重要事項として
より大きくなっています
オープンソースの活用の仕方が
私たちにとっても大切です
>> そうですね
ではそのバックドロップとして
なぜCloud Foundryを選択したのですか？
どういった思考があって
Mastercardに最適だと
思ったんでしょうか？
>> 沢山の理由があって
全てお話する時間はないですが
[笑] ただ
一番の理由というのは
抽象化レイヤーです
デジタル改革を行う時
いろんな事が起こります
その一つにはブラウンフィールドから
実際に動作するグリーンフィールドに
なるまで
すべての人々を統括して
いかなければならない
Cloud Foundry による
抽象化のレイヤーは
アプリケーションを移行する中で
呼吸する余地を与えてくれました
そうすることで
スタッフの知識を増やしながら
作業することができる
>> そうですね
>> あとは間違った抽象化レイヤーの
スタックにムーブダウンもできます
>> なるほど
私には娘がいるんですけれど

Chinese: 
它是越来越大的一个标准，
而不仅仅是一个复选框。
开放源码是怎样完成的，
对我们来说也很重要。
>> 对。
所以，在这样的背景下，
你为什么选择了Cloud Foundry？
你有怎样的考量，
才会说，嘿，这个对万事达信用卡公司
有好处？
>> 嗯，有很多，
很多原因，
今天没办法深入地一一说明了。
[笑声] 但是
主要的原因就是，
从概念来看，对我们来说
是可行的。
当你们进行
数字化改造过程中，
有很多事情发生了。
其中一件事情就是
你保留了所有改造前已经在工作、
逐渐转到在数字化环境下工作的
全部员工。
并且，Cloud Foundry所提供的
概念层面的东西
给予了我们喘息的空间，
所以我们开始移动应用程序，
然后实现那样的事情。
所以我们可以给我们的员工
灌输更多知识，
这样我们就可以干其他事情了。
>> 对。
>> 然后就有点像搬开这堆
不同的抽象层。
>> 对。
我是一名家长，

Chinese: 
我经常告诉我的女儿，
你可以做任何事情，
但不是所有事情。
然后我觉得，
要进行某种转型的话，
这句话对你的团队来说
也是正确的。
你可以学习做任何事情，
但是你没办法学习
做全部事情，
所以你需要
选出那些抽象层。
>> 嗯，从你真正可以做的
事情开始。
[笑声] 我见过很多公司
是这样开始的，
我们要开始搭建
自己的平台了，
然后他们之前在云端
没有做过任何事情。
这是他们要做的第一件事，
所以他们将要做的事情
可能是最困难的，
因为他们知道得最清楚。
我们不是这样开始的。
>> 所以显然在公共云
有很多参与者，他们都在进行报价，
所有的Cloud Foundry用户，
实际上所有都来自世界500强。
关于Azure的什么
让你觉得兴奋呢？
>> 嗯，我会说，
我知道这不是他们的口号，
但是它像是给成人的云端，
对吗？
在万事达信用卡公司，
我们是一家大公司，

English: 
And The abstraction layer, provided by Cloud
Foundry gives us the breathing room as we
start moving applications so that we can do
that.
So we can start increasing​ the knowledge
of our staff so that we can start working
on, Other things.
>> Right.
>> And then sort of move down the stack of
the different abstraction layers.
>> Right.
I'm a parent and I always tell my daughters
you can do anything, but not everything.
And I sort of feel like that's true for your
team when you're going into any sort of transformation.
You can learn to do anything, you can't learn
to do everything so you have to pick those
abstractions.
>> Well, starting with something that you
can actually do.
[LAUGH] I've seen a lot of companies start
with we're going to build our own platform
and they've never done anything in the cloud
before.
This was their first thing, so they were going
to do the most complicated thing possible
because they know best.
We didn't start that way.
>> So there's obviously a lot of players in
the public cloud and they've all been quoting,
all Cloud Foundry users, in fact all of the
Fortune 500.

Japanese: 
いつも言ってることは
君は何でもできるだよ
でも全てじゃない
チームにとっても
そうだと思うんです
ある改革をしていく時
あらゆることを学ぶことができる
ただ全てを学ぶことはできない
抽象化を選択しなければならない
>> そうですね
できることから始めることです
[笑] 独自のプラットフォームを
構築しようとする
沢山の企業を見てきました
以前にクラウドの活用は
全くしたことがない企業です
彼らが一番最初にすることは
最も複雑なことを
可能にすることですが
私達はそのやり方は取りません
>> 現在パブリッククラウドの分野では
沢山のプレイヤーがいて
Cloud Foundryのユーザーを
惹きつけています
実際にFORTUNE 500の企業ばかりです
ではAzureの何があなたを
惹きつけますか？
>> そうですね
これはスローガンではありませんが
Azureは成長した企業のための
クラウドですよね
MaterCardは大企業で

Chinese: 
我總是告訴我的女兒，
你可以做任何事情，
但不是所有事情。
所以我感到，對於要進行任何
轉換的團隊來說，確實如此。
你可以學會做任何事情，
你不能學會做所有事情，所以
你必須選擇哪些抽象層。
>> 嗯，從你實際能做的某樣事情開始。
[笑]我見過很多公司開始時
就打算建立自己的平臺，
他們從未在雲中做過任何事情。
這是他們的第一次，他們就打算做
最複雜的事情，因為他們最懂行。
我們開始不是那樣做的。
>> 那麼，在公有雲中
顯然有很多公司，
他們都有向所有Cloud Foundry用戶，
事實上所有財富500強企業報價。
Azure有什麼吸引了你們？
>> 我會說，我知道這不是他們的口號,
但它是成年人的雲，對吧？
萬事達卡公司是一家大公司，

Russian: 
я всегда говорю:
сделать можно всё, что угодно,
но не всё сразу.
То же можно сказать
и про вашу команду,
когда необходимо
внедрить что-то новое.
Всему можно научиться,
но не всему сразу,
так что ты ранжируешь
абстракции.
>> На первом месте стоит то,
что точно осуществимо.
[СМЕХ] Многие компании
сразу брались
за создание
собственной платформы,
не имея опыта
облачной разработки.
Для первого проекта выбирали
максимально сложную вещь,
думая, что знают всё лучше всех.
Мы так не думали.
>> Публичное облако
используется очень широко,
при этом, почти всегда речь
идёт о Cloud Foundry,
её используют
крупнейшие компании.
А чем тебя привлекает Azure?
>> Мне нравится -
прозвучит, как слоган -
но мне нравится,
что это облачная платформа
для серьезных взрослых людей.

Korean: 
제 딸에게
너는 어느 것이나 할 수 있지만
모든 것을 할 수는 없다고 항상 말합니다
저는 당신이 모든 종류의 변환을
거치려고 할 때에도
그것이 적용된다고 생각합니다
여러분은 어느 것이나
하는 것을 배울 수 있습니다
여러분은 모든 것을 하는 것을
배울 수는 없기 때문에
여러분은 그러한 추상화를
골라야 합니다
>> 그러니까, 여러분이 실제로 하는 무언가로
시작하는 것입니다
[웃음] 저는 많은 회사들이
자체 플랫품을 구축하는 것부터
시작하는 것을 목격했는데
그들은 이전에는 클라우드에서
아무 것도 한 적이 없었습니다
이것은 그들의 첫 번째 일이었기 때문에
그들은 자신들이 가장 잘 알기 때문에
가장 복잡한 것을 하려고 했습니다
우리는 그런 방식으로 시작하지 않았습니다
>> 따라서 공용 클라우드 분야에는
많은 업체들이 있는데
그들은 모두
모든 Cloud Foundry 사용자,
사실 모든 포춘 500 기업들을
인용했습니다
Azure에 있어서
당신에게 신나는 일은 무엇인가요?
>> 글쎄요,
이것이 그들의 슬로건은 아니지만,
성인들을 위한 일종의 클라우드라고
하겠습니다, 맞죠?
Mastercard는 큰 회사이고

Chinese: 
這是我們第一次涉足雲。
我們需要一家公司
能提供我們需要的支援。
他們創建的東西對我們
來說不只是發出警告。
他們給我們大量手把手的教導，
在我們需要時，
他們都能提供幫助，
我跟你說，支持是一流的。
>> 所以Azure是成年人的雲，
而Pivotal給你改變時的喘息機會。
>> [笑]
>> 言之有理。
除了我自己也是Cloud Foundry
的供應商這個事實，
我猜上面還有很多
供應商是我想認識的。
作為Cloud Fountry供應商，
Pivotal是什麼？
>> 就是你和
James Waters。
所以，這對我們是新事物，
我們不熟悉雲，
我們要和已經做過這個
事情很多很多次的人合作。
讓我們依賴於他人的經驗，
而不是自己反復失敗或者
和我們不是很肯定的人合作。

English: 
What is it about Azure that's exciting to
you?
>> Well, I would say that, I know this isn't
their slogan, but it's kinda cloud for grown
ups right?
At Mastercard we're a big company and this
is our first foray in the cloud.
And we needed someone that could provide us
the support that we needed.
And was building something that was more caveat
for us.
They've done a lot of hand holding, they were
there when we needed them, so the support
I tell you, just number one.
>> So Azure is cloud for grown ups, and Pivotal
gives you breathing room while you change.
>> [LAUGH] >> This makes sense.
I guess the Cloud Foundry has a number of
vendors I would love to know other than the
fact that I'm also personally.
What was it about Pivotal as a Cloud Foundry
vendor that was- >> It was all you and James

Chinese: 
这也是我们在云端领域的首次尝试。
然后我们需要有人能够
提供我们所需的支持
给我们。
搭建某样东西
对于我们来说更需要预先警告。
他们已经手把手做了很多事情，
当我们需要他们的时候，
他们就会出现，
所以我告诉你，支持是首要的。
>> 所以Azure是给成人的
云端，
然后当你改变的时候，
Pivotal给你喘息的空间。
>> [笑声]
>> 这很有道理。
我想Cloud Foundry
有很多供应商，
这是我想要听到的事实，
而不是我只是一个人。
Pivotal是Cloud Foundry的一个供应商，
这意味着什么呢-
>> 全部都是你和
James Waters.
所以，再一次，这对于我们来说很新，
我们也对云端不熟悉，
我们也希望和已经做过很多次的人
一起去完成。
让我们一起依赖
别人的经验，
而不是自己不断地失败，
或者和我们不太确定的人
一起工作。

Korean: 
이것은 클라우드에 대한
우리의 첫 번째 개입입니다
그리고 우리는 우리가 필요로 하는
지원을 제공할 수 있는
누군가가 필요합니다
그리고 우리에게는 다소 주의에 해당했던
무언가를 구축하고 있었습니다
그들은 수많은 휴대 작업을 했고,
우리가 그들을 필요로 할 때
그들이 거기에 있었기 때문에
감히 말하건데 지원이 첫 번째입니다
>> 그러니까 Azure는 성인들을 위한
클라우드이고
Pivotal은 여러분이 변화하는 동안
숨쉴 수 있는 공간을 제공하는군요
>> [웃음]
>> 일리가 있습니다
Cloud Foundry에
다수의 벤더들이 있는 것 같은데
제가 개인적으로 아는 사실 외에
다른 게 있나요?
Cloud Foundry 공급업체로서
Pivotal에 대해서는 어땠나요?
>> 당신과
James Waters가 전부입니다
그럼 다시, 이것은 우리에게 새로운 것이고,
우리는 클라우드에 대해서 새롭고,
우리는 이것을 여러 번 했던 누군가와
함께 하고 싶습니다
다른 이들의 경험에 의존해야지
우리 스스로 반복적으로 실패한 방식을
답습하거나
우리가 확신할 수 없는
누군가과 협력해서는 안 됩니다

Russian: 
Mastercard - крупная компания,
и раньше мы
с облаком не работали.
Так что было нужно,
чтобы нам оказали
в этом поддержку,
чтобы помогли
во всём разобраться.
И они очень здорово помогли нам,
когда мы в этом нуждались.
Так что больше всего я ценю их
за оказанную поддержку.
>> Итак, Azure -
платформа для взрослых,
а Pivotal развязывает руки
при внедрении новшеств.
>> [СМЕХ]
>> Звучит разумно.
Мне интересны
поставщики Cloud Foundry,
да я и сам из их числа.
Чем тебе нравится Pivotal
как поставщик Cloud Foundry?
>> Он мне нравится тем, что
тым есть ты
и Джеймс Уотерс.
Как я и говорил,
облако для нас внове,
поэтому мы хотим работать с тем,
у кого есть опыт в этой сфере.
Проще довериться
профессионалам,
чем действовать наугад,
совершая много ошибок,

Japanese: 
これがクラウドでの
初めての試みです
私たちが必要とする
サポートを提供してくれる
誰かが必要でした
警告を受けながら
構築できるものです
Azureは必要な時に
手厚いサポートをしてくれ
サポートが
ナンバーワンの決め手でした
>> Azureは成長した企業のための
クラウドで
Pivotalが変化の中で
深呼吸をする余地を与える
>> [笑]
>> わかりやすいですね
Cloud Foundryには
数々のベンダーがいますが
個人的に知りたいと思っています
Cloud Foundryのベンダーとしての
Pivotalについてご意見はありますか？
>> それはあなたと
ジェームス・ウォーターが全てです
繰り返しますがこれは私たちにとって
新しい試みです
私たちはクラウドの新参者なので
自身で試して何度も失敗したり
あまり詳しくない人と
一緒に取り組むよりも
経験豊富な誰かと
一緒に取り組みを進めて
他の人の経験に
頼っていきたいと思いました

Chinese: 
所以我们知道我们需要帮助，
来正确地进行部署，
并且我们和有最多的经验的人
一起去做这个事情。
对于我们来说，
真的没有思考太多。
>> 对，
>> 我的确想要简单地说说OpenStack，
但是我今天所强调的
许多东西，
都是基于一种情景，
就是选择买还是搭建。
你可以从GitHub下载东西，
运行它们，
或者你可以想想怎样建一个团队，
然后自己组装东西。
你可以说，嘿，
我们将要搭建自己的平台了。
并且我们看到很多人
花了很多年用OpenStack来做这个事情，
但没有取得满意的结果。
当你跟你的同伴、主管
和其他金融公司说起的时候，
你觉得
针对这类决定
有没有
一个通用的原则？
说嘿，这就是你怎么看待
你买的东西，
还有我做的东西[笑声]。
>> 我觉得你搭建的
任何一样东西，
开发者在你的组织中
是一种宝贵的资源，对吗？
你写的每一串字符，
应该有利于

Chinese: 
所以我們知道需要幫助來正確地部署，
我們和經驗最豐富的人合作。
其實對我們來說沒有什麼可想的。
>> 對，
>> 我想簡單說下
OpenStack，但要在這裡先強調下背景，
就是購買還是自建的選擇。
你可以從GitHub下載系統並運行，
或者研究出如何組建
一個團隊並自建系統。
你可以說，嗨，
我們打算建立自己的平臺。
多年來我們看到很多人
這樣使用OpenStack，
令人沮喪。
你認為，在你和你的同行、
高管和其他金融公司討論時，
有沒有一個
作出這種決定的通用原則呢？
就是說，嗨，這就是你
該如何考慮購買什麼和
自建什麼。我有 [笑]
>> 我認為，你構建任何
東西時，開發者
是你組織中的寶貴資源，對吧？
你寫的每一行代碼都應該有益於

Korean: 
따라서 우리는 정확하게 배포하려면
우리가 도움이 필요하다는 것을 알았고
우리는 가장 많은 경험을 가진
사람들과 협력했습니다
따라서 우리로서는 많은 것을
생각할 여지가 없었습니다
>> 맞습니다.
>> 저는 OpenStack에 대해
간략히 이야기하고 싶지만
맥락 상 제가 여기에서 강조하고 있는 것은
구입 대 구축 결정입니다
여러분은 모든 것을 GitHub에서 다운로드하여
그것들을 실행하거나
팀을 어떻게 구성하고
그것들을 어떻게 엮을 것인지 생각하게 됩니다
여러분은 우리가 자체 플랫폼을
구축하려고 한다고 말할 수 있습니다
그리고 우리는 많은 사람들이
수년 동안 OpenStack으로
힘빠진 상태에서
그 일을 하는 것을 보았습니다
당신이 동료, 경영진 및
다른 금융 회사들에게 이야기할 때
이러한 종류의 의사 결정을 위한
일반 원칙이 있다고 생각하세요
당신이 무엇을 사고
무엇을 제작하는지에 대해
당신이 어떻게 생각하는지가
여기에 나와 있습니다[웃음]
>> 저는 당신이 제작하는
모든 것에서
개발자들이 귀사 조직의 중요한 자원이라고
생각하는데, 맞죠?
여러분이 작성하는 모든 코드의 라인은

English: 
Waters.
So again, this is new to us, we're new to
cloud and we want to go with someone that
has done this many, many times.
Let's rely on the experience of others, rather
than iteratively failing ourselves many times
or going with someone that we're not quite
sure about.
So we knew we needed help to deploy it correctly,
and we went with the people that had the most
experience.
Really not much to think about for us.
>> Right, >> I do want to talk briefly about
OpenStack, but really in the context of a
lot of what I am emphasizing here is these
buy versus build decisions.
You can download things from GitHub and run
them or you can figure out how to build a
team and assemble stuff yourself.
You can say, hey, we are going to build our
own platform.
And we saw a lot of people d that with OpenStack,
for a depressing number of years.
Do you think there's a general principle for

Russian: 
или работать с кем-то,
в ком у нас нет уверенности.
В общем, нам нужна была помощь
для верного начала работы,
и мы обратились
к самым опытным ребятам.
Это очевидное решение.
>> Ясно.
>> Хочется сказать
пару слов про OpenStack,
но на фоне всего сказанного
вырисовывается интересная тема:
это тема выбора -
создавать или покупать.
Можно загружать проекты
с GitHub и использовать их,
или собрать команду
и делать всё самим:
«Ребята, сейчас мы создадим
свою платформу».
И они садятся
и создают её в OpenStack,
тратя на это не один год.
Есть ли какой-то общий принцип
принятия таких решений, когда
они обсуждаются с дирекцией
и теми, кто отвечает
за распределение средств?
Ты ведь думаешь о том,
что покупать,
а что создавать? >> Думаю.
[СМЕХ].
>> Я думаю, что всё,
что создаётся -

Japanese: 
これを正しく展開するために
サポートが必要なことは気づいていました
その時経験豊富な誰かと
一緒にやりたかったのです
自分たち自身のことについては
それほど考えませんでした
>> なるほど
>> あとで簡単にOpenStackについて
話したいと思うんですが
先ほど私が強調していたのは
購入 vs 構築の意思決定です
GitHubからダウンロードして
それを実行させてチームが
どうやって構築をするか解明して
実際に組み立てていく
そしたら独自のプラットフォームを
構築しようと言うかもしれません
この何年もの間OpenStackで
それをやっている人も沢山います
あなたがチームメンバーや役員や
その他の金融機関と
意思決定について話す時
一般的な原則はありますか
購入するのと
構築するのでは
こういう風になるでしょう
というように [笑]
>> 構築するものすべての中で
開発者は組織の中で
貴重なリソースです
あなたが書くコードのすべてのラインが
顧客にとって株主にとって

Japanese: 
利益にならなければならない
なので利益を生まないものは
書くべきではない
ここに立ち戻れば
簡単に意思決定できます
後は2つの質問をします
できるかどうか考える前に
すべきかどうかを考える
なのでこれをすべきかどうか
>> なるほど
>> 開発者はあらゆることを
しようとします
誰もが自分なら10%以上
上手くできると思うからです
ただそこですべきかどうか考えます
>> なるほど
>> もし可能でも すべきなのかどうか
この質問はMasterCardの
チームでもよくするし
業界の他の人と話す時にも
よくします
>> なるほど
開発者の思考の中には
誤った属性エラーも
たくさんあると思います
例えば
悪いコードを書いたのは
人が悪かったからとか
私が悪いコードを書くのは
技術的負債と
プレッシャーがあったからだとか
>> [笑]
>> なので
将来のコードを想像してみると
完璧なものを想像します
今までの誰のコードよりも
優秀なコードになる
購入 vs 構築の意思決定にも

Chinese: 
你的客戶或股東。
所以你不應該寫無益於他們的東西。
如果你回想下那一點，
決定就容易多了。
另外，我想問兩個問題。
我們應該嗎？然後是，我們能嗎？
我們應該這樣做嗎？
>> 對。
>> 開發者想做很多事情，
因為每個人都認為
我做到110%。
但我們應該這樣做嗎？
>> 對。
>> 即使你能，我們應該嗎？
所以我向我在萬事達卡公司
的團隊問了很多次這個問題，
我也和業內其他人討論過。
>> 對，對。
我認為，開發者的心態中
有很多假的屬性錯誤。
例如說，
其他人寫了不好的代碼，
因為他們是壞人。
我寫了不好的代碼，
因為它是技術債務且
我承受了壓力。
>> [笑]
>> 所以，
當我們想像在未來編寫代碼時，
我們想像它將是完美無瑕的。
因此比其他所有人
的代碼都要更好。
所以在這些購買或
自建的決定中，有很多

Russian: 
ведь разработчики -
ценный ресурс компании -
так что каждая строка кода
должна быть небесполезной
для клиентов и акционеров.
Нет смысла создавать
что-то впустую.
Если об этом помнить, тот самый
выбор становится гораздо проще.
Есть ещё два полезных вопроса.
Начинать ли проект, когда
не уверен, что всё получится?
Стоит ли вообще пытаться?
>> Точно.
>> Разработчики будут рваться
в бой, ведь каждый уверен,
что может сделать что угодно
на 10% лучше всех остальных.
Но стоит ли?
>> Ясно.
>> Даже если возможно.
Я часто задаю этот вопрос
своей команде
и сотрудникам MasterCard,
обсуждаю его с другими людьми
в нашем деле.
>> Интересно.
Похоже, разработчики
часто совершают
ошибку атрибуции.
Это работает так:
«У других что-то не выходит,
так как они плохие разработчики,
а мой код хромает, потому что
мне дали много работы
и мало времени».
>> [СМЕХ]
>> Так что разработчику кажется,

Chinese: 
你的顾客或者股东。
所以，你不应该写一些
不利于他们的东西。
如果你回归到这一点，
做出决定就会容易很多。
另外，我也想
问两个问题。
我们应该做什么是先于
我们可以做什么吗？
所以，我们应该做这个？
>> 对的。
>> 开发者会想做很多，
因为每个人都觉得
我可以做得好10%。
但是我们应该做吗？
>> 对的。
>> 即使你可以做到，我们应该做吗？
所以这个问题我问了
我在万事达信用卡公司的团队，
也跟行内的其他人
讨论过这个问题。
>> 对的，对的。
我觉得，
在开发者的思维中，
有很多归因错误。
比如说，嗯，
其他人写的代码不好，
是因为他们是坏人。
我写的代码不好，
是因为它属于技术债务，
而我处于压力之下。
>> [笑声]
>> 所以，
当我们想象在未来
编写代码的时候，
我们想象这个过程会是
完美无瑕的。
因此，写出来的编码
也比任何人的好。
所以在面对
买还是搭建这个选择的时候，

English: 
these sorts of decisions when you're talking
to your peers, executives, and other financial
companies.
Say hey here's how you think about what do
you buy and what do you build I do [LAUGH].
>> I think that everything that you build,
developers are a precious resource in your
organization, right?
Every line of code that you write should benefit
your customers or shareholders.
So you shouldn't be writing things that don't
benefit them.
If you go back to that, it makes the decision
easier.
Also, I'd like to ask two questions.
Should we before can we?
So, should we do this?
>> Right.
>> Developers would want to do a lot because
everyone thinks I can do this 10% better.
But should we?
>> Right.
>> Even if you can, should we?
So I asked that question a lot to both my
team at MasterCard and I discuss that with
other people in the industry.
>> Right, right.
There's a lot of false attribution error in
the developer mindset I think.
Which is like, well, other people have written

Korean: 
여러분의 고객이나 이해 관계자에게
도움을 주어야 합니다
따라서 그들에게 도움이 되지 않는
것들을 작성해서는 안 됩니다
여러분이 그것으로 되돌아가면
결정하기가 쉬워집니다
두 가지 질문을 드리고 싶습니다
우리가 할 수 있기 전에
그것을 해야 합니까?
그러니까, 이것을 우리가 해야 합니까?
>> 맞습니다
>> 개발자들은 많은 것을
하고 싶어할 것입니다
왜냐면 누구나 이것을 10% 더 잘할 수 있다고
생각하기 때문입니다
하지만 우리가 해야 합니까?
>> 맞습니다.
>> 당신이 할 수 있는 경우에도요?
저는 MasterCard에 있는 제 팀에게
그 질문을 많이 했고
업계에 있는 다른 사람들과도 논의합니다
>> 맞아요, 맞아요
개발자 마음 자세에는
많은 잘못된 속성 오류가
있는 것 같습니다
그것은 다음과 같은 것입니다
다른 사람들은 나쁜 사람들이기 때문에
나쁜 코드를 작성했다
나는 그것이 기술적 부채이고
압력 하에 있기 때문에
나쁜 코드를 작성한다
>> [웃음]
>> 따라서
미래에 코드를 작성하는 것을 상상할 때
우리는 그것이 결점 없는 것이
되기를 상상합니다
다른 사람의 코드보다
더 나은 코드를 말이죠
따라서 이 구입 대 제작 결정에는

English: 
bad code because they're bad people.
I write bad code because it's technical debt
and I was under pressure.
>> [LAUGH] >> And so when we imagine writing
code in the future, we imagine it's going
to be flawless.
And therefore better than everyone else's
code.
And so there's a lot of accidental hubris
in these buy versus build decisions.
>> And I think open source communities are
a fun way to watch that play out.
But let's look at the Cloud Foundry Foundation
for a second.
What signal do you think it sends to have
Microsoft joining the foundation so publicly?
>> Well, I think I sense a very strong signal
to us, because we consider both Microsoft
and Cloud Foundry to be important partners
for us moving forward.
So the huge buy-in to the foundation, which
is extremely important and a big part of our
decision to go with Cloud Foundry.
I mean that gives us some confidence and security.

Chinese: 
随之而来的还有很多傲慢自恃。
>> 并且我认为，
开放源码社区，会是看这场好戏的
一种有趣的方式。
但是让我们一起看一下
Cloud Foundry基金会。
你觉得，
微软如此公开地加入基金会，
发出了什么信号？
>> 嗯，我觉得给我们
发出了很强的信号，
因为我们把微软和
Cloud Foundry都看作
对于我们继续发展来说
非常重要的伙伴。
所以，这次大量买进，
会是对我们决定
继续和Cloud Foundry合作来说，
有着重要的意义，
也是很重要的一部分。
我的意思是说，
给我们带来了信心和安全感。
>> 你也提到，
它不只是开放源码，
开放源码是怎样的？以及
它是怎样搭建起来的？
而不仅仅是一个因素。
然后你看到覆盖
我们整个客户基础。
你可以对此
阐释多一点吗？
这个社区的什么对你、
对万事达信用卡
非常重要？
嗯，重要的是，
它支持协作，
并且你可以参与到
路线图。

Russian: 
что его следующий проект
будет просто безупречен.
Лучше любого чужого проекта.
И вот такая
наивная самоуверенность
иногда приводит
к неверным решениям.
Думаю, пользователи Open
Source не раз наблюдали,
как разворачивается эта драма.
Но давайте снова вернёмся
к Cloud Foundry Foundation.
Какие, по-твоему,
выводы можно сделать
из того факта, что Microsoft
так открыто заявил
о своём присоединении?
>> Для нас это
очень много значит.
ведь для нас и Microsoft,
и Cloud Foundry
являются важными
партнёрами на пути к успеху.
И присоединение такого гиганта -
это большой шаг вперёд,
что лишь подтверждает: мы не
ошиблись, выбрав Cloud Foundry.
Теперь мы можем быть
в этом полностью уверены.
>> Ты ещё упоминал,
что тебе нравится не только то,
что это открытое программное
обеспечение, но и то,
как оно сделано.
Об этом же говорят
все наши клиенты.
Можешь добавить
пару слов на эту тему?

Japanese: 
偶発的な思い上がりがあります
>> オープンソースコミュニティは
実験のためにも楽しい
やり方だと思います
Cloud Foundry Foundationについて
少しお伺いしたいんですが
マイクロソフトが財団に
加入したことは
どんなサインでしたか？
>> 私たちにとっては
非常に強いサインだった感じています
私たちがこれから前進するのに
MicrosoftとCloud Foundryは
両方とも大切なパートナーだと
思っています
今回の大きな買収は
Cloud Foundryで取り組む
私たちにとって非常に重要で
私たちの意思決定の大部分を
占めました
自信と安全性を
確保できたと思います
>> これはただの
オープンソースではなくて
どうやってオープンソースを展開して
どうやって構築をするのかが
ファクターになってきています
私たちの顧客ベース全体を
見渡してもそれが見て取れます
それについて少し
お話ししていただけますか？
コミュニティ内やMasterCardで
何があなたにとって
大切なのか？
それはコラボレーションや
ロードマップへの参加です

Chinese: 
意外的傲慢。
>> 我認為開源社區是觀察這個發展
有趣方式。
但讓我們先看一下
Cloud Foundry Foundation。
你認為微軟這樣公開地
加入Cloud Foundry
發出什麼信號？
>> 我認為這給我們
發出了很強的信號，
因為我們認為微軟和
Cloud Foundry對我們未來發展
都將是重要合作夥伴。
因此大舉進入Cloud Foundry，
這一點非常重要，是我們
決定和Cloud Foundry
合作的主要原因。
我是說這給了我們
一些信心和安全感。
>> 你也提到那不僅是
因為它是開源的，
而它是如何開源及
它如何構建是越來越重要
的因素。
你在我們整個
客戶群中看到那一點。
你想詳細說一下嗎？
這個社區有什麼對你
和萬事達卡公司
重要？
好的，就是它是協作性的，
你能參與到路線圖中。

Korean: 
수많은 우발적인 교만이 있습니다
>> 그리고 저는
오픈 소스 커뮤니티라는 것이
그 연극을 지켜볼 수 있는
좋은 방법이라고 생각합니다
하지만 두 번째에 대해서
Cloud Foundry Foundation을 살펴 보죠
Microsoft가 재단에
그토록 공개적으로 합류하는 것이
어떤 신호를 보낸다고 생각하세요?
>> 글쎄요, 제 생각에
우리에 대한 매우 강한 신호를 감지합니다
왜냐하면 Microsoft와 Cloud Foundry
모두
당사가 진전을 이루는데 대한
중요한 파트너들이기 때문입니다
따라서 재단에 대한
커다란 매입은
극히 중요하고
Cloud Foundry과 함께 하려는
당사의 의사결정의 중요한 부부입니다
제 말은 그것이 당사에
약간의 확신과 보장을 제공한다는 말입니다
>> 당신은 또한 그것이
단지 오픈 소스인것뿐만 아니라
그것이 어떻게 오픈 소스이고
어떻게 제작되었는지가
더 중요한 요소라고 말씀하셨습니다
그리고 당신은 당사의 전체
고객 기반을 통틀어 그것을 보고 있습니다
그것에 대해 약간 자세히
설명해 주시겠어요?
당신과 MasterCard에 대해 중요한 것은
커뮤니티에 대한 어느 것입니까?
그러니까, 그것이
협업적이 될 수 있고
여러분이 로드맵에
참여할 수 있다는 것입니다

Japanese: 
例えばオープンソースの
プロジェクトがあるとしたら
コード エスクローだと思います
私たちは
OpenStackの初期から知っていますが
パッチへの貢献を許可されない
クラウドプロジェクトがありました
パッチを修正できず
方向性に影響を与えられないとしたら
それはただのクローズドソース
のように思います
>> そうですね
>> パッチによって修正する
能力だけじゃなくて
方向性への影響力をもつこと
ファンデーションはひとつの企業とは
分離されているので
それは重要なことです
プロジェクトを見る時
プロジェクトの種類や
企業に関わらず
ファンデーションに
入っているものを選びます
>> OpenStackで
起きることを考える時
プライベートクラウドや
パブリッククラウドの観念は
大切なのですが

Korean: 
따라서 오픈 소스 프로젝트가 있는 경우
사실은 코드 에스크로만
있는 거죠, 맞죠?
제 말은 당신과 제가 OpenStack
이전부터 모두 알고 있듯이
여러분이 패치에 기여하는 것은 허용하지 않는
클라우드 프로젝트들이 있었습니다
내가 패치를 수정할 수 없고,
방향에만 영향을 미칠 수 있다면
그것은 나에게는 닫힌 소스처럼
보입니다
>> 맞아요, 맞아요
>> 그러니까 패치를 통해 제출하고
방향에 영향을 줄 수 있는 것뿐만 아니라
어떤 하나의 회사로부터
분리된 토대를 가질 수 있는
능력을 가지고 잇는 것이
중요한 것입니다
제가 다른 프로젝트를 보고 있는 경우
프로젝트와 회사와 관계 없이
그렇지 않은 것보다는
해당 재단에 있는 것으로
가려고 합니다
>> 우리가 당신이 아는 것에 대해 생각할 때
오픈 스택에 대해 일어났던 일은
분명 사설 클라우드와 같고
공용 클라우드는 여전히 중요하고

Chinese: 
如果外面有開源項目，
他們只是代碼託管，對吧？
我是說，正如你我
在OpenStack成立
以前所知道的，有些雲
項目並不允許你貢獻補丁。
如果我不能修補系統，
不能影響方向，
那麼它對我來說就像是閉源的
>> 對，對。
>> 所以不僅擁有提交補丁和影響
方向的能力，還能讓基金與任何
一家公司分離，這是很重要的。
我會說，在我考慮任何項目時，
不管項目和公司，我會優先選擇
基金中的而不是基金外的。
>> 當我們考慮OpenStack發生的情況
肯定有這樣一個觀念，就是私有雲、
公有雲依然重要，未來的混合雲

English: 
>> You also mention it's not just that it's
open source, but how is it open source and
how is it built that it's more and more a
factor.
And you see that across our whole customer
base.
Do you wanna elaborate on that a bit?
What is it about the community that's important
to you and to MasterCard?
Well, it's that it can be collaborative and
you can participate in the roadmap.
So if there are open source projects out there
that are really just code escrow, right?
I mean, as you and I both know from before
the days of OpenStack there were cloud projects
out there that didn't allow you to contribute
patches.
And if I can't fix patches, if I can influence
a direction then it's just like closed source
to me.
>> Right, right.
>> So having not only the ability to submit
by patches and influence direction, but a
foundation that is separate from any one company
is an important thing.
And I would say that if I'm looking at any

Russian: 
Что в Cloud Foundry
Foundation важно для тебя
и для MasterCard?
То, что оно даёт простор
для сотрудничества
и участия в составлении плана.
Знаешь, существуют, например,
условно-открытые проекты.
Стоит вспомнить хотя бы,
как всё было
до появления OpenStack,
тогда на облачные проекты
нельзя было ставить патчи.
А если я не могу править код,
регулировать ход работы,
то это всё равно
что закрытый код.
>> Точно.
>> Для меня важно не только
иметь возможность
вносить изменения
и контролировать процесс, но
также работать с организацией,
которая не зависит
ни от одной компании.
И при рассмотрении
потенциальных проектов

Chinese: 
所以如果真的有
开放源码项目，
那就真的只是
代码托管，对吗？
我是说，因为你和我
都从之前OpenStack的经验知道，
有云项目
不允许你
提供补丁。
然后如果我不能修复补丁，
如果我可以影响一个方向，
那么对于我来说，
它就像是封闭源码。
>> 对的，对的。
>> 所以不仅仅拥有
通过补丁提交和
影响方向的能力，
还有独立于任何一家公司的
基金会，
也非常重要。
然后我会说，
如果我在评判任何一个项目，
我会选择
属于基金会的项目，
不管是什么项目和什么公司。
>> 当我们在想，你知道吗，
究竟OpenStack发生了什么的时候，
私人云端和公共云端
这些概念
当然还是很重要，
这两个的混合版

Russian: 
я предпочту проект
в рамках Cloud Foundry Foundation
любому другому проекту
не важно, какой компании.
>> Если вспомнить о том,
что случилось с Open Stack,
станет ясно, что это
проблема общедоступного
и частного облака,
и их возможных гибридов,
скоро можно будет
работать с Azure Stack.
Также существуют проекты
для управления контейнерами,
такие как OCI,
Run C или kubernetes,
к которому Pivotal обращался
в работе над Kubo,
с Run C мы тоже работали.
Что ты думаешь,
насколько для тебя
важен вопрос гибридизации,
как ты работаешь
с общедоступным и частным
облаком?
Как распределяешь задачи?
Или важна сама возможность
выбрать один тип
и позже передумать?
Да, для нас важна
возможность выбора,
но нормативные требования
многое определяют
за нас.

English: 
project, that I'm going to go for the one
in the foundation before I go for one that's
not regardless of the project and the company.
>> When we think about you know, what happened
with open stack for sure was this notion of
hey private cloud, public cloud are still
important and what does hybrid look like in
the future and now we see >> Azure Stack on
the horizon and we see certainly on the container
side things like OCI, and Run C, and even
kubernetes which Pivotal has adopted with
Kubo and directly with Run C. Do you?
Are you thinking carefully about the kind
of hybrid story to what goes into public cloud,
what goes into private?
How do you mix those?
Or is it still a question of preserving optionality
and be able to move it later?
Well, so for us it's about preserving optionality.
But that's because regulatory requirements
going to drive that for us.
>> Right >> If I was at a different company,

Japanese: 
将来2つのハイブリッドについてどう考えますか？
>> 現在はAzure Stackがホライズンにあって
OCIやRun Cなど
コンテナサイドがあって
PivotalがKuboと適用して
Run Cに直結する
Kubernetesなどもあります
何かご意見ありますか？
ハイブリッドストーリーで
何をパブリッククラウドに置いて
何をプライベートに置いて
どうやってミックスするのか
どのように考えますか？
もしくは選択オプションセットして
まだ疑問があるものなのか？
今後進んでいくものなのか？
私たちにとっては
選択の一つとして
保留しているもので
理由のひとつは
ドライブ規定要件です
>> なるほど
>> ただもし規定要件を持たず
クラウドが一つの国にだけ存在する
別の企業にいたなら
個人的にはパブリッククラウドのみを
選択します
>> なるほど
Pivotalの顧客は
FORTUNE500の企業が
ほとんどなので
数社のみがハイブリッドを持ってます
ただその他のほとんどの企業も
ハイブリッドへの計画はしています

Chinese: 
會是什麼樣子，現在我們看到了
>> Azure Stack出現了
我們在容器方面
當然看到開放容器計畫（OCI）
和Run C等，甚至kubernetes，
Pivotal已經
通過Kubo採用，並直接使用Run C。
你是否...
有關混合雲，你有仔細考慮
什麼進入公有雲，什麼進入私有雲嗎？
你如何混合它們？
抑或它依然是一個保留選擇的問題，
可在稍後推進？
對我們來說，這是保留選擇。
但那是因為監管要求將為
我們推動它
>> 對
>> 如果我在另一家
公司，我沒有監管要求或
只能在一個國家，
我個人會僅僅選擇公有雲。
>> 對。
是的，我們看到
Pivotal只有少量客戶
因為我們基本上只跟
財富500強企業打交道。
他們大部分使用某種混合雲。

Chinese: 
在未来是怎样的？
>> 现在我们看到Azure Stack将要诞生，
当然我们还看
容器方面的东西，
比如OCI和runC，
甚至还有Pivotal与Kubo相适配、
直接和runC相适配的
Kubernetes。
你有没有？
你有没有仔细想过
混合方面的东西？
公共云端的什么可取？
私人云端的什么可取？
你怎么把两者混合起来？
或者仍然还是
一个保留可选性的问题，
可以留到以后研究呢？
嗯，对于我们来说
还是一个保留可选性的问题。
但是这是因为
规章要求在为我们
做决定。
>> 对
>> 如果我是在另外一家公司，
在那里我没有规章要求，
或者只能在一个国家的话，
个人来说，我会选择公共云端。
>> 对的。
嗯，我们只看到一小部分
Pivotal的客户，
还有就是因为我们一般都是
和世界500强打交道。
他们大部分都是既用公共云端
也用私人云端。

Korean: 
하이브리드는 미래에 있는 개념이었습니다
>> 수평에는 Azure Stack이 있고
컨테이너 측에는 분명 OCI와 Run C와
같은 것들이 있고
Kubo를 통해 채택했고
직접 Run C를 통해 채택했던
kubernetes도 있습니다
그래요?
어떤 것이 공용 클라우드로 가고
어떤 것이 사설 클라우드로 가는지에 대한
일종의 하이브리드 이야기에 대해
주의 깊게 생각하고 계세요?
그것들을 어떻게 혼합합니까?
아니면 그것이 여전히
유지용 옵션 가능성의 문제이고
나중에 옮길 수 있게 될까요?
글쎄요, 저희에게는
보존용 옵션 가능성입니다.
하지만 그것은 규제 요건으로 인해
우리에게 강요되기 때문입니다
>> 맞아요
>> 제가 규제 요건이 없는
다른 회사에 있거나
한 국가에만 있을 수 있다면
저는 개인적으로 그냥 공용을 택할 겁니다
>> 맞아요
저는 단지 적은 수의 Pivotal의
고객들만 보는데
다시 말씀드리자면 우리가 기본적으로
포춘 500 기업과만 거래를 하기 때문입니다
그것들 대부분은
일종의 하이브리드 이야기가 있습니다

Chinese: 
>> 那谬论呢？
我觉得20年前，
30年前的时候，
开放源码是很简单的，
因为内容不多，
但是现在内容太多了，
每个人都变得迷惑，
现在又不光如此了，
人们相信
有简单的样式。
他们相信，
所以会不会出现这样的情况？
你说，嗯，有一个供应商过来找我，
说了X，然后他们认为，
这个东西非常重要，
是一个我真的不在乎的东西。
>> 嗯，我会说，
我们有很多传过来的
假消息。
>> 关于虚假新闻，
#虚假新闻和开放源码？
>> 嗯，有一些
来源于开放源码供应商，
是关于其他供应商的，
但是我不想把供应商掺和进来。
>> 当然。
>> 但是，嗯。
确实有一些这样的虚假消息，然后我，
你知道吗，
我很努力去确保
我们远离信息。
确保我们不会
陷入这些谬论。
>> 对的，对的，
这很有趣。

Korean: 
>> 신화는 없나요?
저는 20년 전 또는 30년 전에는
진행되는 내용이 적었기 때문에
오픈 소스가 간단했다고 생각하는데
지금은 그 지점을 넘어
너무도 많은 것이 진행되어
모두가 혼란을 겪고 있고
이제는 심지어 그 선을 넘어
사람들은 간단한 패턴이 있다고
믿습니다
사람들은 어떤 벤더가 와서
X라고 말했는데,
그들은 그것이 정말로 중요했다고
생각했지만
나는 사실 신경 쓰지 않는 것이라고
말하는 경우가 있다고 믿습니다
>> 예, 그런 잘못된 정보를
얻는 경우가 많습니다
>> 허위 뉴스라는 측면에서,
#fakenews와 오픈 소스는 어떻습니까?
>> 예, 그 중 일부는 다른 벤더에 대해
오픈 소스 벤더로부터 나오는데,
벤더들을 호명하고 싶지는 않습니다
>> 물론입니다
>> 하지만, 정말 많이 있었고
아시다시피
저는 외부 정보를 얻는 것을 보장하기 위해
열심히 노력했습니다
우리가 그러한 잘못된 신화에
빠지지 않도록 하는 것입니다
>> 맞아요, 맞아요, 흥미롭네요

Chinese: 
>> 繆見方面如何？
我感覺20年前、
30年前開源很簡單，
因為當時沒幾個項目，
如今則太多項目了，大家都
感到困惑，現在更進一步了，
人們相信有更簡單的模式。
他們相信，因此你是否遇到過這種情況，
供應商找到你並說某樣東西，
他們認為這是非常
重要的，但你其實並不很關心。
>> 是的，我會說我們
接收過很多錯誤資訊。
>> 說到虛假消息，#fakenews 和開源？
>> 是的，其中一些來自開源供應商，
是關於另一家供應商的，
我不想說出供應商的名字。
>> 當然。
>> 但，是的。 頗有一些，而我，
你知道，
我努力確保我們得到外部消息。
確保我們不會誤信哪些傳說。
>> 對，對，那很有意思。

Russian: 
>> Ясно.
>> Будь это
другая компания -
без нормативных требований и
работающая
в одной стране, лично я бы отдал
предпочтение
общественному облаку.
>> Понятно.
Не всегда удаётся пообщаться
напрямую с клиентами Pivotal,
так как это, в основном,
крупнейшие мировые компании.
Большинство из них совмещает
работу с разными типами облака.
>> Поговорим о заблуждениях.
Открытое программное
обеспечение 20-30 лет назад
было гораздо проще
для освоения и понимания,
потому что активность там
была гораздо ниже, чем сейчас,
а сегодня в этой сфере
происходит столько всего,
но людям кажется,
что всё устроено очень просто.
Скажи, с тобой случалось такое,
что поставщик говорил тебе:
«Нам необходимо что-то»,
а на деле это оказывалось
совершенно бесполезным?
>> Да, приходится иметь дело
с большим количеством
недостоверной информации.

Japanese: 
>> 作り話ついてはどうですか？
20～30年前のオープンソースは
とてもシンプルで
今ほど内容も濃くなかったのが
今やあらゆることが
行われています
みんな困惑し
それ以上に
シンプルなパターンがあると
信じています
ベンダーがやってきて何々と言って
彼らはそれをとても重要だと
思っていたけれど
大して重要なことではなかった
そんなケースはありますか？
>> そうですね間違った情報が
届くことはたくさんあります
>> オープンソースでの
#fakenewsみたいなものですか
>> そうです それは時に
オープンソースベンダーから来ます
そこでベンダーに
連絡を取りたくありませんが
>> そうですね
>> そういったものはたくさん
あります
情報の外側を把握するのに努力して
ある種のデマに落ちて
はまらないようにしています
>> 興味深いですね

English: 
where I didn't have regulatory requirements
or could only be in one country, I would just
chose public, personally.
>> Right.
Yeah, we see only a small number of Pivotal's
customers and because we again deal basically
with the Fortune 500.
Most of them have some kind of hybrid story
>> What about myths?
I feel like open source 20 years ago, 30 years
ago was simple because there was so little
going on and now it's beyond the point of
so much going on that everyone is confused
and now it's even more than that and people
believe there are simple patterns.
They believe, so are there cases where you
say well I had a vendor come to me and say
X and they thought it was really important
and it's not a thing I really care about.
>> Yeah I would say that we have a lot of
misinformation that comes.
>> In terms of fake news, #fakenews and open

Chinese: 
我觉得在开放源码
最容易看清楚
工作时候的个性，
还有看到社区文化
在早期贡献者之间
是怎样形成的。
所以，在你的观点看来，
它就仅仅是代码托管。
就是你的源代码
怎样变成公共的，
但是不是变成支持协作的。
它并不是真的帮助到任何人。
然后，你知道吗，
其他我看到的虚假新闻，
或者我觉得我想要问的问题是，
标准呢？
你知道？
因为过去所有的东西
都是关于标准化组织，
RFC（请求评议），还有DMTF（分布式管理任务组），
还有DMTF（分布式管理任务组）等等，
现在看起来，
好像社区共识
就是标准。
>> 嗯，市场似乎
定义了标准，
而不是追寻标准。
所以，我很相信它。
关于标准化组织，
尤其是在很多
你可能注意到，
但是很多大型供应商
涉足标准化组织，
就是要让它们
放慢[笑声]。

Korean: 
오픈 소스에서는
직장에서의 개성을 보고
초기 기여자 주변 커뮤니티가 구성하는
문화의 방식을 보는 것이
정말 쉽다고 생각합니다
따라서 그 개념은 당신의 요점에 대해서
단순한 코드 에스크로인 것처럼 보입니다
그것은 소스 코드에 대해
공개적이 되는 방식이지
협업적이 되는 방법이 아닙니다
그것은 실제로 아무에게도 도움을 주지 않습니다
저는 또 다른 허위 뉴스를 보는데
표준이라는 게 무엇인가 하는
의문이 듭니다
아세요?
모든 것이 표준화 기구,
즉, RFC와 DMTF 등에 대한 것이었지만
이제는 커뮤니티 동의가
표준인 것처럼 보입니다
>> 예, 좇아가는 대신
시장이 일종의 표준을 규정합니다
저는 확고하게 그렇게 믿습니다
표준화 기구들
특히 많은 것들이 있지만
대규모 벤더들 다수가
표준 제정을 늦추기 위해
표준 기구에 참여합니다[웃음]

Japanese: 
オープンソースにて
パーソナリティや
初期のコントリビューターによってできた
コミュニティのカルチャーを
見るのは最も簡単なことです
だからこそあなたの考え方は
コードエスクローのようなものです
ソースコードの公開というだけで
誰かとコラボレーションというわけではなく
誰の役にも立たない
私が見た他の嘘のニュースとしては
スタンダードとは何ですか？
かつてはRFCやDMTFなどの
スタンダードがありました
でも現在はコミュニティでの総意が
スタンダードになっています
>> それを追い回すよりも
マーケットがスタンダードを
定義しています
私もそう思います
お気づきかもしれませんが
大規模ベンダーの多くは
スタンダードな組織に関与して
スローダウンさせています [笑]

Russian: 
>> Смотри новости открытого ПО
под хештегом #fakenews.
>> Иногда один поставщик услуг
в области отрытого ПО
пытается так очернить другого.
Не буду называть имён.
>> Конечно.
>> Но ложной информации много,
это так.
Поэтому я стараюсь
обеспечить нам
доступ к надёжным источникам,
чтобы подобные вещи
не сбивали нас с толку.
>> Понятно. Очень интересно.
В Open source проще следить за
работой конкретных людей
и наблюдать, какое сильное
влияние на культуру сообщества
оказывают те, кто начали
работу над проектом.
И тот псевдооткрытый код,
который ты упоминал -
это способ показать всем
свой исходный код,
но не способ сотрудничества.
Это никому не идёт на пользу.
Другой вопрос, связанный
с неточной информацией,
касается стандартов.
Какого ты о них мнения?
Раньше всё подчинялось

Chinese: 
我想在開源領域最容易看到人性
暴露，看到社區的文化
在初期貢獻者周圍形成。
這對應你說過的，純代碼託管。
它只是一種公佈原始程式碼的方式，
但並非協作性的。
那種方式對任何人都無濟於事。
你知道，我看到的另一個假消息是，
或者我的問題是，怎麼看待標準？
你知道？ 因為以往一切
都要標準組織參與，例如RFC，DMTF
或其他什麼，但現在似乎是
社區的共識在哪裡，那裡就是標準。
>> 是的，市場會定義標準，
而不是追逐它。
所以我堅信一點，
就是標準組織
尤其是在，有很多，
你可能已經注意到，
但很多大供應商參與標準
組織只是為了拖慢它們[笑]。

English: 
source?
>> Yeah and some of it comes from open source
vendor about another, and I don't want to
call out vendors.
>> Sure.
>> But yeah.
There's been quite a bit and I, you know,
I've worked hard to make sure that we get
outside information.
Make sure that we don't fall for those sorts
of myths.
>> Right, right, that's interesting.
I I think it's easiest in open source to see
the personalities at work, and to see the
way the sort of culture of the community forms
around the early contributors.
So that notion to your point of like if it's
just code escrow.
It's just a way to be public about your source
code but not be collaborative.
It doesn't really help anyone.
the, you know, the other fake news thing I
see, or I guess the question I would have
is, what about standards?
You know?
Because it used to be everything was about
the standards body, the RFCs and the DMTF
and the Whatever but now it seems like where

English: 
the community consensus is is the standard.
>> Yeah, the market sort of defines the standard,
and rather than chasing it.
So I firmly believe that.
That the standard bodies, especially in there
a many you've probably noticed, but many of
the large vendors are involved in standard
organizations just to slow them down [LAUGH].
>> [LAUGH] Yeah.
>> So they tend to lag, while people try to
get their products, the companies try to get
their products right.
So, whatever is out there works.
>> Right.
>> Ends up becoming the standard.
>> Right >> Just, let me take this one step
even weirder, right?
So, you're saying, look, we work with the
open source community because we can collaborate,
we can influence the roadmap.
We know that, over time, it's going to be
more and more exactly what we need.
And then, you think about, okay, also we're
working in a >> Competitive world where we
have other companies that want to get close
to us in our market.
And I think in particular in the Fintech startup
space.

Chinese: 
>> [笑] 是的。
>> 他們傾向於滯後，當人們嘗試獲得
產品時，公司會嘗試做好產品。
所以，外面的任何東西都是可用的。
>> 對。
>> 最終成為標準。
>> 對
>> 讓我更進一步，好嗎？
你在說，看，我們和開源社區合作，
因為我們能協作，
我們能影響路線圖。
我們知道，久而久之，
它將變得越來越
和我們需要的一致。
然後你會想，好的，
我們也在一個競爭的世界中工作，
有其他公司也想在我們的市場中
接近我們。
我想，尤其是在Fintech初創空間中。
現在你萬事達卡公司內部做決定時，
會不會說
嗨，這些事情我們將在開源中做。
這些事情我們將繼續自己做。
因為我們認為它們是競爭優勢
或者目標是否總是快於執行，更快前進？
還有優先開源是不是政策？
>> 我不知道優先開源是不是政策。

Chinese: 
>> [笑声] 嗯。
>> 所以他们往往会落后，
当人们想要得到他们的产品，
公司只想把产品
弄得恰到好处。
所以，不管有什么，都是可行的。
>> 对的。
>> 自然就成为
标准了。
>> 对的。
>> 就是，
让我来谈谈这个情况更加神秘的一点，
可以吗？
所以，你说，看，
我们和开放源码社区合作，
因为我们可以协作，
我们可以影响路线图。
我们知道，随着时间推移，
就越来越靠近
我们真正想要的了。
然后，你想，好的，
我们工作在一个
>> 竞争激烈的世界，
在这个世界里，
有其他公司
想要来抢夺我们的市场。
然后我想尤其是
在金融科技初创空间。
现在，在万事达信用卡公司
做决定的时候，你们会不会说
喂，这些东西
我们要公开地去做，
这些东西
我们自己知道就好。
因为我们认为它们是
有竞争力的区分点，
或者是总是要超越、突破的目标？
以及，是不是以开放
为第一要务呢？
>> 我不知道开放
是不是第一要务。

Korean: 
>> [웃음] 예
>> 따라서 사람들이
제품을 구입하려고 노력하는 동안
그들이 늦어지는 경향이 있을 때
회사들은 자신의 제품을 고치려고 합니다
따라서 무엇이 잘못되었든
거기에서는 동작합니다
>> 맞아요
>> 표준이 되는 것을 끝냅니다
>> 맞아요
>> 단지
이것을 약간 비뚤어진 방식으로
보게 해주세요, 괜찮나요?
그러니까, 다음과 같이 말하는 셈입니다.
우리는 오픈 소스 커뮤니티와 협력합니다
우리는 협업할 수 있기 때문에
로드맵에 영향을 미칠 수 있습니다
우리는 오랜 시간을 통해 그것을 알고,
그것은 우리가 필요로 하는 것과
점점 더 정확히 같아져 갑니다
그런 다음, 여러분은 다음과 같이 생각합니다
또 우리는...
>> 경쟁적인 세상이라서
시장에는 우리에게 근접하고자 하는
다른 회사들이 있습니다
그리고 저는 특히
Fintech 창업 공간에 대해 생각합니다
당신은 MasterCard 내부에서
이제 이런 것을 오픈으로 하려고 하고,
그리고 이런 것들은 있는 그대로
유지하려고 한다는 결정을 합니까?
우리는 그것들이
경쟁 차별화 요소라고 생각하거나
아니면 그것이 과다 실행하고,
빨리 실행하는 것이 됩니까?
그리고 정책 상 오픈이 우선입니까?
>> 저는 그것이 오픈 우선 정책인지는
모릅니다

Russian: 
определённым стандартам,
как RFC или DMTF и прочие,
но сейчас, похоже,
стандарты задаются
самим сообществом.
>> Да, можно сказать,
рынок сам задаёт стандарты,
а не пытается им следовать.
Так что ты абсолютно прав.
Может, ты и сам замечал,
что всякие органы
по установлению стандартов,
особенно если их много, -
большие компании используют их,
чтобы потянуть время.
[СМЕХ].
>> [СМЕХ] Ясно.
>> Они часто работают
очень медленно,
и у компаний появляется время,
чтобы доделать свой продукт.
Так это и работает.
>> Вот оно что.
>> Так появляется стандарт.
>> Ясно.
>> Позволь задать тебе
ещё один странный вопрос.
Ты говорил, работая с открытым
программным обеспечением,
можно строить планы
и создавать что-то вместе.
Понятно, что чем дальше,
тем важнее будет этот аспект.
Но с другой стороны,
мы живём в мире
постоянной конкуренции,
и другие компании
были бы не прочь

Japanese: 
>> [笑] そうですね
>> 製品を正しくつくる一方
速度を落とす傾向がある
それに合ってうまくいくものが
>> そうですね
>> スタンダードとなる
>> そうですね
>> では
少し話がおかしな方向に
いくかもしれないんですけれど
オープンソースコミュニティで
作業して
コラボレーションして
ロードマップに影響を与えていて
これで全て行くと私たちが本当に
必要とするものが出来上がる
するとその時
競争のある世界に
気づくでしょう
例えばマーケットで
フィンテックのような新興企業で
私たちに歩み寄りたい企業があります
MasterCardの中で
これはオープンソースで展開をして
これは独自に競合他社との違いと
なるのでキープしようなど
決定権をもっていますか？
もしくはもゴールは
常に素早く展開をするという
展開第一ポリシーが
あるのでしょうか？
>> ポリシーとして
展開第一であるかはわかりません

Russian: 
потеснить нас на рынке.
Особенно развивающиеся в
отрасли финансовых технологий.
И в MasterCard вы, возможно,
принимаете решения так:
тут мы работаем открыто,
а вот это мы показывать
никому не будем,
это наше конкурентное
преимущество.
Или цель, наоборот, показать,
что вы первые?
Это часть политики компании?
>> Не знаю, насколько это часть
политики компании.
Но зачем кому-то в отрасли
ещё это делать, если не ради
конкурентного преимущества?
По нашим сетям курирует
огромное число данных,
так что мы сохраняем открытость,
когда она нужна,
а когда не нужна, -
ну, значит, тогда не нужна.
>> Ясно.
>> [СМЕХ]
>> Когда Сэм Рэмджи
возглавлял Cloud Foundry
Foundation, он говорил,

English: 
Do you make decisions inside MasterCard now
on hey these things we are going to do in
the open.
And these things we are going to just keep
to ourselves.
Because we think they are a competitive differentiator
or is the goal always to out execute, go faster?
And is it open first as a policy?
>> I don't know if it's open first as a policy.
I mean, I think that there are reasons in
our industry to not do that separate from
competition.
That there's a huge volume of finance information
that flows across our network >> So I think
we are open when it's best and not open when
it's best.
>> Right >> [LAUGH] >> Yeah, Sam Ramgy, when
he was running the Club Foundry Foundation
was famous for having coined this idea of
Club Foundry as a place of practice.
And I think he was taking in certain terms
of sort of a Buddhist framing of practice

Japanese: 
競合他社とかけ離れないような
理由が業界の中にあるはずです
高いボリュームの金融の情報が
ネットワークを全体を流れるように
>> オープンが良いとだと考えられる時は
オープンで
オープンでない方が良いと考えられる時は
オープンでないと思います
>> なるほど
>> [笑]
>> サム・ラムジーが
Cloud Foundry Foundationにいた時
Cloud Foundryはアイディアを実行する
安全な場所として有名でした
背景に仏教的な考え方があったかと
思うんですけれども
ホールマークとして
健全なオープンソース
コミュニティとして
私も計画的なイテレーションの
アイディアを好みます
本当の意味で健全な
オープンソースコミュニティがすることは
使う準備ができるのはいつか
いつまで実験段階なのかを
定義することです
私たちがCloud Foundryコミュニティで

Korean: 
제 말은 우리 업계에는
경쟁업체들과 다르게 하지 않는
이유들이 있습니다
네트워크를 통틀어 방대한 양의
금융 정보들이 흐르고 있습니다
>> 따라서 저는 그것이 최선일 때 오픈으로 가고
그것이 최선일 때 오픈으로 안 갑니다
>> 맞아요
>> [예]
>> 예, Sam Ramgy이
Club Foundry 재단을 운영하고 있을 때
그가 Club Foundry라는 아이디어를
실천의 장소로서 만든 것으로 유명했습니다
그리고 저는 그가 특정 면에서
불교의 실천 틀을
취하고 있다고 생각하지만
저는 건강한 오픈 소스
커뮤니티에 대한 일종의 각인으로서
숙고적인 반복이라는
아이디어를 좋아합니다
하지만 진정으로 건강한 커뮤니티가
잘하는 어떤 것은
언제 그것이 사용 준비가 되는지지와
여전히 실험 중인지를
규정하는 것입니다
그리고 추측건데, 우리가
Cloud Foundry 안에서

Chinese: 
我是說，我認為我們行業中，除了競爭
還有很多原因不那樣做。
我們的網路中有巨量
金融資訊流動
>> 因此我想我們在最適合時
使用開源，最適合時不使用開源。
>> 對
>> [笑]
>> 是的， Sam Ramgy,當他
經營Cloud Foundry時，他因為
構思了Club Foundry
作為練習的地方而出名。
我認為他是領會了某種
佛教的修煉構思，但
我真的喜歡深思熟慮的反覆運算的想法
作為一個健康開源社區的標記。
但一個真正健康社區做得好的事情是
定義它什麼時候可供使用和
什麼時候仍是試驗性的。
我估計，對於Cloud Foundry社區有一件事

Chinese: 
我是说，我觉得在我们行内
有不这样做来脱颖而出的
原因。
其一就是
在我们的网络中
流动着大量的金融信息，
>> 所以我觉得开放是最好的话就开放，
不开放是最好的话
就不开放。
>> 对对
>> [笑声]
>> 嗯，Sam Ramgy，当他在运作
Cloud Foundry基金会的时候，
因为提出Cloud Foundry基金会
是实践的地方这个想法
而出名。
然后我想他采用的
是某种
佛教实践框架，
但是
我真的很喜欢
刻意迭代这个概念，
可以作为健康开放源码社区的
一种标志。
但是一个真正健康的社区
做得好的地方是
定义什么时候可以投入使用，
什么时候还处于试验阶段。
然后，我觉得，
在Cloud Foundry社区，

English: 
but I actually like the idea of deliberate
iteration as kind of the hallmark of a healthy
open source community.
But something that a really healthy community
does well is to define when is it ready for
use and when is it still experimental.
And I guess, something we've been trying to
be very deliberate about in the Cloud Foundry
community is say, hey, every subproject releases
whenever they want which is sometimes every
day, sometimes every week, but Cloud Foundry,
Pivotal Cloud Foundry overall is released
every quarter on a steady cadence and then
once a month there's a dot release.
We're trying to find that sweet spot between
the rapid agile delivery of an open source
community and what any big enterprise can
rationally consume.
Right, because CD is amazing.
You don't want to CD everything every day,
right.
I don't want to go up to the terminal, point
of sale terminal with my MasterCard and go
to pay a bill.
And have all the buttons in a different place
every day.
I'd be like, how do I tip?
I guess the tip options today are in Greek

Chinese: 
我们尝试刻意去做的是，
嘿，每一个子项目可以
在任何时候发布，
有时候是每天，
有时候是每周，
但是Cloud Foundry，
Pivotal Cloud Foundry整体来看，
是按照稳定的节奏每个季度进行发布，
然后一次一个月，逐渐频繁。
我们努力寻找
开放源码社区的快速、敏捷交付
和大公司的合理消费之间的
平衡点。
对的，因为编码很神奇。
你不需要每天
给任何东西都编码，对的。
我不希望
走到那个终点，
和我的万事达信用卡走到那个销售终点，
然后支付账单。
然后每一天
所有的按钮在不同的位置。
我会更喜欢，我怎样给小费？
我猜现在
给小费的选项有
希腊数字或者其他。
>> [笑声]
>> 你在哪里可以掌控到那个平衡点，
要走快点，走慢点，
还是走快点同时保证安全？
>> 所以我觉得这取决于
你在堆栈中的位置。
我喜欢思考事情的
方式是

Chinese: 
我們一直嘗試做好的，就是
嗨，每個子項目隨時發佈更新
有時每天，有時每週，
但Cloud Foundry,
Pivotal Cloud Foundry
總體而言以穩定的節奏
每個季度發佈，然後每月一個小更新。
我們嘗試在開源社區的快速敏捷交付
和大企業可合理消化的程度之間
找到那個理想點。
對，CD是很棒的。
但你不會每天都聽CD的，對吧。
當我拿著我的萬事達卡
去到一台銷售終端前付款時，
我不想看到所有按鈕
每天都在不同的地方。
我會說，我該怎樣付小費？
我估計現在的消費選擇是用
希臘數字或某種東西。
>> [笑]
>> 你認為在快速前進，
緩慢前進與安全地快速
前進之間的理想點在哪？
>> 我估計這取決於你在堆疊的哪個位置。
我的想法是

Korean: 
매우 숙고적이 되기 위해
노력했던 어떤 것은
모든 하위 프로젝트들이
그들이 원할 때마다
때때로 매일, 때때로 매주 배포되지만,
Cloud Foundry, 즉
전반적인 Pivotal Cloud Foundry는
정기적인 속도로 매 분기별로 배포되고
점이 들어가는 배포는 한 달에 한 번
하기로 한 것이었습니다
우리는 오픈 소스 커뮤니티에 대한
신속하고 민첩한 제공과
어떤 대기업이
합리적으로 소비할 수 있는 것
사이의 달콤한 지점을 찾기 위해
노력하고 있습니다
Right, because CD is amazing.
여러분은 날마다 CD로 굽고 싶지 않습니다
저는 MasterCard를 가지고
판매 시점 터미널에 가서
요금을 결제하고 싶지 않습니다
그리고 날마다 서로 다른 장소에
버튼들이 있는 것을 원하지 않습니다
어떻게 팁을 얻을 수 있을까요?
제 추측으로는
오늘날 팁 옵션이 그리스
숫자 또는 어떤 것으로 되어 있습니다
>> [웃음]
>> 빨리 진행하느냐와 느리게 진행하느냐,
아니면 빠르면서도 안전하게 사이의
그 달콤한 지점을 어디에서 보게 될까요?
>> 저는 여러분이 스택의 어디에
있는가에 달려 있다고 생각합니다
일들에 대해 제가 생각하고 싶은 방식은

Japanese: 
故意的にしようとしていたことは
全てのサブプロジェクトを
希望通りにリリースすること
ある時は毎日　ある時は毎週
ただPivotal cloud foundryは結局
毎四半期に一定の間隔で
リリースをしたり
毎月ポイントリースする時も
ありました
オープンソースコミュニティの
高速でアジャイルなデリバリと
大企業でも合理的に
消費できる間隔の
スイートスポットを
見つけようとしているんです
CD（継続的デプロイ）は
素晴らしいと思うけど
すべてを毎日CDしたいとは
思いませんよね
MasterCardを持って
POSターミナルに行って請求額を支払う時
ボタンが毎日違う場所にある
なんてことはしたくないです
どうやってチップを足すんだっけ？
あー今日のチップオプションは
ギリシャ数字か
みたいになってしまいます
>> [笑]
>> 高速デプロイ　低速デプロイ
高速だけれど安全なデプロイ
スイートスポットをどう見つけてますか？
>> それはたぶんスタック中の
どこにいるかにもよるかと思います
私が好きな考え方は

Russian: 
что работа в его компании -
возможность попрактиковаться.
Возможно, он имел
в виду практику
с буддистской точки зрения,
Мне нравится мысль,
что намеренное повторение -
это признак здорового
open source сообщества.
Но главная задача
такого сообщества -
это понимать,
когда продукт уже готов,
а когда ещё нужна доработка.
И мы в Cloud Foundry
соблюдаем чёткий график.
Релизы подпроектов
происходят тогда,
когда команда сама пожелает, -
иногда каждый день,
каждую неделю, но основные
проекты Pivotal в Cloud Foundry
выпускаются каждый
квартал чётко и регулярно,
проекты поменьше
выходят ежемесячно.
Мы стремимся
найти баланс между
высокой скоростью работы
open source сообщества
и потребностью в продуктах
у больших компаний.
С одной стороны, постоянное
движение вперёд - это хорошо.
Но не стоит
всё обновлять каждый день.
Если я, например,
оплачиваю счета

Chinese: 
你很快地发布
各个版本。
服务和
然后你让你的客户决定
什么时候接受它们。
>> 对的。
>> 所以
这就是我对事情的看法，
也希望所有东西都可行。
>> 所以你刚刚说的
意思是
核心想法是你有了客户，
然后内部服务有了客户，
因此你有了你的产品。
每一项服务都是一个产品。
产品得到广泛的应用的话，
就可以成为
供应商。
然后你有了你的
最终终端用户和客户。
你觉不觉得产品管理思维
实际上很普遍呢？
因为我想在数字化改造过程中
我们所看到的是
去教企业是最难的部分。
是要有一种产品思维，
然后说，我想，这是一个产品，
不仅仅是内部服务。
这是真实世界的东西。
你怎样促进这件事情，
还是说你就雇用了很多人？
>> 嗯，
你知道有一些是来自于，
文化来自于顶部。
所以我想，在万事达信用卡公司，
我们促进了这样一种文化，
然后这就是我们
怎样看待事情。

English: 
numerals or something.
>> [LAUGH] >> Where do you see that sweet
spot between like go fast, and go slow, or
go fast and be safe?
>> So I guess it depends on where you are
in the stack.
The way I like to think of things is you release
quickly with version.
Services and then you let your customers decide
when they accept them.
>> Right.
>> So that's kind of my view of things and
hopefully everything works.
>> So that what you just said there is that
this key idea is that you have customers,
that the internal service has customers therefore
you have your product.
Each service is a product.
The larger application of the product that
has those as vendors.
And then you have your eventual end user customers.
Do you think product management thinking is
actually common yet?
Because I guess what we see in digital transformation
is that it's the hardest thing to go teach
companies.
It's to have a product mindset and say I guess
this is a Product, not just an internal service.

Russian: 
своей MasterCard
на платёжном терминале,
а кнопки на нём меняют
расположение каждый день,
то что это вообще такое?
Для меня это
всё равно что читать
на китайском.
>> [СМЕХ] >> Где же находится
золотая середина
между изменениями? Как расти
быстро, но безопасно?
>> Зависит от того, с какой
стороны смотришь на проблему.
Мне нравится подход,
когда ты быстро разрабатываешь
новые версии
своих продуктов,
а клиент уже решает,
когда он готов их принять.
>> Ясно.
>> Это мой взгляд, но, думаю,
это должно быть эффективно.
>> То есть ты хочешь сказать,
что у тебя есть клиенты, есть
спрос на внутренние продукты,
поэтому у тебя есть
продукты на продажу.
Любой продукт - это товар.
Продукт широко
используется поставщиками,
при этом
есть и клиенты,
его конечные потребители.
Уделено ли внимание
управлению производством?
В наше время расширения
цифровой сферы

Korean: 
버전을 통해 신속하게
배포하는 것입니다
서비스를 제공한 다음
고객들이 언제 그것들을 채택할 것인지를
선택하게 하십시오
>> 맞아요
>> 따라서
그것은 일에 대한 저의 견해이고
바라건데 모든 것이 동작합니다
>> 그러니까 당신이 방금 말씀하신 내용의
핵심 아이디어는 고객을 가지고 있고,
내부 서비스 고객이 있고
그 다음에 제품을 갖는 것입니다
각 서비스가 제품입니다
그것들을 공급업체로서 가지고 있는
제품의 더 큰 응용입니다
그런 다음 여러분은 궁극적인
최종 사용자 고객을 갖습니다
제품 관리 사고가 실제로
이미 공통이라고 생각하세요?
우리가 디지털 변환에서 보는 것은
회사들을 교육하는 것이 가장 어려운
일이라고 추측합니다
그것은 제품 마음 자세를 갖는 것인데
말하자면 그것을 내부 서비스가 아니라
하나의 제품으로 간주합니다
그것은 실제 세상에서 벌어지는 일입니다
그것을 어떻게 촉진하고 있습니까?
아니면 그냥 사람만 많이 고용하고 있습니까?
>> 글쎄요, 여러분은 그 일부가
즉, 문화가 최상위에서 나온다는 것을
알고 있습니다
따라서 저는 MasterCard가
그런 종류의 문화를 조성하였고
그것이 바로 우리가 사물을 보는
방식입니다

Chinese: 
快速發佈版本。
服務，
然後讓你的客戶決定他們何時接受。
>> 對。 >> 所以，
那是我對事情的看法，希望一切順利。
>> 你剛才所說的是有這個
關鍵想法，即你有客戶，內部
服務有客戶，因此你有你的產品。
每個服務就是一個產品。
產品的更大應用有作為
供應商的那些客戶。
然後你有你最終的終端客戶。
你是否認為產品管理
思維實際上已普及了？
因為我想我們在數字轉化中看到
的情況是，最難的
事情是去教那些公司。
它需要一個產品心態，
就是說，我想這是一個產品，
而不僅是一個內部服務。
這是現實世界的東西。
你如何培養這一點，
還是你雇用很多人？
>> 你知道，一部分來自...
文化來自上層。
我想我們，在萬事達卡公司，
已經培育了那種文化，
那是我們看待事情的方式。

Japanese: 
バージョンサービスを含めて
迅速にリリースをして
顧客がそれを承認した時
顧客に選択させる
>> なるほど
>> 私は
そういう風に考えています
そうやってうまく動いていけばいいと思います
>> キーアイディアには顧客がいて
内部のサービスに顧客がいて
そこにあなたの製品がある
それぞれのサービスが製品で
製品にはベンダーを持つ
大規模アプリケーションがあって
最終的なエンドユーザーである顧客がいる
製品管理は一般的に
なってきていると思いますか？
デジタル改革の中で
一番難しいポイントは
企業を教育するという点だと思います
製品のマインドセットが
既にあって
それが製品となるが
ただ内部サービスではない
どうやってそれを育てていきますか？
多くの人材を雇うのでしょうか？
>> それは
トップの文化から
くるものでしょう
私たちはMasterCardで
文化の育成をしました

Korean: 
우리가 구축하는 내부 서비스에서
그것은 하나의 제품이 되고
우리는 사용자들을
고객들로 대우하게 됩니다
>> 맞아요
>> 마땅히 그래야 하는 것처럼요
>> 맞아요, 맞아요
공용 클라우드 환경에서는
맞습니다
제 말은 합리적으로
여러분이 소규모 창업 기업인 경우
여러분은 아마도 모두
공용 클라우드로 갈 것입니다
단일 벤더로 가거나
여전히 여러 벤더를 찾아 보실 계획인가요?
이것에 대해서는 어떻게 생각하세요?
>> 그러니까 그것은
내가 어디에 있어야 하는가에 따라 다릅니다
여러분이 Netflix와 같은 누군가를 보면
그 단일 벤더가 그들에게 효과가 있습니다
저는 여러분이 누구인가에 관계 없이
모든 공용 클라우드 제공업체들의 회복력이
여러분의 현재  회복력보다
더 낫다고 생각합니다
>> [웃음]
>> [웃음] 따라서
모든 정신적 고뇌는
사실 가짜입니다
>> 맞아요
>> 제 말은 그들이 이미
여러분보다 낫다는 것입니다
>> 맞아요
>> 따라서
>> 따라서 여러분은 단 하나만 선택하여
하나로만 갈 수 있습니다
>> 예
>> 이제 그것들은 모두 한 자리에
있지 않습니다
하나에 대한 서비스에 대해
한때 여러분이 작성하곤 했던
몇 가지 간단한 것이 있습니다
>> 음
>> 그러니까 제가
미국에만 있을 필요가 있는 경우죠
>> 맞아요
>> 저는 하나의 클라우드 제공업체와만
함께 할 것입니다

Russian: 
именно это становится камнем
преткновения для компаний.
Важно это понимать
и видеть во внутреннем
продукте товар.
Это нечто реальное.
Как ты учишь этому сотрудников?
Просто набираешь их побольше?
>> Корпоративная культура
начинается с верха.
Думаю, нам в MasterCard удалось
выработать культуру
и правильный взгляд на вещи.
Любой внутренний продукт,
который мы создаём - это товар,
а его пользователи -
наши клиенты.
>> Ясно.
>> Вот так.
>> Хорошо.
Возвращаясь к теме
общественного облака.
Если бы вы были небольшой
начинающей компанией,
ты бы предпочёл работать с ним.
У вас был бы один поставщик
или, как сейчас, несколько,
что скажешь?
>> Зависит от того,
где бы мы находились.
Можно вспомнить, к примеру,
Netflix, у них
отдельные поставщики.
Кем бы вы ни были, я уверен,
что любая организация,
работающая
с общественным облаком,
окажется более гибкой.
>> [СМЕХ]
>> [СМЕХ]
И для всех этих
метаний нет причин.
>> Ясно.
>> То есть, тут они
в любом случае впереди.
>> Ладно.
>> Итак,
>> выбираешь одного поставщика
и работаешь с ним.

English: 
It's the real world thing.
How do you foster that or are you just hiring
a lot of people?
>> Well, you know some of it comes from, culture
comes from the top.
So I think we, at MasterCard, have fostered
that kind of culture and that's how we look
at things.
The, in the internal service we build, it's
It's gonna be a product and we're gonna treat
the users like customers.
>> Right.
>> Like we should.
>> Right, yeah.
On the public cloud landscape, right, you
mentioned, I mean, rationally, if you were
a small startup you'd probably just go all
in on public cloud.
Would you go all in on a single vendor, or
would you still look for multiple vendors,
and how do you think about?
>> So it depends, it depends on where I need
to be.
If you look at someone like.
Netflix, that single vendors work for them.
I think that no matter who you are, I think
I can guarantee the resiliency of any public
cloud provider is better than your resiliency
now.
>> [LAUGH] >> [LAUGH] So all of the mental
anguish, it's really just fake.
>> Right.

Chinese: 
我们所设计的内部服务
要变成一种产品，
然后我们会把用户
当作客户去对待。
>> 对的。
>> 我们早就应该。
>> 嗯，对的。
在公共云层面，
对的，你提到，
我的意思是，理性上，
如果你是一家小型初创公司，
你可能只需要把全部东西
都放在公共云端上。
你会把全部东西
都交给一个供应商吗？
还是说你还是
会找多个供应商？
然后你是怎么想的？
>> 看情况，
看我需要什么。
如果你是像Netflix的情况，
那么，一个供应商
就够了。
我想不管
你是谁，
我想我可以保障任何
公共云端供应商的弹性
都要比你现在的弹性要好。
>> [笑声]
>> [笑声] 所以
所有的精神上的痛苦，
都是假的。
>> 对的。
>> 我是说，
他们真的要比你好。
>> 对的。
>> 所以
>> 所以，你可以选择一个，
然后就一直用它。
>> 对的。
>> 总之，它们现在
不是都在相同的位置。
一旦你适应了
给其中一个的服务进行编写
就会变得安心。
>> 唔......
>> 所以，比如
我只需要在美国。
>> 对的。
>> 我可能会只跟
一个云端供应商合作。

Japanese: 
構築した内部サービスは
その後製品になり
ユーザーを顧客のように
対応していきます
>> なるほど
>> そうあるべきだと考えます
>> そうですね
パブリッククラウドの
ランドスケープとして
新興企業の規模だったら
パブリッククラウドを
使うべきと話していましたが
その時一つのベンダーだけを
使いますか？
もしくは複数のベンダーを
使いますか？
どうお考えでしょう？
>> 状況によるでしょう
必要となるロケーションにもよります
NetFlixのようなものを考える時
単一ベンダーで上手くいくかもしれません
どんなものかに関わらず
パブリッククラウドプロバイダーの
伸縮性は
あなたが現在持っているものよりも
いいと保証します
>> [笑]
>> [笑]
精神面での苦悩はなくなるでしょう
>> そうですね
>> それはあなたより優れています
>> なるほど
>> なので
>> 1つを選んで
とにかくやってみるといいでしょう
>> なるほど
>> 彼らは全て
同じ場所にはいません
1つのサービスを書いたら
書きやすくなるケースもあります
>> なるほど
>> もし私が米国のみで
サービスが必要な場合は
>> はい
>> おそらく1つのクラウドプロバイダーと
契約するでしょう

Chinese: 
我們創建的內部服務將會是
一個產品，我們將把使用者當成客戶。
>> 對。 >> 象我們該做的那樣。
>> 對，沒錯。
在公有雲方面，你提到過。
我是說，合理地，如果
你是一家小型初創企業，
你可能會完全使用公有雲。
你會完全使用一家供應商，還是
還會尋找多個供應商，
對此你有什麼想法？
>> 這個要看情況而定，
取決於我需要在哪裡。
象Netflix這樣的公司，
單一供應商就可以滿足了。
我想，不管你是誰，
我可以擔保任何公有雲提供者
的彈性都比你現在的彈性要好。
>> [笑]
>> [笑] 所以，
所有的精神折磨，其實都是假的。
>> 對。
>> 我是說，他們已經比你更好了。
>> 對。 >> 所以，
>> 所以，你可以挑選一家
並與之合作。
>> 是的。 >> 現在他們不是
都在相同地方的。
一旦你習慣了針對一家的
服務來寫，就會比較輕鬆了。
>> 嗯嗯。
>> 如果我只需要在美國。
>> 對。
>> 我可能會和一家雲提供者合作。

English: 
>> I mean, they're already better than you.
>> Right.
>> So >> So, you could just pick one and go
with one.
>> Yeah.
>> Now they're not all in all the same places.
There is some ease once you get used to writing
to the services of one.
>> Mm-hm.
>> So, if I only needed to be in the US.
>> RIght.
>> I would probably go with one cloud provider.
>> Right.
>> And stay with them and develop a good partnership
with them.
>> Right.
>> Cuz I'm not really worried about >> Any
cloud going down.
>> Right.
>> I'm not worried about it.
>> Yeah, I still see differentiation.
Kind of pretty interesting tech differentiation,
and the focus, and the talent.
And when you think about a company like Microsoft,
with tens of thousands of developers who've
worked for decades on Things like SQL Server.
They know SQL really well and you've obviously
worked on SQL Technologies.
>> Mm-hm.
>> Back in the day.
>> [LAUGH] >> How would you counsel other
Enterprises, other ones of pivotal's customers

Russian: 
>> Ясно.
>> Но они
все находятся в разных местах.
Будет проще,
когда привыкнешь работать
с одним подрядчиком.
>> Ясно.
>> Если бы я работал
только в США,
>> Да.
>> я бы сотрудничал
с одним поставщиком.
>> Ясно.
>> Я работал бы
на развитие нашего партнёрства.
>> Ясно.
>> Даже
если вдруг что-то
>> Случится с одним облаком.
>> Понял.
>> Пускай.
>> Однако есть разница
в техническом уровне, в подходе,
в сотрудниках.
Например, в такой компании,
как Microsoft,
десятки тысяч разработчиков,
которые десятки лет работают
над проектами вроде SQL Server.
Они настоящие профи SQL.
Ты ведь тоже работал
в SQL Technologies?
>> Да.
>> Было время.

Chinese: 
>> 對。 >> 並和他們保持合作，
發展良好合作夥伴關係。
>> 對。 >> 因為我並不
很擔心 >>任何雲關閉。
>> 對。 >> 我不會擔心這個。
>> 是的，我依然看到差異化。
相當耐人尋味的技術差異化，還有焦點，
和才能。
想下微軟這樣的公司，
它有數以萬計的開發者，數十年來
一直研究SQL Server這樣的專案。
他們對SQL非常瞭解，
你顯然用過SQL技術。
>> 嗯嗯。
>> 在當年。
>> [笑]
>> 你會如何在其他
企業，Pivotal的其他
客戶作出那些
決定的時候提供意見？
>> 只是讓你的開發人員
用他們想用的任何東西，
還是給他們一個選擇列表，還是?
>> 我並不認為應該讓他們
用他們想用的任何東西。
[笑] 我是說，如果可以那樣當然很好，但
那樣最終會變得無法管理。

Chinese: 
>> 对的。
>> 然后一直保持合作，
跟他们开展
良好的合作关系。
>> 对的。
>> 因为我真的
没有担心
>> 有哪一个云端会变差。
>> 对的。
>> 我没有担心这个事情。
>> 对的，
我还看到分化。
挺有趣的技术分化，
还有关注点，
还有人才。
当你想到像微软
这样的公司，
有上万名开发者
花了数十年的时间
在SQL Server
这样的东西上。
他们很了解SQL，
并且显然，
你也从事过SQL技术的工作。
>> 唔......
>> 当年
>> [笑声]
>> 你会怎么咨询其他公司，
其他Pivotal的客户，
当你要作出这些决定的时候？
>> 就让你的开发者
用他们想用的东西，
还是给他们一张列表，还是怎样？
>> 我不认为
你可以让他们用到他们想用的东西。
[笑声] 我是说，如果你可以的话，
非常好，但是
这样很难管理，
没办法掌控。

Korean: 
>> 맞습니다
>> 그리고 그들을 계속 유지하는 가운데
그들과 새로운 제휴를 발전시킵니다
>> 맞아요
>> 왜냐하면
제가 정마로 걱정하지 않기 때문입니다
>> 모든 클라우드나 중단됩니다
>> 맞아요
>> 저는 그것에 대해 걱정하지 않습니다
>> 예.
저는 여전히 차별화 요소를 봅니다
매우 흥미로운 기술적 차별화 요소,
중점 및 재능입니다
여러분이 수십년 동안
SQL 서버와 같은 것들에 대해
작업을 해 온
수만 명의 개발자가 있는
Microsoft와 같은 회사를 생각하는
경우입니다
그들은 SQL을 정말 잘 알고
여러분은 명백히 SQL 기술에 대해
작업해 왔습니다
>> 음
>> 그때 당시에
>> [웃음]
>> 다른 기업들,
Pivotal의 고객들 중 다른 회사들에게
이런 결정에 대해
어떻게 상담하시겠습니까?
>> 개발자들이 자신들이 원하는 것을
사용하게 하거나
그들에게 선택 목록을 제공합니까?
>> 저는 그들이 원하는 것을 사용하도록
여러분이 내버려 두지 않는다고 생각합니다
[웃음] 여러분이 그렇게 할 수 있다면 좋겠지만
결과적으로 관리할 수 없게 되거나
그것에 대한 관할 권한이 없습니다

Japanese: 
>> はい
>> 彼らと一緒に取り組んで
良いパートナー関係を
築いていくと思います
>> なるほど
>> なぜならば
クラウドが退行するという
心配はしていないからです
それは心配していません
>> フォーカスとかタレントとか
テクノロジーの違いの中で
Microsoftのような企業を考える時
何千何万の開発者が取り組んで
何十年にも渡って
例えばSQLサーバーなどで
作業しています
彼らはSQLサーバーに長けています
>> はい
>> あなたも以前は
SQLテクノロジーを使っていたと思うんですが
>> [笑]
>> 他の企業や他のPivotalの顧客の
意思決定をする時
どうカウンセリング
しているのですか？
>> 開発者が好きなようにさせるのか
選択リストを作って与えるのか？
>> 好きな物を使わせる
選択肢はありません
[笑] そうできたら
いいんでしょうけど
管理不能の状態に陥って

Chinese: 
你必須能管理好。
那些開發人員。
如果每個人都為所欲為，
一旦某個人被巴士撞到了，
你就倒楣了。
所以進行開發必須有某種管理，
以便其他人能接手。
所以我不會說，拿出你的信用卡，
使用你要的任何技術。
我想那可能是一個錯誤。
>> 是的。 是的。
開發的第一天
是容易的。
問題在第2天、第7天和第400天。
情況是，我需要修補它，
而它已經變得老舊。
任何一個新系統，只要不消亡，
最終都會變得
老舊。
最後的想法？
結束前的想法，有關企業就使用開源作出
決定，圍繞傳統供應商改造自己，
新基金，新技術。
>> 我會談下自建還是購買，如果你不肯定，
不要自建。
>> [笑] 如果有任何疑問，

Russian: 
>> [СМЕХ] >> Что бы ты
посоветовал другим компаниям,
которые работают с клиентами
Pivotal, по такому вопросу:
стоит ли позволять
разработчикам использовать
все доступные ресурсы
или как-то их ограничивать?
>> Думаю, не стоит давать
им в руки абсолютно всё.
[СМЕХ] Конечно, это было бы
здорово,
но тогда процесс
становится неуправляемым.
Поэтому не стоит так делать.
Если разработчики
делают, что хотят,
и вдруг одного сбивает машина,
ты оказываешься в тупике.
Так что нужно курировать работу,
чтобы в случае чего
кто-то мог её подхватить.
Я не сказал бы разработчику:
«Вот кредитка, вот технологии,
делай что хочешь».
Хорошим бы это не кончилось.
>> Точно. Первый день в работе -
самый простой.
Трудно со второго дня
и до бесконечности.
Продукт надо патчить,
а он уже устарел.
Любой проект с нуля устаревает,
иногда безнадёжно.
Ну что?
Поделитесь напоследок парой
мыслей о работе компаний
с OpenSource, и о том,
как старые поставщики
ищут новые подходы, осваивают
новые сферы и технологии.

English: 
for when you make those decisions of saying
>> Just let your developers use whatever they
want, or give them a pick list or?
>> I don't think you can let them use whatever
they want.
[LAUGH] I mean yeah that'd be great if you
could but that ends up being unmanageable
and there's no governance around it.
So you have to be able to.
Those developers.
If everyone does whatever they want, when
one of them gets hit by a bus, then you're
just out of luck.
So things have to be done with some sort of
governance so that someone else can pick up.
And so I wouldn't just say, take out your
credit card.
Use whatever technologies you want.
I think that that would probably be a mistake.
>> Yeah.
Yeah.
The first day of I built it is the easy part.
It's day two and day seven and day 400.
It's like, I need to patch it and it's already
a legacy.
Every green field system turns into legacy
eventually if it doesn't die.
Last thoughts?
Parting thoughts on these themes of enterprise
decisions around OpenSource and around the

Korean: 
따라서 여러분은 할 수 있어야 합니다
그러한 개발자들에게요
모두가 자신이 원하는 일을 하게 되면
그들 중 한 명이 버스에 치이면
여러분은 운이 없는 것입니다
따라서 일들은 약간의 관리를 통해
이루어져야만
다른 누군가가 선택할 수 있습니다
따라서 저는 여러분이 신용카드를 꺼내라고
말하고 싶지 않습니다
원하는 어떤 기술이나 사용하십시오
저는 그것이 아마도 실수가 될 것이라고
생각합니다
>> 예. 예.
제가 그것을 제작하는 첫 날은
쉬운 부분입니다
그것은 제2일, 제7일 및 제400일입니다
그것은 마치 내가 패치를 필요로 하는데,
그것은 이미 유산이라고 말하는 셈입니다
모든 신규 시스템들은 죽지 않는 한
결과적으로 구식이 됩니다
마지막 생각은요?
오픈소스와 이전 벤더들이 자신들을
재창조하고 있는 방식을 둘러싼
기업 의사결정에 대한
이들 주제들에 관한 작별 생각들은
자신들 본인, 새로운 토대, 새로운 기술을
재창조하고 있습니다
>> 그럼 제작이냐 구입이냐에 대해
말씀드리겠습니다
확신이 서지 않는 한 제작하지 마십시오
>> [웃음]
>> 의심이 드는 경우에는

Chinese: 
所以你需要掌控
这些开发者。
如果每个人都
做他们想做的，
当某一天
有一个人被巴士撞了，
那你就遭殃了。
所以需要某种掌控
才可以完成这些事情，
这样的话其他人才可以接手。
然后我不会只说，
拿出你的信用卡。
用你想要用的
技术吧。
我想这可能
会是个错误。
>> 嗯。嗯。
我搭建它的第一天
很简单。
然后第二天，第七天，
第四百天。
就好像，我需要给它补丁，
它已经是一份遗产了。
每一个新的系统，
如果没有消亡的话，
最后都会变成遗产。
最后的想法？
围绕开放源码，
围绕旧供应商怎样彻底改造自己，
新的基金会，新的技术，
在公司决议的
这些话题上的
一些零星想法，
>> 所以我会说，搭建还是购买，
如果你不确定的话，
不要去建。
>> [笑声]
>> 如果有任何疑惑，

Japanese: 
統括ができなくなるでしょう
いくらかの
舵取りが必要です
ある開発者がバスにひかれたら
その作業は抜けてしまいます
ある程度の指揮が必要で
そうすれば誰かが代わりに
作業することができるでしょう
なのでクレジットカードを出して
好きなテクノロジーは
何でも使っていいよとは言いません
大きな間違いになるでしょう
>> そうですね
私が初めて構築した頃は
とても簡単なパートだったのが
2日目　7日目　400日目となるうち
パッチする必要が出てきたり
すでにレガシーとして扱われたり
全てのグリーンフィールドシステムは
それが死なない限り
最終的にはレガシーとして
扱われることになります
最後に何かありますか？
OpenSourceでの企業の意思決定
古いベンダーの新たなやり方
新しいファンデーションや
テクノロジーについてなど
>> 購入 vs 構築について
どちらかを悩んでいたら
構築しないこと
>> [笑]
>> 少しでも疑問がある場合は

Chinese: 
那麼你的決定就是錯誤的。
是的，此前你在應否和能否上沒有
任何含糊，但現在變成，
如果不確定，就不要做。
>> 我告訴你我未說出來的，對“應否”這個問題，
除非這是你所做的事情，我的答案永遠是“不”。
除非這是你公司所做的事情。
你知道，Pivotal做的就是建立平臺，一個
雲平臺，以便你能做到。
>> 是的。
>> 萬事達卡公司
不是做這個的。
>> 對
>> 我們應該做
我們擅長的事情。
>> 對，沒錯。
這就是我們完全
不做賬務系統的原因。
你知道，我們沒有嘗試過，
也不應該嘗試。
>> 其他人會嘗試。
你知道，某處有家初創公司說，
“你知道嗎？
這些賬務系統都不適合我們，
我們自己建一個吧。”，
但這個工作非常複雜。
>> 對。
>> 是的。
對，它們難以建立的
原因是因為有大量
並不明顯的細節。
實際上就是那個抽象問題，
如果你在交付抽象方面做得足夠好，
人們會認為你的軟體是瑣碎的，
因為使用它應該是瑣碎的。
但實際上，在背後所做的事情並不瑣碎。
>> 很棒。

Japanese: 
間違った決定を下すことになります
先の「するべきか できるのか」には
曖昧さがなかったんですが
ここではもし確信できないなら
やるなということですね
>> さっきお話しなかったのですが
やるべきかについての答えは
いま現在あなたや企業が
それをしていない限り
常にノーなんです
例えばPivotalがしていることは
クラウドプラットフォームを作ることで
それはすべきなんです
>> そうですね
>> それはMasterCardが
していることではないんです
>> そうですね
>> 私たちは得意なことを
すべきなんです
>> その通りですね
それは私たちが決済システムを
構築していない理由でもありますね
いまだかつてやってきてないのだから
やるべきではない
>> 他の人がやるかもしれないですけれど
どっかの新興企業が
どの決済システムも
上手く機能しないから
独自のものを作ろうと言うかもしれないけど
とても複雑なものになるでしょう
>> そうですね
>> はい
決済システムの難しさは
一筋縄にはいかない
細かい作業沢山あることです
抽象化についても
抽象化のデリバリを
きちんとしてると
人々はそのソフトウェアを
平凡と思うでしょう
それを使うのも平凡だと
思うからです
ただその裏は一切平凡では
ありません
>> では

Russian: 
>> Добавлю про выбор
покупать-создавать: не уверен -
не создавай.
>> [СМЕХ]
>> Если сомневаешься, значит,
от этого решения
лучше отказаться.
Раньше ты давал простор:
«если я могу, то стоит ли?»,
а теперь совсем категоричен:
«Сомневаешься - нет!»
>> Стоило добавить,
что нужно отказываться,
но только,
если это не сфера деятельности
твоей компании.
Так, Pivotal может
создать платформу,
это ваша работа.
>> Да.
>> Но не MasterCard.
>> Да уж.
>> Делай то, в чём ты хорош.
>> Я понял.
Поэтому мы не занимаемся
системами выставления счёта.
Мы не пробовали
и даже не собираемся.
>> Кто-то бы попробовал.
Многие начинающие
рассуждают так:
«Нам не подходят эти системы,
сделаем свою»,
но это не так просто.
>> Точно.
>> Да.
И причина того, что это непросто,
в большом количестве
неочевидных мелочей.
А ещё, если ты
хорошо объясняешь
абстрактные вещи
простыми словами, люди думают,
что и твой продукт очень простой
ведь его легко использовать.
Но на деле всё совсем иначе.
>> Вот так.

English: 
way that Old vendors are reinventing themselves,
new foundations, new technologies.
>> So I will say about build versus buy, if
you're not sure, don't build it.
>> [LAUGH] >> If there's any doubt than you
are making the wrong decision.
Yeah, there was no ambiguity in your previous
of should I and can I, but now you're like
if you're not sure don't.
>> I'll tell you what I didn't say is that
the answer to should I is almost always no
unless it's the thing that you do.
Unless it's what your company does.
You know, what pivotal does Is make a platform,
a cloud platform, so you should do that >> Yes
>> That's not what MasterCard does.
>> Right >> We should do the things we're
good at.
>> Right, yeah.
It's also why we don't do billing systems
at all.
You know, it's like, we have not tried, and
should not try.
>> Other people would try.
You know, somewhere there's a startup saying,
"You know what?
None of these billing systems work for us,
let's build our own.", but it's really complicated.
>> Right.
>> Yes.

Korean: 
잘못된 결정을 하는 것입니다
이전에는 해야 하는지, 할 수 있는지라는
당신의 질문에서는 모호성이 없었지만
이제 당신은 확신이 서지 않으면
하지 말라고 하시네요
>> 말씀드리겠지만 제가 말하지 않은 것은
해야 하는지에 대한 답은 여러분이 하는 일이 아닌 한
거의 항상 아니오라는 것입니다
그것이 여러분의 회사가 하는 일이 아니라면요
아시겠지만 Pivotal이 하는 일은
플랫폼, 클라우드 플랫폼을 만드는 것이라서
여러분은 그것을 해야 합니다
>> 예
>> 그것은
MasterCard가 하는 일이 아닙니다
>> 맞아요
>> 우리는 우리가 익숙한 일을
해야 합니다
>> 맞아요, 예.
우리가 과금 시스템을 전혀 하지 않는 이유도
그 때문입니다
우리가 시도한 적이 없다면
시도해서는 안 되는 것과 마찬가지입니다
>> 다른 사람들이 시도할 것입니다
어딘가에 다음과 같이 말하는
창업 기업이 있습니다
알고 계십니까, 이 과금 시스템 중 어느 것도
우리에게 맞지 않으므로
우리 자신의 것을 구축하자고 하는데,
그것은 정말 복잡합니다
>> 맞아요
>> 예
그들이 제작하기 어려운 이유는
명백하지 않은 세부적인 내용들이
많기 때문입니다
그리고 사실 그 추상화는
해당 추상화를 제공하는데
정말 훌륭한 일을 하는 경우
사람들은 여러분의 소프트웨어가
사소하다고 생각하게 될 것입니다
왜냐하면 그것을 사용하는 것이
사소해야 하기 때문입니다
하지만 사실 그것이 배후에서 하는 일은
그렇지 않습니다
>> 매우 멋지네요

Chinese: 
那么你就是在做
错误的决定。
嗯，之前“我应该吗”和“我可以吗”
之间是没有含糊的地方的，
但是现在，如果你不确定，
你就不要做。
>> 我告诉你，我之前没有说完，
“我应该吗”的答案往往是不，
除非是你做的事情。
除非是你公司做的事情。
你知道吗，Pivotal在做的是弄一个平台，
一个云端平台，
所以你应该做。
>> 对
>> 这不是
万事达信用卡做的。
>> 对
>> 我们应该做
我们擅长的。
>> 嗯，对的。
这也是为什么
我们不做计费系统。
你知道吗，就好像，
我们没有尝试过，也不应该尝试。
>> 其他人会尝试的。
你知道吗，在某个地方，
有家初创公司说，
“你知道吗？
没有计费系统适合我们，
我们来做自己的计费系统吧”
但是这真的很复杂。
>> 对的。
>> 嗯。
嗯，很难去搭建的原因是
因为有太多不明显的
细节。
然后实际上，
抽象概念的东西，
如果传达抽象概念
你做得好的话，
人们就会觉得
你的软件根本不重要，
因为使用它
应该会很琐碎的。
但是实际上，
软件背后所做的并不是。
>> 很棒。

Korean: 
와 주셔서 정말 감사합니다
모시게 되어 정말 기뻤습니다
>> 언제든지요, John. 고마워요
>> 감사합니다
>> [박수 갈채]

Japanese: 
今日はお越しいただき
ありがとうございました
お話できて大変光栄でした
>> こちらこそありがとうございました
>> ありがとうございました
>> [拍手]

Russian: 
Спасибо большое за беседу,
было очень интересно
поговорить с тобой.
>> Взаимно, Джошуа.
>> Спасибо.
>> [АПЛОДИСМЕНТЫ]

Chinese: 
嘿，我真的很开心
你可以来到这里分享这些。
你来到这里，
真的太棒了。
>> John，欢迎随时再来。 谢谢。
>> 谢谢。
>> [掌声]

English: 
Yeah, the reason they're hard to build is
because there's a lot of details that are
not obvious.
And actually that abstraction thing, if you
do a really good job of delivering the abstraction,
people will assume your software is trivial,
because using it should be trivial.
But actually, what it's doing behind is not.
>> Very cool.
Hey, I really appreciate you coming over for
this.
It's been fantastic having you here.
>> Any time, John.
Thanks.
>> Thanks.
>> [APPLAUSE]

Chinese: 
嗨，我真的感謝你過來。
能有你在此真的非常棒。
>> 不客氣，John。 謝謝！
>> 謝謝！
>> [鼓掌]
