آشنایی با 20 اصطلاح مهم و باکلاس در معماری نرم‌افزار!

1. DDD (Domain Driven Design)

در حدود سال 2003 کتابی به نام Domain Driven Design توسط فرد بسیار ** به نام اریک ایوان* نوشته شد که بسیاری از اصطلاحاتی که به کار گرفته است، از جمله DDD یا Domain Driven Design، امروزه در صنعت معماری نرم افزار کاربرد فراوان دارند.

در تعریف Domain Driven Design طبق یکی از مصاحبه‌هایی که خود اریک ایوان داشته، میتونیم بگیم:

" وقتی که داریم یک نرم‌افراز را توسعه میدیم نباید تمرکز اولیه ما روی تکنولوژی‌ها باشه بلکه باید اول روی کسب و کار یا هدفی که قراره این نرم افزار داشته باشه تمرکز کنیم. یعنی دامنه یا همون Domain! "

احتمالا اولین سوالی که پیش میاد اینه که دامنه یعنی چی؟ دامنه در واقع همون مسئله‌ایه که کسب و کار ما داره تلاش میکنه با یک نرم افزار حلش کنه. مثلا دامنه بانکی. (به نظر شما دامنه اسنپ یا تپسی چیه؟ به نظر من حمل و نقل)

در واقع Domain Driven Design نگاه بالا به پایین (top-down) داره، اگه به عنوان مثال به شکل زیر نگاه کنیم، میبینیم برای داشتن یک سرویس بخش‌های زیادی وجود داره که برنامه نویس‌ها و عوامل دیگه درگیرش هستند مثلا کلاس بندی چطوری باشه، چه دیزاین پترنی بهتره، ماژول‌های اصلی چیا باشه و ...

ولی در Domain Driven Design دید کلی‌تری داریم و در واقع میایم نگاه می‌کنیم چه سرویس‌هایی برای حل مسئله کسب و کار ما لازمه و باید وجود داشته باشه و به جزییات هر بخش کاری نداریم. تصویر زیر میتونه دید بهتری بده:

در نهایت ممکنه براتون سوال به وجود بیاد که خب این رویکرد اصلا به چه دردی میخوره؟! چرا باید یادش بگیریم؟!

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

2. Hexagonal Architecture

معماری شش ضلعی یا Hexagonal Architecture در اصل یکی از رویکرد سازماندهی کدهایمان است که به زبانی خیلی ساده با ایجاد قوانین و محدودیت‌های منطقی مشخص میکند هر نوع کد مختص به کدام بخش سیستم نرم‌افزاری است و تمرکز آن بر تولید کامپوننت‌ها به صورت loosely coupled است، برخلاف معماری‌های لایه‌ای که لایه ها برای تغییر، تست و ... روی یکدیگر تاثیر می‌گذراند. نام دیگر ولی کمتر رایج این معماری ports and adapters است که در ادامه توضیحات و از شکل زیر می‌توان دلیل آن را فهمید.

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

نکته دیگری که ممکن است ذهن شما را مثل من(!) درگیر کرده باشد این است که نام شش ضلعی این مفهوم را می‌رساند که حتما 6 بخش در معماری Hexagonal Architecture وجود دارد، در صورتی که 4 بخش اصلی داریم.

• لایه‌ی دامنه API
• لایه‌ی بیزینس
• لایه‌ی REST Adapter
• لایه‌ی Persistence Adapter

من بعد از کمی سرچ متوجه شدم بیشتر به خاطر شمایل گرافی و وجود فضای کافی برای نمایش سایر رابط‌های کاربری اینطور نمایش داده شده و لزوما نباید 6 تا بخش اصلی داشت.( خوشحال می‌شم اگر نکته‌ی دیگری بود برام بنویسید.)

در نهایت هم اگر خیلی کوتاه بخوام در باره‌ی مزایای این معماری بگم:

• راحت میشه اداپتر اضافه یا کم کنیم، به اصطلاح میگن: plug and play
• قابلیت تست را افزایش می‌دهد.
• کد تمیزتر و خوانا می‌شه.
• سازماندهی سیستم به خصوص در آینده راحت‌تر می‌شه.
• پایگاه داده مستقل میشه و تغییرات این بخش هم آسون‌تر میشه.

