به طور کلی یعنی معماری نرم افزار ما با domain آن مشخص شود. منظور از domain موضوع اصلی که نرم افزار حول آن توسعه داده میشود است. البته در بسیاری موارد ممکن است یک نرم افزار شامل موضوعات متفاوتی باشد یا نتوان به راحتی تفکیک میان domain ها را داشته باشیم، در این حالت باید موضوعات مختلف موجود در نرم افزاربه صورت جداگانه مورد بررسی قرار داده شوند که هر کدام محتوا و متخصصان domain خود را خواهند داشت (bounded context). با استفاده از این جداسازی کار بر روی هر یک از domain ها و مدیریت آن ها راحت تر جلو میرود.DDD راه حلی برای توسعه نرم افزار هایی است که پیاده سازی آن ها به شدت با مدل بیزینسی و domain بیزینس ارتباط دارد و ارتباط بین توسعه دهندگان و افراد آشنا به بیزینس را بسیار راحت تر خواهد کرد. به همین دلیل DDD بیشتر در نرم افزار ها یا سازمان های بزرگ کارایی دارد. برای ارتباط راحت و کارا بین توسعه دهندگان و افراد آشنا به بیزینس از زبان ubiquitous استفاده میشود تا با وجود زبان مشترک کار انتقال مطالب سریعتر و راحت تر باشد همچنین ابهامات در گزارشات و بیان مطالب بین این دو گروه از بین برود.
نام دیگر آن port and addaptors است.در واقع Hexagonal architecture یک design pattern برای نرم افزار هایی است که باید بسیار maintainble باشند. اولین بار به عنوان را حل برای مشکلات موجود با object orient سیستم ها مطرح شد. این pattern میگوید تغییرات هرچه سریعتر تر روی سیستم اعمال شوند بهتر است همچنین این pattern سعی میکند موارد و تعداد technical dept ها را حداقل کند که نتیجه این موارد باعث میشود راحت تر بتوان سیستم را maintain کرد. نمایش این pattern به شکل ۶ ضلعی است با این وجود اصرای بر وجود ۶ port در پیاده سازی نیست و به توسعه دهندگان و نیازمندی ها بستگی دارد.
موجودیت های pattern:
پورت: در واقع interface هایی هستند که فرمت دیتای خروجی را مشخص میکنند و شامل دسته بندی زیر میشوند:
آداپتور: برای ارتباط بین لایه های مختلف بوسیله port ها که در این حالت ارتباطات بین لایه و تغییرات در آن ها تاثیری روی منطق سطح بالا (core logic) نمیگذارد و هر adapter به صورت مستقل کار میکند (به طور مثال ممکن است چندین adapter برای یک core تعریف شود که مستقل هستند و تغییرات آن ها تاثیری روی core نخواهد داشت). Adapters هم شامل دسته های Primary و Secondary میشود.
مخفف Command and Query Responsibility Segregation است و یک pattern برای تفکیک فرایند read و write داده در database است. در روش های قدیمی فرایند write و read از یک موجودیت استفاده میکند که برای استفاده های پیچیده و سنگین به دلیل اینکه در سمت خواندن شامل query های متفاوت و در سمت write شامل policy های متنوعی میباشد ممکن است با یک مدل بیش از حد پیچیده که بار زیادی روی آن هست روبه رو شویم. در روش تعریف شده که تا حد زیادی مشابه event sourcing هست و در واقع کار query زدن روی event sourcing را حل میکند دیتا به صورت لاگ های مجزا وارد یک صف میشوند و در واقع ما تاریخچه ای از وقایع را نگهداری میکنیم پس از این مرحله دیتابیس ما قرار دارد که read کردن از آن اتفاق میافتد.در واقع write دیتا مجموعه از وقایع را تشکیل میدهد که این لاگ ها باعث update و insert دیتا در پایگاه داده میشود. پس از write یا ایجاد یک واقعه یک لاگ برای آن ثبت و در صف قرار میگیرد حالا دیتابیس که حساس به ورود لاگ است update میشود و در نهایت فرایند read از این ماژول اتفاق میافتد.اگر بخواهیم در زمان read روی لاگ ها پردازش داشته باشیم بسیار کند میشویم. این راه حل باعث بهبود ویژگی های performance , scalability و security میشود. البته به دلیل جدا شدن فرایند read و write ممکن است inconsistency داشته باشیم.
یک design pattern است که تمرکز اصلی آن بر روی جدا سازی لاجیک برنامه از کنترلر های interface است. این design pattern با نام model view binder هم شناخته میشود و توسط microsoft ایجاد شده است. این روش سعی میکند تا برنامه را به ماژول هایی تقسیم بندی کند که کار توسعه، بروزرسانی و نگهداری سیتم را راحت تر کند. این طراحی شامل view، view model و model میشود:
در این طراحی سعی شده ui از لاجیک اصلی(بیزینسی) برنامه تفکیک شود و همین موضوع باعث میشود طراحی قابل فهم و تست باشد همچنین توسعه دهندگان و designer ها میتوانند به راحتی کنار یکدیگر کار کنند.همچنین باعث میشود قسمت ها و مدل های مجزا قابلیت reuse را داشته باشند به طور مثال برای لاجیک اصلی چندین نوع ui متفاوت برای web,mobile app و … تعریف شود.
در این روش برخلاف حالت معمول برای ذخیره و دریافت اطلاعات که در آن همیشه حالت نهایی ذخیره میشود و در واقع با ایجاد هر رویداد رکورد متناظر با آن update میشود، برای هر واقعه و درخواست یک لاگ insert میشود. این روش برای کاربرد هایی که نیاز به تاریخچه رویداد ها دارند یا حتی توالی این رویداد ها برای آنها مهم است کاربرد دارد. در event sourcing مجموعه رویداد ها به صورت لاگ در سیستم در نظر گرفته میشود و برای حفظ توالی آنها به صورت دنباله ای از وقایع ذخیره میشوند. سیستم برای ذخیره رویداد ها از event store استفاده میکند که پایگاه داده ما برای ذخیره وقایع هست. این پایگاه داده ها که باید ویژگی حفظ توالی رویداد ها را داشته باشند در واقع دارند مشابه message broker ها عمل میکنند، به این ترتیب شما با داشتن تاریخچه ای از رویداد ها اگر مشکلی در سیستم رخ دهد سناریو ایجاد آن مشکل را خواهید داشت و همواره قادر خواهید بود توالی رویداد ها را ردیابی کنید و راحت تر مشکل را حل کنید. این روش مناسبی برای سیستم های رویداد محور است و چالش های آن ها را حل کرده اما این روش چالش های پیاده سازی دارد که از آن ها میتوان به آشنایی با ابزار های متفاوت پیاده سازی و query زدن برای read کردن دیتا نام برد.
این مفهوم تلاش میکند تا مفاهیم میکرو سرویس را وارد دنیای frontend کند. در واقع فرانت اند هایی که به صورت یکجا توسعه، نگهداری و اجرا میشوند هزینه نگهداری و تغییر بالایی دارند به همین دلیل در Micro Frontends سعی می شود فرانت اند به application هایی مستقل و تا حد امکان با کمترین وابستگی شکسته شود.در سیستم های قدیمی به دلیل اینکه کل سیستم به صورت واحد و monolithic است امکان اینکه تیم های توسعه به صورت مستقل از هم کار کنند و وابستگی به هم نداشته باشند وجود ندارد همچنین هزینه نگهداری آن به مرور افزایش می یابد زیرا پروژه سنگین تر و پیچیده تر می شود. در این حالت مجموعه ای از micro frontend ها کل فرانت اند سیستم را خواهند ساخت که هر کدام به صورت مستقل توسعه و نگهداری میشوند، به همین دلیل تیم های مختلف میتوانند به صورت مستقل و با کمترین وابستگی روی یک قسمت خاص از فرانت اند کار کنند که کار توسعه، تغییر و نگهداری در هر کدام بسیار کم هزینه تر و راحت تر میشود همچنین تمرکز محصول بیشتر به سمت مشتری میرود زیرا هر قسمت به صورت مستقل امکان بهبود و تولید ویژگی های جدید را خواهد داشت. در نهایت برای اجرا و نمایش کل پروژه نیاز است کل این قسمت ها با هم ادغام شوند و خروجی واحد را بسازند.
در مورد پلتفرم هایی است که میتوانند با کمترین هزینه اولیه برای توسعه ، پیاده سازی و آموزش راه اندازی و اجرا شوند. بیشتر با توجه به اسم طراحی فکرشان به سمت این می رود که باید سیستم با کمترین مقدار کدی که به صورت دستی توسط توسعه دهندگان نوشته میشود به فاز نهایی و اجرا برسد درصورتی که این مفهوم شامل مواردی مثل راحتی نسبی در توسعه و اجرا، پوشش کامل اهداف و نیازمندی ها با کمترین هزینه و سرعت بالای توسعه میشود. بنابراین بسته به حجم و پیچیدگی قابلیت ها یا نیازمندی ها یی که پروژه دارد ممکن است نیاز به توسعه و حجم کد بالایی داشته باشیم تا الزامات برطرف شوند یا ممکن است بدون هیچ کدی امکان پاسخگویی و راه اندازی را داشته باشیم. استفاده از این روش باعث میشود یک سازمان بتواند بدون استفاده از تعداد بالای مهندسان نرم افزار و پرداخت هزینه زیاد فرایند جذب و آنبورد آن ها نرم افزار های پیچیده و متناسب با نیاز خود رو تولید کند همچنین توسعه دهندگان با تجربه کمتر و بدون سابقه طولانی میتوانند نرم افزار های پیچیده را طراحی و راه اندازی کنند. البته از معایب آن میتوان به این مورد اشاره کرد به دلیل نبود درک عمیقی از مفاهیم مهندسی نرم افزار، توسعه دهندگان نتوانند تصمیم های مناسبی در مورد طرز کار سیستم بگیرند همچنین ممکن است در طراحی مواردی مثل ذخیره برخی لاگ ها و وقایع که در بازاریابی ، اشکال یابی و بررسی موارد این چنینی مورد نیاز است نادیده گرفته شوند.
یک معماری است که شامل مجموعه ای قوانین و اصول برای ادغام انواع برنامه های کاربردی که توسط توسعه دهندگان و مجموعه های مختلف ایجاد و توسعه داده شده اند. این روش قابلیت ادغام و یکپارچه سازی برخی کاربرد ها را میدهد اما نحوه انجام و میزان قابلیت های آن بسته به نیازمندی تفاوت میکند. شما در واقع برای یکپارچه کردن تمامی این برنامه ها یک گذرگاه ارتباطی مشترک بین آن ها قرار می‌دهید و سپس هر برنامه برای ارتباط با دیگران باید از این BUS مشترک استفاده کند. استفاده از این گذرگاه مشترک باعث میشود این برنامه ها که معمولا توسعه دهندگان منحصر به فردی دارند بدون وابستگی و آگاهی از یکدیگر تنها از طریق BUS ارتباط برقرار کنند. به دلیل اینکه در ارتباط یک به یک بعد از گذشت زمان و افزایش سرویس ها، مدیریت ارتباط ها سخت و شکننده میشود و همچنین اشکال یابی در ساختار point to point با وجود سرویس های زیاد دشوار میشود نیاز است با وجود یک ساختار مرکزی برای ارتباط بین اجزای مختلف سازمان مدیریت لاگ و ارتباط های بین آن ها بسیار ساده تر شود همچنین تغییرات در ارتباطات بین برنامه ای در این معماری ساده تر انجام میشود. علاوه بر این سیستم مقیاس پذیر تر میشود و با ورود یا ایجاد یک سرویس جدید تعریف ارتباطات آن میتواند به راحتی انجام گیرد.
یک ابزار برای مدیریت api ها که بین client و سرویس هایی که ارائه دهنده api ها هستند است و بین آن ها قرار میگیرد. تمامی سرویس هایی که یک سازمان ارائه میدهد بوسیله api gateway در دسترس است و بسیار معمول است که خدمات سازمان ها از این طریق ارائه شوند.در ابتدا گمان میکنیم کل کار به دریافت یک request و پاسخ به آن مربوط میشود اما پارامتر ها و وظایف متنوعی میتواند درگیر شود. برای مثال:
شما درواقع با استفاده از api gateway میتوانید تمامی پیچیدگی های درون سیستم خود را از دید کاربر پنهان کنید و کاربر بوسیله آن سرویس مورد انتظار خود را بگیرد و این api gateway است که وابسته به درخواست از سرویس های متنوع برای پاسخگویی استفاده میکند.
بر اساس نوع کسب و کار و مدل آن این روش برای طراحی، تحلیل، اجرا و پایش فرآیندهای کسب و کارها استفاده میشود. روش های قدیمی تر تنها تمرکزشان بر ری ایجاد مدلی از کسب و کار و اجرای متمرکز آن بوده در حالی که در BPMS سعی میشود فرایند های کسب و کار ها با ورودی و منابع درست و در زمان درست به صورت خودکار اجرا شوند. برای اینکه بیشتر BPMS درک شود میتوان آن را مشابه پکیج های برنامه نویسی دانست که برای یک هدف و نیازمندی ممکن است پکیج های زیادی موجود باشد که کاربر میتواند از بین آن ها انتخاب کند همچنین استفاده از این پکیج ها باعث میشود کابر بدون اینکه درگیر پیاده سازی های داخلی و جزئیات شود از خدمات آن ها استفاده کند. درBPMS هم نرم افزار ها و مجموعه های ارایه دهنده آنها هرکدام دارای ویژگی هایی هستند که کسب و کار ها میتوانند با انتخاب آن ها نیاز هایی که در این زمینه دارند را بدون درگیری در چگونگی پیاده سازی و جزییات فرایند خودکار سازی پاسخ دهند. همچنین به دلیل وجود و راحتی در ابزارهای ساخت، اجرا (پلتفرم) و مانیتورینگ فرایند ها به کاربر های این فرصت داده میشود تا در بهبود و رفع خطاهای فرایند های کسب و کار بوسیله ابزار های ساده مشارکت داشته باشند.
قوانین تجاری اهداف سازمان را مشخص میکنند و برای اجرای فرایند های متفاوت دستورالعمل های متناسب را ارایه میدهند به همین دلیل در واقع فعالیت های تجاری کسب و کار ها را تعریف یا حتی محدود میکنند. در سازمان هایی که این قوانین مستند نیستند، کارکنان آن سازمان به خصوص افراد با سابقه میدانند باید به چه شکلی کار ها انجام شود یا فرایندی طی شود اما این کار ناهماهنگی و ناکارآمدی را در سطح سازمان افزایش میدهد. با مستند کردن و مدیریت این فرایند ها تعریف واحد و رسمی برای انجام فرایند های کسب و کار ایجاد میشود که اهداف انجام آن ها برای همه افراد سازمان مشخص است. BRMS یک راه حل نرم افزاری برای تعریف، مستند سازی، اجرا و مانیتورینگ و مدیریت قوانین تجاری است یعنی با استفاده از BRMS، استفاده از قوانین تجاری در کل سازمان خودکار میشود و سازمان هایی که دارای قوانین تجاری هستند و هنوز از روش های قدیمی و غیر خودکار استفاده میکنند با این کار ویژگی های زیر را بدست خواهند آورد:
یک نوع راه برای انتقال پیام به صورت asynchronous است.انتقال پیام در صف دو طرف producer و consumer دارد که وظیفه producer انتقال پیام و وظیفه consumer دریافت آن است. در Message queue ها داده ها به همان ترتیبی که وارد میشوند نگهداری میشوند و تا زمانی که پیامی خوانده یا حذف نشود (ack فرستاده نشود) آن پیام در صف باقی میماند.به طور مثال در معماری های microservice برای ارتباط بین دو سرویس یا در eventsourcing برای دریافت لاگ ها یا وقایع استفاده میشود، علاوه بر انتقال پیام میتوان برای بافر کردن یا تقسیم load بین منابع پردازشی هم از صف ها استفاده کرد. استفاده از صف ها تا حد خوبی میتواند قابلیت اطمینان و مقیاس پذیری در انتقال پیام را افزایش دهد. حالتی را در نظر بگیرید که قدرت پردازش تولید کننده پیام بیشتر از مصرف کننده آن است یا بازه زمانی پردازش داده در این دو گروه متفاوت است (cronjob ها) در این حالت اگر قرار باشد همان زمانی که تولید کننده (ارسال کننده) پیام را ایجاد کرده مصرف کننده(دریافت کننده) آن را دریافت یا پردازش کند احتمالا همه یا تعداد بسیاری پیام از دست میرود.استفاده از صف ها باعث میشود وابستگی بین دو گروه producer و consumer در برخی کاربرد ها کم شود و امکان انتقال پیام بین این دو گروه با تفاوت هایی که گفته شد امکان داشته باشد.
منظور از Containerization یعنی ایجاد یک بسته و گروه که شامل فایل ها و تنظیمات و …. با خود برنامه که در واقع هر چیزی برای اجرای برنامه نیاز است را فراهم میکند تا در یک محیط ایزوله اجرا شود. این روش اجرا بسیار سبک تر از روش های قدیمی است زیرا مستقیما روی سیستم عامل میزبان اجرا میشود و از منابع و ویژگی هایی که از قبل سیستم عامل داشته استفاده میکند. برای ایجاد و راه اندازی برنامه ها به این روش راه حل های متفاوتی وجود دارد ولی محبوب ترین آن ها docker است. پس در واقع docker روشی است برای ساختن container ها به صورت ساده و سریع به طوری که روی سیستم عامل های متنوع قابلیت به کارگیری دارد و هم در فضای development و هم production استفاده میشود. همچنین docker دارای repository از container های آماده است که با شما امکان میدهد زمانی که میخواهید برنامه خود را بوسیله آن بالا بیاورید میتوانید نیازمندی هایی دیگر یا ابزار های مورد نیاز خود را در رجیستری جست و جو و به صورت آماده استفاده کنید . استفاده از Containerization باعث انعطاف پذیری بیشتر، مدیریت بهتر منابع، افزایش سرعت فرایند اجرا، کاهش نگرانی ها و ریسک ها در مورد بستر پایده سازی و منابعی که به آن ها وابسته هستیم، امنیت و مدیریت راحت تر و… میشود، اما استفاده از Containerization ها ممکن است هزینه هایی داشته باشد مثل نبود معماری خوب یا نبود توسعه دهندگان با سابقه در استفاده از این روش ها تحت نیازمندی خاص.
برای خودکار کردن مجموعه کار های مورد نیاز برای deploy و اجرای container ها در فضای production که شامل مواردی میشود که توسعه دهندگان برای مدیریت مجموعه ای از کار ها مثل deployment, scaling, networking و load balancing انجام میدهند. به دلیل اینکه استفاده از container ها در معماری microservice به دلیل سبک بودن و مقیاس پذیر بودنشان بسیار مورد استفاده است در سیستم های بزرگ با مقیاس بالا ممکن است دارای تعداد زیادی از این container ها باشیم که مدیریت اجرا و توسعه آن ها بعد از گذشت مدتی نیاز به تلاش بسیاری دارد و اگر این کار ها به صورت دستی انجام شود سرعت عمل را در تیم های Devops کم میکند برای همین Container orchestration فرایند توسعه و عملیات های مربوطه را خودکار میکنند تا برای تیم های devops استفاده از container ها و مدیریت آن در فضای production منطقی باشد. ابزار های موجود میتوانند بوسیله هماهنگی بین container ها بر اساس تقاضا و درخواست ها scaling دوباره انجام دهند یا در مواردی که نیاز است راه اندازی مجدد را انجام دهند به این ترتیب انعطاف پذیری افزایش پیدا میکند.همچنین سازماندهی و حفظ امنیت در container ها بالا میرود و امکان خطای انسانی در مدیریت آن ها به کمترین حد خود می‌رسد.
لاگ ها، وقایع و گزارش هایی هستند که برنامه و سیستم در روند اجرای خود ثبت و ارسال میکند و میتواند شامل پیام های مختلف، گزارش خطا، request های دریافتی و … شود که باید زمان وقوع آن ها هم ثبت شود به همین دلیل timestamp در کنار گزارش برای ثبت زمان آن می‌آید. Log Management و ابزار های مورد استفاده در آن برای ایجاد فرایندی است که به طور پیوسته نسبت به جمع آوری، ذخیره سازی، پردازش و تحلیل گزارش عمل میکنند که خروجی آن ها برای بررسی performance ، تشخیص خرابی، حجم خطای سیستم، مدیریت بهتر منابع و حفظ بهتر امنیت سیستم و تشخیص سریع خطر های احتمالی به کار می آید. استفاده از ابزار های مناسب در جمع آوری ، مانیتورینگ، ذخیره سازی و… باعث میشود تیم های مختلف توسعه و نگهداری برنامه نرم افزاری و سیستم بتوانند به راحتی وضعیت و کیفیت بخش های مختلف را رصد کنند و برای گزارش خرابی فرایند های خودکاری تعریف کنند همچنین در صورت بوجود آمدن اشکال کار رصد و یافتن منبع مشکل ساده تر انجام شود. در انتخاب ابزار باید نکاتی مثل ذخیره سازی یکپارچه داده ها، بهبود امنیت، تشخیص زمان درست و واقعه، ابزار مانیتورینگ قابل مشاهده در تمام سازمان و متناسب با نیازمندی های آن ها، تجزیه و تحلیل متناسب با سیستم و نیازمندی ها، عیب یابی سریع و و شامل اطلاعات دقیق و درست را در نظر گرفت.
ابزار هایی که برای رصد پیوسته وضعیت سیستم استفاده می شود تا بوسیله آن بتوانیم در زمان درستی از failure, defect و اشکالات آگاه شویم. از مانیتورینگ میتوان در ابزار ها و محیط های متفاوتی استفاده کرد و کاربرد آن فقط در برنامه و کد های زده شده نیست به طور مثال برای پایگاه داده ها، وضعیت شبکه، امنیت، حجم منابع مورد استفاده و …. هم میتوان استفاده کرد. میتوان برای هر یک از موارد threshold و مرزهایی تعیین کرد تا در صورت تجاوز از آن به صورت خودکار به مدیران و توسعه دهندگان مربوطه alert دهد. وجود تاریخچه ای از رفتار سیستم بر اساس گزارش ها و نمودار های مانیتورینگ در بسیاری از مواقع میتواند در مواردی مثل ارزیابی سیستم یا تشخیص رفتار کلاینت ها به سازمان دید بدهد، و در صورت نیاز به بهبود عملکرد، بتوان با اطلاع دریافتی از مانیتورینگ تغییرات درست و متناسب در تنظیمات و config های پروژه و ابزار های وابسته به آن را داد. البته باید به این موضوع دقت کرد که معمولا ابزار های مانیتورینگ یک دید از بالا نسبت به وضعیت سیستم و اجزای سیستم به ما میدهد و باید با اولین نگاه بتوان اطلاعات درستی از نمودار ها و گزارش های آن گرفت برای همین باید زمان تعریف آن ها دقت لازم برای هر چه کمتر کردن پیچیدگی های اضافی و متناسب ساختن آن با نیازمندی های سازمان را انجام داد.
روشی برای یافتن اشکالات و خطاهای کد های زده شده بدون اجرای آن ها است همچنین کد ها و ساختار آن ها بررسی میشود تا کیفیت لازم را داشته باشند، اصول و استاندارد های تعریف شده را هم رعایت کرده باشند. این روش توسط تیم های توسعه نرم افزار و تضمین کیفیت بوسیله ابزار هایی به کار گرفته میشود تا کد های پروژه اسکن و تحلیل شوند و موارد لازم برای اصلاح مشخص و انجام شوند. استفاده از این ابزار ها باعث کاهش خطاهای برنامه نویسی میشود و پیش از ایجاد اشکالات بزرگ و تاثیر گذاری در کل سیستم این اشکالات شناسایی و رفع میشوند همچنین در صورت نقض استاندارد ها و ساختار کلی پروژه نسبت به تغییر آن هشدار داده میشود. جلوگیری از ایجاد مقادیر تعریف نشده و خطاهایی که به syntax مربوط میشوند یا حتی در مواردی بررسی آسیب پذیری های امنیتی نیز انجام میشود. روند انجام این کار بوسیله ابزار های خودکار با تعریف یک سری از قوانین برای اسکن و تحلیل کد ها شروع میشود که پس از آن ابزار به صورت خودکار کد را بررسی و درصورت رعایت نکردن قوانین هشدار های لازم را میدهد. ممکن است درمواردی هشداری داده نشود که این مورد ضرورت بررسی کد بوسیله توسعه دهندگان را نشان میدهد اما درصورت نبود ابزار هایی که این کار را تا حد زیادی خودکار کنند بررسی آن توسط عامل انسانی علاوه بر این که درصد اشتباه را بالا می‌برد سرعت توسعه دهندگان و کیفیت خروجی آن ها را کاهش میداد.
در دنیای امروزی که سرعت تغییرات زیاد شده و نیازمندی های جدید و تغییر آن ها با نرخ بسیار بیشتری به سمت توسعه دهندگان می آید استفاده از روش های قدیمی برای deploy ناکارآمد است و پروژه باید همیشه با تغییرات انجام شده قابلیت deploy و نمایش برای کلاینت ها را داشته باشد. Continuous Delivery فرایندی است که به ما این امکان را میدهد به صورت پیوسته انواع مختلف تغییرات در کد را که شامل اضافه کردن ویژگی جدید، رفع باگ یا تغییر تنظیمات و … میشود را در production اعمال کنیم و تغییرات به صورت امن و پایدار در کمترین زمان توسط کلاینت قابل استفاده باشد. بنابراین باید همیشه مطمئن باشیم پروژه و کد های ما آماده deploy هستند که این نیاز به این دارد مراحل integration و test و … قبل از آن انجام شده باشد. اغلب وقتی از deploy مستمر و همیشگی صحبت میشود به کیفیت پایین تر و پایداری کمتر فکر میشود ولی در این روش و با استفاده از ابزار های مناسب علاوه بر اینکه این مشکلات بوجود نمی آید بلکه در زمینه رقابت با رقبا به دلیل توجه سریعتر و همیشگی به نیاز ها، موفق تر ظاهر می شویم همچنین ریسک خطر نیز کاهش پیدا میکند زیرا در هر لحظه امکان تغییر و اصلاح را داریم همچنین با وجود مراحل تست و بررسی های مربوط به کیفیت خطر بوجود آمدن مشکل به کمترین حد خود می‌رسد.
زمانی که از یک سرویس مشترک برای احراز هویت و لاگین کلاینت ها استفاده میشود و به کاربران برای دسترسی به سرویس های گوناگون تنها لازم به لاگین از طریق یک سرویس هستند در واقع از SSO استفاده میشود. SSO میتواند در سیستم ها با مقیاس های مختلف استفاده شود. SSO یک federal identity management است که یکی از مثال های معروف آن میتواند OAuth باشد که در آن کاربر یک حساب گوگل، فیس بوک یا … دارد و میتواند بوسیله آن ها در بسیاری از سایت ها ثبت نام کند و از خدمات آن ها استفاده کند. روش های مختلفی برای پیاده سازی SSO وجود دارد مثلا سرویس احراز هویت یک تیکت به کاربر بدهد و کاربر دیگر از آن برای دریافت خدمات از سرویس های دیگر استفاده کند. استفاده از این روش ریسک هایی دارد که اگر پیش بینی نشوند و از آن ها جلوگیری نشود منجر به حمله های امنیتی و مشکلات بزرگی میشود. مثلا اگر اطلاعات ورود کاربر به نوعی توسط attacker گرفته شود میتواند بوسیله آن به همه سرویس ها و خدمات دسترسی داشته باشد و خسارت بالای ایجاد کند به همین دلیل معمولا از روش هایی مثل multi factor authentication استفاده میشود اما اگر ملاحظات امنیتی رعایت شود به دلیل اینکه کاربر تنها یک بار لاگین میکند و میتواند از همه خدمات استفاده کند سهولت کار با سیستم بیشتر میشود همچنین خطا یابی و و اصلاح در این سیستم راحت تر میشود.
یک روش برای ارتباط و اشتراک و کنترل قسمت های مختلف برای اشتراک داده ها است و یک ساختار و لایه جدا و مشخص است که کار مدیریت ارتباط را انجام میدهد و و به دلیل مستقل بودن آن مشاهده‌پذیری، امنیت و قابلیت اطمینان برنامه‌ها افزایش می یابد.معماری microservice شامل سرویس های مجزایی هستند که به صورت مستقل توسعه و نگهداری میشوند اما ارتباطاتی با یکدیگر دارند که در سیستم های بزرگ و یا در حال توسعه نیاز به مدیریت دارند ،service mesh برای این منظور استفاده میشود. پیاده سازی آن بوسیله مجموعه ای از پراکسی ها است که مقیاس پذیر هستند و علاوه بر این که ارتباطات بین سرویس ا بوسیله آن ها انجام میشود feature های مورد نیاز در service mesh هم در آن ها تعریف میشود. این روش در خدمات ابری کاربرد زیادی دارد زیرا ممکن است در آن ها یک برنامه شامل سرویس های زیادی باشد که از هرکدام چندیدن instance بالا باشد، مدیریت ارتباطات میان این ها که هر کدام ممکن است به صورت مستقل هر لحظه تغییر یا reconfig شوند، برای اطمینان از عملکرد و وضعیتشان بسیار مهم است. نمونه ای از feature هایی که میتوان در service mesh پیاده سازی کرد:
