MongoDB CTO: آنچه که توسعه دهندگان امروزی برای موفقیت به آن نیاز دارند

مارک پورتر، مدیر ارشد فناوری MongoDB، در مورد اسنوبیسم رابطه‌ای، پیروزی JSON، اهمیت اعتماد، نحوه سوء مدیریت شرکت‌ها بر توسعه‌دهندگان و چگونگی تکامل سطح سوم بحث می‌کند.

مارک پورتر مدیر ارشد فناوری MongoDB و یک تکنولوژیست با علایق گسترده و سابقه عمیق در رهبری و عملکرد نرم افزار است. پورتر در ابتدای سال ۲۰۲۰، پس از خدمت به عنوان مدیر ارشد فناوری در Grab، یک شرکت «superapp» اشتراک‌گذاری سواری، تحویل و پرداخت‌های موبایلی مستقر در سنگاپور، به MongoDB پیوست. قبل از آن، او نه سال را صرف ساخت سرویس های پایگاه داده مدیریت شده Amazon RDS در AWS کرد. او در اوایل کار خود، ۱۲ سال را در Oracle گذراند، جایی که او در Oracle RDBMS کار کرد، تیم توسعه سرور Oracle RDBMS را مدیریت کرد، و در نهایت رتبه‌ها را ارتقا داد و مستقیماً به مدیر عامل لری الیسون گزارش داد.

من اخیراً این فرصت را داشتم که با پورتر در مورد پیوستن به MongoDB، مزیت‌های مدل سند، نحوه خوشحال کردن توسعه‌دهندگان نرم‌افزار، نحوه ایمن کردن استقرار نرم‌افزار، و آنچه توسعه‌دهندگان امروزی از پایگاه داده نیاز دارند صحبت کنم. ردیف پورتر همچنین درباره چگونگی کار با لری الیسون و اینکه چرا توسعه‌دهندگان برای «موفقیت» نباید مدیر شوند، صحبت کرد.

مارک پورتر مدیر ارشد فناوری MongoDB

متیو تایسون: هی مارک، از اینکه با من گپ زدی متشکرم. شما در ابتدای سال ۲۰۲۰ در MongoDB مانتو CTO را انتخاب کردید. درست در زمان شیوع بیماری همه گیر، آن تجربه چگونه بود؟

مارک پورتر: مت، از اینکه وقت گذاشتید متشکرم. سفر من به MongoDB سفر جالبی بود. برای اینکه واقعی باشم و کمی شرمنده باشم، واقعاً نفهمیدم خودم را درگیر چه چیزی کرده بودم. در حالی که من از MongoDB در چندین کار استفاده کرده بودم، باید بگویم که من هنوز هم یک آدم بدبین بودم. اما با دیدن قدرت مدل سند، مقیاس پذیری داخلی و در دسترس بودن بالا کاملاً معماری، ذهنم بازتر شد. صادقانه بگویم، MongoDB یک سیستم توزیع شده بومی و بسیار در دسترس است که تراکنش‌ها را مدیریت می‌کند، در حالی که پایگاه‌های داده رابطه‌ای، سیستم‌های تراکنشی تک اولیه هستند که با توزیع و در دسترس بودن مشکل دارند. همچنین مدتی طول کشید تا قدرت یک پلتفرم مدرن را به طور کامل درک کنم – با درایورهای MongoDB، شما به طور طبیعی به زبان خود برنامه‌نویسی می‌کنید و نیازی به گذر از این لایه ترجمه فوق‌العاده دشوار SQL ندارید. مطمئنا، SQL از نظر ریاضی واقعاً خالص است. اما MongoDB به شما امکان می‌دهد کارها را عملی‌تر، آسان‌تر و کارآمدتر انجام دهید.

تایسون: به‌عنوان مرزها در داده‌ها چه می‌بینید؟ کجا MongoDB در حال تحقیق و پیشبرد وضعیت هنر است؟

پورتر: خوب، JSON، چه باور کنید چه نه، هنوز در حال پیشروی در مرز داده است. ما با JSON در سال ۲۰۰۹ راه‌اندازی کردیم، و قدرت این نوع داده که هم توسط کامپیوتر و هم توسط انسان قابل خواندن و پردازش است، هنوز در سراسر جهان احساس می‌شود. استانداردهای باز مانند JSON، پارکت و غیره بسیار قدرتمند هستند. و ترکیب آنها با استانداردهای پخش و ذخیره اشیاء اقتصادی عظیم در ارائه دهندگان ابری امکان ادغام سیستم ها را آسان تر از همیشه فراهم می کند. ما واقعاً بر روی آسان‌تر کردن انتقال داده‌ها بین خوشه‌های MongoDB و دریاچه‌های داده و همچنین به داخل و خارج از MongoDB تمرکز کرده‌ایم. و ما همه آن را برای شما مدیریت خواهیم کرد. درست همانطور که نیاز به ایجاد یک خوشه جستجوی جداگانه، مدیریت آن و ارتقای آن را حذف کردیم – جستجوی منبع باز Lucene را مستقیماً به موتور پشتیبان خود اضافه کردیم. تقریباً هر برنامه اکنون به جستجو نیاز دارد و با Atlas، آن را با کلیک یک دکمه یا یک تماس API روشن می‌کنید. من ادغام‌های بیشتر و بیشتری مانند آن را تصور می‌کنم، اما همه اینها بر اساس استانداردها و ترکیب‌پذیر باقی می‌مانند، بنابراین افراد می‌توانند ما را در هر جایی از گردش کار خود ادغام کنند – به عنوان سیستم ثبت، به عنوان نقطه فرود برای داده‌های اینترنت اشیا یا به عنوان سینک برای همه داده های ۳۶۰ درجه یک شرکت در مورد مشتریان و تامین کنندگان آنها. همه چیز در مورد آسان ساختن با آن است.

تایسون: شگفت‌انگیز است که فکر کنیم چگونه یک ویژگی زبان به ظاهر بی‌ضرر مانند JSON چنین تأثیر عظیمی داشته است (متشکرم، داگلاس کراکفورد).

من واقعاً کنجکاو هستم که شما چطور می‌خواهید با توسعه‌دهندگان «روی زمین» در تماس باشید. چگونه با حفظ و گسترش چنین عملیات بزرگی، نبض همه چیز را دنبال می کنید؟

پورتر: MongoDB همیشه اولین شرکت توسعه دهنده بوده است. اما گفتن یک چیز و انجام آن چیز دیگری است. شما باید به جای استفاده از “ابتدا توسعه دهنده” به عنوان یک ترفند بازاریابی پنهان، بخواهید از بازخوردهایی که داده می شود گوش کنید و یاد بگیرید. آنها به درستی از طریق آن، و به طور موجه می بینند.

بنابراین اولاً، فکر می‌کنم این یک مسئله ذهنیت است تا اجرای “چگونه”. در تمام سال های اولیه ما، مهندسان MongoDB زمان زیادی را در جلسات و کنفرانس ها صرف می کردند. البته، هر تعاملی نمی‌تواند حضوری باشد و همه‌گیری قطعاً این نقطه را برای ما و بسیاری از شرکت‌های فناوری دیگر به ارمغان آورده است. اکنون که بزرگ‌تر شده‌ایم، با میلیون‌ها بارگیری و صدها هزار ثبت‌نام در ماه، یک تیم بسیار بزرگ Developer Relations، یک برنامه Champions داریم و همان جلسات و کنفرانس‌ها را دوباره راه‌اندازی می‌کنیم. اما صادقانه بگویم، این چیزها در مقیاس بندی مشکل دارند. بنابراین ما ابزارهای بسیار خوبی داریم که به ما کمک می‌کند با توسعه‌دهندگان و ریشه‌های منبع باز خود در ارتباط باشیم و بسیاری از محصولات منبع باز ما را با جامعه در ارتباط نگه می‌دارند.

برای مثال، ما همچنان مشکلات را پذیرفته و درخواست‌ها را از طریق GitHub دریافت می‌کنیم. ما از Jira استفاده می کنیم و بلیط های ما برای بهبودها عمومی است، بنابراین کاربران در مورد آن نظر می دهند و می توانند مستقیماً با مهندسان ما مکاتبه کنند. ما از اینترکام برای پشتیبانی چت استفاده می کنیم. می‌توانید با مهندسان پشتیبانی MongoDB تماس بگیرید و معمولاً در عرض پنج دقیقه، ۲۴ در ۷ پاسخ دریافت کنید. و سپس ما از Chorus.ai استفاده می‌کنیم که بررسی‌ها و مکالمات با کاربران را ضبط می‌کند و آنها را رونویسی می‌کند. در انتهای صفحه، تیم محصول ما از طریق آن رونوشت‌ها بررسی می‌کند و از آن داده‌ها برای اطلاع دادن به آنچه که اولویت داریم و آنچه می‌سازیم استفاده می‌کند. در سطح کلی‌تر، همه نظرسنجی‌های توسعه‌دهنده را که می‌توانیم سالانه پیدا کنیم، تجزیه و تحلیل و بررسی می‌کنیم – نظرسنجی JetBrains، نظرسنجی Stack Overflow، و وضعیت جاوا اسکریپت نمونه‌هایی هستند.

من فکر می‌کنم ما گاهی اوقات در موقعیتی مشابه با پایگاه مشتری خود قرار می‌گیریم، یعنی این که داده‌های زیادی داریم – جمع‌آوری و تجزیه و تحلیل آن‌ها به منظور اولویت‌بندی و تصمیم‌گیری – این چیزی است که سخت است. بنابراین، ما خیلی کارها را انجام می‌دهیم تا شخصاً با توسعه‌دهندگان در ارتباط باشیم و به دلیل مقیاس، نرم‌افزار و داده‌ها را نیز برای کمک به آن وارد می‌کنیم. هیچ الگوریتم فشرده سازی یا میانبری برای این بخش از تجارت وجود ندارد – انسان ها پیچیده هستند!

تایسون: وقتی عنوان مقاله اخیر شما را دیدم (“غلبه بر ترس و نفرت از هل دادن به Prod”) مجبور شدم بخندم. زمانی که لاستیک با جاده برخورد می کند و کسب و کار به کدی که ما نوشتیم بستگی دارد، همیشه نگرانی خاصی وجود دارد.

پست‌های بسیار خوبی در مورد چگونگی استقرار قوی‌تر نوشته‌اید (“قانون ۱۸۰”، “Goldilocks Gauge”، و غیره). سوال من در اینجا این است که چقدر سخت است که مردم و فرهنگ را به این شیوه ها بپذیرند؟ آیا اطلاعاتی در مورد آن دارید؟

پورتر: (می خندد.) از اینکه شما مطالب من را بخوانید، به نوعی عصبی هستم. فکر می کنم ممکن است خوانندگان شما را با پاسخ خود شگفت زده کنم. این پست‌ها و این بحث‌ها در واقع از هر چیزی که در مورد پایگاه‌های اطلاعاتی یا داده‌ها می‌گویم محبوب‌تر و مورد تقاضای من هستند. من به طور مرتب در جلسات همه جانبه تیم های مهندسی صحبت می کنم و در مورد دو موضوع اصلی صحبت می کنیم: فرهنگ مهندسی و استقرار. اخیراً از من خواسته شد که با یک پانل متشکل از ۵۶ مدیر ارشد فناوری اطلاعات صحبت کنم، و تنها چیزی که آنها می خواستند در مورد فرهنگ و استقرار صحبت کنند! زیرا همانطور که شما می گویید آنها دو روی یک سکه هستند. من تیم‌ها را راهنمایی می‌کنم تا بر روی مکالمات صریح و باز در بالا و پایین زنجیره مدیریت تمرکز کنند. مدیران باید زمینه را به توسعه دهندگان بدهند، و توسعه دهندگان باید به مدیران به روزرسانی های صادقانه و به موقع ارائه دهند – به خصوص وقتی اخبار بد هستند.

اما به سوال واقعی شما برگردیم… من متوجه شدم که هم مدیران و هم رهبران باید شجاعتر باشند. آن‌ها می‌دانند چه چیزی استقرارشان را ایمن‌تر می‌کند، چه چیزی توسعه‌دهندگانشان را خوشحال‌تر می‌کند، و چه چیزی سرعت‌هایشان را قابل پیش‌بینی‌تر می‌کند. بنابراین وقتی با آنها صحبت می‌کنم، در مورد گفتگوهای کم خطر و صادقانه صحبت می‌کنم، جایی که همه طرف‌ها هم با نیت خوب صحبت می‌کنند و هم گوش می‌دهند. زمانی که آن را ثابت کرد، بقیه ممکن است اتفاق بیفتد. بدون آن اعتماد، همه چیز خیلی سخت است.

تایسون: شما با چندین اختراع از جمله یک با لری الیسون اوراکل. فرآیند انتقال یک ایده تا پایان ثبت اختراع چگونه است؟ نقش پتنت ها را در تجارت نرم افزار چگونه می بینید؟

پورتر: آن یکی با لری داستان خنده‌داری دارد. من در یک مغازه منتظر تعمیر ماشینم بودم و لری در مورد چیزی کاملا نامرتبط با من تماس گرفت. اما، بیش از یک ساعت بعد، مدت‌ها پس از اینکه ماشین من آماده شد، ما به این ایده برای تنظیم پهنای باند و وضوح شبکه آگاه برای پخش ویدئو رسیدیم. با توجه به نقش پتنت ها به طور کلی، من روی دو جنبه تمرکز می کنم – مهندسی و تجاری. خلوص خاصی در رساندن یک ایده مهندسی به چنان وضوحی وجود دارد که می توانید آن را در مجموعه ای از ادعاها بیان کنید که پیاز ظریفی را تشکیل می دهند و لایه به لایه ایده را بنا می کنند. و مهندسان باید به این افتخار کنند – در نهایت، کاهش هرج و مرج به نظم به معنای واقعی کلمه همان کاری است که ما انجام می دهیم.

علاوه بر این، از نقطه نظر تجاری، برای شرکت‌ها مهم است که سبدهایی داشته باشند که بتوانند از آنها برای محافظت در برابر ترول‌های خارج از کشور استفاده کنند، آنهایی که سعی می‌کنند بدون افزودن هیچ سود واقعی به جهان، پول به دست آورند. من به حق ثبت اختراع خود افتخار می کنم، و همچنین یک برنامه ثبت اختراع در MongoDB داریم که به مهندسان کمک می کند به نوآوری های خود افتخار کنند – و تعداد زیادی از آنها در حال پیشرفت هستند!

تایسون: لری الیسون چهره نمادینی است، کار کردن با او چگونه بود؟

پورتر: هه، حالا دستکش‌ها خاموش است، همین است؟ لری در واقع یک فرد نمادین است. دریافته‌ام که رهبرانی مانند او، یا اندی جاسی در AWS، یا حتی رئیس فعلی من، Dev [Ittycheria]، اینجا در MongoDB، فرهنگ را برای شرکت تنظیم کرده‌اند. شخصی که با عصبانیت برای ایجاد یا حمایت از مشتریان در شرکت تایپ می کند. لری شهرت متفاوتی دارد، بدون شک. تعاملات من با او فنی بود – در مورد ساخت پایگاه داده و فناوری سرور ویدئو – و اشتیاق او همیشه ساختن محصول ظریف مناسب بود، محصولی که باعث صرفه جویی در هزینه مشتریان و کمک به آنها در حرکت سریعتر شود. در طول سال هایی که هم به صورت غیرمستقیم و هم در نهایت مستقیم برای او کار کردم، چیزهای زیادی از او یاد گرفتم.

به‌عنوان مثال، فرهنگ جلساتی داشتیم که در آن همه جلسات کارکنان اجرایی دوشنبه، سپس سطح بعدی سه‌شنبه و سپس در طول هفته در شرکت پایین بود. با انجام این کار، تک تک کارکنان شرکت این فرصت را داشتند که در مورد ایده‌ها یا دستورالعمل‌های جدید از جلسه کارکنان لری، شخصاً با توانایی اظهار نظر و پرسیدن سؤال در عرض یک هفته، بشنوند.