3. CQRS

در الگوی CQRS یا Command query responsibility segregation نرم افزار به دو بخش خواندن و نوشتن (به‌روز رسانی) تقسیم می‌شود(Read and Write sides). در بیشتر سیستم‌های نرم افزاری تعداد دفعات خواندن اطلاعات چندین برابر نوشتن اطلاعات است. با کمک این الگو و جداسازی این دو بخش می‌توان وقوع تداخل‌ها را کنترل کرد و همچین سرعت را بسیار بالا برد. (همان طور که میدانید سرعت خواندن اطلاعات خیلی بیشتر از نوشتن آن است.)

در ادامه برای مثال سه روشی که می‌توان الگوی CQRS را پیاده سازی کرد توضیح میدهیم:

• با کمک یک دیتابیس: ساده ترین نوع است و همانطور که در تصویر زیر مشاهده می‌کنید کامندها از طریق لایه‌ی persistence نتیجه را در دیتابیس ذخیره می‌کنند و کوئری‌ها به کمک یک لایه‎‌ی data access به دیتابیس وصل می‌شوند.

• با کمک دو دیتابیس: همونطور که احتمالا توی ذهنتون اومد، یکی از دیتابیس ها برای خواندن و دومی برای نوشتنه اطلاعات استفاده میشه. نکته مهم هماهنگی و یکپارچگی اطلاعات این دو دیتابیسه! همونطور که در تصویر می‌بینید با هر افزایش یا به روزرسانی اطلاعات دیتابیس Write DB باید دیتابیس دیگر یعنی Read DB هم به روزرسانی بشه.

• روش منبع یابی رویدادی یا event-sourcing: ایده‌ی کلی این روش اینه که تغییرات موجودیت‌ها در طول زمان ذخیره بشه و بامکانیزمی وضعیت گذشته و فعلی یک شئ را مقایسه کنیم. سرعت این روش از حالت‌های قبلی هم بالاتر میره ولی ایرادی که داره اینه که نمیتونیم eventهای قبلیمونو ویرایش یا حذف کنیم و فقط میشه event جدید اضافه کنیم.

(منبع1 و منبع2)

4. MVVM

معماری MVVM یا Model - View - ViewModel یکی از الگوهای معماری نرم‌افزار است که توسط مایکروسافت معرفی شده و شباهت زیادی به MVC داره (اگر با MVC آشنا نیستید میتونید سرچ کنید یا از اینجا بخونید). این تقسیم بندی توسعه موازی بخش‌های مختلف نرم‌افزارو ممکن می‌کند.

• مدل یا Model : بیزینس آبجکت‌هایی که داده ها و دامنه اپلیکیشن را کپسوله‌سازی (encapsulate) می‌کنند. درواقع مسئول نگهداری داده‌ها و اطلاعات به صورت خام است و حدالامکان سعی می‌شه که سرویس خاصی برای ویرایش و ... داده‌ها ارائه نکنه.
• نما یا View: همون رابط کاربری و پوسته‌ای از برنامس که کاربر با اون در ارتباطه.
• نما-مدل یا ViewModel: پیوند بین دو بخش قبلی اینجا اتفاق میفته، مثلا داده ها از مدل بازیابی میشوند و تغییراتی که لازم هست اتفاق میفته و در نما نمایش داده میشه. انتقال داده بین نما و نما-مدل توسط تکنیکی به نام data-binding انجام میشه.
  

در کل برای اینکه یک برنامه‌ی ساختار یافته‌تر داشته باشیم پترن MVVM میتونه مفید باشه. (منبع1 ، منبع2)

5. Event Sourcing

اگر بخوایم در یک جمله مفهوم event-sourcing رو بگیم خوبه به این جمله از مارتین فاولر (Martin Fowler) مراجعه کنیم که میگه :

"Capture all changes to an application state as a sequence of events."

در ایونت سورسینگ هدف اینه که رفتار نرم‌افزار در تمامی رویدادهایی که اتفاق میفته ثبت بشه و در یک لیست یا مخزن ذخیره شه. این لیست اصطلاحا append-only هست. یعنی نمیشه لاگ‌های قبلی ویرایش یا حذف بشن. یکی از مزایای بزرگ این روش دیباگ و کنترل رفتار برنامه است. از جمله کاربردهای این روش میشه به سیستم‌های مالی، سیستم‌های مرتبط با مسائل بهداشتی و کنترل سلامت، دولتی، حمل و نقل، بازی های ویدیویی و ... اشاره کرد ولی در کنار همه‌ی مزایایی که برای ما فراهم میکنه مثل هر روش دیگه معایبی هم داره. مثلا کوئری زدن به یک مخزن ایونت کار نسبتا سختی محسوب میشه و برای همین از CQRS استفاده میشه. (مورد سوم همین نوشته) ولی از طرفی چون همه رفتار و جزییات در تاریخچه ثبت شده از لحاظ زمانی کار با کوئری ها خیلی راحت تره! (مزایا و معایبش در هم تنیده شده!) (منبع1، منبع2 و منبع3)

6. Micro Frontends

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

"سبک معماری که در آن برنامه های کاربردی مستقل در یک کل بزرگتر مونتاژ می شوند."

اگر بخواهیم چندتا از مزیت‌های استفاده از میکرو فرانت‌اند رو بگیم:

• میتونیم تیم‌های کوچیک‌تر و بیشتر داشته باشیم و به جای اینکه مثلا 20 نفر روی یک پروژه کار کنند که معمولا هم لازمه تخصصشون یکی باشه میشه مثلا 5 تا تیم کوچیکتر داشته باشیم که حتی یکی React کار میکنه یکی Vue و ... و در عین حال سرعت رشد پروژه هم بالاتر بره.
• همونطور که گفتیم قدرت نگهداری برنامه که یکی از Quality Attribute های مهم در معماری نرم‌افزار است بالاتر میره.

اگرچه هنوز میکرو فرانت اند نسبت به میکرو سرویس سمت بک‌اند کم طرافدار تره، طبق گزارشات هرساله درصد بیشتری از دولوپرها به سمت استفاده از میکرو فرانت‌اند میرن.

تصویر زیر به خوبی این مفهوم و تیم مزایایی که توضیح دادیمو نشون میده:

( منبع1، منبع2 و منبع3)

7. Low Code Platforms

پلتفرم‌های کم کد ابزارهایی گرافیکی هستند که برای طراحی سایت، اپلیکیشن و ... به کار گرفته می‌شوند. این پلتفرم‌ها باعث می‌شوند سازمان در زمان نسبتا کمی به به ابزار و نیازهای خود برسه و نیاز نداشته باشه نیروی گرون قیمت و زیاد استخدام کنه ولی از طرفی سطح توانایی این ابزار در حدی نیست که در رقابت با سایر رقبای بازار بتونه جز بهترین‌ها باشه. از سمت دیگه چون این ابزار طبق یک سری چهارچوب کد تولید می‌کنند لزوما بهترین کد تولید نمی‌شه و بعدها ممکنه موقع توسعه مشکلات زیادی برای سازمان به وجود بیاد. از نمونه‌های رایج این پلتفرم‌ها Canvas Apps هستن که یک اپلیکیشن از بالا به پایین (top - down) طراحی میشه.

توی منبعی که در زیر اوردم 9 تا از بهترین پلتفرم‌های کم کد (low code) به تربیت زیر اورده:

• Appian
• Mendix
• OutSystems
• Quickbase
• Zoho Creator
• Kissflow
• Salesforce Lightning
• Microsoft Power Apps
• Nintex

( منبع1 ، منبع2)

8.ESB

گذرگاه سرویس سازمانی یا ESB مخفف عبارت Enterprise Service Bus است. در واقع یک میان افزار است که برای ادغام سرویس‌ها، سیستم ها و ... مختلف که با زبان های متفاوتی صحبت می‌کنند در یک سازمان استفاده میشود. هر وقت یکی از بخش ها پیامی برای انتقال دارد ابتدا ESB ان را ترجمه میکند و بعد به مقصد مناسب هدایت میکند.

از مزایای این راهکار میتوان به یکپارچگی و سهولت ارتباط بین سرویس گیرندگان اشاره کرد . در عین حال نقاط تبادل در سیستم کمتر میشود و نه تنها مدیریت عملکرد و توسعه راحت تر شده بلکه به نوعی خودش موجب افزایش امنیت است. در نهایت نگهداری سرویس های قدیمی تر راحت تر خواهد بود و نیاز نیست برای ایجار ارتباطات جدید هربار سرویس های دیگر دستخوش تغییر بشن. تصویر زیر به درک بهتر مفهوم ESB در یک معماری سرویس گرا کمک میکند:

(منبع1، منبع2)

9. API Gateway

اگه دستی در برنامه نویسی داشته باشین قطعا بارها اسم API به گوشتون خورده، برای مرور میتونید این منبع رو مطالعه کنید. اما API Gateway یا دروازه API یه ابزار مدیریت API محسوب میشه که ارتباط بین کلاینت و مجموعه‌ای از سرویس‌های بک‌اندی رو مدیریت میکنه. در واقع تمامی API call هارو میگیره و نتیجه مناسب بهشون رو برمیگردونه. این مسئله از طرفی تا حد خوبی امنیت سرویس‌ها رو هم تضمین میکنه چون دیگه کلاینت مستقیم با همه‌ی سرویس ها در ارتباط نیست. از طرفی نگهداری و توسعه کد هم ساده تر می‌شه چون دیگه لازم نیست برای تغییر یک سرویس از سمت کلاینت هم تغییری ایجاد شه. یکی از ابزار معروف اوپن سورس در این زمینه هم HAProxy است. در نهایت اگر به این موضوع علاقه مند بودید نوشته‌ی "API Gateway چیست و چرا از آن استفاده می‌کنیم؟" میتونه مفید باشه. (منبع2)

10. Business Rules Management Systems (BRMS)

سیستم مدیریت قوانین کسب و کار یا BRMS راهکاری برای ذخیره کردن، ویرایش و اجرای سریعتر و راحت تر قوانین تجاری است. قوانین تجاری هم دستور العمل های منطقی‌ای(and or) هستن که فعالیت‌های سازمانو تعریف، کنترل و محدود میکنند. خیلی از سازمان ها به صورت سنتی و نانوشته یک سری قوانینی دارند که رعایت و به خاطر سپاری اونهارو برای کارمندها سخت میکنه و منجر به ناهنجاری میشه. با کمک BRMS مواردی که گفته شد حل میشه و مزایای دیگه‌ای از جمله موارد زیر به دست میاد:

• افزایش کارایی به علت وجود تصمیم گیری خودکار در مواردی که اتوماسیون شده اند. پس تصمیمات تکراری که دستی انجام میشدند هم کمتر میشن.
• توانایی مقیاس بندی تصمیمات برای اپلیکیشن های مختلف
• بهبود خدماتی که به کاربر ارائه میشود و بهبود تجربه کاربر
• با کمک BRMS میشه برای کارکنان مختلف یا پیمانکارهای خارجی سطح دستری تعیین کرد و به نوعی بر امنیت موثر است.

(منبع1، منبع2)

11. Business Process Management Systems (BPMS)

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

1. افزایش چابکی سازمان (agile)

2. اتوماسیون گردش کار

3. مدیریت و تعریف و پیگیری راحت تر فرایند ها

4. ایجاد داشبورد های بصری که با یک نگاه اطلاعات مهم را بتوان دید

5. قابلیت هایی برای ایجاد و حفظ یکپارچگی (Integration)

و...

از معروف ترین و پرکاربردترین BPMSهای معروف میتوان به bonitasoft و Red Hat JBoss BPM Suite اشاره کرد. (در پست تفاوت BPMS و BRMS این دو راهکارو مقایسه کردم و تصاویری از محیط نرم افزارها وجود داره که اگه دوست داشتید میتونید بخونید.)

منبع1

12. Message Queue

صف‌های پیام یا Message Queue بخشی از نرم افزار هستند که ارتباط برنامه را ساده‌تر میکنند. صف پیام در واقع یک بافر یا حافظه موقتی محسوب می‌شود و این موضوع ارتباط غیر هم زمان بین گیرنده و فرستنده را ممکن میکند. صف‌ها از قانون FIFO پیروی میکنند یعنی اولین ایتم وارد شده در لیست اولین آیتمی است که رسیدگی می‌شود.

در معماری صف یک یا چند تولید کننده(producer) داریم که پیام‌ها را روی صف قرار میدهند و از سوی دیگر مصرف کننده(ها)(consumer) پیام ها را دریافت میکنند و اقدامات لازم را انجام میدهند.

