CEO PlanetScale di Cloud-Prem dan Mendaki Tangga Teknik

Sam Lambert adalah CEO dari PlanetSkala, penyedia database tanpa server yang kompatibel dengan MySQL. Sebelum bergabung dengan PlanetScale (saat itu sebagai chief product officer), dia adalah VP of engineering di GitHub.

Dalam wawancara ini, Lambert membahas sejumlah topik yang terkait dengan model pengiriman perangkat lunak asli cloud, termasuk seperti apa tampilan tanpa server yang baik, siapa yang harus menjalankan Kubernetes, dan munculnya “cloud-prem” — model penerapan yang menggabungkan kekuatan dari -prem software dan penawaran SaaS. Dia juga berbagi pengalamannya menjadi CEO non-pendiri, dan nasihatnya tentang kapan dan bagaimana beralih dari teknik ke manajemen.

---

MASA DEPAN: Anda telah menjelaskan apa yang dilakukan PlanetScale — setidaknya bukan penawaran SaaS murni — komputasi “cloud-prem”. Bagaimana Anda mendefinisikan istilah itu?

SAM LAMBERT: Cloud-prem adalah model baru — solusi asli cloud untuk lokal, pada dasarnya. Secara tradisional, perusahaan harus memiliki lokal solusi atau awan solusi, dan mengangkangi keduanya secara tradisional sangat sulit. Di GitHub, kami mengalami ketegangan menjalankan github.com dan juga menjual GitHub Enterprise sebagai solusi lokal. Dengan produk cloud, kami harus mampu mendorong dan memberikan secara terus-menerus. Memotong rilis berdasarkan itu adalah tugas yang sangat sulit, dan membangun arsitektur untuk keduanya berarti bahwa kami tidak memberikan solusi lokal sebaik yang bisa kami lakukan; itu hanya sangat sulit untuk dilakukan. 

Ketika kami datang ke PlanetScale, kami memutuskan bahwa kami ingin menjadi cloud-only, tetapi, tentu saja, Anda tidak dapat melakukannya hanya dengan produk database atau produk yang memiliki persyaratan kepatuhan yang ketat. Jadi, dengan cloud-prem, kami pada dasarnya menyebarkan bidang data produk kami ke dalam a VPC dikelola oleh pengguna, di mana mereka menggunakan bidang kontrol kami untuk mengaturnya dan kami mengelolanya. Ini pada dasarnya terasa seperti Anda hanya menggunakan produk SaaS berbasis cloud biasa, tetapi data berada di dalam akun Anda. Tim keamanan Anda dapat mengauditnya, dan mereka merasakan keamanan dan kepercayaan memilikinya dalam batas-batas infrastruktur mereka, tanpa kerugian karena harus menambal, merilis, dan mengelola sendiri perangkat lunak lokal.

Ada satu manfaat tambahan lainnya, yaitu jika Anda adalah pelanggan besar dengan tarif negosiasi yang bagus dengan Amazon, misalnya, Anda tetap dapat membayar tarif tersebut dan mempertahankan komitmen belanja Anda dengan Amazon di dalam akun Anda.

Apa jenis pushback yang Anda dapatkan? Ada beberapa SaaS diehard dan toko lokal di luar sana …

Kami dapat memberi Anda SaaS murni, tempat kami meng-host data di dalam akun kami, dan orang-orang sepenuhnya setuju dengan itu. Penolakan sebenarnya adalah jika orang hanya ingin di tempat. Tetapi model cloud-prem benar-benar mulai beresonansi. Kami memiliki perusahaan teregulasi yang menggunakan produk karena mereka melihat manfaat ganda dari menyimpan data secara lokal sehingga keamanan atau kepatuhan senang, tetapi juga tidak harus mengelolanya. 

Inilah sebabnya mengapa model ini sangat unik dan sangat tepat waktu: Karena model ini mengatasi masalah bukan perusahaan yang tidak ingin melakukan on-prem — dan itu menjadi model lama yang sudah mati, pada dasarnya — tetapi sebagian besar masih memenuhi persyaratan bahwa di tempat akan.

