خانه / Agile / مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

هرچند تفکر و ایده ی ورای Microservices به سال ها قبل برمی گردد؛ اما این اصطلاح در سال 2014 به مهمترین ترند در دنیای نرم افزار تبدیل شد و به عنوان یکی از hottest topic ها در این سال سهم بیشتر سخنرانی ها؛ کنفرانس ها و مقالات را بخود اختصاص داد. بطوریکه خیلی سریع به بالای نمودار گارتنر رسید. شرکت ها و موسسات و افراد بسیار زیاد و مختلفی هر کدام از دیدگاه و نقطه نظر خود به این موضوع پرداختند. و دیدگاه های مختلفی از این معماری نوظهور ارائه شد؛ که نشان از این داشت که هر کسی از دیدگاه و نقطه نظر خود به موضوع نگاه می کرد. در این میان عده ی زیادی نیز وجود داشتند که Microservices را فقط بیان جدید و یک rebranding از soa دانسته و از این دیدگاه به مسئله ی Microservices ها نگاه انداختند. Microservices از شرکتهایی از جمله ی Netflix؛ Gilt؛ Amazon و SoundCloud نشات کرفته شد. این شرکتهای استارت آپی بزرگ که دارای سیستم های نرم افزاری monolithic بودند در طی زمان اقدام به decompose نمودن سیستم های خود به service های کوچکتری نمودند که که از طریق مکانیزم هایی از جمله RESTFull API ها اقدام به communicate نمودن با هم جهت تکمیل business use case ها می کردند. Maintain کردن راحت تر و سریعتر؛ توسعه سریعتر؛ شکستن complexity سیستم های بزرگ به سرویس های کوچکتر و … مواردی از دلایل سوق دادن این شرکت ها و شرکت های مشابه به decompose کردن سیستم های خود به سرویس های کوچکتر بود. این اشتراکات این شرکتهای پیشرو فقط محدود به معماری و طراحی معماری های آنها نمی شد. این شرکتها علاوه بر این دارای ساختار و فرهنگ سازمانی مشابه؛ زیرساخت های فنی و clud-based مشابه و سطج اجایلیتی مشابهی نیز می باشند. شرکت های خیلی زیادی که در Microservices ها موفق بوده و هستند از همین رویکرد ها و پیش زمینه و ساختارهای سازمانی استفاده نمودند.

خوب اما ممکن است این سوال پیش بیاید که چه ارتباطی ممکن است میان Microservices ها و تفکر و فرهنگ اجایل وجود داشته باشد؟ که در ادامه به توضیح این موضوع خواهم پرداخت.

تعدادی از افراد پیشرو در صنعنت نرم افزار سال 2001 اقدام به انتشار بیانیه ای نمودند که به مانیفست اجایل معروف شد. این مانیفست در واقع بیانیه ای بود از یکسری ارزشها که باعث بهبود توسعه نرم افزار می شد. همانطور که در بالا بیان شد Microservices در تقابل با Monolithic ها و به عنوان راه حلی جهت حل نمودن مشکلات این سیستم ها مطرح شد؛ مانیفست اجایل نیز به عنوان نقطه ی تقابل “documentation-driven, heavyweight software development processes.”  مطرح شد. اجایل در واقع در تلاش بود که با انجام کارهای کوچکتر بصورت افزایشی و تکراری و با تمرکز بر collaboration بیشتر با مشتری و user ها سعی در غلبه نمودن بر overhead ها و risk های توسعه سیستم های با مقیاس بزرگ داشت.

گسترش و محبوبیت استفاده از متدولوژی های اجایل منجر به تاکید بیشتر و highlight شدن Continuous Integration و practice هم که توی متدلوژی eXtreme Programming وجود داشته؛ در سایر متدولوژی های اجایل شد. CI بر مساله combine شدن هر چه سریعتر component های نرم افزار جهت از بین بردن مساله Code Integration تاکید و تمرکز داشت. در واقع با معرفی اجایل چالش های document-driven حل شد. و سپس مساله و چالش تیم از فرآیند توسعه به code integration تبدیل شد؛ که با تاکید بیشتر بر CI سعی در حل این مشکلات شد. Bottleneck تیم ها اما پس از مدتی از code integration یک قدم جلوتر رفت و تیم ها و سازمانها متوجه آن شدند که باتلنک اصلی آنها در حال حاضر release نرم افزار می باشد.

جهت غلبه بر مشکلات releasing مجدد در سال 2006 تاکید بیشتری بر مفاهیم Continuous Delivery شد. CI نیز در واقع تاکید زیادی بر “Potentially shippable product increment” داشت. CD سعی در تعریف یک pipeline داشت که هر چه سریعتر تغییرات به production منتقل شود. ابزارها و تکنیک های زیادی جهت اعمال پرکتیس های CD معرفی شد. ترکیب صحیحی از agile  و CD باعث میشد که هم سرعت توسعه بیشتر شده و هم releaseهای سریعتری داشت و هم کیفیت نرم افزار نیز بالاتر برود.