یکی از ابزارهای معروف در این زمینه RabbitMQ است که یک صف پیام اوپن سورس و قابل توسعه می‌باشد. RabbitMQ از پروتکل AMQP پیروی میکند که مخفف Advanced Message Queuing Protocol است.

(منبع1 ، منبع2)

13. Docker and Containerization

کانتینر واحد استاندارد سازی شده نرم افزار است که شامل کدها و وابستگی‌های آن می‌شود و بر لایه سیستم عامل مجازی سازی می شود تا بهتر، سبک‌تر و سریع‌تر از سرور مجازی کار کند و برنامه با اطمینان و سرعت بالا از یک محیط محاسباتی به محیط دیگر اجرا شود. Containerization مفهومیه که امروزه خیلی پر طرفدار شده و به معنی بسته بندی کردن (packing) تمامی مواردی است که برای اجرای برنامه لازمند مثلا وابستگی های زمان احجرا (runtime dependencies) ، فایل های تنظیمات و ... . راه حل های نرم افزاری مختلفی وجود دارند که داکر یکی از محبوب ترین هاست.

پس داکر یک راه حل کانتینر سازی یا containerization است که این کار را ساده تر و سریع تر میکند و بدون در نظر گرفتن نوع سیستم عامل (ویندوز، لینوکس و ...) روی هر بستری راه اندازی میشود. ساده ترین مورد استفاده از داکر برای اجرای یک یا چند کانتینر آماده به عنوان وابستگی‌های کد هستند. مثلا اگر برنامه ما از یک پایگاه داده‌ی postgreSQL استفاده کنه به جای نصب مستقیم روی دستگاه میشه از داکر استفاده کرد. در منبع 2 دستورات لازم برای اجرای این مثال اومده که اگر علاقه دارید میتونید بخونید.

( منبع1، منبع2 و منبع3)

14. Container Orchestration

در مورد قبلی دیدیم که کانتینر سازی برنامه‌ها و سرویس‌ها هر روز محبوب تر میشه ولی با زیاد شدن کانتینرها مدیریت و نگهداری هم سخت تر میشه، برای اینکار ابزارهایی به وجود اومدن که orchestrator نام دارند که به خودکار سازی (اتوماسیون) این موضوع هم کمک می‌کنند و شامل طیف گسترده‌ای از مواردیه که تیم توسعه دهنده برای مدیریت چرخه طول عمر کانتینر (container’s lifecycle) بهشون لازم داره مثلا اسکیل کردن(کم و زیاد)، موراد شبکه، دیپلوی و ... .
از مزایای استفاده از ارکستراسیون کانتینرها میتونیم به موارد زیر اشاره کنیم:

• ساده سازی عملیات: همونطور که گفتیم با زیاد شدن تعداد کانتینرها پیچیدگی و ناهماهنگی هم زیاد میشه و اگر دقت نکنیم ممکنه کلا مدیریت سیستم از کنترل خارج شه. پس اصلی تریم و مهم ترین مزیت به نظر من این مورده.
• انعطاف پذیری(Resilience): خود ابزار هماهنگ سازی (orchestration ) قادر هستن که به صورت خودکار کانتینر مورد نیازو ری‌استارت یا اسکیل کنند.
• امنیت: با توجه به این که به سمت اتوماسیون میریم خطای انسانی کمتر میشه و به نوعی امنیت بهبود پیدا میکنه.
  در تصویر زیر چند تا از پرکاربرد ترین ابزارهای ارکستراسیون نام برده شدند.
  

(برخی از منابع: منبع1 ، منبع2)

15. Log Management Tools

ابزارهای مدیریت لاگ یا Log Management Tools محصولاتی هستند که لاگ‌های سیستم را به صورت متمرکز تر نمایش میدهند و قابلیت تجزیه و تحلیل و ویژوالایز آن‌ها را فراهم میکنند. برخی از ابزار مدیریت لاگ مکانیزم هشدار real-time هم فراهم میکنند. همچنین میتوان به صورت زنده و داینامیک کارایی سیستم هم بررسی کرد و تحت نظارت داشت و درکل عملکرد مدیریت به صورت پویا و راحت تر برای سازمان فراهم میشه. علاوه بر مواردی که گفته شد این ابزار معمولا قابلیت پاک سازی و تبدیل و ... داده های لاگ شده رو هم دارند.