من فکر می‌کنم لری در جایی که با مشکل مواجه شد و همچنان به مبارزه ادامه می‌دهد این است که به مدیران ارشد اطرافش اجازه می‌دهد فرهنگ رفتار نکردن با مشتریان را خوب بسازند، و او وارد عمل نمی‌شود و البته آن را اصلاح نمی‌کند. در مجموع، من یکی از طرفداران لری هستم و برای ۱۳ سالی که افتخار همکاری با او و اوراکل را داشتم عمیقا ارزش قائل هستم. با این اوصاف، فکر می‌کنم فرهنگ توانمندسازی مهندسی، صداقت فکری، و نیت خیری که Dev در اینجا ایجاد کرده است بسیار خارق‌العاده است – و من هنوز تقریباً دانشجوی آن بازی خاص هستم.

تایسون: خواندم که شما مقداری کدنویسی در Apple II در پاسکال، و باید به شما بگویم که خاطرات را زنده می کند. (زمانی که شما نرم افزاری برای کمک به آلاسکاها در یادگیری تجارت ایجاد می کردید، من در حال نوشتن Ultima clones بودم 🙂

در همان مقاله شما می گویید که “هر سطح مدیریتی باید دارای یک سطح رهبری مشارکت کننده فردی باشد و دستمزد باید معادل باشد.” این واقعاً مرا تحت تأثیر قرار داد. چگونه می توانیم شرکت ها را متقاعد کنیم که این کار را انجام دهند؟ به خصوص با توجه به رواج این باور که فرد باید از کدنویسی دست بردارد و در نقطه ای خاص شروع به مدیریت کند؟

پورتر: اول – آخر! چه دنیای شگفت انگیزی بود. این شگفت انگیز بود که ما با ۶۴K حافظه، پردازنده ای که بیش از یک میلیون دستورالعمل هشت بیتی در ثانیه اجرا می کند و ۱۴۰K روی یک فلاپی درایو، چه کاری می توانیم انجام دهیم، درست است؟ دیوانه.

به سوال شما در مورد اینکه برای موفقیت باید وارد مدیریت شوید برگردید. این یک دکمه داغ واقعی با من است. در دهه گذشته، در News Corp، AWS، Grab، و اکنون در MongoDB، من کار کرده‌ام تا نردبان‌های مشارکت‌کننده و نردبان مدیریتی معادل داشته باشم. و نه تنها از نظر دستمزد – بلکه از نظر مسئولیت و تأثیر نیز معادل است. به عنوان مثال، در حال حاضر در MongoDB، مهندسین ممتاز هم سطح با معاونان رئیس جمهور هستند و در سطوح مناسب تصمیم گیری و برنامه ریزی مشارکت دارند. اما همانطور که شما می گویید، این باور رایج وجود دارد که باید به سمت مدیریت بروید تا بیشترین درآمد را داشته باشید و بالاترین عنوان و بیشترین تأثیر را داشته باشید. کل هوگوش. در هر یک از آن شرکت‌ها، من سندی در مورد تفاوت‌های بین مشارکت‌کنندگان ارشد فردی و رهبران ارشد افراد نوشته‌ام. هر دو نقش عمیقاً به شرکت و البته به مردم اهمیت می دهند. اما رهبر مردم علاقه عمیقی به درون دارد و مسئولیت هر یک از مبارزات، رشد، جبران خسارت و شغل افراد را بر عهده دارد. در حالی که مشارکت‌کننده ارشد افراد را راهنمایی می‌کند، اما به همان اندازه روی کیفیت کد، فرآیندها و معماری تمرکز می‌کند.

تایسون: جایی خواندم که شما با آموزش برنامه نویسی به فرزندانتان (اسکالا، جاوا و دیگران) به برنامه نویسی خود ادامه می دهید. آیا بینشی در مورد چگونگی حفظ تعادل کار/زندگی گریزان دارید؟

• پایگاه داده
• پایگاه‌های داده سند< /a>
• پایگاه‌های داده NoSQL< /a>
• توسعه نرم افزار< /a>
• رایانش ابری< /a>