Tapi, ya, Anda terkadang masih menemui perlawanan. Ada beberapa perusahaan yang tidak akan mempercayai perangkat lunak SaaS, tetapi cloud dengan cepat menghapusnya. Seperti, Anda tidak bisa memutuskan kapan atau bagaimana Amazon memperbarui S3 dan membuat S3 lebih baik, itu terjadi begitu saja. Ini semua tentang membangun kepercayaan dengan banyak pelanggan bahwa Anda adalah perusahaan terbaik untuk mengelola pekerjaan tertentu untuk mereka, dan membantu mereka merasa lebih nyaman dengan itu. 

Anda tidak dapat membangun pengalaman pengembang terbaik saat mengirimkan perangkat lunak lokal. Anda tidak dapat terus meningkatkan. Anda tidak dapat mengelola kualitas, ketersediaan, waktu aktif — semua itu adalah bagian dari pengalaman.

Pengembang bisa sangat berpendirian tentang database yang mereka gunakan. Bagaimana model penerapan cloud-prem berbicara dengan pengalaman pengembang?

Ini lebih seperti model penyebaran menghapus pemblokir. Anda tidak dapat membangun pengalaman pengembang terbaik saat mengirimkan perangkat lunak lokal. Anda tidak dapat terus meningkatkan. Anda tidak dapat mengelola kualitas, ketersediaan, waktu aktif — semua itu adalah bagian dari pengalaman. Jika Anda tidak mengelola layanan sendiri, sangat sulit untuk menciptakan pengalaman tingkat tinggi. 

Pemblokir utama untuk SaaS saja, tentu saja, adalah kebutuhan bagi beberapa pengguna untuk menyimpan data di bawah kendali mereka. Pemblokir utama untuk lokal mungkin adalah skalabilitas. Jadi model cloud-prem lebih seperti mekanisme untuk menyingkirkan pemblokir tersebut dan memberikan semua yang terbaik dari kedua dunia.

Apa peran Kubernetes dalam model penerapan Anda? Dan menurut Anda apa peran Kubernetes secara keseluruhan untuk sesuatu seperti penerapan cloud-prem?

Kubernetes memungkinkan kami untuk menerapkan ke lingkungan pelanggan dengan cara yang sangat standar, dan terlihat sama dengan cluster Kubernetes yang kami jalankan secara internal. Secara arsitektur, kami juga didasarkan pada Vitess, yang berjalan di Kubernetes dan dikembangkan di Borg, pendahulu Kubernetes di Google. Jadi, secara alami, ini sangat menyembuhkan diri sendiri. Jika Anda kehilangan pod atau Anda kehilangan infrastruktur, itu cukup menyembuhkan dirinya sendiri; failover bukanlah sesuatu yang harus Anda pertimbangkan secara manual.

Dalam model kami, pengguna tidak harus menjalankan cluster Kubernetes yang kami terapkan. Kami tidak melakukan model penerapan ke cluster Kubernetes yang ada, yang dilakukan beberapa vendor lokal sebagai cara untuk membuatnya lebih mudah. Saya skeptis apakah itu lebih mudah, jujur.

Kebanyakan orang tidak perlu menjalankan Kubernetes. Ini adalah backend yang bagus untuk penyedia infrastruktur, tapi Saya tidak berpikir itu mekanisme penyebaran yang tepat untuk sebagian besar perusahaan. Saya pikir banyak orang telah menempuh rute itu dan menemukan sedikit atau tidak ada nilai dari melakukannya.

Jika Anda mengunggah file ke Dropbox dan mereka bertanya kepada Anda, “Berapa banyak server yang Anda ingin kami pertahankan agar file ini tetap tersedia?” Anda akan seperti, “Bukankah itu yang saya bayar kamu untuk?"

Apakah ada tingkat skala di mana itu mulai masuk akal, menurut Anda? Atau kasus penggunaan tertentu, seperti menjalankan tim platform internal?