چند تا از بهترین ابزار مدیریت لاگ در منبع1 اومده که من هم پرکاردبرترین‌هاشو مختصرا معرفی میکنم:

1. رتریس یا Retrace:

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

2. لاگ اینتریز یا Logentries : این ابزار بر بستر کلاد کار میکنه و مدیریت و سرچ لاگ‌ها رو به صورت زنده (real-time) فراهم میکنه. به گفته‌ی خودشون از پروتکل های مدرن برای محافظت دیتای سیستم شما استفاده میکنه.

(برخی از منابع: منبع2 ، منبع3)

16. Monitoring Tools

روش‌های پایش (نظارت) یا Monitoring tools مجموعه‌ای از ابزار نظارت سیستم هستن که کمک می کنن به صورت مداوم وضعیت سیستم رو بررسی کنیم و در صورت لزوم بهبود ببخشیم. از آن جایی که نظارت برای کسب و کارها بسیار ضروری است این ابزار کمک می‌کنند ایرادهای سیستم به محض رخ دادن پیدا و از ایجاد مشکلات بزرگ‌تر جلوگیری بشه. اگر نظارت به درستی انجام نشه ممکنه آسیب‌ها و اختلالات زیادی به وجود بیاد. مثلا یکی از این ابزار های نظارتی اوپن سورس prometheus است که امکانات رسم و تصویرسازی خوبی را به همراه زبان کوئری مخصوص داره و در وهله‌ی اول بر جمع آوری، تجزیه و تحلیل دیتا بر اساس سری‌های زمانی به کاربران و توسعه دهندگان قابلیت‌های نظارت را خودشان تنظیم کنند.

برخی از بخش هایی که نیاز دارند در شرکت نظارت روشون باشه:

• سرورها در زمان واقعی
• زیر ساخت‌های ابری
• کانتینرها مثل داکر و ...
• عملکر شبکه
• و موارد بسیار دیگر

از دیگر ابزار مانیتورینگ می‌توان به زیبکس ( Zabbix)، ناگیوس (Nagios) و ریمان (Riemann) اشاره کرد که همگی اوپن سورس هستند. برخی از شرکت‌های ایرانی نیز پشتیبانی و نمایندگی‌هایی بر روی برخی از این ابزار ایجاد کرده‌اند مثلا شرکت سدید آفرین در حوزه‌ی مانیتورینگ زیر ساخت‌ها، سرویس‌ها و ... فعالیت می‌کند.
(منبع1 و منبع2 و منبع3)

17. Static Code Analysis

در static code analysis یا تحلیل ایستا کد، کد بررسی و دیباگ میشه ولی آنرا اجرا نمیشه! هدف از این بررسی اینه که مطمئن شیم آیا این کد با استاندارد های تعیین شده یا مورد نظرمان تطبیق داره یا نه؟

برای تحلیل ایستا که گاهی با اسم Source Code Analysisهم ممکنه به گوشتون بخوره، یک سری ابزار تسهیل یا خودکارسازی وجود دارند که کمک می‌کنن توسعه دهندگان این تحلیل‌ها رو راحت تر انجام بدن. این ابزار ها کد رو اسکن می‌کنن و نقص‌ها و ضعف‌های اونو بررسی و کشف می‌کنند. مثلا خطا های برنامه نویسی یا تخطی از استاندارد ها. گاهی هم ممکن است خطاهای نحوی یا امنیتی را کشف کنن. تحلیل ایستا انواع مختلفی داره که عبارتند از:

• تحلیل کنترلی (که بر منطق برنامه تمرکز دارد)
• تحلیل داده (بر استفاده ی درست از داده تمرکز دارد)
• تحلیل خطا و واسط ها که به ترتیب بر خطاهای مدل و واسط های بخش های مختلف کد تمرکز دارند.

برای مثال RIPS یکی از ابزار تحلیل ایستای کد برای زبان PHP هست که توی عکس زیر طرز کارش هست :

یا مثلا OWASP که از محبوب ترین ابزار برای این کاره :

