SlideShare a Scribd company logo
1 of 52
Microservices:
Martin Fowler:
"Microservices" - yet another new term on the crowded streets of software architecture.
https://martinfowler.com/articles/microservices.html
Masoud Bahrami
http://Refactor.Ir
Agile Developer
‫مایکروسرویس‬‫ها‬
Masoud Bahrami
http://www.Refactor.Ir
Masoud@Refactor.IR
https://t.me/MyMicroservices
‫سرفصل‬
•‫ها‬ ‫مایکروسرویس‬ ‫معماری‬ ‫بر‬ ‫ای‬ ‫مقدمه‬
•‫شده‬ ‫توزیع‬ ‫های‬ ‫سیستم‬ ‫تاریخی‬ ‫سیر‬ ‫بر‬ ‫نگاهی‬
•REST API
•‫ها‬ ‫مایکروسرویس‬ ‫معماری‬ ‫و‬ ‫اجایل‬ ‫های‬ ‫متدولوژی‬
•‫با‬ ‫ها‬ ‫مایکرسرویس‬ ‫معماری‬ ‫پیدایش‬ ‫سیر‬ ‫به‬ ‫نگاهی‬
‫ارائه‬Case Study‫از‬ThoughWorks
•‫ها‬ ‫مایکروسرویس‬ ‫تعریف‬
•‫معماری‬ ‫با‬ ‫شده‬ ‫داده‬ ‫توسعه‬ ‫های‬ ‫برنامه‬ ‫مقایسه‬
‫مانولیت‬ ‫های‬ ‫برنامه‬ ‫مقابل‬ ‫در‬ ‫ها‬ ‫مایکروسرویس‬
•‫ها‬ ‫مایکروسرویس‬ ‫معماری‬ ‫های‬ ‫ویژگی‬
‫مایکروسرویس‬ ‫معماری‬ ‫بر‬ ‫ای‬ ‫مقدمه‬
‫ها‬
•‫دنیای‬ ‫از‬ ‫برخواسته‬
Distributed SystemsDomain-Driver DesignAgile
Continues Integration &
Continues Deployment
Provisioning
&
Virtualization
Refactoring BBoM and
fragile systems
RESTful
‫سال‬2014‫ها‬ ‫مایکروسرویس‬ ‫سال‬
Gartner Hype cycle.
‫شده‬ ‫توزیع‬ ‫های‬ ‫سیستم‬ ‫تکامل‬ ‫سیر‬
•Remote Procedure Call(RPC)
•The Session Façade‫توسط‬Kyle Brown‫و‬John Crupi‫و‬Martin Fowler
•do the simplest thing that could possibly work
•Service Oriented Architecture(SOA)‫و‬Simple Object Access
Protocol(SOAP)
•Remote Method Invocation(RMI)
Exception handling, transaction support, security, and digital signatures
Be of the web, not behind the web
Representational State Transfer (REST)
•"Architectural Styles and the Design of Network-based Software
Architectures"
•‫بر‬ ‫مبتنی‬ ‫ساده‬ ‫های‬ ‫درخواست‬ ‫ارسال‬HTTP
•‫از‬ ‫استفاده‬HTTP Verb‫درخواست‬ ‫نوع‬ ‫تعیین‬ ‫جهت‬ ‫ها‬
•URL
‫گانه‬ ‫شش‬ ‫اصول‬REST
.1Client-Server
.2Stateless
.3Cacheable
.4Uniform Interface
.5Layered System
.6Code on Demand
Representation
Resource Identifier
abc.com/API/file/5
Uniform Interface
.1Resource-Based
.2Manipulation of Resources Through Representations
.3Self-Descriptive Messages
.4Hypermedia As The Engine Of Application State(HATEOAS)
https://martinfowler.com/articles/richardsonMaturityModel.html
http://royalhope.nhs.uk/slots/1234/appointment
If something is important, make it an
explicit part of your design
‫رویکردهای‬ ‫برای‬ ‫جایگزین‬ ‫حلی‬ ‫راه‬ ‫یافتن‬ ‫بدبنال‬document driven‫و‬
heavyweight‫افزار‬ ‫نرم‬ ‫تولید‬ ‫فرآیند‬ ‫در‬
‫کرد‬ ‫تالش‬ ‫اجایل‬overhead‫و‬risk‫کمک‬ ‫با‬ ‫را‬ ‫بزرگ‬ ‫مقیاس‬ ‫در‬ ‫سیستم‬ ‫توسعه‬
‫ایجاد‬ ‫طریق‬ ‫از‬ ‫و‬ ‫افزایشی‬ ‫و‬ ‫کوتاه‬ ‫تکرارهای‬ ‫تعریف‬prototype‫در‬ ‫ها‬
‫کند‬ ‫حل‬ ‫محصول‬ ‫فیدبک‬ ‫چرخه‬ ‫در‬ ‫تسریع‬ ‫جهت‬ ‫تکرار‬ ‫هر‬ ‫پایان‬
‫اتفاقات‬ ‫پسا‬
‫اجایل‬
In 2009, John Allspaw and Paul Hammond
from Flickr at O’Reilly Velocity conference
SoundCloud Netflix
Agile Software Architecture
Agile Software Architecture is built using a collection of small, loosely coupled
components/services that collaborate together to satisfy an end-goal.
 Provides agility.
 Small loosely coupled components/services van 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.
‫مایکروسرویس‬ ‫معماری‬ ‫بر‬ ‫ای‬ ‫مقدمه‬
‫ها‬
•‫دقیق‬ ‫تعریف‬‫؛‬‫سبک‬ ‫این‬ ‫از‬ ‫شده‬ ‫پذیرفته‬ ‫و‬ ‫مشخص‬
‫ندارد‬ ‫وجود‬ ‫معماری‬
•‫مشترک‬ ‫مشخصات‬ ‫و‬ ‫ها‬ ‫ویژگی‬‫سازمان‬
‫فرآیند‬
‫تولید‬
‫چابک‬
‫ی‬
‫اتومیشین‬
‫فرآیند‬
‫دیپلوی‬
Polyglot
Databases
Polyglot
Languages
‫پیدایش‬‫اصطالح‬Microservices
•‫می‬ ‫بار‬ ‫اولین‬2012‫کنفرانس‬Software Architectures
‫ونیز‬ ‫نزدیک‬
•‫می‬2012‫اصطالح‬ ‫روی‬ ‫بر‬ ‫توافق‬“Microservices”‫عنوان‬ ‫به‬
‫اصطالح‬ ‫ترین‬ ‫مناسب‬
•‫مارچ‬2012‫کنفرانس‬ ‫در‬33rd Degree‫؛‬James Lewis‫قالب‬ ‫در‬
‫یک‬Case Study‫کرد‬ ‫مطرح‬ ‫را‬ ‫ها‬ ‫ایده‬ ‫برخی‬
‫برای‬ ‫لوئیز‬ ‫جیمز‬ ‫که‬ ‫های‬ ‫ویژگی‬
‫برشمرد‬ ‫های‬ ‫مایکرسرویس‬
•Small with a Single Responsibility
•Containerless and installed as well behaved Unix services
•Located in different VCS roots
•Provisioned automatically
•Status aware and auto-scaling
• James Lewis:
•Capabilities‫طریق‬ ‫از‬ ‫تعامل‬ ‫با‬ ‫ها‬Uniform Interfaces‫با‬
‫دارند‬ ‫تعامل‬ ‫یکدیگر‬
•‫هرچند‬James Lewis‫از‬RESTful‫ویژگی‬ ‫ولی‬ ‫نکرده‬ ‫صحبتی‬
‫برای‬ ‫را‬ ‫زیر‬ ‫های‬Uniform Interfaces‫شمرد‬ ‫بر‬:
•HTTP(Be of the web, not behind the web)
•HATOS
•Standard Media Types
Capabilities‫صورت‬ ‫چه‬ ‫به‬ ‫ها‬Product‫را‬
‫دهند‬ ‫می‬ ‫تشکیل‬
‫مایکروسرویس‬ ‫معماری‬ ‫سبک‬ ‫تعریف‬
‫ه‬‫ا‬
Sam Newman(Building Microservices, O’rriely 2015):
Microservices are small, autonomous services that work together.
‫توسعه‬ ‫جهت‬ ‫است‬ ‫رویکردی‬ ‫ها؛‬ ‫مایکروسرویس‬ ‫معماری‬ ‫سبک‬
‫بصورت‬ ‫برنامه‬ ‫یک‬:
.1‫کوچک‬ ‫های‬ ‫سرویس‬ ‫از‬ ‫ای‬ ‫مجموعه‬
.2‫خود‬ ‫مخصوص‬ ‫پراسس‬ ‫روی‬ ‫بر‬ ‫سرویس‬ ‫هر‬run‫شود‬ ‫می‬
.3‫وزن‬ ‫سبک‬ ‫های‬ ‫مکانیزم‬ ‫طریق‬ ‫از‬ ‫ها‬ ‫سرویس‬ ‫دیگر‬ ‫با‬ ‫تعامل‬
‫غالبا‬HTTP resource API
‫اتوماتیک‬ ‫کامال‬ ‫انتشار‬ ‫فرآیند‬ ‫توسط‬ ‫مستقل‬ ‫انتشار‬ ‫قابلیت‬
‫تکنولوژی‬ ‫در‬ ‫مثال‬ ‫عنوان‬ ‫به‬ ‫مرکزی‬ ‫مدیریت‬ ‫میزان‬ ‫کمترین‬
‫نویسی‬ ‫برنامه‬ ‫های‬ ‫زبان‬ ‫و‬ ‫ها‬ ‫داده‬ ‫سازی‬ ‫ذخیره‬
‫مبنای‬ ‫بر‬ ‫شده‬ ‫داده‬ ‫توسعه‬Business Capabilities
‫ت‬‫یک‬ ‫دادن‬ ‫انجام‬ ‫خوب‬ ‫روی‬ ‫بر‬ ‫مرکز‬
‫چیز‬
•‫هر‬iteration‫مقداری‬code‫به‬code base‫می‬ ‫افزوده‬ ‫اولیه‬
‫شود‬
Robbert C.Martin:
Gather together those things that change for the same reason, and separate those things that change
for different things.
‫یعنی‬ ‫کوچک؛‬ ‫سرویس‬
‫اندازه؟؟؟‬ ‫چه‬
•‫روی‬ ‫بر‬ ‫مستقل‬ ‫بصورت‬ ‫مایکروسرویس‬ ‫هر‬PaaS‫بتواند‬
‫شود‬ ‫اجرا‬ ‫خود‬ ‫مخصوص‬ ‫پراسس‬ ‫در‬ ‫یا‬ ‫شود‬ ‫دیپلوی‬.
•Communication‫می‬ ‫انجام‬ ‫شبکه‬ ‫روی‬ ‫بر‬ ‫های‬ ‫سرویس‬ ‫بین‬
‫شود‬
•‫در‬ ‫تغییر‬ ‫به‬ ‫نیاز‬ ‫بدون‬ ‫باید‬ ‫سرویس‬ ‫هر‬consumer
‫باشد‬ ‫داشته‬ ‫دیپلوی‬ ‫و‬ ‫تغییر‬ ‫قابلیت‬ ‫هایش؛‬
•‫یک‬ ‫سرویس‬ ‫هر‬Application programming Interface(API)‫را‬
‫دهد‬ ‫می‬ ‫ارائه‬
Autonomous
‫را‬ ‫تغییری‬ ‫ها؛‬ ‫سرویس‬ ‫سایر‬ ‫در‬ ‫تغییر‬ ‫به‬ ‫نیاز‬ ‫بدون‬ ‫توان‬ ‫می‬ ‫آیا‬
‫کرد؟‬ ‫دیپلوی‬ ‫آنرا‬ ‫سپس‬ ‫و‬ ‫کرد‬ ‫ایجاد‬ ‫سرویس‬ ‫یک‬ ‫در‬
‫مانولیتیک‬ ‫برنامه‬ ‫یک‬
‫تمام‬Capability‫ها‬
‫سیستم‬ ‫پراسس‬ ‫یک‬ ‫در‬
‫شوند‬ ‫می‬ ‫اجرا‬ ‫عامل‬
‫می‬ ‫مقیاس‬ ‫افقی‬ ‫بصورت‬
‫شود‬
‫مشکالت‬:
‫تغییر‬ ‫های‬ ‫چرخه‬
‫به‬ ‫وابسته‬ ‫و‬ ‫طوالنی‬
‫یکدیگر‬
‫ماژوالر‬ ‫ساختار‬ ‫حفظ‬
‫زمان‬ ‫گذشت‬ ‫با‬ ‫اولیه‬
‫باشد‬ ‫می‬ ‫مشکل‬
‫نیازمند‬ ‫پذیر‬ ‫مقیاس‬
‫کل‬ ‫کردن‬ ‫مقیاس‬
‫باشد‬ ‫می‬ ‫برنامه‬
‫مایکروسرویس‬ ‫معماری‬
Capability‫سرویس‬ ‫به‬ ‫ها‬
‫می‬ ‫منتقل‬ ‫جداگانه‬ ‫های‬
‫کند‬
‫می‬ ‫مقیاس‬ ‫عمودی‬ ‫بصورت‬
‫شود‬
Scale 3d Cube- by: The Art of Scalability.
‫معماری‬ ‫های‬ ‫مزیت‬
‫ها‬
‫تکنولوژی‬ ‫به‬ ‫وابستگی‬ ‫عدم‬
‫دیتابیس‬
‫رابطه‬
‫ای‬
Blob
‫دیتابیس‬
Graph
‫دیتابیس‬
‫اطالعات‬
‫ماشین‬
C#
‫بارگیری‬ ‫محل‬
Python
‫تصاویر‬
PHP
‫ارتجاعی‬ ‫قابلیت‬-Resilience
•‫برنامه‬ ‫کل‬ ‫روی‬ ‫بر‬ ‫آبشاری‬ ‫تاثیرات‬ ‫از‬ ‫جلوگیری‬
•Service Boundaries‫تاثیر‬ ‫از‬ ‫جلوگیری‬ ‫عامل‬ ‫؛‬fail‫یک‬ ‫ها‬
‫باشد‬ ‫می‬ ‫برنامه‬ ‫کل‬ ‫بر‬ ‫سرویس‬
•‫به‬ ‫باید‬ ‫شدگی؛‬ ‫توزیع‬ ‫ماهیت‬ ‫بدلیل‬Network fails‫ها‬
‫شود‬ ‫توجه‬ ‫نیز‬
‫پذیری‬ ‫مقیاس‬
Instance 1 Instance 2
‫محل‬
‫بارگیری‬
Instance 1 Instance 2
‫اطالعات‬
‫ماشین‬
Instance 3
Instance 1 Instance 2
‫تصاویر‬
Instance 4
Instance 4 Instance 5 Instance 6
Gilt
‫تر‬ ‫ساده‬ ‫دیپلوی‬
‫مانولیت‬ ‫کل‬ ‫دیپلوی‬ ‫نیازمند‬
‫باشد‬ ‫می‬
‫و‬ ‫سنگین‬ ‫محصول‬ ‫دیپلوی‬ ‫چرخه‬
‫باال‬ ‫ریسک‬ ‫با‬
scope‫سرویس‬ ‫به‬ ‫محدود‬ ‫تغییرات‬
‫ها؛‬
‫با‬ ‫و‬ ‫شده‬ ‫سریعتر‬ ‫بسیار‬ ‫دیپلوی‬
‫کمتر‬ ‫ریسک‬
Amazon Netflix
‫سازمانی‬ ‫ساختار‬ ‫با‬ ‫انظباق‬
‫مجدد‬ ‫استفاده‬ ‫و‬ ‫ترکیب‬ ‫قابلیت‬
•‫و‬ ‫مختلف‬ ‫های‬ ‫صورت‬ ‫به‬ ‫توانند‬ ‫می‬ ‫های‬ ‫مایکروسرویس‬
‫توسط‬consumer‫قرار‬ ‫استفاده‬ ‫مورد‬ ‫بیشتری‬ ‫های‬
‫بگیرند‬
•‫و‬ ‫مختلف‬ ‫های‬ ‫محیط‬device‫نیازمندی‬ ‫متفاوت‬ ‫ها‬
‫این‬ ‫با‬ ‫بتواند‬ ‫باید‬ ‫سیستم‬ ‫نتیجه‬ ‫در‬ ‫دارند‬ ‫متفاوتی‬
‫باشد‬ ‫داشته‬ ‫پذیری‬ ‫وفق‬ ‫قابلیت‬ ‫شرایط‬ ‫تغییر‬
‫با‬ ‫و‬ ‫تر‬ ‫راحت‬ ‫جایگزینی‬ ‫قابلیت‬
‫کمتر‬ ‫هزینه‬
‫نوشتن‬ ‫و‬ ‫جایگزینی‬ ‫ی‬ ‫هزینه‬ ‫ها؛‬ ‫سرویس‬ ‫بودن‬ ‫کوچکتر‬ ‫با‬
‫باشد‬ ‫می‬ ‫کمتر‬ ‫بسیار‬ ‫ها‬ ‫سرویس‬ ‫مجددا‬

More Related Content

Similar to Microservices Workshop Part 1

طرح رایانش ابری در صنعت برق خراسان
طرح رایانش ابری در صنعت برق خراسانطرح رایانش ابری در صنعت برق خراسان
طرح رایانش ابری در صنعت برق خراسانعباس بني اسدي مقدم
 
Cloud Computing and Cloud Services
Cloud Computing and Cloud ServicesCloud Computing and Cloud Services
Cloud Computing and Cloud ServicesSaeid Bostandoust
 
رایانش ابری
رایانش ابریرایانش ابری
رایانش ابریShiraz LUG
 
agil software managment by scrunm in tfs
agil software managment by scrunm in tfsagil software managment by scrunm in tfs
agil software managment by scrunm in tfsReza Rahimy
 
معماری استایل‌های بزرگ اندازه
معماری استایل‌های بزرگ اندازهمعماری استایل‌های بزرگ اندازه
معماری استایل‌های بزرگ اندازهWeb Standards School
 
آموزش ASP.NET MVC فصل اول : مقدمات
آموزش ASP.NET MVC فصل اول : مقدماتآموزش ASP.NET MVC فصل اول : مقدمات
آموزش ASP.NET MVC فصل اول : مقدماتMorteza Dalil
 
معرفی ServiceWorker و کاربردهای آن
معرفی ServiceWorker و کاربردهای آنمعرفی ServiceWorker و کاربردهای آن
معرفی ServiceWorker و کاربردهای آنWeb Standards School
 
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...Web Standards School
 
برنامه مدیریت ارتباط با مشتری مایکروسافت CRM
برنامه مدیریت ارتباط با مشتری مایکروسافت CRMبرنامه مدیریت ارتباط با مشتری مایکروسافت CRM
برنامه مدیریت ارتباط با مشتری مایکروسافت CRMJavad Pourhosaini
 
13940305-NetManagementOS_ver1.5
13940305-NetManagementOS_ver1.513940305-NetManagementOS_ver1.5
13940305-NetManagementOS_ver1.5Ehsan Khanahmadi
 
چارچوب متن باز جهت توسعه سیستم های نرم افزاری
چارچوب متن باز جهت توسعه سیستم های نرم افزاریچارچوب متن باز جهت توسعه سیستم های نرم افزاری
چارچوب متن باز جهت توسعه سیستم های نرم افزاریعباس بني اسدي مقدم
 

Similar to Microservices Workshop Part 1 (20)

ESB
ESBESB
ESB
 
software defined network
software defined networksoftware defined network
software defined network
 
Mvvm in wpf
Mvvm in wpfMvvm in wpf
Mvvm in wpf
 
طرح رایانش ابری در صنعت برق خراسان
طرح رایانش ابری در صنعت برق خراسانطرح رایانش ابری در صنعت برق خراسان
طرح رایانش ابری در صنعت برق خراسان
 
Cloud Computing and Cloud Services
Cloud Computing and Cloud ServicesCloud Computing and Cloud Services
Cloud Computing and Cloud Services
 
رایانش ابری
رایانش ابریرایانش ابری
رایانش ابری
 
agil software managment by scrunm in tfs
agil software managment by scrunm in tfsagil software managment by scrunm in tfs
agil software managment by scrunm in tfs
 
معماری استایل‌های بزرگ اندازه
معماری استایل‌های بزرگ اندازهمعماری استایل‌های بزرگ اندازه
معماری استایل‌های بزرگ اندازه
 
About Expert Cms
About Expert CmsAbout Expert Cms
About Expert Cms
 
آموزش ASP.NET MVC فصل اول : مقدمات
آموزش ASP.NET MVC فصل اول : مقدماتآموزش ASP.NET MVC فصل اول : مقدمات
آموزش ASP.NET MVC فصل اول : مقدمات
 
Software architecture002
Software architecture002Software architecture002
Software architecture002
 
About Comp Cms
About Comp CmsAbout Comp Cms
About Comp Cms
 
معرفی ServiceWorker و کاربردهای آن
معرفی ServiceWorker و کاربردهای آنمعرفی ServiceWorker و کاربردهای آن
معرفی ServiceWorker و کاربردهای آن
 
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...
 
94.10.18
94.10.1894.10.18
94.10.18
 
برنامه مدیریت ارتباط با مشتری مایکروسافت CRM
برنامه مدیریت ارتباط با مشتری مایکروسافت CRMبرنامه مدیریت ارتباط با مشتری مایکروسافت CRM
برنامه مدیریت ارتباط با مشتری مایکروسافت CRM
 
Mobile Backend as a Service
Mobile Backend as a ServiceMobile Backend as a Service
Mobile Backend as a Service
 
RayBPMS (Rayvarz Business Process Management System)
RayBPMS (Rayvarz Business Process Management System)RayBPMS (Rayvarz Business Process Management System)
RayBPMS (Rayvarz Business Process Management System)
 
13940305-NetManagementOS_ver1.5
13940305-NetManagementOS_ver1.513940305-NetManagementOS_ver1.5
13940305-NetManagementOS_ver1.5
 
چارچوب متن باز جهت توسعه سیستم های نرم افزاری
چارچوب متن باز جهت توسعه سیستم های نرم افزاریچارچوب متن باز جهت توسعه سیستم های نرم افزاری
چارچوب متن باز جهت توسعه سیستم های نرم افزاری
 

Microservices Workshop Part 1

  • 1. Microservices: Martin Fowler: "Microservices" - yet another new term on the crowded streets of software architecture. https://martinfowler.com/articles/microservices.html Masoud Bahrami http://Refactor.Ir Agile Developer ‫مایکروسرویس‬‫ها‬
  • 3. ‫سرفصل‬ •‫ها‬ ‫مایکروسرویس‬ ‫معماری‬ ‫بر‬ ‫ای‬ ‫مقدمه‬ •‫شده‬ ‫توزیع‬ ‫های‬ ‫سیستم‬ ‫تاریخی‬ ‫سیر‬ ‫بر‬ ‫نگاهی‬ •REST API •‫ها‬ ‫مایکروسرویس‬ ‫معماری‬ ‫و‬ ‫اجایل‬ ‫های‬ ‫متدولوژی‬ •‫با‬ ‫ها‬ ‫مایکرسرویس‬ ‫معماری‬ ‫پیدایش‬ ‫سیر‬ ‫به‬ ‫نگاهی‬ ‫ارائه‬Case Study‫از‬ThoughWorks •‫ها‬ ‫مایکروسرویس‬ ‫تعریف‬ •‫معماری‬ ‫با‬ ‫شده‬ ‫داده‬ ‫توسعه‬ ‫های‬ ‫برنامه‬ ‫مقایسه‬ ‫مانولیت‬ ‫های‬ ‫برنامه‬ ‫مقابل‬ ‫در‬ ‫ها‬ ‫مایکروسرویس‬ •‫ها‬ ‫مایکروسرویس‬ ‫معماری‬ ‫های‬ ‫ویژگی‬
  • 4. ‫مایکروسرویس‬ ‫معماری‬ ‫بر‬ ‫ای‬ ‫مقدمه‬ ‫ها‬ •‫دنیای‬ ‫از‬ ‫برخواسته‬ Distributed SystemsDomain-Driver DesignAgile Continues Integration & Continues Deployment Provisioning & Virtualization Refactoring BBoM and fragile systems RESTful ‫سال‬2014‫ها‬ ‫مایکروسرویس‬ ‫سال‬ Gartner Hype cycle.
  • 5.
  • 6. ‫شده‬ ‫توزیع‬ ‫های‬ ‫سیستم‬ ‫تکامل‬ ‫سیر‬ •Remote Procedure Call(RPC) •The Session Façade‫توسط‬Kyle Brown‫و‬John Crupi‫و‬Martin Fowler •do the simplest thing that could possibly work •Service Oriented Architecture(SOA)‫و‬Simple Object Access Protocol(SOAP) •Remote Method Invocation(RMI)
  • 7. Exception handling, transaction support, security, and digital signatures Be of the web, not behind the web
  • 8. Representational State Transfer (REST) •"Architectural Styles and the Design of Network-based Software Architectures" •‫بر‬ ‫مبتنی‬ ‫ساده‬ ‫های‬ ‫درخواست‬ ‫ارسال‬HTTP •‫از‬ ‫استفاده‬HTTP Verb‫درخواست‬ ‫نوع‬ ‫تعیین‬ ‫جهت‬ ‫ها‬ •URL
  • 9. ‫گانه‬ ‫شش‬ ‫اصول‬REST .1Client-Server .2Stateless .3Cacheable .4Uniform Interface .5Layered System .6Code on Demand Representation Resource Identifier abc.com/API/file/5
  • 10. Uniform Interface .1Resource-Based .2Manipulation of Resources Through Representations .3Self-Descriptive Messages .4Hypermedia As The Engine Of Application State(HATEOAS)
  • 12.
  • 13.
  • 15.
  • 16.
  • 17. If something is important, make it an explicit part of your design
  • 18.
  • 19. ‫رویکردهای‬ ‫برای‬ ‫جایگزین‬ ‫حلی‬ ‫راه‬ ‫یافتن‬ ‫بدبنال‬document driven‫و‬ heavyweight‫افزار‬ ‫نرم‬ ‫تولید‬ ‫فرآیند‬ ‫در‬
  • 20.
  • 21. ‫کرد‬ ‫تالش‬ ‫اجایل‬overhead‫و‬risk‫کمک‬ ‫با‬ ‫را‬ ‫بزرگ‬ ‫مقیاس‬ ‫در‬ ‫سیستم‬ ‫توسعه‬ ‫ایجاد‬ ‫طریق‬ ‫از‬ ‫و‬ ‫افزایشی‬ ‫و‬ ‫کوتاه‬ ‫تکرارهای‬ ‫تعریف‬prototype‫در‬ ‫ها‬ ‫کند‬ ‫حل‬ ‫محصول‬ ‫فیدبک‬ ‫چرخه‬ ‫در‬ ‫تسریع‬ ‫جهت‬ ‫تکرار‬ ‫هر‬ ‫پایان‬
  • 22.
  • 24. In 2009, John Allspaw and Paul Hammond from Flickr at O’Reilly Velocity conference SoundCloud Netflix
  • 25. Agile Software Architecture Agile Software Architecture is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal.  Provides agility.  Small loosely coupled components/services van 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.
  • 26. ‫مایکروسرویس‬ ‫معماری‬ ‫بر‬ ‫ای‬ ‫مقدمه‬ ‫ها‬ •‫دقیق‬ ‫تعریف‬‫؛‬‫سبک‬ ‫این‬ ‫از‬ ‫شده‬ ‫پذیرفته‬ ‫و‬ ‫مشخص‬ ‫ندارد‬ ‫وجود‬ ‫معماری‬ •‫مشترک‬ ‫مشخصات‬ ‫و‬ ‫ها‬ ‫ویژگی‬‫سازمان‬ ‫فرآیند‬ ‫تولید‬ ‫چابک‬ ‫ی‬ ‫اتومیشین‬ ‫فرآیند‬ ‫دیپلوی‬ Polyglot Databases Polyglot Languages
  • 27. ‫پیدایش‬‫اصطالح‬Microservices •‫می‬ ‫بار‬ ‫اولین‬2012‫کنفرانس‬Software Architectures ‫ونیز‬ ‫نزدیک‬ •‫می‬2012‫اصطالح‬ ‫روی‬ ‫بر‬ ‫توافق‬“Microservices”‫عنوان‬ ‫به‬ ‫اصطالح‬ ‫ترین‬ ‫مناسب‬ •‫مارچ‬2012‫کنفرانس‬ ‫در‬33rd Degree‫؛‬James Lewis‫قالب‬ ‫در‬ ‫یک‬Case Study‫کرد‬ ‫مطرح‬ ‫را‬ ‫ها‬ ‫ایده‬ ‫برخی‬
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35. ‫برای‬ ‫لوئیز‬ ‫جیمز‬ ‫که‬ ‫های‬ ‫ویژگی‬ ‫برشمرد‬ ‫های‬ ‫مایکرسرویس‬ •Small with a Single Responsibility •Containerless and installed as well behaved Unix services •Located in different VCS roots •Provisioned automatically •Status aware and auto-scaling
  • 36.
  • 37.
  • 38. • James Lewis: •Capabilities‫طریق‬ ‫از‬ ‫تعامل‬ ‫با‬ ‫ها‬Uniform Interfaces‫با‬ ‫دارند‬ ‫تعامل‬ ‫یکدیگر‬ •‫هرچند‬James Lewis‫از‬RESTful‫ویژگی‬ ‫ولی‬ ‫نکرده‬ ‫صحبتی‬ ‫برای‬ ‫را‬ ‫زیر‬ ‫های‬Uniform Interfaces‫شمرد‬ ‫بر‬: •HTTP(Be of the web, not behind the web) •HATOS •Standard Media Types Capabilities‫صورت‬ ‫چه‬ ‫به‬ ‫ها‬Product‫را‬ ‫دهند‬ ‫می‬ ‫تشکیل‬
  • 39.
  • 40. ‫مایکروسرویس‬ ‫معماری‬ ‫سبک‬ ‫تعریف‬ ‫ه‬‫ا‬ Sam Newman(Building Microservices, O’rriely 2015): Microservices are small, autonomous services that work together. ‫توسعه‬ ‫جهت‬ ‫است‬ ‫رویکردی‬ ‫ها؛‬ ‫مایکروسرویس‬ ‫معماری‬ ‫سبک‬ ‫بصورت‬ ‫برنامه‬ ‫یک‬: .1‫کوچک‬ ‫های‬ ‫سرویس‬ ‫از‬ ‫ای‬ ‫مجموعه‬ .2‫خود‬ ‫مخصوص‬ ‫پراسس‬ ‫روی‬ ‫بر‬ ‫سرویس‬ ‫هر‬run‫شود‬ ‫می‬ .3‫وزن‬ ‫سبک‬ ‫های‬ ‫مکانیزم‬ ‫طریق‬ ‫از‬ ‫ها‬ ‫سرویس‬ ‫دیگر‬ ‫با‬ ‫تعامل‬ ‫غالبا‬HTTP resource API ‫اتوماتیک‬ ‫کامال‬ ‫انتشار‬ ‫فرآیند‬ ‫توسط‬ ‫مستقل‬ ‫انتشار‬ ‫قابلیت‬ ‫تکنولوژی‬ ‫در‬ ‫مثال‬ ‫عنوان‬ ‫به‬ ‫مرکزی‬ ‫مدیریت‬ ‫میزان‬ ‫کمترین‬ ‫نویسی‬ ‫برنامه‬ ‫های‬ ‫زبان‬ ‫و‬ ‫ها‬ ‫داده‬ ‫سازی‬ ‫ذخیره‬ ‫مبنای‬ ‫بر‬ ‫شده‬ ‫داده‬ ‫توسعه‬Business Capabilities
  • 41. ‫ت‬‫یک‬ ‫دادن‬ ‫انجام‬ ‫خوب‬ ‫روی‬ ‫بر‬ ‫مرکز‬ ‫چیز‬ •‫هر‬iteration‫مقداری‬code‫به‬code base‫می‬ ‫افزوده‬ ‫اولیه‬ ‫شود‬ Robbert C.Martin: Gather together those things that change for the same reason, and separate those things that change for different things. ‫یعنی‬ ‫کوچک؛‬ ‫سرویس‬ ‫اندازه؟؟؟‬ ‫چه‬
  • 42. •‫روی‬ ‫بر‬ ‫مستقل‬ ‫بصورت‬ ‫مایکروسرویس‬ ‫هر‬PaaS‫بتواند‬ ‫شود‬ ‫اجرا‬ ‫خود‬ ‫مخصوص‬ ‫پراسس‬ ‫در‬ ‫یا‬ ‫شود‬ ‫دیپلوی‬. •Communication‫می‬ ‫انجام‬ ‫شبکه‬ ‫روی‬ ‫بر‬ ‫های‬ ‫سرویس‬ ‫بین‬ ‫شود‬ •‫در‬ ‫تغییر‬ ‫به‬ ‫نیاز‬ ‫بدون‬ ‫باید‬ ‫سرویس‬ ‫هر‬consumer ‫باشد‬ ‫داشته‬ ‫دیپلوی‬ ‫و‬ ‫تغییر‬ ‫قابلیت‬ ‫هایش؛‬ •‫یک‬ ‫سرویس‬ ‫هر‬Application programming Interface(API)‫را‬ ‫دهد‬ ‫می‬ ‫ارائه‬ Autonomous ‫را‬ ‫تغییری‬ ‫ها؛‬ ‫سرویس‬ ‫سایر‬ ‫در‬ ‫تغییر‬ ‫به‬ ‫نیاز‬ ‫بدون‬ ‫توان‬ ‫می‬ ‫آیا‬ ‫کرد؟‬ ‫دیپلوی‬ ‫آنرا‬ ‫سپس‬ ‫و‬ ‫کرد‬ ‫ایجاد‬ ‫سرویس‬ ‫یک‬ ‫در‬
  • 43. ‫مانولیتیک‬ ‫برنامه‬ ‫یک‬ ‫تمام‬Capability‫ها‬ ‫سیستم‬ ‫پراسس‬ ‫یک‬ ‫در‬ ‫شوند‬ ‫می‬ ‫اجرا‬ ‫عامل‬ ‫می‬ ‫مقیاس‬ ‫افقی‬ ‫بصورت‬ ‫شود‬ ‫مشکالت‬: ‫تغییر‬ ‫های‬ ‫چرخه‬ ‫به‬ ‫وابسته‬ ‫و‬ ‫طوالنی‬ ‫یکدیگر‬ ‫ماژوالر‬ ‫ساختار‬ ‫حفظ‬ ‫زمان‬ ‫گذشت‬ ‫با‬ ‫اولیه‬ ‫باشد‬ ‫می‬ ‫مشکل‬ ‫نیازمند‬ ‫پذیر‬ ‫مقیاس‬ ‫کل‬ ‫کردن‬ ‫مقیاس‬ ‫باشد‬ ‫می‬ ‫برنامه‬ ‫مایکروسرویس‬ ‫معماری‬ Capability‫سرویس‬ ‫به‬ ‫ها‬ ‫می‬ ‫منتقل‬ ‫جداگانه‬ ‫های‬ ‫کند‬ ‫می‬ ‫مقیاس‬ ‫عمودی‬ ‫بصورت‬ ‫شود‬
  • 44. Scale 3d Cube- by: The Art of Scalability.
  • 46. ‫تکنولوژی‬ ‫به‬ ‫وابستگی‬ ‫عدم‬ ‫دیتابیس‬ ‫رابطه‬ ‫ای‬ Blob ‫دیتابیس‬ Graph ‫دیتابیس‬ ‫اطالعات‬ ‫ماشین‬ C# ‫بارگیری‬ ‫محل‬ Python ‫تصاویر‬ PHP
  • 47. ‫ارتجاعی‬ ‫قابلیت‬-Resilience •‫برنامه‬ ‫کل‬ ‫روی‬ ‫بر‬ ‫آبشاری‬ ‫تاثیرات‬ ‫از‬ ‫جلوگیری‬ •Service Boundaries‫تاثیر‬ ‫از‬ ‫جلوگیری‬ ‫عامل‬ ‫؛‬fail‫یک‬ ‫ها‬ ‫باشد‬ ‫می‬ ‫برنامه‬ ‫کل‬ ‫بر‬ ‫سرویس‬ •‫به‬ ‫باید‬ ‫شدگی؛‬ ‫توزیع‬ ‫ماهیت‬ ‫بدلیل‬Network fails‫ها‬ ‫شود‬ ‫توجه‬ ‫نیز‬
  • 48. ‫پذیری‬ ‫مقیاس‬ Instance 1 Instance 2 ‫محل‬ ‫بارگیری‬ Instance 1 Instance 2 ‫اطالعات‬ ‫ماشین‬ Instance 3 Instance 1 Instance 2 ‫تصاویر‬ Instance 4 Instance 4 Instance 5 Instance 6 Gilt
  • 49. ‫تر‬ ‫ساده‬ ‫دیپلوی‬ ‫مانولیت‬ ‫کل‬ ‫دیپلوی‬ ‫نیازمند‬ ‫باشد‬ ‫می‬ ‫و‬ ‫سنگین‬ ‫محصول‬ ‫دیپلوی‬ ‫چرخه‬ ‫باال‬ ‫ریسک‬ ‫با‬ scope‫سرویس‬ ‫به‬ ‫محدود‬ ‫تغییرات‬ ‫ها؛‬ ‫با‬ ‫و‬ ‫شده‬ ‫سریعتر‬ ‫بسیار‬ ‫دیپلوی‬ ‫کمتر‬ ‫ریسک‬ Amazon Netflix
  • 51. ‫مجدد‬ ‫استفاده‬ ‫و‬ ‫ترکیب‬ ‫قابلیت‬ •‫و‬ ‫مختلف‬ ‫های‬ ‫صورت‬ ‫به‬ ‫توانند‬ ‫می‬ ‫های‬ ‫مایکروسرویس‬ ‫توسط‬consumer‫قرار‬ ‫استفاده‬ ‫مورد‬ ‫بیشتری‬ ‫های‬ ‫بگیرند‬ •‫و‬ ‫مختلف‬ ‫های‬ ‫محیط‬device‫نیازمندی‬ ‫متفاوت‬ ‫ها‬ ‫این‬ ‫با‬ ‫بتواند‬ ‫باید‬ ‫سیستم‬ ‫نتیجه‬ ‫در‬ ‫دارند‬ ‫متفاوتی‬ ‫باشد‬ ‫داشته‬ ‫پذیری‬ ‫وفق‬ ‫قابلیت‬ ‫شرایط‬ ‫تغییر‬
  • 52. ‫با‬ ‫و‬ ‫تر‬ ‫راحت‬ ‫جایگزینی‬ ‫قابلیت‬ ‫کمتر‬ ‫هزینه‬ ‫نوشتن‬ ‫و‬ ‫جایگزینی‬ ‫ی‬ ‫هزینه‬ ‫ها؛‬ ‫سرویس‬ ‫بودن‬ ‫کوچکتر‬ ‫با‬ ‫باشد‬ ‫می‬ ‫کمتر‬ ‫بسیار‬ ‫ها‬ ‫سرویس‬ ‫مجددا‬

Editor's Notes

  1. In each of RPC technologies, the basic idea was to make remote calls transparent to developers. The promise was that if developers didn’t have to care whether the procedure calls or methods they were invoking were local or remote, then they could build larger machine-crossing systems that could avoid the processing and memory scalability issues that affected systems of the time. (Remember that the most common processors at this time were 16-bit processors with a 64K address space!) ----------- The Façade pattern was about encapsulating the unstructured interfaces of a large system within a single, more structured interface to reduce “chattiness.” ---------- The Session Façade approach, applied Facade pattern to distributed systems by identifying the key, large-grained interfaces of an entire subsystem and exposing only those for distribution. ---------------- We implemented our first Session Façades with Enterprise JavaBeans (EJBs), which, while fine if you were only working in Java, were complicated, difficult to debug, and not interoperable with other languages or even other vendor products. That lack of interoperability led directly to the next effort of the early to mid 2000s: what would become known as Service Oriented Architecture (SOA). SOA didn’t start out with such grandiose terminology, though. It originally began as a “do the simplest thing that could possibly work” effort called Simple Object Access Protocol (SOAP), originally released by Microsoft in 1999. --------------- At its heart, SOAP was nothing more than a way of invoking object methods over HTTP. 
  2. In early 2001, a group of software professionals published the Agile Manifesto as a statement of values on how to improve software development. Although the principles stated were not new -- they were a consolidation of ideas from extreme programming, scrum, lean, and more -- the unified voice caught the industry’s attention. Just as microservice architecture is frequently defined in contrast to monolithic architecture, the manifesto differentiates agile software development from “documentation-driven, heavyweight software development processes.” The agile approach sought to remove the overhead and risk of large-scale software development by using smaller work increments, frequent iterations, and prototyping as a means of collaboration with users. The adoption of agile methods in the industry grew consistently following the publication of the manifesto.
  3. In early 2001, a group of software professionals published the Agile Manifesto as a statement of values on how to improve software development. Although the principles stated were not new -- they were a consolidation of ideas from extreme programming, scrum, lean, and more -- the unified voice caught the industry’s attention. Just as microservice architecture is frequently defined in contrast to monolithic architecture, the manifesto differentiates agile software development from “documentation-driven, heavyweight software development processes.” The agile approach sought to remove the overhead and risk of large-scale software development by using smaller work increments, frequent iterations, and prototyping as a means of collaboration with users. The adoption of agile methods in the industry grew consistently following the publication of the manifesto.
  4. Still, there were bottlenecks. Agile’s primary scope was on the development of software, while CD extended that scope to include production deployment, an operations task. In most organizations, development and operations were consciously divided in both reporting and mission. In 2009, John Allspaw and Paul Hammond from Flickr gave an influential talk at the O’Reilly Velocity conference detailing how they had bridged this gap. From experiences like theirs, the devops movement arose to address this cultural divide.
  5. I'm back in The Netherlands next week to deliver the opening keynote at the Agile Software Architecture Symposium, where I'll be speaking about agility and the essence of software architecture. But what does "agile software architecture" actually mean? ----------------------------------------------------------------- In my experience, people tend to use the word "agile" to refer to a couple of things. The first is when talking about agile approaches to software development; moving fast, embracing change, releasing often, getting feedback and so on. The second use of the word relates to the agile mindset and how people work together in agile environments. This is usually about team dynamics, systems thinking, psychology and other things you might associate with creating high performing teams. ---------------------------------------- Leaving the fluffy stuff aside, for me, labelling a software architecture as being "agile" means that it can react to change within its environment, adapting to the ever changing requirements that people throw at it. This isn't necessarily the same as the software architecture that an agile team will create. Delivering software in an agile way doesn't guarantee that the resulting software architecture *is* agile. In fact, in my experience, the opposite typically happens because teams are more focussed on delivering functionality rather than looking after their 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. However, nothing in life is ever free. Building a software system like this takes time, effort and discipline. Many people don't need this level of adaptability either, which is why you see so many teams building software systems that are much more monolithic in nature, where everything is bundled together and deployed as a single unit. Although simpler to build, this style of architecture usually takes more effort to adapt in the face of changing requirements because functionality is often interwoven across the codebase. With pragmatism in mind, you can always opt to build a software system that consists of a number of small components yet is still deployed as a single unit. You need to understand the trade-offs and make your choices accordingly. However you build your software system, creating a well structured architecture isn't something that happens all by itself. You need to put time, effort and discipline into it. In order to do this, everybody on the team needs to understand software architecture and contribute to its success. How you do this is what my talk is all about...
  6. The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.
  7. The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.
  8. To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable[2]. Any changes to the system involve building and deploying a new version of the server-side application. Such a monolithic server is a natural way to approach building such a system. All your logic for handling a request runs in a single process, allowing you to use the basic features of your language to divide up the application into classes, functions, and namespaces. With some care, you can run and test the application on a developer's laptop, and use a deployment pipeline to ensure that changes are properly tested and deployed into production. You can horizontally scale the monolith by running many instances behind a load-balancer. ----------------------------------------------------------------------------------------- Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource. ----------------------------------------------------------------- These frustrations have led to the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams . We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix. But we do think that not enough people consider a microservice architecture and that many software developments would be better off if they used it. ------------------------------------------------------- Successful applications have a habit of growing over time and eventually becoming huge. During each sprint, your development team implements a few more stories, which, of course, means adding many lines of code. After a few years, your small, simple application will have grown into a monstrous monolith. ----------------------------------------------------------------------------- Once your application has become a large, complex monolith, your development organization is probably in a world of pain. Any attempts at agile development and delivery will flounder. One major problem is that the application is overwhelmingly complex. It’s simply too large for any single developer to fully understand. As a result, fixing bugs and implementing new features correctly becomes difficult and time consuming. What’s more, this tends to be a downwards spiral. If the codebase is difficult to understand, then changes won’t be made correctly. You will end up with a monstrous, incomprehensible big ball of mud. -------------------------------------------------------------------------------- The sheer size of the application will also slow down development. The larger the application, the longer the start‑up time is. For example, in a recent survey some developers reported start‑up times as long as 12 minutes. I’ve also heard anecdotes of applications taking as long as 40 minutes to start up. If developers regularly have to restart the application server, then a large part of their day will be spent waiting around and their productivity will suffer. --------------------------------------------------------------------------------- Another problem with a large, complex monolithic application is that it is an obstacle to continuous deployment. Today, the state of the art for SaaS applications is to push changes into production many times a day. This is extremely difficult to do with a complex monolith since you must redeploy the entire application in order to update any one part of it. The lengthy start‑up times that I mentioned earlier won’t help either. Also, since the impact of a change is usually not very well understood, it is likely that you have to do extensive manual testing. Consequently, continuous deployment is next to impossible to do. ----------------------------------------------------------------------------------- Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements. For example, one module might implement CPU‑intensive image processing logic and would ideally be deployed in Amazon EC2 Compute Optimized instances. Another module might be an in‑memory database and best suited for EC2 Memory‑optimized instances. However, because these modules are deployed together you have to compromise on the choice of hardware. ---------------------------------------------------------------------------------- Another problem with monolithic applications is reliability. Because all modules are running within the same process, a bug in any module, such as a memory leak, can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application. ------------------------------------------------------------------------------------- Last but not least, monolithic applications make it extremely difficult to adopt new frameworks and languages. For example, let’s imagine that you have 2 million lines of code written using the XYZ framework. It would be extremely expensive (in both time and cost) to rewrite the entire application to use the newer ABC framework, even if that framework was considerably better. As a result, there is a huge barrier to adopting new technologies. You are stuck with whatever technology choices you made at the start of the project. ---------------------------------------------------------------------------------------- To summarize: you have a successful business‑critical application that has grown into a monstrous monolith that very few, if any, developers understand. It is written using obsolete, unproductive technology that makes hiring talented developers difficult. The application is difficult to scale and is unreliable. As a result, agile development and delivery of applications is impossible.
  9. The Microservices Architecture pattern corresponds to the Y‑axis scaling of the Scale Cube, which is a 3D model of scalability from the excellent book The Art of Scalability. The other two scaling axes are X‑axis scaling, which consists of running multiple identical copies of the application behind a load balancer, and Z‑axis scaling (or data partitioning), where an attribute of the request (for example, the primary key of a row or identity of a customer) is used to route the request to a particular server. -------------------------------------------------------------------------------------- Applications typically use the three types of scaling together. Y‑axis scaling decomposes the application into microservices as shown above in the first figure in this section. At runtime, X‑axis scaling runs multiple instances of each service behind a load balancer for throughput and availability. Some applications might also use Z‑axis scaling to partition the services.