Jika Anda melakukan apa yang kami lakukan, di mana Anda ingin menyederhanakan infrastruktur dan memiliki sesuatu yang fleksibel seperti Kubernetes, maka itu bagus. Tetapi tingkat fleksibilitas itu sangat terbuka sehingga jika Anda baru saja membangun, katakanlah, sebuah perusahaan e-niaga yang mencoba meng-host situs web, Anda tidak perlu Kubernetes di backend untuk melakukan itu. 

Ini diadopsi secara luas, dan saya pikir banyak orang mencoba membangun platform internal ini dan mereka melihat Kubernetes sebagai cara untuk memiliki infrastruktur internal yang sederhana. Hanya saja tidak demikian; itu tidak cukup jauh dengan pengalaman pengguna akhir. Orang harus menggunakan cloud untuk apa sekarang terbaik untuk, dan membiarkan cloud dan orang-orang seperti kami menjalankan Kubernetes sebagai cara untuk menyederhanakan apa we lakukan. 

Tapi tentu ada titik di mana sebuah organisasi memiliki jejak yang cukup besar untuk membenarkan menjalankan sesuatu seperti Kubernetes secara internal, bukan? Seperti yang Anda lakukan di GitHub?

Jika Anda memiliki banyak host untuk dikelola — dan kita berbicara tentang ribuan mesin, yang tidak banyak perusahaan — dan Anda menginginkan infrastruktur yang sedikit lebih menyembuhkan diri sendiri atau dapat memanfaatkan armada mesin yang besar, ada baiknya Anda memiliki fleksibilitas untuk menangani hal-hal ini. 

Saya pikir pertanyaan untuk setiap perusahaan, apa pun pilihan teknisnya, seharusnya: Apakah ini membedakan untuk pelanggan kami? Apakah ada cerita atau persyaratan pengguna akhir yang dibuat lebih baik oleh kami menjalankan dan mengelola infrastruktur ini? Dan jika jawabannya adalah tidak, maka Anda tidak boleh melakukannya dengan teknologi apa pun.

Seperti, pada dasarnya tidak ada yang sekarang dapat membenarkan menjalankan hosting Git mereka sendiri. Sungguh gila tidak menghabiskan jumlah uang yang sangat rendah agar GitHub atau GitLab melakukannya untuk Anda. Ini adalah argumen yang diselesaikan; tidak ada untungnya melakukannya sendiri. Karena tanpa server dan hanya teknologi, secara umum, menjadi lebih baik, jalur itu bergerak ke mana-mana untuk semua orang. Anda hanya tidak akan membangun tim database internal atau tim operasi yang lebih baik daripada penyedia layanan seperti kami. 

Dan bahkan jika Anda melakukannya, bagaimana pengguna tahu? Apa yang akan dilakukannya untuk basis pengguna Anda? Sangat sedikit — 99.9 persen dari waktu, mereka tidak peduli dengan tumpukan teknologi Anda. Setiap perusahaan seharusnya hanya melakukan hal-hal yang menggerakkan jarum untuk pengguna mereka sendiri dan memanfaatkan infrastruktur terkelola sebanyak mungkin.

Keamanan adalah masalah pengalaman pengguna dan itu sangat mendasar. Sulit untuk merasa aman jika Anda mempersulit pengguna Anda untuk melakukan hal yang benar.

Bagaimana Anda melihat masalah keamanan dan privasi data berkembang, terutama untuk penyedia SaaS?

Semua orang peduli dengan keamanan. Ini adalah sesuatu yang harus kami tangani dengan sangat serius sebagai perusahaan yang menampung data orang. Salah satu tren yang saya lihat adalah itu perusahaan akan mendapatkan sertifikasi kepatuhan mereka jauh lebih cepat daripada sebelumnya. Sekarang Anda harus mendapatkan Sertifikasi SOC 2 cukup banyak segera, jika tidak, Anda tidak akan bisa bermain. (Jika Anda ingin sedikit membaca, Fly.io menulis posting blog di SOC 2 itu layak untuk dilihat.)