در نهایت خوبه بدونین یک سری خطاهایی هم داره ( هم false negative و هم false posetive ) که اگر خواستید میتونید توی منبع1 بیشتر در موردش بخونید. (منبع1 ، منبع2)

18. Continuous Delivery

در continous delivery یا تحویل پیوسته یا تحویل مستمر (همون CD در CICD که احتمالا به گوشتون خورده) هدف افزایش دقت و سرعت انتشار کد جدید است که امروزه از طریق خودکارسازی (Automate) به اون میرسن و معمولا توی تیم‌ دواپس یک شرکت انجام می‌شه.

در این رویکرد توی دوره‌های کوچک فرآیند توسعه اتفاق می‌افته و به سرعت منتشر میشه و همین باعث میشود هر ویژگی کوچکی که اضافه می‌شه تست شه و هزینه و ریسک‌های فنی کم بشن و از طرفی سرعت توسعه هم بالا میره. فرآیند آماده سازی و تست کدها در این نوع رویکرد به صورت خودکار اتفاق میفته. در نهایت با تست و انتشار تغییرات در یک مخزن مثل github در قسمت‌های کوچک، فرآیندdeploy رو در محیط اصلی ساده تر و کم هزینه تر میکنه. اگه سری به کتاب معماری تمیز رابرت مارتین (عمو باب معروف) زده باشید یه بخشی هست که میاد از مصیبت انتشار نسخه‌های جدید نرم‌افزار صحبت میکنه که تیم ها قدیم 5 روز هفته کد میزدن 2 روز اخر جمع میشدن دور هم تا کدهارو ادغام کنن و نسخه جدیدو بالا بیارن! و اینکار کاملا دستی انجام میشده. بعد شما فکر کنید نه تنها چندین دولوپر چند روز از توسعه و کار اصلی عقب میفتادن بلکه با مکافات رفع باگ میکردن و ساعت‌ها و حتی روزها بالا آوردن نسخه جدید طول می‌کشیده. (منبع1 ، منبع2)

19. Single Sign On (SSO) and Identity Management

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

حالا identity management چیه؟ در این مفهوم هدف اینه که ما بررسی کنیم آیا یک کاربر خاص اجازه‌ی دسترسی به یک بخش خاص از نرم افزار را داره یا نه؟ و متناسب با اجازه‌هایی که دارد به او دسترسی بدیم. امروزه مدیریت هویت بخش مهم امنیتی در سیستم های نرم افزاری به خصوص IOT به حساب میاد. علاوه بر مزایای واضحی که داره باعث میشه شرکت‌ها بتونن راحت تر به پیمان کارهای خارج از شرکت دسترسی بدن.

(منبع1، منبع2، منبع3)

20. Service Mesh

سرویس مش راهکاری برای کنترل چگونگی به اشتراک گذاشتن داده در قسمت های مختلف اپلیکیشنه در واقع یک لایه ی زیرساختیه که داخل اپلیکیشن قرار گرفته است و می‌تونه این موضوع که بخش های مختلف یک اپلیکیشن چقدر خوب با هم ارتباط برقرار میکنند را ثبت کند با این روش میشه ارتباطات را به سادگی بهینه سازی کرد.

مثلا یک اپلیکیشن مدرن میکرو سرویسی رو تصور کنید که از بخش های مختلف زیادی تشکیل شده( همونطور که میدونید اپلیکیشن های مدرن معمولاً میکروسرویسی هستن و از تعدادی سرویس تشکیل شدن که هرکدوم کار خودشونو انجام میدن ولی ممکنه یک سرویس برای اجرا نیاز به داده و ارتباط با دیگران داشته باشه). حالا فرض کنید یکی از سرویس ها بیش از حد درخواست دریافت کنه. اینجاست که service mesh وارد عمل میشه و درخواست ها را از یه سرویس به بعدی انتقال می دهد و این ارتباطات را بهینه می کند.

در میکروسرویس ها همین ارتباط سرویس به سرویس است که باعث کارایی آنها میشود، میکروسرویس بدون service mesh هم ممکنه کار کنه اما هرچه تعداد سرویس ها بیشتر و ارتباطات پیچیده میشه، وجود سرویس مش ضروری تره.

یکی از پروژه های اوپن سورس معروف این رویکرد Istio هست میتونید اینجا راجع بهش بخونید. (منبع)