Go Casts 🚀
سوال بعدی که مطرح شد این بود که از نگاه یه teach lead که چندین engineer رو مدیریت میکنه و باید task هارو بهشون assign کنه یه چالشی که وجود داره اینه که بسیاری از این مهندسین از زبان های قدیمی تر php و c# میان و شما باید به عنوان tech lead هم به quality کد…
سوال بعدی که مطرح شد این بود که نزدیک به یک دهه است که داریم با گولنگ محصول توسعه میدیم و حالا قراره generic اضافه بشه. به نظر شما generic چه تاثیری روی تجربه ما با گولنگ خواهد داشت؟
بیل پاسخ داد که من نمیخوام از جنریک استفاده کنم پس نمیتونم تجربه مو بگم!
بیل ادامه داد که جنریک یک انتخابه اما من پیشنهاد میکنم که اگه میخواید حتما با جنریک یه سری experiment داشته باشید اما برنامه ریزی نکنید که در کدهاتون ازش استفاده کنید. چون مدتی طول میکشه که best practice هاش مشخص بشه
جنریک یعنی polymorphism، و ما در لحظه با وجود interface در گولنگ polymorphism داریم، اما interface یک run-time polymorphism هست و generic یک compile-time polymorphism هست. احتمالا جایی که تو کد interface{} استفاده میکنید و از reflection استفاده میکنید، این قسمت ها جایی هست که generic باید استفاده بشه که این یعنی همون استفاده classic و درست از generic. در غیر از اینجاها من لزومی بر استفاده اش نمیبینم.
من هم در مورد جنریک هیجان زده هستم، اما اینکه بخوام در پروداکشن ازش استفاده کنم؟ خیر
#bill_kennedy
@gocasts
بیل پاسخ داد که من نمیخوام از جنریک استفاده کنم پس نمیتونم تجربه مو بگم!
بیل ادامه داد که جنریک یک انتخابه اما من پیشنهاد میکنم که اگه میخواید حتما با جنریک یه سری experiment داشته باشید اما برنامه ریزی نکنید که در کدهاتون ازش استفاده کنید. چون مدتی طول میکشه که best practice هاش مشخص بشه
جنریک یعنی polymorphism، و ما در لحظه با وجود interface در گولنگ polymorphism داریم، اما interface یک run-time polymorphism هست و generic یک compile-time polymorphism هست. احتمالا جایی که تو کد interface{} استفاده میکنید و از reflection استفاده میکنید، این قسمت ها جایی هست که generic باید استفاده بشه که این یعنی همون استفاده classic و درست از generic. در غیر از اینجاها من لزومی بر استفاده اش نمیبینم.
من هم در مورد جنریک هیجان زده هستم، اما اینکه بخوام در پروداکشن ازش استفاده کنم؟ خیر
#bill_kennedy
@gocasts
❤2👍1
Go Casts 🚀
سوال بعدی که مطرح شد این بود که نزدیک به یک دهه است که داریم با گولنگ محصول توسعه میدیم و حالا قراره generic اضافه بشه. به نظر شما generic چه تاثیری روی تجربه ما با گولنگ خواهد داشت؟ بیل پاسخ داد که من نمیخوام از جنریک استفاده کنم پس نمیتونم تجربه مو بگم!…
سوال بعدی این بود که دغدغه ای که وجود داره اینه که چون جنریک یک feature جدید هست و همه در موردش هیجان زده هستن امکان داره کد های زیادی در سطح پروداکشن دچار generic pollution بشن که خیلی میتونه بد باشه، چیکار کنیم که این اتفاق نیفته؟
گفت این به شما و تیم شما بستگی داره که نظم و قانون داشته باشید، شما نباید به دنبال طراحی کردن polymorphism باشید، شما باید polymorphism رو explore کنید. اگه شما و کل تیم به این نتیجه رسیدید که تنها راه حل این مساله استفاده از generic هست، خیلی خب پس استفاده اش کنید. جنریک رو یه ابزار ببینید و مثل هر ابزار دیگه ای مطمئن بشید که باید ازش در جای درست استفاده کنید.
#bill_kennedy
@gocasts
گفت این به شما و تیم شما بستگی داره که نظم و قانون داشته باشید، شما نباید به دنبال طراحی کردن polymorphism باشید، شما باید polymorphism رو explore کنید. اگه شما و کل تیم به این نتیجه رسیدید که تنها راه حل این مساله استفاده از generic هست، خیلی خب پس استفاده اش کنید. جنریک رو یه ابزار ببینید و مثل هر ابزار دیگه ای مطمئن بشید که باید ازش در جای درست استفاده کنید.
#bill_kennedy
@gocasts
❤1
Go Casts 🚀
سوال بعدی این بود که دغدغه ای که وجود داره اینه که چون جنریک یک feature جدید هست و همه در موردش هیجان زده هستن امکان داره کد های زیادی در سطح پروداکشن دچار generic pollution بشن که خیلی میتونه بد باشه، چیکار کنیم که این اتفاق نیفته؟ گفت این به شما و تیم شما…
سوال بعدی که پرسیده شد اینه که بر اساس تجربه شما، رایج ترین مشکلی که در نرم افزارهای گولنگی وجود داره چیه؟
گفت از نظر من مشکلی که خیلی دیده میشه اینه که افراد برای پروژه هاشون یک solid project structure ندارن. این code structure باید بگونه ای باشه که guideline و فلسفه داشته باشه. من خیلی میگم که نباید پکیج هایی وجود داشته باشه مثل common یا پکیجی مثل types که کل پروژه داره ازش استفاده میکنه. این وابسته کردن پروژه به یک پکیج خاص میتونه باعث بشه که کل پروژه بایک تغییر در این پکیج به هم بریزه. و این چیزیه که من در دوره ultimate service درس میدم
#bill_kennedy
@gocasts
گفت از نظر من مشکلی که خیلی دیده میشه اینه که افراد برای پروژه هاشون یک solid project structure ندارن. این code structure باید بگونه ای باشه که guideline و فلسفه داشته باشه. من خیلی میگم که نباید پکیج هایی وجود داشته باشه مثل common یا پکیجی مثل types که کل پروژه داره ازش استفاده میکنه. این وابسته کردن پروژه به یک پکیج خاص میتونه باعث بشه که کل پروژه بایک تغییر در این پکیج به هم بریزه. و این چیزیه که من در دوره ultimate service درس میدم
#bill_kennedy
@gocasts
❤1
Go Casts 🚀
سوال بعدی که پرسیده شد اینه که بر اساس تجربه شما، رایج ترین مشکلی که در نرم افزارهای گولنگی وجود داره چیه؟ گفت از نظر من مشکلی که خیلی دیده میشه اینه که افراد برای پروژه هاشون یک solid project structure ندارن. این code structure باید بگونه ای باشه که guideline…
سوال بعدی این بود که clean architecture یا hexagonal architecture یه معماری خیلی محبوبه که در پروژه های گولنگی استفاده میشه، آیا شما فکر میکنید این معماری برای گولنگ best fit هست یا این در مقابل فلسفه شماست؟
جواب داد که دهه ۹۰ میلادی یک کتابی منتشر شد که الگوهای رایج oop رو نوشته بود (منظورش gang of four بود) و من چندین بار تلاش میکردم که چالش های پیش روی خودمو سعی کنم بایکی از الگوهای اون کتاب منطبق کنم که بتونم از راه حل هاش استفاده کنم. اما اصلا باهاش راحت نبودم و دیگه هیچوقت چنین کاری رو نکردم. من برای پروژه هایی که دارم سعی میکنم بر اساس دانش و تجربه خودم و حتی اگه لازم باشه از دانش تجربه دیگران کمک میگیرم و بر اساس این تجربه و دانش سعی می کنم پروژه رو با حداقل ترین چیزهایی که لازم داره طراحی کنم. این کاریه که در ultimate service هم کردم. و من همیشه میگم که complexity اضافه به پروژه اضافه نکنید در حالیکه پروژه اصلا اون رو نیاز نداره. اضافه کردن complexity باعث کند شدن توسعه پروژه میشه و ship کردن کد رو دچار اخلال میکنه.
#bill_kennedy
@gocasts
جواب داد که دهه ۹۰ میلادی یک کتابی منتشر شد که الگوهای رایج oop رو نوشته بود (منظورش gang of four بود) و من چندین بار تلاش میکردم که چالش های پیش روی خودمو سعی کنم بایکی از الگوهای اون کتاب منطبق کنم که بتونم از راه حل هاش استفاده کنم. اما اصلا باهاش راحت نبودم و دیگه هیچوقت چنین کاری رو نکردم. من برای پروژه هایی که دارم سعی میکنم بر اساس دانش و تجربه خودم و حتی اگه لازم باشه از دانش تجربه دیگران کمک میگیرم و بر اساس این تجربه و دانش سعی می کنم پروژه رو با حداقل ترین چیزهایی که لازم داره طراحی کنم. این کاریه که در ultimate service هم کردم. و من همیشه میگم که complexity اضافه به پروژه اضافه نکنید در حالیکه پروژه اصلا اون رو نیاز نداره. اضافه کردن complexity باعث کند شدن توسعه پروژه میشه و ship کردن کد رو دچار اخلال میکنه.
#bill_kennedy
@gocasts
❤2
Go Casts 🚀
سوال بعدی این بود که clean architecture یا hexagonal architecture یه معماری خیلی محبوبه که در پروژه های گولنگی استفاده میشه، آیا شما فکر میکنید این معماری برای گولنگ best fit هست یا این در مقابل فلسفه شماست؟ جواب داد که دهه ۹۰ میلادی یک کتابی منتشر شد که…
سوال بعدی این بود که تو پروژه هامون چه موقع باید یه چالشی رو داخل پروژه حل کنیم و به پروژه complexity اضافه کنیم (مثل cache کردن) و چه موقع باید از ابزارهای خارجی استفاده کنیم (مثل redis) و پروژه هامون رو بهشون وابسته کنیم؟
بیل پاسخ داد که این موضوع خیلی به این بستگی داره که واقعا چالش چیه و چقدر complexity به پروژه اضافه میکنه؟
مثلا من توصیه میکنم برای نسخه اولیه سرویس با ساده سازی اونو به پروژه (سرویس) خودم اضافه میکردم، بعد اگه لازم بود به سرویس اضافه بشه ولی اگه مدیریت اون پیچیدگی خیلی چالش و دغدغه داشته باشه خب باید از سرویس خارجی استفاده بشه. و البته بستگی داره که شما یه تیم کوچیک ۲، ۳ نفره هستید یا یک شرکت بزرگ با کلی نیروی مختلف در حوزه های مختلف
#bill_kennedy
@gocasts
بیل پاسخ داد که این موضوع خیلی به این بستگی داره که واقعا چالش چیه و چقدر complexity به پروژه اضافه میکنه؟
مثلا من توصیه میکنم برای نسخه اولیه سرویس با ساده سازی اونو به پروژه (سرویس) خودم اضافه میکردم، بعد اگه لازم بود به سرویس اضافه بشه ولی اگه مدیریت اون پیچیدگی خیلی چالش و دغدغه داشته باشه خب باید از سرویس خارجی استفاده بشه. و البته بستگی داره که شما یه تیم کوچیک ۲، ۳ نفره هستید یا یک شرکت بزرگ با کلی نیروی مختلف در حوزه های مختلف
#bill_kennedy
@gocasts
❤2
Go Casts 🚀
سوال بعدی این بود که تو پروژه هامون چه موقع باید یه چالشی رو داخل پروژه حل کنیم و به پروژه complexity اضافه کنیم (مثل cache کردن) و چه موقع باید از ابزارهای خارجی استفاده کنیم (مثل redis) و پروژه هامون رو بهشون وابسته کنیم؟ بیل پاسخ داد که این موضوع خیلی…
سوال بعدی این بود که یادگیری concurrency تو گولنگ کار ساده ای نیست، هم به این دلیل که نسبت به زبان های رایج دیگه شیوه متفاوتی داره و هم اینکه در پروژه های تیپیکال هم خود کتابخونه و پکیج هایی که استفاده میکنیم این موضوع رو هندل میکنن و برنامه نویس کمتر میتونه خودش با concurrency سر و کله بزنه، برای اینکه concurrency رو در حد production بتونیم یادبگیریم باید چیکار کنیم؟
بیل پاسخ داد که اول باید مطمئن بشید که concurrency برای رفع مساله ای که پیش روتونه لازمه. مفهوم concurrency یعنی out of order execution، یعنی شما چند تا کار رو میخوای انجام بدی و مهم نیست ترتیب اجراشون چی باشه. این میشه concurrency. شما باید به دنبال چالش هایی باشی که out of order execution لازم داشته باشن، مثل همون سرویس distributed chat. یا مثلا من تو تمریناتم یه مثال barber shop دارم که برای آموزش concurrency ازش استفاده میکنم.
من سعی میکنم چالش رو بصورت single thread حل کنم که به اندازه کافی سخت خواهد بود، بعد اگر تونستم از مزیت concurrency بهره ببرم کد رو refactor میکنم. کلا multi thread programming خیلی سخته و من نمیگم که گولنگ اونو ساده کرده، من میگم گولنگ به ما ابزار میده، اگه ازش درست استفاده کنیم، به ما کمک میکنه، اگه درست استفاده نکنیم به پروژه مون complexity اضافه کردیم.
اتفاقی که خیلی میفتاد و تو خیلی از کدها همه جا از channel استفاده میشد و تو ریفکتور میدیدی که حذفش میکردن! اتفاقی که ممکنه برای جنریک هم بیفته
فکر کنم این باشه
https://github.com/ardanlabs/gotraining/blob/master/topics/go/algorithms/fun/barber/shop/shop.go
#bill_kennedy
@gocasts
بیل پاسخ داد که اول باید مطمئن بشید که concurrency برای رفع مساله ای که پیش روتونه لازمه. مفهوم concurrency یعنی out of order execution، یعنی شما چند تا کار رو میخوای انجام بدی و مهم نیست ترتیب اجراشون چی باشه. این میشه concurrency. شما باید به دنبال چالش هایی باشی که out of order execution لازم داشته باشن، مثل همون سرویس distributed chat. یا مثلا من تو تمریناتم یه مثال barber shop دارم که برای آموزش concurrency ازش استفاده میکنم.
من سعی میکنم چالش رو بصورت single thread حل کنم که به اندازه کافی سخت خواهد بود، بعد اگر تونستم از مزیت concurrency بهره ببرم کد رو refactor میکنم. کلا multi thread programming خیلی سخته و من نمیگم که گولنگ اونو ساده کرده، من میگم گولنگ به ما ابزار میده، اگه ازش درست استفاده کنیم، به ما کمک میکنه، اگه درست استفاده نکنیم به پروژه مون complexity اضافه کردیم.
اتفاقی که خیلی میفتاد و تو خیلی از کدها همه جا از channel استفاده میشد و تو ریفکتور میدیدی که حذفش میکردن! اتفاقی که ممکنه برای جنریک هم بیفته
فکر کنم این باشه
https://github.com/ardanlabs/gotraining/blob/master/topics/go/algorithms/fun/barber/shop/shop.go
#bill_kennedy
@gocasts
GitHub
gotraining/topics/go/algorithms/fun/barber/shop/shop.go at master · ardanlabs/gotraining
Go Training Class Material : . Contribute to ardanlabs/gotraining development by creating an account on GitHub.
❤1👍1
Go Casts 🚀
سوال بعدی این بود که یادگیری concurrency تو گولنگ کار ساده ای نیست، هم به این دلیل که نسبت به زبان های رایج دیگه شیوه متفاوتی داره و هم اینکه در پروژه های تیپیکال هم خود کتابخونه و پکیج هایی که استفاده میکنیم این موضوع رو هندل میکنن و برنامه نویس کمتر میتونه…
سوال بعدی که پرسیدم این بود که شما گولنگ رو بیشتر یه زبان data oriented میدونید تا object oriented. چه ویژگی های گولنگ باعث شده که اینطور فکر کنید؟
که اولش این نقل رو از rob pike گفت
Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
بعدش گفت که اگه شما data رو نشناسی در واقع problem رو نمیشناسی و نمیتونی حلش کنی. چون هر کدی که ما مینویسیم و هر تابعی فقط داره data transformation میکنه.
یه نکته خیلی مهم برای senior بودن شما، اینه که data semantic های گولنگ رو بشناسی و بدونی از کدوم چه وقت استفاده کنی. این که value semantic که یه نسخه از دیتارو کپی میکنه در پروسه زنجیره فراخوانی توابع (function call chain) و pointer semantic که داره دیتارو به اشتراک میذاره چه تفاوت هایی با هم دارن. و من value semantic رو خیلی استفاده میکنم چون مزایای خیلی زیادی داره، هرجا که بتونم ازش استفاده میکنم.
https://users.ece.utexas.edu/~adnan/pike.html
#bill_kennedy
@gocasts
که اولش این نقل رو از rob pike گفت
Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
بعدش گفت که اگه شما data رو نشناسی در واقع problem رو نمیشناسی و نمیتونی حلش کنی. چون هر کدی که ما مینویسیم و هر تابعی فقط داره data transformation میکنه.
یه نکته خیلی مهم برای senior بودن شما، اینه که data semantic های گولنگ رو بشناسی و بدونی از کدوم چه وقت استفاده کنی. این که value semantic که یه نسخه از دیتارو کپی میکنه در پروسه زنجیره فراخوانی توابع (function call chain) و pointer semantic که داره دیتارو به اشتراک میذاره چه تفاوت هایی با هم دارن. و من value semantic رو خیلی استفاده میکنم چون مزایای خیلی زیادی داره، هرجا که بتونم ازش استفاده میکنم.
https://users.ece.utexas.edu/~adnan/pike.html
#bill_kennedy
@gocasts
Go Casts 🚀
سوال بعدی که پرسیدم این بود که شما گولنگ رو بیشتر یه زبان data oriented میدونید تا object oriented. چه ویژگی های گولنگ باعث شده که اینطور فکر کنید؟ که اولش این نقل رو از rob pike گفت Data dominates. If you've chosen the right data structures and organized…
در آخر هم من از بیل تشکر کردم به خاطر حضورش تو جلسه و به اشتراک گذاشتن تجربیاتش با برنامه نویس های ایرانی
بیل هم گفت که من همیشه اگه کسی تو توییتر و اسلک بهم پیام بده سعی میکنم در حد توانم بهش کمک کنم.
بنده هم این موضوع رو تایید میکنم واقعا بیل خیلی با روی باز جواب میده و اگه سوالی دارید میتونید ازش بپرسید و برای یادگیری گولنگ خیلی میتونه کمکتون کنه
#bill_kennedy
@gocasts
بیل هم گفت که من همیشه اگه کسی تو توییتر و اسلک بهم پیام بده سعی میکنم در حد توانم بهش کمک کنم.
بنده هم این موضوع رو تایید میکنم واقعا بیل خیلی با روی باز جواب میده و اگه سوالی دارید میتونید ازش بپرسید و برای یادگیری گولنگ خیلی میتونه کمکتون کنه
#bill_kennedy
@gocasts
Audio
توضیحاتی در مورد جلسه با بیل کندی
اون repository ی که گفتم
https://github.com/ardanlabs/gotraining/blob/master/topics/go/README.md
پادکستی که اشاره شد
https://changelog.com/gotime/172
دوره آموزشی که ازش نام بردم
https://courses.ardanlabs.com/courses/ultimate-service-3-0
#bill_kennedy
@gocasts
اون repository ی که گفتم
https://github.com/ardanlabs/gotraining/blob/master/topics/go/README.md
پادکستی که اشاره شد
https://changelog.com/gotime/172
دوره آموزشی که ازش نام بردم
https://courses.ardanlabs.com/courses/ultimate-service-3-0
#bill_kennedy
@gocasts
سلام به همه دوستان
امروز میخوام کمی در مورد این صحبت کنم که چطور کیفیت کار خودتون و محصولی که دارید توسعه میدید رو ارزیابی کنید.
مورد توجه استارت آپ ها، مدیرهای محصول و بچه های فنی
The four engineering metrics that will streamline your software delivery
در طول مدت این چند سالی که خدا توفیق داده تو استارت آپ ها و شرکت های مختلف نقش کوچیکی تو توسعه محصول نرم افزاری داشتم، همیشه این نکته برام سوال بود که با چه معیار و metricی میشه عملکرد تیم رو سنجید. احتمالا معیارهای خیلی زیاد و متفاوتی وجود داره. اما من معیارهایی که تو این مقاله ذکر شده رو خیلی دوست دارم و درست میدونم از این لحاظ که هدف رو توسعه محصول در نظر گرفته نه کیفیت فنی محصول یا چیز دیگه.
این مقاله نسبتا کوتاه رو میتونید از اینجا بخونید
https://stackoverflow.blog/2021/11/29/the-four-engineering-metrics-that-will-streamline-your-software-delivery
Deployment frequency
با چه فراوانی ای نسخه جدید روی پروداکشن میره. این مورد خیلی بستگی داره که محصول شما تو چه استیجی هست. اما اگه لانچ کردید، احتمالا هفته ای یک یا چند دیپلویمنت باید داشته باشید، اگه بیشتر از یک هفته طول میکشه احتمالا یه جای کار داره میلنگه!
Mean change lead time
چقدر طول میکشه از زمانی که کد commit میشه تا اینکه روی پروداکشن اجرا بشه. این موضوع بیشتر سرعت تیم فنی رو نشون میده و همچنین اینکه شما چقدر به پروسه ci/cd تو پروژه تون اهمیت میدید.
Mean time to recovery
چقدر طول میکشه از یه bugی که گزارش میشه هر failure دیگه ای recover بشه سیستم. این موضوع بیشتر استراتژی های failure recovery رو هدف قرار میده و یه نکته پنهان هم داره، اینکه شما چقدر observability و monitoring براتون مهمه. چون software خوب اونیه که observability بالایی داشته باشه. یکی از نکاتی که observability خیلی کمک میکنه همینه که شما سریعتر باگ و مشکل رو پیدا کنید و فیکس کنید.
Change failure rate
با چه نرخی release های جدید باعث ایجاد failure میشه. این هم طبیعتا کیفیت فنی محصول رو میرسونه، چقدر محصول reliable هست. این معیار یکی از اون معیارهایی ست که نه تنها کیفیت محصول بلکه کیفیت فنی اعضای توسعه دهنده رو هم بازگو میکنه. هر چقدر تیم شما با تجربه تر باشه، معماری درستی رو انتخاب کرده باشه و تلاش زیادی برای پیاده سازی و تست محصول کرده باشه این نرخ باید کمتر باشه.
البته کاملا متوجه هستم که محصولات نرم افزاری ذاتا خیلی متنوع هستن و بسته به اندازه تیم و بیزینس میتونه معیارهای خیلی متفاوتی وجود داشته باشه. اما من این معیار ها رو معیارهای خیلی خوب و درستی برای تیم های استارت آپی میبینم.
حتی شما به عنوان برنامه نویس میتونید با این معیارها کیفیت کار خودتون رو هم بسنجید که محصولی که تولید کردید چه نمره ای داره.
صبحتون بخیر و دمتون گرم 🌹
#software_delivery #engineering_metrics
@gocasts
امروز میخوام کمی در مورد این صحبت کنم که چطور کیفیت کار خودتون و محصولی که دارید توسعه میدید رو ارزیابی کنید.
مورد توجه استارت آپ ها، مدیرهای محصول و بچه های فنی
The four engineering metrics that will streamline your software delivery
در طول مدت این چند سالی که خدا توفیق داده تو استارت آپ ها و شرکت های مختلف نقش کوچیکی تو توسعه محصول نرم افزاری داشتم، همیشه این نکته برام سوال بود که با چه معیار و metricی میشه عملکرد تیم رو سنجید. احتمالا معیارهای خیلی زیاد و متفاوتی وجود داره. اما من معیارهایی که تو این مقاله ذکر شده رو خیلی دوست دارم و درست میدونم از این لحاظ که هدف رو توسعه محصول در نظر گرفته نه کیفیت فنی محصول یا چیز دیگه.
این مقاله نسبتا کوتاه رو میتونید از اینجا بخونید
https://stackoverflow.blog/2021/11/29/the-four-engineering-metrics-that-will-streamline-your-software-delivery
Deployment frequency
با چه فراوانی ای نسخه جدید روی پروداکشن میره. این مورد خیلی بستگی داره که محصول شما تو چه استیجی هست. اما اگه لانچ کردید، احتمالا هفته ای یک یا چند دیپلویمنت باید داشته باشید، اگه بیشتر از یک هفته طول میکشه احتمالا یه جای کار داره میلنگه!
Mean change lead time
چقدر طول میکشه از زمانی که کد commit میشه تا اینکه روی پروداکشن اجرا بشه. این موضوع بیشتر سرعت تیم فنی رو نشون میده و همچنین اینکه شما چقدر به پروسه ci/cd تو پروژه تون اهمیت میدید.
Mean time to recovery
چقدر طول میکشه از یه bugی که گزارش میشه هر failure دیگه ای recover بشه سیستم. این موضوع بیشتر استراتژی های failure recovery رو هدف قرار میده و یه نکته پنهان هم داره، اینکه شما چقدر observability و monitoring براتون مهمه. چون software خوب اونیه که observability بالایی داشته باشه. یکی از نکاتی که observability خیلی کمک میکنه همینه که شما سریعتر باگ و مشکل رو پیدا کنید و فیکس کنید.
Change failure rate
با چه نرخی release های جدید باعث ایجاد failure میشه. این هم طبیعتا کیفیت فنی محصول رو میرسونه، چقدر محصول reliable هست. این معیار یکی از اون معیارهایی ست که نه تنها کیفیت محصول بلکه کیفیت فنی اعضای توسعه دهنده رو هم بازگو میکنه. هر چقدر تیم شما با تجربه تر باشه، معماری درستی رو انتخاب کرده باشه و تلاش زیادی برای پیاده سازی و تست محصول کرده باشه این نرخ باید کمتر باشه.
البته کاملا متوجه هستم که محصولات نرم افزاری ذاتا خیلی متنوع هستن و بسته به اندازه تیم و بیزینس میتونه معیارهای خیلی متفاوتی وجود داشته باشه. اما من این معیار ها رو معیارهای خیلی خوب و درستی برای تیم های استارت آپی میبینم.
حتی شما به عنوان برنامه نویس میتونید با این معیارها کیفیت کار خودتون رو هم بسنجید که محصولی که تولید کردید چه نمره ای داره.
صبحتون بخیر و دمتون گرم 🌹
#software_delivery #engineering_metrics
@gocasts
Stack Overflow Blog
The four engineering metrics that will streamline your software delivery
Productive teams get product fixes and features out the door fast. Here's the metrics to check to see how your team is delivering.
❤2
go_talk-20091030.pdf
241.7 KB
این یکی از اولین ارائه های Rob Pike هست برای معرفی گولنگ. مربوط به سال ۲۰۰۹ میشه (چند روز بعد از اعلام عمومی) یعنی تقریبا دو سال بعد از تولد گولنگ و ۲ سال قبل از ارائه نسخه پایدار v1. خوندنش خالی از لطف نیست.
نکته قابل توجهش اینه که همون موقع هم generic یکی از دغدغه های اصلیشون بوده و چون راه حل خوبی براش نداشتن ارائه ش ندادن
این صحبت های Rob Pike در مورد generic هست:
Go does not have generic types, etc.
We don't yet understand the right semantics for them given Go's type system but we're still thinking. They will add complexity so must be done right.
Generics would definitely be useful, though maps, slices, and interfaces address many common use cases.
این ویدیو کوتاه هم از معرفی Go هست که Russ Cox صحبت میکنه و تعریف کوتاهش از گولنگ واقعا همونیه که باعث شده محبوب و قدرتمند بشه
Go is a fast, fun and productive language
https://www.youtube.com/watch?v=wwoWei-GAPo
https://opensource.googleblog.com/2009/11/hey-ho-lets-go.html
https://go.dev/blog/go1
#go #generic
@gocasts
نکته قابل توجهش اینه که همون موقع هم generic یکی از دغدغه های اصلیشون بوده و چون راه حل خوبی براش نداشتن ارائه ش ندادن
این صحبت های Rob Pike در مورد generic هست:
Go does not have generic types, etc.
We don't yet understand the right semantics for them given Go's type system but we're still thinking. They will add complexity so must be done right.
Generics would definitely be useful, though maps, slices, and interfaces address many common use cases.
این ویدیو کوتاه هم از معرفی Go هست که Russ Cox صحبت میکنه و تعریف کوتاهش از گولنگ واقعا همونیه که باعث شده محبوب و قدرتمند بشه
Go is a fast, fun and productive language
https://www.youtube.com/watch?v=wwoWei-GAPo
https://opensource.googleblog.com/2009/11/hey-ho-lets-go.html
https://go.dev/blog/go1
#go #generic
@gocasts
سلام دوستان، یلدا مبارک 🌹
این نقشه راه با هدف توسعه نرم افزارهای بکند و برای برنامه نویسانی ست که با گولنگ تجربه ای ندارند یا تجربه خیلی کمی دارند.
این بنده حقیر به شما اطمینان میدم که به چیزی بیشتر از موارد ذکر شده در نقشه راه برای یادگیری زبان گولنگ احتیاج نخواهید داشت. بعدش فقط کار و کار و کار. یادگیری کم و مستمر حین کار بهترین نتیجه رو میده.
اگر به صورت متمرکز روزانه بین ۲ تا ۳ ساعت وقت بذارید، نباید انجام موارد ذکر شده در نقشه راه بیشتر از ۲ ماه از شما وقت بگیره. اگر به طور متوسط روزی ۴ ساعت به یادگیری گولنگ اختصاص بدید قطعا زیر ۱ ماه آیتم های ذکر شده را میتونید مطالعه کنید.
از طریق لینک زیر میتونید نقشه راه رو مطالعه کنید
https://gocasts.ir/golang-roadmap-for-beginners?utm_source=telegram&utm_medium=message&utm_campaign=yalda
#golang #roadmap
@gocasts
این نقشه راه با هدف توسعه نرم افزارهای بکند و برای برنامه نویسانی ست که با گولنگ تجربه ای ندارند یا تجربه خیلی کمی دارند.
این بنده حقیر به شما اطمینان میدم که به چیزی بیشتر از موارد ذکر شده در نقشه راه برای یادگیری زبان گولنگ احتیاج نخواهید داشت. بعدش فقط کار و کار و کار. یادگیری کم و مستمر حین کار بهترین نتیجه رو میده.
اگر به صورت متمرکز روزانه بین ۲ تا ۳ ساعت وقت بذارید، نباید انجام موارد ذکر شده در نقشه راه بیشتر از ۲ ماه از شما وقت بگیره. اگر به طور متوسط روزی ۴ ساعت به یادگیری گولنگ اختصاص بدید قطعا زیر ۱ ماه آیتم های ذکر شده را میتونید مطالعه کنید.
از طریق لینک زیر میتونید نقشه راه رو مطالعه کنید
https://gocasts.ir/golang-roadmap-for-beginners?utm_source=telegram&utm_medium=message&utm_campaign=yalda
#golang #roadmap
@gocasts
GoCasts
ساده و سریع، نقشه راه یادگیری زبان گو - قابل توجه برنامه نویسان کم تجربه یا بی تجربه
نقشه راه کامل یادگیری گولنگ برای توسعه بکند - از نصب تا پروژه واقعی، REST API، JWT، دیتابیس، Docker و استقرار. راهنمای گام به گام برای مبتدیان
👍6
احتمالا خیلی هاتون با کانال یوتیوب TechWorld with Nana آشنا باشید، ویدیوهای آموزشی مرتب با DevOps این کانال معروفه. حالا در جدید ترین ویدیوی خودشون یه Full Course آموزشی Golang برای Beginners ها گذاشته که فکر میکنم دیدنش خالی از لطف نباشه.
Golang Tutorial for Beginners | Full Go Course
https://www.youtube.com/watch?v=yyUHQIec83I
#golang #tutorial
@gocasts
Golang Tutorial for Beginners | Full Go Course
https://www.youtube.com/watch?v=yyUHQIec83I
#golang #tutorial
@gocasts
YouTube
Golang Tutorial for Beginners | Full Go Course
Full Golang Tutorial to learn the Go Programming Language while building a simple CLI application
In this full Golang course you will learn about one of the youngest programming languages that is becoming more and more popular in the cloud engineering world…
In this full Golang course you will learn about one of the youngest programming languages that is becoming more and more popular in the cloud engineering world…
Go Casts 🚀
بیاید با هم فکر کنیم مثلا چه use-case هایی میشه واسه این الگو پیدا کرد! اگه بخوام مثالی بزنم که این الگو کارآمد باشه شاید بشه سیستم هایی که با نقشه سر و کار دارند رو مثال زد. چون تو این سیستم ها حجم داده ذاتا زیاده و در عین حال حجم محاسباتی که real-time هم…
الگوی بعدی از دنیای Distributed System ها یک الگوی خیلی جدید هست به اسم Functions and Event-Driven Processing
تا حالا الگوهایی که بررسی کردیم همه مربوط میشدن به process هایی که بصورت long-running بودن. در این الگوها سرور همیشه در حال اجراست و به درخواست ها پاسخ میده. این الگوها برای زمانی مناسب هستند که سیستم زیر لود زیادی قرار داره یا مجبوره حجم زیادی از دیتارو تو ram نگه داره یا حتی لازم هست که یه جورایی background processing انجام بده. در همه این حالت ها الگوهای long-running computation کاربرد دارند.
یه دسته دیگه از application ها هستند که لازم هست موقتا اجرا بشن و یک درخواستی رو مدیریت کنن و یا به یک event پاسخ بدن. این دسته از application ها در چند سال اخیر با ارائه محصولات FaaS(function-as-a-service) از سوی cloud provider ها رایج شده.
توجه به این نکته ضروریه که گاها serverless با event-driven FaaS اشتباه گرفته میشه. در حالیکه serverless computation دسته بزرگتری از کاربردهارو شامل میشه. مثلا سرویس های Container as a Service هم serverless هستند اما event-driven نیستند. یا شما میتونید یک open source FaaS رو روی physical server های خودتون بالا بیارید که event-driven هست اما serverless نیست. تفاوت بین FaaS و serverless مهمه برای اینکه بتونید معماری درستی برای نیازهاتون داشته باشید.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
تا حالا الگوهایی که بررسی کردیم همه مربوط میشدن به process هایی که بصورت long-running بودن. در این الگوها سرور همیشه در حال اجراست و به درخواست ها پاسخ میده. این الگوها برای زمانی مناسب هستند که سیستم زیر لود زیادی قرار داره یا مجبوره حجم زیادی از دیتارو تو ram نگه داره یا حتی لازم هست که یه جورایی background processing انجام بده. در همه این حالت ها الگوهای long-running computation کاربرد دارند.
یه دسته دیگه از application ها هستند که لازم هست موقتا اجرا بشن و یک درخواستی رو مدیریت کنن و یا به یک event پاسخ بدن. این دسته از application ها در چند سال اخیر با ارائه محصولات FaaS(function-as-a-service) از سوی cloud provider ها رایج شده.
توجه به این نکته ضروریه که گاها serverless با event-driven FaaS اشتباه گرفته میشه. در حالیکه serverless computation دسته بزرگتری از کاربردهارو شامل میشه. مثلا سرویس های Container as a Service هم serverless هستند اما event-driven نیستند. یا شما میتونید یک open source FaaS رو روی physical server های خودتون بالا بیارید که event-driven هست اما serverless نیست. تفاوت بین FaaS و serverless مهمه برای اینکه بتونید معماری درستی برای نیازهاتون داشته باشید.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
🤩2
Go Casts 🚀
الگوی بعدی از دنیای Distributed System ها یک الگوی خیلی جدید هست به اسم Functions and Event-Driven Processing تا حالا الگوهایی که بررسی کردیم همه مربوط میشدن به process هایی که بصورت long-running بودن. در این الگوها سرور همیشه در حال اجراست و به درخواست ها…
خب حالا بهتره در مورد این صحبت کنیم که FaaS چه زمانی یه انتخاب درسته
مزایای FaaS
اولین مزیتش برای developer هاست، که به شدت پروسه استقرار رو ساده میکنه و کافیه که فقط کدتون رو push کنید روی سرور که اجرا بشه همین!! نیازی نیست هیچ artifact دیگه ای رو بسازید (docker image و غیره..)
مزیت دیگه اش automatic scalability هست که با زیاد شدن ترافیک تعداد instanceهای بیشتری از function های شما روی سرور اجرا میشه که پاسخگوی درخواست ها باشن.
مزیت مهم دیگه granularity بیشتر برای طراحی distributed system ها هست. شما با داشتن container ها به یک درجه خوبی از granularity میرسید که میتونید با compose کردن اونها سیستم تون رو طراحی کنید. حالا اگه جای container شما building blockهای سیستم تون رو function در نظر بگیرید باز هم از granularity بیشتری برخوردار میشید. به این دلیل که function ها stateless هستن بنابراین سیستمی که بر پایه functionها طراحی میکنید هم modularتره و هم بیش از پیش ماژول ها از همدیگه decouple میشن. البته بیش از حد decouple شدن هم خودش میتونه یه چالش باشه و باید به این موضوع با دقت فکر کرد.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
مزایای FaaS
اولین مزیتش برای developer هاست، که به شدت پروسه استقرار رو ساده میکنه و کافیه که فقط کدتون رو push کنید روی سرور که اجرا بشه همین!! نیازی نیست هیچ artifact دیگه ای رو بسازید (docker image و غیره..)
مزیت دیگه اش automatic scalability هست که با زیاد شدن ترافیک تعداد instanceهای بیشتری از function های شما روی سرور اجرا میشه که پاسخگوی درخواست ها باشن.
مزیت مهم دیگه granularity بیشتر برای طراحی distributed system ها هست. شما با داشتن container ها به یک درجه خوبی از granularity میرسید که میتونید با compose کردن اونها سیستم تون رو طراحی کنید. حالا اگه جای container شما building blockهای سیستم تون رو function در نظر بگیرید باز هم از granularity بیشتری برخوردار میشید. به این دلیل که function ها stateless هستن بنابراین سیستمی که بر پایه functionها طراحی میکنید هم modularتره و هم بیش از پیش ماژول ها از همدیگه decouple میشن. البته بیش از حد decouple شدن هم خودش میتونه یه چالش باشه و باید به این موضوع با دقت فکر کرد.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
خب حالا بهتره در مورد این صحبت کنیم که FaaS چه زمانی یه انتخاب درسته مزایای FaaS اولین مزیتش برای developer هاست، که به شدت پروسه استقرار رو ساده میکنه و کافیه که فقط کدتون رو push کنید روی سرور که اجرا بشه همین!! نیازی نیست هیچ artifact دیگه ای رو بسازید…
معایب FaaS
معماری FaaS شمارو مجبور میکنه که تک تک اجزاء سرویس شما از همدیگه strongly decoupled باشن و این نکته درسته که سرعت توسعه سرویس رو برای شما زیاد میکنه، اما مرحله operation و maintenance روی پروداکشن رو پیچیده میکنه. تنها راه communication تابع های شما network هست و همچنین توابع local memory ندارن و مجبورن همه چیز رو در storage service ذخیره کنن. همچنین وقتی مشکلی در سرویس بوجود میاد تشخیص مشکل خیلی سخت تر میشه. چون توابع شما کاملا مستقل از هم هستن و دیباگ کد سخت خواهد بود.
راه چاره اینه که monitoring خیلی خوبی روی سرویس هاتون راه اندازی کنید که هنگام بوجود اومدن مشکل بتونید راحت source خطارو پیدا کنید. هر چند این قضیه پیچیدگی monitoring در مقابل سادگی FaaS قرار میگیره و این trade-offیه که شما حین طراحی باید توجه کنید بهش ببینید FaaS ارزشش رو داره یا خیر.
معمولا FaaS بخاطر ذات serverless بودنش در زمان اجرا time-bound هست و این مساله استفاده از FaaS رو برای انواع processing مخصوصا background processing مشکل میکنه.
همچنین بخاطر عدم داشتن local memory برای برخی استفاده ها که دیتای زیادی رو در ram لازم داره مناسب نیست. چون با هر بار اجرای تابع مجبور هستیم حجم زیادی از دیتا رو لود کنیم. لود کردن خود دیتا به اندازه کافی latency ایجاد میکنه که استفاده از FaaS رو نامناسب کنه. مثلا سرویس search یه نمونه از این درخواست هاست. شاید یه راه حل این باشه که خب با هر بار اجرای function که مجبوره دیتای زیادی رو لود کنه، جای پاسخگویی به یک درخواست، چندین درخواست پاسخ داده بشه که این latency مربوط به لود اولیه دیتا تاثیرش کم بشه. اما خب نکته ش اینه که اگه شما تابع رو برای پاسخگویی به تعداد زیادی درخواست بالا نگه دارید احتمالا به ازاء هر درخواست دارید به cloud provider هزینه بیشتری رو میپردازید که عملا overpay میشه.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
معماری FaaS شمارو مجبور میکنه که تک تک اجزاء سرویس شما از همدیگه strongly decoupled باشن و این نکته درسته که سرعت توسعه سرویس رو برای شما زیاد میکنه، اما مرحله operation و maintenance روی پروداکشن رو پیچیده میکنه. تنها راه communication تابع های شما network هست و همچنین توابع local memory ندارن و مجبورن همه چیز رو در storage service ذخیره کنن. همچنین وقتی مشکلی در سرویس بوجود میاد تشخیص مشکل خیلی سخت تر میشه. چون توابع شما کاملا مستقل از هم هستن و دیباگ کد سخت خواهد بود.
راه چاره اینه که monitoring خیلی خوبی روی سرویس هاتون راه اندازی کنید که هنگام بوجود اومدن مشکل بتونید راحت source خطارو پیدا کنید. هر چند این قضیه پیچیدگی monitoring در مقابل سادگی FaaS قرار میگیره و این trade-offیه که شما حین طراحی باید توجه کنید بهش ببینید FaaS ارزشش رو داره یا خیر.
معمولا FaaS بخاطر ذات serverless بودنش در زمان اجرا time-bound هست و این مساله استفاده از FaaS رو برای انواع processing مخصوصا background processing مشکل میکنه.
همچنین بخاطر عدم داشتن local memory برای برخی استفاده ها که دیتای زیادی رو در ram لازم داره مناسب نیست. چون با هر بار اجرای تابع مجبور هستیم حجم زیادی از دیتا رو لود کنیم. لود کردن خود دیتا به اندازه کافی latency ایجاد میکنه که استفاده از FaaS رو نامناسب کنه. مثلا سرویس search یه نمونه از این درخواست هاست. شاید یه راه حل این باشه که خب با هر بار اجرای function که مجبوره دیتای زیادی رو لود کنه، جای پاسخگویی به یک درخواست، چندین درخواست پاسخ داده بشه که این latency مربوط به لود اولیه دیتا تاثیرش کم بشه. اما خب نکته ش اینه که اگه شما تابع رو برای پاسخگویی به تعداد زیادی درخواست بالا نگه دارید احتمالا به ازاء هر درخواست دارید به cloud provider هزینه بیشتری رو میپردازید که عملا overpay میشه.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
معایب FaaS معماری FaaS شمارو مجبور میکنه که تک تک اجزاء سرویس شما از همدیگه strongly decoupled باشن و این نکته درسته که سرعت توسعه سرویس رو برای شما زیاد میکنه، اما مرحله operation و maintenance روی پروداکشن رو پیچیده میکنه. تنها راه communication تابع های…
توضیحی در مورد مدل قیمت گذاری FaaS
در FaaS مدل پرداخت per-request هست و اگه شما در دقیقه یا ساعت درخواست های کمی دارید این مدل خیلی بهتر از اینه که شما همیشه یه container داشته باشید که مجبور باشید به خاطر idle-timeش هم هزینه بدید. اما کم کم که تعداد درخواست ها زیاد میشه سرویس FaaS شما عملا همیشه در حال اجراست و اینجاست که دیگه مدل per-request خیلی هزینه بر میشه و داشتن یه container که همیشه در حال اجراست و به درخواست ها جواب میده راه حل بهتریه.
یه ایده جایگزین اینه که شما open-source FaaS رو روی Kubernetes اجرا کنید، اینطوری عملا هزینه virtual machine رو میپردازید ولی از مزایای FaaS هم بهره مند میشید.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
در FaaS مدل پرداخت per-request هست و اگه شما در دقیقه یا ساعت درخواست های کمی دارید این مدل خیلی بهتر از اینه که شما همیشه یه container داشته باشید که مجبور باشید به خاطر idle-timeش هم هزینه بدید. اما کم کم که تعداد درخواست ها زیاد میشه سرویس FaaS شما عملا همیشه در حال اجراست و اینجاست که دیگه مدل per-request خیلی هزینه بر میشه و داشتن یه container که همیشه در حال اجراست و به درخواست ها جواب میده راه حل بهتریه.
یه ایده جایگزین اینه که شما open-source FaaS رو روی Kubernetes اجرا کنید، اینطوری عملا هزینه virtual machine رو میپردازید ولی از مزایای FaaS هم بهره مند میشید.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
توضیحی در مورد مدل قیمت گذاری FaaS در FaaS مدل پرداخت per-request هست و اگه شما در دقیقه یا ساعت درخواست های کمی دارید این مدل خیلی بهتر از اینه که شما همیشه یه container داشته باشید که مجبور باشید به خاطر idle-timeش هم هزینه بدید. اما کم کم که تعداد درخواست…
الگوهای FaaS
The Decorator Pattern: Request or Response Transformation
الگوی decorator در زبان python شباهت زیادی به این الگو دارد. چون که decorator معمولا stateless هستند و معمولا بعد از نوشته شدن کد اصلی اضافه میشن.
مثال خیلی روشنش وقتیه که شما میخواید یه سری فیلد ها به request یا response سرویس تون اضافه کنید، اونجا FaaS میتونه خیلی کمک کننده باشه. همچنین به خاطر سادگی FaaS شما میتونید انواع مختلفی از decorator هارو روی سرویس تون تست کنید بدون اینکه سرویس اصلی تون دست بخوره و فقط اون هایی که رفتار مورد نظرتون رو دارن حفظ کنید یا حتی منتقلشون کنید داخل سرویس اصلی.
در الگوهای گذشته یه الگوی adapter داشتیم که به صورت یه container در جلوی container اصلی قرار میگرفت و همین کار رو میکرد. خب مشکل adapter اینه که شما مجبور هستید به همان میزان که سرویس اصلی قراره scale پیدا کنه adapter container رو هم scale بدید در حالیکه خیلی از عملیات ها مثل request transformation عملیات های سبکی هستند و نیازی به scale بالا ندارند، پس FaaS اینجا میتونه خیلی کمک کننده باشه.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
The Decorator Pattern: Request or Response Transformation
الگوی decorator در زبان python شباهت زیادی به این الگو دارد. چون که decorator معمولا stateless هستند و معمولا بعد از نوشته شدن کد اصلی اضافه میشن.
مثال خیلی روشنش وقتیه که شما میخواید یه سری فیلد ها به request یا response سرویس تون اضافه کنید، اونجا FaaS میتونه خیلی کمک کننده باشه. همچنین به خاطر سادگی FaaS شما میتونید انواع مختلفی از decorator هارو روی سرویس تون تست کنید بدون اینکه سرویس اصلی تون دست بخوره و فقط اون هایی که رفتار مورد نظرتون رو دارن حفظ کنید یا حتی منتقلشون کنید داخل سرویس اصلی.
در الگوهای گذشته یه الگوی adapter داشتیم که به صورت یه container در جلوی container اصلی قرار میگرفت و همین کار رو میکرد. خب مشکل adapter اینه که شما مجبور هستید به همان میزان که سرویس اصلی قراره scale پیدا کنه adapter container رو هم scale بدید در حالیکه خیلی از عملیات ها مثل request transformation عملیات های سبکی هستند و نیازی به scale بالا ندارند، پس FaaS اینجا میتونه خیلی کمک کننده باشه.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
الگوهای FaaS The Decorator Pattern: Request or Response Transformation الگوی decorator در زبان python شباهت زیادی به این الگو دارد. چون که decorator معمولا stateless هستند و معمولا بعد از نوشته شدن کد اصلی اضافه میشن. مثال خیلی روشنش وقتیه که شما میخواید…
Handling Event
بیشتر سیستم ها request driven هستند که یه حجم قابل توجهی از api request های کاربر رو handle میکنن. یک بخش دیگری از سیستم ها event driven هستند. تفاوت event و request در اینه که معمولا request جزئی از یک مجموعه تعامل (interaction) یا session هست. معمولا هر درخواست کاربر یک جزیی از تعامل کاربر با وب اپلیکیشن هست. در طرف مقابل event ها معمولا single-instance و asynchronous هستند. معمولا event ها مهم هستند و باید اجرا بشن اما نکته ای که وجود داره اینه که معمولا event ها در زنجیره اصلی تعامل نیستند و با ناهمگامی زمانی هم میشه اجراشون کرد. مثلا ارسال ایمیل خوش آمدگویی به کاربران جدید یه event هست که کامل مستقل از تعامل اصلی کاربر با سیستم هست. به همچنین ارسال notification برای کاربران.
به دلیل ذات مستقل بودن و stateless بودن event ها و همچنین با در نظر گرفتن این نکته که نرخ اتفاق افتادن event ها میتونه خیلی متغیر باشه، معماری FaaS یه گزینه خیلی ایده آل برای سیستم های event driven هستند.
همچنین eventهای جدید بصورت dynamic به سرویس اضافه میشن و به خاطر lightweight بودن deployment توابع، FaaS میتونه گزینه ایده آلی برای اضافه کردن event handler ها برای سرویس ها باشه. علاوه بر این به خاطر مستقل بودن توابع، باعث میشه پیچیدگی سیستم کم بشه و developer فقط روی کارهایی که برای رسیدگی به یه single event داره تمرکز کنه نه چیز دیگه ای.
یه مثال مناسب برای event ها میتونه two-factor authentication باشه، جای اینکه سرویس اصلی مجبور به generate کردن کد بشه و اونو بخواد برای کاربر پیامک کنه، سرویس اصلی فقط کافیه یک web-hook request به FaaS بفرسته، و FaaS میتونه خودش پس از جنریت کردن کد برای کاربر ارسالش کنه.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
بیشتر سیستم ها request driven هستند که یه حجم قابل توجهی از api request های کاربر رو handle میکنن. یک بخش دیگری از سیستم ها event driven هستند. تفاوت event و request در اینه که معمولا request جزئی از یک مجموعه تعامل (interaction) یا session هست. معمولا هر درخواست کاربر یک جزیی از تعامل کاربر با وب اپلیکیشن هست. در طرف مقابل event ها معمولا single-instance و asynchronous هستند. معمولا event ها مهم هستند و باید اجرا بشن اما نکته ای که وجود داره اینه که معمولا event ها در زنجیره اصلی تعامل نیستند و با ناهمگامی زمانی هم میشه اجراشون کرد. مثلا ارسال ایمیل خوش آمدگویی به کاربران جدید یه event هست که کامل مستقل از تعامل اصلی کاربر با سیستم هست. به همچنین ارسال notification برای کاربران.
به دلیل ذات مستقل بودن و stateless بودن event ها و همچنین با در نظر گرفتن این نکته که نرخ اتفاق افتادن event ها میتونه خیلی متغیر باشه، معماری FaaS یه گزینه خیلی ایده آل برای سیستم های event driven هستند.
همچنین eventهای جدید بصورت dynamic به سرویس اضافه میشن و به خاطر lightweight بودن deployment توابع، FaaS میتونه گزینه ایده آلی برای اضافه کردن event handler ها برای سرویس ها باشه. علاوه بر این به خاطر مستقل بودن توابع، باعث میشه پیچیدگی سیستم کم بشه و developer فقط روی کارهایی که برای رسیدگی به یه single event داره تمرکز کنه نه چیز دیگه ای.
یه مثال مناسب برای event ها میتونه two-factor authentication باشه، جای اینکه سرویس اصلی مجبور به generate کردن کد بشه و اونو بخواد برای کاربر پیامک کنه، سرویس اصلی فقط کافیه یک web-hook request به FaaS بفرسته، و FaaS میتونه خودش پس از جنریت کردن کد برای کاربر ارسالش کنه.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
👍2
Go Casts 🚀
Handling Event بیشتر سیستم ها request driven هستند که یه حجم قابل توجهی از api request های کاربر رو handle میکنن. یک بخش دیگری از سیستم ها event driven هستند. تفاوت event و request در اینه که معمولا request جزئی از یک مجموعه تعامل (interaction) یا session…
Event-Based Pipeline
دسته ای از application ها وجود دارن که بهتره اونارو بصورت یه pipelineی از decoupled event ها ببینیم. در الگوی event pipeline هر node یک function یا webhook هست و ارتباط این نودها از طریق network و http request هست. هیچ shared stateی بین نودها وجود نداره البته از context یا reference point های مشابه میشه استفاده کرد اگه لازم باشه informationی بین node ها share بشه.
سوالی که ممکنه پیش بیاد اینه که تفاوت event pipeline با microservice architecture چیه؟
دو تا تفاوت اصلی وجود داره. تفاوت اول، تفاوت ماهیت function و long-running service هاست. معماری event-base pipeline ذاتا event driven هست اما microservice ها معمولا مجموعه ای از چند long-running service هستند.
تفاوت دوم در asynchronous بودن event-base pipeline و همچنین تنوع event هایی هست که میتونن با هم تشکیل یک pipeline رو بدن، بر عکس microservice که معمولا سرویس هایی زیرمجموعه دارای اشتراکات زیادی هستن.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
دسته ای از application ها وجود دارن که بهتره اونارو بصورت یه pipelineی از decoupled event ها ببینیم. در الگوی event pipeline هر node یک function یا webhook هست و ارتباط این نودها از طریق network و http request هست. هیچ shared stateی بین نودها وجود نداره البته از context یا reference point های مشابه میشه استفاده کرد اگه لازم باشه informationی بین node ها share بشه.
سوالی که ممکنه پیش بیاد اینه که تفاوت event pipeline با microservice architecture چیه؟
دو تا تفاوت اصلی وجود داره. تفاوت اول، تفاوت ماهیت function و long-running service هاست. معماری event-base pipeline ذاتا event driven هست اما microservice ها معمولا مجموعه ای از چند long-running service هستند.
تفاوت دوم در asynchronous بودن event-base pipeline و همچنین تنوع event هایی هست که میتونن با هم تشکیل یک pipeline رو بدن، بر عکس microservice که معمولا سرویس هایی زیرمجموعه دارای اشتراکات زیادی هستن.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
🎉1
Go Casts 🚀
Event-Based Pipeline دسته ای از application ها وجود دارن که بهتره اونارو بصورت یه pipelineی از decoupled event ها ببینیم. در الگوی event pipeline هر node یک function یا webhook هست و ارتباط این نودها از طریق network و http request هست. هیچ shared stateی بین…
تجربه شخصی از FaaS
ما یه سرویس link preview داشتیم که روی کلاستر aws اجرا میشد و وظیفه اش این بود که برای پیام های جدید کاربران که حاوی لینک بود بره از لینک مورد نظر یه open-graph data بگیره، یا اگه لینک مربوط به social network ها بود به شیوه خاص خودش لینک رو scrape کنه و دیتای مورد نیاز رو جمع کنه. ضمنا دیتا رو باید تو دیتابیس ذخیره میکرد که دفعات بعد از دیتابیس دیتارو لود کنه.
یه مشکل دیگه هم که بود این بود که سایت های پربازدید معمولا درخواست های از مبدا سرورهای aws رو block میکنن. به همین دلیل مجبور بودیم یه سری http proxy همیشه توی دیتابیس آپدیت کنیم که از طریق اون درخواست ها ارسال بشه.
نرخ تعداد درخواست های link preview هم خیلی متغیر بود گاها خیلی کم بود گاهی هم پیش میومد زیاد باشه.
با این راه حل ما هم داشتیم هزینه containerی که همیشه این سرویس رو up نگه میداشت رو میدادیم هم هزینه دیتابیس میدادیم (از rds آمازون استفاده میکردیم) و هم مشکل proxy رو باید حل میکردیم.
راه حل جایگزینی که دوستم ارائه داد این بود که یه تابع ساده پایتونی نوشت که یه لینک میگرفت و دیتای مورد نیاز رو scrape میکرد و پاسخ رو پس میداد. این تابع رو بصورت FaaS رو اگه اشتباه نکنم روی Heroku بالا آورد (که ۱ میلیون درخواست اولش رایگان بود...). نیاز به storage هم نداشت چون سرویس پشت cache system بود (فکر کنم cloudfront) و فقط درخواست هایی که حاوی لینک جدید بودن function رو اجرا میکردن (تو معماری قبلی سرویس همیشه در حال اجرا بود و کلی resource مصرف میکرد)، بقیه رو خود cache جواب میداد. مشکل proxy هم دیگه نداشتیم.
عملا هم کلی هزینه کم شد، و هم کد و معماری ساده تر شد.
در انتها هم شاید بد نباشه پروژه OpenFaaS رو یه نگاهی بندازید.
https://github.com/openfaas/faas
https://www.openfaas.com
این پادکست هم شاید شنیدنش بد نباشه.
https://ardanlabs.buzzsprout.com/1466944/9750624-finding-a-model-for-open-source-with-alex-ellis
این کتاب هم من خیلی دوست دارم داشته باشم اگه گیر آوردید به منم بدید 🙂
Serverless for Everyone Else
https://openfaas.gumroad.com/l/serverless-for-everyone-else
#faas #open_faas
#designing_distributed_systems_brendan_burns
@gocasts
ما یه سرویس link preview داشتیم که روی کلاستر aws اجرا میشد و وظیفه اش این بود که برای پیام های جدید کاربران که حاوی لینک بود بره از لینک مورد نظر یه open-graph data بگیره، یا اگه لینک مربوط به social network ها بود به شیوه خاص خودش لینک رو scrape کنه و دیتای مورد نیاز رو جمع کنه. ضمنا دیتا رو باید تو دیتابیس ذخیره میکرد که دفعات بعد از دیتابیس دیتارو لود کنه.
یه مشکل دیگه هم که بود این بود که سایت های پربازدید معمولا درخواست های از مبدا سرورهای aws رو block میکنن. به همین دلیل مجبور بودیم یه سری http proxy همیشه توی دیتابیس آپدیت کنیم که از طریق اون درخواست ها ارسال بشه.
نرخ تعداد درخواست های link preview هم خیلی متغیر بود گاها خیلی کم بود گاهی هم پیش میومد زیاد باشه.
با این راه حل ما هم داشتیم هزینه containerی که همیشه این سرویس رو up نگه میداشت رو میدادیم هم هزینه دیتابیس میدادیم (از rds آمازون استفاده میکردیم) و هم مشکل proxy رو باید حل میکردیم.
راه حل جایگزینی که دوستم ارائه داد این بود که یه تابع ساده پایتونی نوشت که یه لینک میگرفت و دیتای مورد نیاز رو scrape میکرد و پاسخ رو پس میداد. این تابع رو بصورت FaaS رو اگه اشتباه نکنم روی Heroku بالا آورد (که ۱ میلیون درخواست اولش رایگان بود...). نیاز به storage هم نداشت چون سرویس پشت cache system بود (فکر کنم cloudfront) و فقط درخواست هایی که حاوی لینک جدید بودن function رو اجرا میکردن (تو معماری قبلی سرویس همیشه در حال اجرا بود و کلی resource مصرف میکرد)، بقیه رو خود cache جواب میداد. مشکل proxy هم دیگه نداشتیم.
عملا هم کلی هزینه کم شد، و هم کد و معماری ساده تر شد.
در انتها هم شاید بد نباشه پروژه OpenFaaS رو یه نگاهی بندازید.
https://github.com/openfaas/faas
https://www.openfaas.com
این پادکست هم شاید شنیدنش بد نباشه.
https://ardanlabs.buzzsprout.com/1466944/9750624-finding-a-model-for-open-source-with-alex-ellis
این کتاب هم من خیلی دوست دارم داشته باشم اگه گیر آوردید به منم بدید 🙂
Serverless for Everyone Else
https://openfaas.gumroad.com/l/serverless-for-everyone-else
#faas #open_faas
#designing_distributed_systems_brendan_burns
@gocasts
GitHub
GitHub - openfaas/faas: OpenFaaS - Serverless Functions Made Simple
OpenFaaS - Serverless Functions Made Simple. Contribute to openfaas/faas development by creating an account on GitHub.
🔥2❤1