Dan, secara umum, perusahaan sangat tertarik pada kemampuan tertentu yang sekarang menjadi taruhan meja, seperti otentikasi masuk tunggal, pencatatan audit, dan token akses yang dapat dibatalkan.

Misalnya, sekarang, jika Anda secara tidak sengaja memeriksa kredensial database Anda ke dalam repositori GitHub publik, kami akan segera mencabutnya sehingga orang tidak dapat mengakses database Anda. Itu hal yang biasa terjadi — orang akan memasukkan kredensial AWS mereka ke dalam repositori open source dan kemudian akun mereka tiba-tiba digunakan untuk penambangan Bitcoin dan mereka menghabiskan puluhan ribu dolar dalam tagihan, atau data mereka di luar sana di internet

Pada akhirnya, pendapat saya adalah bahwa keamanan adalah masalah pengalaman pengguna dan ini sangat mendasar. Sulit untuk merasa aman jika Anda mempersulit pengguna Anda untuk melakukan hal yang benar. Jika Anda membuat keamanan non-default, dan sesuatu yang harus dipikirkan dan dikonfigurasi orang, mereka cenderung membuat kesalahan. Jadi, misalnya, Anda tidak dapat terhubung ke PlanetScale dengan cara yang tidak terenkripsi — Anda tidak bisa. Orang menginginkannya sebaliknya karena mereka ingin bermalas-malasan atau mereka ingin melakukan sesuatu dengan cara tertentu. Kami hanya tidak memungkinkan. Hasilnya adalah tidak ada yang bisa mengacaukan dan mengirim data mereka dalam teks biasa di internet. Itu, sekali lagi, adalah bagian dari pengalaman pengguna. 

Untuk setiap [layanan penyedia cloud] — dan ada ratusan di Amazon — ada lima startup muda yang bersaing melawannya. Dan akan menjadi sangat sulit untuk peduli dengan begitu banyak pengguna dan kasus penggunaan dan tetap menskalakannya.

Anda menyebutkan tanpa server sebelumnya. Apa definisi kerja Anda tentang tanpa server?

Cara saya menggambarkannya adalah bahwa produk tanpa server yang baik seharusnya hanya mengekspos apa yang Anda benar perlu dikendalikan untuk menyelesaikan sesuatu. Jika Anda mengunggah file ke Dropbox dan mereka bertanya kepada Anda, “Berapa banyak server yang Anda ingin kami pertahankan agar file ini tetap tersedia?” Anda akan seperti, “Bukankah itu yang saya bayar kamu untuk?" Apakah itu janji awan? Cloud seharusnya lebih dari sekadar menambahkan vCPU dan memori, tetapi di cloud. 

Tanpa server mengatakan, “Apa satuan nilai untuk pemakai? apa yang pemakai ingin lakukan?” Dan itu tidak memaksa mereka untuk melakukan lebih dari itu. Jadi, bagi saya, ini adalah gerakan optimis yang menuju kesederhanaan dan desain produk yang lebih baik. 

Bagaimana Anda menilai hubungan antara perusahaan Anda dan penyedia cloud saat ini? Apakah "frenemies" adalah deskripsi yang adil?

Ini menarik, karena kami bersaing dalam beberapa hal, tetapi kami juga membawa lebih banyak penggunaan ke platform mereka. Untuk pelanggan yang menjalankan versi cloud-prem terkelola kami, kami bekerja dengan perwakilan Amazon sehingga orang tidak pergi ke Google; mereka tetap di Amazon dan mereka menggunakan perangkat lunak kami. Jadi repetisi masih mendapatkan banyak konsumsi, kami mendapatkan seluruh kesepakatan itu, dan itu bagus. Saya pikir mereka perlahan akan mundur dan membuat perusahaan seperti kami menjadi pengalaman pengguna akhir. Dan pada akhirnya mereka masih menang, karena mereka masih menjual server dengan volume yang semakin besar. 