اما هنوز یک bottleneck وجود داشت. همانطور که ملاحضه خواهیم کرد scope اصلی اجایل و focus آن بر توسعه نرم افزار می باشد, و این درحالیست که CD همانطور که ذکر شد درای scope گسترده تر بود و شامل محیط production-محیط عملیاتی؛ نیز می شد. در اکثر سازمانها development و operation کاملا از هم مجزا و تفکیک بودند. در سال 2009؛ John Allspaw و Paul Hammond از شرکت Flickr  در کنفرانس O’Reilly Velocity درباره ی این به چه صورت می توان این gap موجود میان development و operation و مشکلی که از ترکیب Agile با CD بوجود آمده-یا در واقع boldتر شده؛ صحبت به میان آوردند. بر اساس تجربیات و سخنرانی های این دو نفر DevOps معرفی شد و جهت حل این مشکل تقسیم و جداسازی فرهنگی سنتی موجود در سازمانهای نرم افزاری معرفی شد.

سازمانها هم کم کم متوجه تاثیر و ارزش ترکیب مسئولیت های development و operations توسط یک تیم بر پرکتیس های CD شدند. به همان اندازه که تعاملات و همکاری های Dev و Ops بالاتر می رود یکدلی و همدلی میان این افراد نیز بالاتر می رفت. در این راه حل های ارائه داده شده توسط توسعه دهنده ها بگونه ای بود که دید operational از محیط بیرون از محیط توسعه را نیز در بر میگرفت؛ و از طرف دیگر افراد عملیاتی نیز از رویکردهای مهندسی جهت مواجه شدن با مشکلات استفاده می کردند.

سازمانهایی که از این رویکرد “تسلسل اجایل”- از توجه به توسعه نرم افزار به deploy کردن سیستم و به ساختار عملیاتی- استفاده می کنند؛ سازمانهای پیشرویی بودند که معمولا دارای سیستم های web-based بودند که بصورت یک single application یا monolithic ارائه میشد. و به مراتبی که پیچیدگی و مقیاس بیزینس این شرکت ها افزایش پیدا کرد؛ این سازمانها دریافتند که این ساختار معماری به عنوان یک مانع برای deliver کردن feature های جدید هست. شرکت هایی از جمله SoundCloud همزمان به این نکته پی بردند که شکستن برنامه های monolithic به قسمت های کوچکتر و business-focused؛ با agile delivery methodology و فرهنگ DevOps آنها مناسب تر می باشد. می توان گفت Microservices در واقع فاز معماری از چرخه ی تسلسل اجایل می باشد.

در سال 2013 آقای Simon Brown در  بلاگ شخصی خود؛ در مورد agile software architecture صحبت کرد. در این مطلب او اشاره می کند که Agile Architecture در واقع از Agile Development Practices نشات نمی گیره. در زیر بخشی از صحبت های ایشان آورده شده؛ همانطور که مشاهده می کنید Agile Software Architecture بسیار به Microservices Architecture نزدیک است.

If we look at the characteristics of an agile software architecture, we tend to think of something that is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal. This style of architecture provides agility in a number of ways. Small, loosely coupled components/services can be built, modified and tested in isolation, or even ripped out and replaced depending on how requirements change. This style of architecture also lends itself well to a very flexible and adaptable deployment model, since new components/services can be added and scaled if needed.

نکته های زیادی در اینجا وجود دارد. ولی یکی مهمترین نقطه ی اشتراکات agile software development؛ continuous delivery؛ DevOps culture و Microservices Architecture در اینجا این هست که همگی دارای هدفی مشترک هستند؛ جوابدهی بیشتر به نیازهای مشتری و داشتن سطح بالایی از کیفیت و در دسترس بودن سیستم.

 

منابع:

  1. https://www.infoq.com/articles/towards-agile-software-architecture
  2. http://www.codingthearchitecture.com/2013/09/03/what_is_agile_software_architecture.html
  3. https://en.wikipedia.org/wiki/DevOps
  4. https://www.youtube.com/watch?v=LdOe18KhtT4
  5. https://continuousdelivery.com/
  6. https://openkinect.org/wiki/Code_Integration
  7. https://en.wikipedia.org/wiki/Extreme_programming
  8. https://en.wikipedia.org/wiki/Continuous_integration
  9. http://agilemanifesto.org/principles.html
  10. http://agilemanifesto.org/history.html
  11. http://agilemanifesto.org/

 

 

 

 

 

Trying to be Agile…

Masoud Bahrami

http://refactor.ir/

 

درباره ی masoud@admin

همچنین ببینید

Serverless Architecture for an IoT solution xconf eu 2017

Serverless Architectures معماری Serverless که به عنوان یکی از Deployment Strategy های مورد در استفاده …

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد.

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد. یکی از …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن