سلام دوستان، قصد دارم ان شاءالله یک یا چند ورکشاپ یک روزه بصورت آنلاین برگزار کنم، مدت زمان هر ورکشاپ بسته به موضوع بین ۲ تا ۶ ساعت خواهد بود، اگه به یکی از این موضوعات علاقه مندید لطفا در نظرسنجی شرکت کنید.
اگه موضوع دیگه ای هم هست در حوزه مهندسی نرم افزار یا گولنگ که بهش علاقه مندید لطفا تو کامنت ها ذکر کنید

@gocasts

دوستانی که تازه میخوان زبان گولنگ رو یاد بگیرند، خیلی خوب میشه این مقاله رو با دقت مطالعه کنن، یه دید خیلی خوبی میده بهتون که این زبان چرا بوجود اومده، میتونید چه انتظاراتی ازش داشته باشید و چه چیزی رو نباید انتظار داشته باشید

https://talks.golang.org/2012/splash.article

@gocasts

#golang #rob_pike

دوستان پیشنهاد میکنم حتما این رویداد رایگان رو همین الان ثبت نام کنید و ببینید، در حال برگزاریه
https://event.manbarnamenevisam.ir

@gocasts

یعنی در لحظه اینقدر استقبال شد 😑

از لایو اینستاگرامشون هم میشه دید، اونجا کیفیت لایو خوبه...
https://www.instagram.com/man_barnamenevisam

بسم الله الرحمن الرحیم

معرفی کتاب
دوستان من سعی می کنم کتاب های خوبی که مطالعه شون میتونه به شما کمک کنه که دید بهتری نسبت به دنیای cloud-native و microservice ها داشته باشید بهتون معرفی کنم و در حد توان نکاتی رو به صورت خلاصه وار در مورد اون ها به شما ارائه بدم

Designing Distributed Systems
https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/

#distributed_systems #system_design

#designing_distributed_systems_brendan_burns

@gocasts

در قدم اول یه مختصری در مورد خود نویسنده میگم، نویسنده کتاب آقای Brendan Burns هستن که co-founder ابزار معروف kubernetes هستن و جز leader های microsoft azure هستن الان

https://www.crunchbase.com/person/brendan-burns-2

@gocasts

#designing_distributed_systems_brendan_burns

اگه نظر شخصیمو بخوام در مورد کتاب بگم، اینطوریه که تا این جایی که من از کتاب خوندم، نویسنده سعی کرده بسیار مختصر و کوتاه خیلی الگوهای پرکاربردی رو در دنیای cloud-native معرفی کنه. متن کتاب بسیار روان هست و به شخصه از خوندش لذت بردم.

@gocasts

#designing_distributed_systems_brendan_burns

در بخش مقدمه کتاب نویسنده ابتدا توضیحاتی رو در مورد مزایای خواندن الگوها (patterns) میده از جمله اینکه:

- Standing on the Shoulders of Giants
بسیاری از الگوهای معروف از دل شرکت های بزرگی درومدن که تو سال های متمادی این الگوهارو استفاده کردن

- A Shared Language for Discussing Our Practice
خیلی اوقات پیش میاد تیم ها و افراد مختلف الگوهای یکسانی رو با نام های مختلفی استفاده می کنن، پس داشتن یه لغت نامه مشترک میتونه خیلی کمک کنه که خیلی راحت تر افراد بتونن نظرشون رو در مورد یک pattern یا practice با همدیگه به اشتراک بذارن

- Shared Components for Easy Reuse
اجازه میده که افراد فعال در community کامپوننت ها و کتابخونه هایی رو در مورد اون الگوها ایجاد کنن که براحتی برای همه قابل استفاده مجدد هست و نیازی نیست برای استفاده از الگوی مورد نظر خودمون چیزی رو توسعه بدیم

@gocasts

#designing_distributed_systems_brendan_burns

Part I - Single-Node Patterns
عموما وقتی از distributed system ها صحبت میشه، منظور اجرای سرویس های مختلف بر روی ماشین های مجزا از هم هست، اما خیلی اوقات پیش میاد که ما میتونیم یک application رو به سرویس های مجزا روی یک single-node machine تقسیم کنیم. اینکه چرا این کار میتونه مفید باشه دلایل مختلفی داره از جمله اینکه

establish boundaries around specific resoureces
با داشتن container های مجزا روی یه single node ما میتونیم برای هر container به طور مجزا و اختصاصی resource ها رو تعریف کنیم، اینطوری سرویسی که منابع بیشتری نیاز داره میتونه با اولویت بالاتر تعریف بشه، و الویت مصرف منابع ماشین با container مذکور باشه

delineate team ownership
اجازه میده که مسئولیت و مالکیت هر container (یا همون سرویس) به یک تیم خاص داده بشه

separation of concerns
جدا سازی دغدغه ها یکی دیگه از مزایا هست که اجازه میده بتونیم برای هر service بصورت جداگانه برنامه توسعه (development) و استقرار (deployment) داشته باشیم

@gocasts

#designing_distributed_systems_brendan_burns

The Sidecar Pattern
یکی از الگوهای معروف single-node الگوی sidecar هست

در این الگو هر ماشین یا صحیح تر بگیم، هر pod از دو container تشکیل شده، یکی container اصلی هست که لاجیک اصلی برنامه رو اجرا میکنه و دومین container یک کانتینر جانبی هست که مسئولیتش بهبود دادن و تقویت کردن کانتینر اصلی ست.

https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/ch02.html

@gocasts

#designing_distributed_systems_brendan_burns

به عنوان مثال تصور کنید یه legacy application دارید که سال ها پیش توسعه اون تموم شده و همچنان داره کار میکنه، اما فقط http رو پشتیبانی میکنه، و حالا شرکت تصمیم گرفته که به دلایل امنیتی همه سرویس هاشو بصورت https ارائه بده

برای برطرف کردن این موضوع دو تا راه حل داریم
یک اینکه تیم توسعه این نرم افزار قدیمی رو دوباره پیدا کنیم و محیط توسعه قدیمی رو مجددا راه اندازی کنیم و یه build جدید بگیریم که پشتیبانی https رو هم داره
راه دوم اینه که یه کانتینر جانبی اضافه کنیم که بصورت proxy همه درخواست های کاربر رو بصورت https بگیره و پاسخ اپلیکیشن رو بهشون پس بده!!
مثلا میتونیم از nginx به عنوان sidecar استفاده کنیم

@gocasts

#designing_distributed_systems_brendan_burns

Modular Applicatoin Containers
الگوی sidecar به ما این اجازه رو میده که بتونیم یک سری modular container داشته باشیم که در سرویس های مختلف ازشون استفاده کنیم.
مثلا تصور کنید که شما میخواید برای همه سرویس های زیرساخت تون عملکرد پروسه هارو مانیتور کنید و مصرف منابع رو مشاهده کنید.
یک راهش اینه که همه سرویس هایی که ممکنه به زبان های مختلفی هم توسعه داده شده رو آپدیت کنید و برای همه اون ها یک مسیر /topz اضافه کنید که با فراخوانیش میشه منابع اون پروسه رو مانیتور کرد. که خب این راه حل نیاز داره همه سرویس ها بروزرسانی بشن که خیلی کار سختیه و همچنین اساسا خیلی از زبان ها محدودیت دارن در بدست آوردن چنین اطلاعاتی و خروجی همه اون سرویس ها یکسان نمیشه.

الگوی sidecar این ایده رو میده که ما یه sidecar container داشته باشیم که از PID namespace یکسانی با container اصلی برخوردار هست و تمامی اطلاعات پروسه های container اصلی رو میتونه ببینه، اینطوری ما با فقط نوشتن یک کانتینر ساده میتونیم بصورت ماژولار همه سرویس هامون رو ارتقا بدیم و از مانیتورینگ منابعشون لذت ببریم.

حتی modularity این امکان رو میده که ما دیگه نیاز نداشته باشیم توسعه بدیم و از community و دنیای open-source کمک بگیریم. مثلا در مورد همین /topz میشه از این ایمیج استفاده کرد..

docker run --pidcontainer:${APP_ID} -p 8080:8080 brendanburns/topz:db0fa58 /server --address=0.0.0.0:8080

@gocasts

#designing_distributed_systems_brendan_burns

Designing Sidecars fo Modularity and Reusability
مبحث آخری که در مورد الگوی sidecar در کتاب مطرح میشه بحث طراحی sidecar container هست که باید بگونه ای باشه که قابلیت modularity و reusability داشته باشه
برای طراحی چنین container ی باید موارد زیر رو رعایت کنیم:

- Parameterizing your containers
این موضوع خیلی مهمه، چون اگه نشه کانتینر جانبی رو کانفیگ کرد نمیشه اونو در کنار سرویس های مختلف استفاده کرد، تصور کنید یه nginx رو که فقط به یه دامنه خاص گوش میده.. و آدرس این دامنه hardcode شده باشه داخل sidecar container...، خب طبیعیه که نمیشه این کانتینر رو در کنار سرویس های مختلف استفاده کرد
برای این قضیه هم میشه از command line arguments ها کمک گرفت هم از environment variable ها که استفاده از متغیرهای محیطی راه حل بهتریه عموما

- Creating the API surface of your container
برای کانتیتر جانبی باید یک API ثابت و پایدار تعریف کرد که در طول زمان دچار تغییرات ناسازگار نشه، زیرا وقتی یه کانتینر جانبی در کنار سرویس های مختلف استفاده میشه، ایجاد broken change در کانتینر جانبی عملکرد همه اون سرویس هارو تحت تاثیر قرار میده
به عنوان مثال برای همان nginx container تصور کنید اسم پارامتری که دامنه رو از env میخونه از ADDRESS به DOMAIN تغییر کنه، با همین تغییر کوچیک، در صورت بروزرسانی sidecar خیلی از سرویس ها دیگه مختل میشه کارشون

- Documenting the operation of your container
نکته آخر هم بحث مستندات هست که اگه قرار یه کانتینر جانبی بصورت گسترده استفاده بشه باید حتما مستندات خوبی داشته باشه که برای همه قابل فهم و استفاده باشه، مثلا یکی از راه های مستند کردن نوشتن کامنت های توضیحی در فایل Dockerfile مربوط به کانتینر هست

@gocasts

#designing_distributed_systems_brendan_burns

ضمنا من یه توضیحی بدم که چرا سیستم های توزیع شده و دونستن الگوهاشون مهمه؟ به این دلیل که عموما اکثر محیط های توسعه ای که در چند سال اخیر ما باهاشون سر و کار داشتیم بصورت توزیع شده بوده و هستن، و گاهی خودمون حتی متوجه این موضوع نیستیم، خیلی وقت ها فکر میکنیم چون برنامه ای که نوشتیم بصورت یکپارچه (monolith) هست پس الگوهای توزیع شده دیگه کاربردی ندارن در حالیکه از این موضوع غافل هستیم که در لحظه داریم به انواع مختلف از الگوهای سرویس های توزیع شده استفاده میکنیم و خودمون خبر نداریم. دونستن این الگوها خیلی کمک میکنه سیستم های بهتری طراحی و پیاده سازی کنیم. بنابراین من با کتاب عالی Designing Distributed Systems شروع کردم که فوق العاده کتاب مختصر و مفیدیه

@gocasts


https://www.amazon.co.uk/Designing-Distributed-Systems-Brendan-Burns/dp/1491983647

#distributedsystems #bookreading

#designing_distributed_systems_brendan_burns

یه نکته ای که تو الگوی sidecar باید بهش توجه بشه اینه که این دو تا container اصطلاحا tightly coupled هستن، یعنی یه سری shared resource دارن، مثلا در مثال nginx proxy دو تا container باید یه network داشته باشن
یا مثلا وقتی از fluentd برای log aggregate کردن استفاده میشه به عنوان sidecar باید یه shared mounted volume وجود داشته باشه که application container داخل اون لاگ هاشو میریزه و fluentd container اون لاگ هارو از فایل میخونه و consume میکنه

اصلاحا به container هایی که تو یه گروه هستن، با هم schedule میشن و shared resource دارن pod گفته میشه
تو الگوی sidecar همیشه کانتینر داخل pod مربوط به application قرار میگیره

#designing_distributed_systems_brendan_burns

@gocasts

The Ambassadors pattern
الگوی ambassadors یکی دیگه از single-node pattern هاست که جلوی app container میشینه و ارتباط app رو با دنیای بیرون مدیریت میکنه.

بر خلاف sidecar pattern که عموما یک functionality به app اضافه میکرد الگوی ambassadors عموما در خروجی app مداخله میکنه و تعامل با دنیای بیرون app از طریق ambassador container صورت میگیره

https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/ch03.html

#designing_distributed_systems_brendan_burns

@gocasts

using an Ambassador to Shard a Service
خیلی از اوقات در scale بالا مدیریت حجم زیادی از داده ها در یک single machine ممکن نیست و به اجبار داده ها باید بین چندین instance مختلف shard بشن

این موضوع نباید تغییری در application برای ارتباط با storage layer ایجاد کنه

#designing_distributed_systems_brendan_burns

@gocasts

شاید ایده اولیه ای که به ذهن میرسه این باشه که خود application این موضوع رو مدیریت کنه و با دونستن اینکه چه تعداد shard وجود داره، هر بار بر اساس الگوریتم و داده مورد نظر انتخاب کنه که کوئری رو به کدوم instance بفرسته
اما این راه حل پیچیدگی زیادی به لاجیک اضافه میکنه و مشکلات زیادی داره، از جمله اینکه سیستم باید از سلامت shard instance ها با خبر باشه

راه حل بهتر اینه که یک ambassador service در هر pod مربوط به application باشه که با توجه به کوئری ورودی تعیین کنه درخواست رو به کدوم shard instance بفرسته، مزیت اصلی این الگو اینه که application نیاز نیست تغییری ایجاد کنه و مثل معمول صرفا به یک local database service درخواست هاشو میفرسته، و این ambassador service هست که تمامی پیچیدگی های sharding رو مدیریت میکنه.
مزیت دوم این الگو modularity هست، زیرا میتوان به راحتی این ambassador container رو برای طیف زیادی از application های مختلف استفاده کرد بدون اینکه نیاز باشه در لاجیک اون application ها تغییری ایجاد بشه

به عنوان مثال اگه شما میخواید redis رو بصورت shard شده استفاده کنید میتونید از کد زیر برای پیاده سازی چنین معماری ای در kubernetes استفاده کنید:
https://github.com/brendandburns/designing-distributed-systems/blob/master/ambassadors/redis-shards.yaml

#designing_distributed_systems_brendan_burns

@gocasts

Using an Ambassador for Service Brokering
یکی از ملزومات portable کردن application برای استفاده در محیط های مختلف بحث service discovery هست.

تصور کنید که application شما در محیط production باید به یه public cloud متصل بشه مثل AWS RDS و برای محیط staging به یک physical datacenter یا private cloud متصل بشه

مدیریت کردن این موضوع لاجیک application رو پیچیده میکنه، زیرا بر اساس محیطی که در اون قرار داره باید بحث service discovery رو مدیریت کنه.

بهتر اینه که یک service broker بصورت ambassador container داشته باشیم، که مسئولیت این موضوع رو قبول کنه، و application طبق معمول صرفا به یه local database متصل بشه

#designing_distributed_systems_brendan_burns

@gocasts