Tapi kita berada di fase tengah yang menarik ini, di mana mereka bukan hanya pengecer kotak besar. Mereka masih bersaing dengan kami dengan produk tertentu, tetapi semakin sulit karena, sekarang, untuk setiap layanan mereka — dan ada ratusan di Amazon — ada lima startup muda yang bersaing melawannya. Dan akan menjadi sangat sulit untuk peduli dengan begitu banyak pengguna dan kasus penggunaan dan tetap menskalakannya.

Jika Anda adalah tipe manajer yang tidak berusaha menaiki tangga sepanjang waktu — tetapi hanya melakukan apa yang Anda katakan akan Anda lakukan, dan Anda kolegial saat Anda melakukannya, dan Anda membantu orang menang dan Anda mendorong orang maju — Anda secara alami dibawa ke ruangan yang lebih besar.

Tidak terkait: Anda bukan CEO PlanetScale sejak awal. Bagaimana peralihan Anda dari CPO ke CEO terjadi?

Ketika saya bergabung, perusahaan melakukan hal-hal yang sedikit berbeda. Kami sedang melakukan host Vitess, yang merupakan produk lama yang kami miliki. Saya memutuskan saya ingin membangun produk database luar biasa yang memiliki Vitess pada intinya, di mana Vitess adalah mesin yang mendasarinya, tetapi bukan produk akhir. Jadi kami membuang produk lama dan membangun yang baru, dan itu menjadi sangat sukses. Dan kemudian saya mempekerjakan banyak orang dari perusahaan saya sebelumnya, GitHub, dan orang-orang yang saya kenal baik. 

Pada saat itu, banyak perusahaan dan budayanya adalah orang-orang yang datang untuk bekerja dengan saya — untuk bekerja sama lagi — jadi pergeseran ganda budaya dan produk datang melalui apa yang ingin saya lakukan. Hal logis terakhir adalah menyelaraskan segala sesuatu di bawah visi itu. Itu sebabnya saya menjadi CEO.

Itu adalah transisi sederhana yang dilakukan dan dibersihkan dengan sangat, sangat cepat. Maksudku, pendiri kita hebat. Mereka memulai perusahaan ini, mereka membangun perusahaan, dan kemudian mereka menyerahkannya seperti yang dilakukan banyak pendiri. Beberapa perusahaan seharusnya melakukan cara ini lebih cepat.

Anda juga naik tangga di GitHub dengan cukup cepat, dari DBA ke VP teknik. Apa saran Anda untuk membuat transisi semacam itu berhasil, dan juga untuk memutuskan apakah pindah ke manajemen adalah langkah yang tepat?

Pertama-tama, jika Anda berada di perusahaan yang mengharuskan menjadi seorang manajer untuk memiliki pengaruh, maka Anda berada di perusahaan yang salah. Saya pikir banyak orang meninggalkan peran kontributor individu untuk pergi dan menjadi manajer hanya untuk tetap berada di ruangan, yang mengerikan. 

Saran saya adalah jadilah seorang manajer jika Anda sangat peduli dengan orang lain dan peduli dengan hasil yang dapat dicapai oleh orang-orang hebat. Anda bisa pergi terlalu jauh ke arah lain, di mana Anda hanya seorang manajer orang dan Anda tidak terlalu peduli dengan pekerjaan itu. Saya pikir Anda pada akhirnya ingin melihat hal-hal hebat dibangun, dan Anda melakukannya melalui budaya yang hebat dan memberdayakan orang. Jadi, jika Anda peduli dengan hal-hal itu dan dapat membangunnya, jadilah seorang manajer.

Saya sangat peduli dengan hal-hal itu. Saya bergabung dengan GitHub sebagai seorang insinyur, dan saya memiliki pengaruh di sana dan saya menyukainya. Dan saya tahu bahwa untuk menskalakan, agar kami dapat terus melakukan teknik yang hebat, kami membutuhkan manajemen yang hebat. Saya ingin membangun budaya berkinerja tinggi dengan insinyur hebat. Jadi saya mulai melakukan itu, dan kami memiliki banyak perubahan. Perusahaan tumbuh, tetapi saya hanya sangat konsisten bekerja dengan orang-orang yang saya tahu melakukan hal-hal baik, dan tumbuh dari sana. 

Anda selalu diminta untuk berbuat lebih banyak. Jika Anda adalah tipe manajer yang tidak berusaha menaiki tangga sepanjang waktu — tetapi hanya melakukan apa yang Anda katakan akan Anda lakukan, dan Anda kolegial saat Anda melakukannya, dan Anda membantu orang menang dan Anda mendorong orang maju — Anda secara alami dibawa ke ruangan yang lebih besar. Itu terjadi begitu saja dalam jangka waktu tertentu. Dan akhirnya, ya, saya menjalankan tim besar di sana sebagai VP karena saya selalu melakukan apa yang diperlukan untuk bisnis dan terjebak di dalamnya dan bekerja keras serta memberdayakan orang. 

Dan hal yang paling saya banggakan adalah berapa banyak orang yang datang dari GitHub ke PlanetScale karena mereka tahu itu. Kamu tahu apa yang saya maksud? Mereka tidak memiliki ke. Bagi saya, itu adalah tanda bahwa saya telah menunjukkan bahwa saya dapat secara konsisten melakukan apa yang saya katakan akan saya lakukan sebagai seorang pemimpin. Orang-orang datang untuk itu.

Sebagai tambahan: Sangat sering, manajer merusak perusahaan. Kami menulis manifes manajemen yang menjabarkan bagaimana perasaan kita tentang peran itu.

Jika Anda tidak dapat menangani gagasan bahwa kesalahan Anda akan mengacaukan karier orang, dan bahwa orang-orang benar-benar bergantung pada Anda, maka [manajemen] bukan untuk Anda. 

Jika Anda seorang IC yang ingin beralih ke manajemen, apa langkah pertama?

Saya pikir Anda harus mulai belajar untuk berpikir secara sosiologis tentang dinamika tim dan orang-orang di sekitar Anda, dan bagaimana Anda dapat memengaruhi cara orang bekerja sama sebagai sebuah tim. Menjadi pimpinan teknologi, misalnya, memiliki lebih banyak dinamika sosial daripada sekadar menulis kode terbaik. Anda harus memikirkan hal-hal tempat kita bergantung, orang-orang tempat kita bergantung, dan bagaimana kita membentuk organisasi kita untuk mencerminkan pekerjaan yang akan kita lakukan — tanpa harus masuk ke dalam pikiran dan perasaan orang-orang dan benar-benar mengelolanya . Jadi cara yang baik adalah dengan coba dan pimpin proyek yang memiliki banyak pekerjaan dan ketergantungan lintas fungsi, dan membutuhkan orang-orang yang berfungsi dengan baik bersama-sama, untuk melihat apakah Anda memiliki kemampuan untuk menginspirasi orang lain untuk menyelesaikan pekerjaan mereka sebagai sebuah kelompok. 

Jika Anda berhasil melakukannya, maka Anda dapat mulai mempelajari keterampilan yang diperlukan untuk benar-benar bekerja dengan orang-orang dengan baik dan menjadi manajer mereka. Karena itu peran yang sulit; itu adalah peran pengabdian. Orang-orang menaruh karier mereka di tangan Anda, dan itu adalah sesuatu yang harus Anda anggap sangat serius. Jika Anda tidak dapat menangani gagasan bahwa kesalahan Anda akan mengacaukan karier orang lain, dan bahwa orang-orang benar-benar bergantung pada Anda, maka itu bukan untuk Anda. 

Jika Anda pikir Anda bisa melakukannya dan ingin membantu orang menjadi versi diri mereka yang lebih baik, galilah.

Diposting Agustus 2, 2022