چه اینکه قصد داشته باشید سیستم خودتان رو به یک سرور راه دور منتقل کنید یا اینکه هر چیزی را برای استفاده در هر جایی پکیج بندی کنید ، همیشه انتقال برنامه ها به سرورجدید با الزاماتشان و اجرای انها بدون خطا ، یک چالش به حساب می آید . در حقیقت چالش های زیادی در این راه وجود دارد و راه حل های موجود تا کنون نتوانسته اند برای اکثریت آنها موفقیت آمیز باشند .
به طور خلاصه داکر به عنوان یک پروژه به شما کمک می کند مجموعه ای کامل از ابزارهای سطح بالاتر را برای انتقال هر فرم از برنامه های کاربردی بر روی سیستم ها و ماشین ها (چه فیزیکی و چه مجازی ) بکار بگیرید و مزایای زیادی با خود به ارمغان می آورد .
داکر برنامه های کاربردی خود را (چه فرآیند ها و چه منابع ) از طریق محفظه های لینوکسی (به عنوان مثال فضاهای نام یا دیگر ویژگی های کرنل ) آرشیو می کند . قابلیت های دیگر آن از خود قطعات پروژه و اجزای آن منشا می گیرد ، ویژگی هایی که همه پیچیدگی کار را با ابزارهای سطح پایین تر یا API های لینوکس که برای سیستم و مدیریت برنامه های کاربردی با توجه به امنیت فرآیندها ، به کار می رود مرتفع می سازد .

محفظه های داکر چندین ویژگی خاص دارند . آنها اجازه :
قابلیت حمل نرم افزار
جداسازی فرآیندها
مدیریت مصرف منابع
و نیاز به منابع کمتر به نسبت روش های سنتی مجازی سازی
می دهد . و اجازه :
تداخل با دیگر فرآیندها
ایجاد وابستگی
کار نکردن روی یک سیستم دیگر
آسیب پذیری در برابر حمله ها
سوء استفاده از منابع تمام سیستم و … را نمی دهد ++

داکر، هیجان مجازی‌سازی

داکر سریع است، استفاده از آن راحت است و ابزاری برنامه‌نویس محور است. ماموریتش در اساس این است: بسته‌بندی و انتقال کد را ساده کند. برنامه‌نویس‌ها به دنبال ابزارهایی هستند که بخش زیادی از جزییات ‌این فرآیند را از کار آن‌ها مجزا کند. آن‌ها فقط انتظار دارند ببینند کدی که می‌‌‌‌نویسند کار می‌‌‌‌کند. همین مسئله منجر به انواع تضادها با مدیران سیستم می‌‌‌‌شود؛ زمانی که کد از یک جا به جای دیگر منتقل می‌‌‌‌شود و در محیطی به جز محیط خود برنامه‌نویس درست کار نمی‌‌‌‌کد. داکر تلاش می‌‌‌‌کند کد شما را تا حد ممکن قابل انتقال سازد و این قابل انتقال بودن را برای کاربر ساده و دوستانه کند.

داکر مجازی‌سازی در سطح سیستم‌عامل است. بر خلاف مجازی‌سازی hypervisor، که در آن ماشین‌مجازی(VM) از طریق یک لایه واسط روی سخت‌افزار فیزیکی اجرا می‌‌‌‌شود (خود hypervisor)، حامل‌ها فضای کاربر را روی هسته سیستم‌عامل اجرا می‌‌‌‌کنند. این باعث می‌‌‌‌شود بسیار سبک و سریع باشند.

اجزای اصلی داکر :
– محفظه های داکر :
محفظه هایی شامل هر برنامه کاربردی شما مثل سیستم عامل.
کل عملیات انتقال برنامه ها که با داکر انجام می شود متکی بر محفظه های داکر اند . محفظه های داکر اساسا دایرکتوری هایی هستند که می توانند بسته بندی شوند و بعد به اشتراک گذاشته شوند یا روی ماشین مجازی های مختلف با پلت فرم های مختلف اجرا شوند . تنها وابستگی ای که دارند این است که میزبان باید برای اجرای محفظه ها تنظیم شده باشد ( به عبارتی داکر روی میزبان نصب شده باشد ) .
تصاویر داکر : تصاویری از محفظه ها یا خود ایمیج های سیستم عامل (اوبونتو ) که کمک می کند محفظه های داکر اجرا شوند (لانچ شوند ).
فایل های داکر : اسکریپت هایی که فرآیند ساخت تصاویر را خودکارسازی می کند .

رایانش ابری نظیر به نظیر

امروزه بزر گترین و محبو بترین سرویسهای اینترنتی شامل , Dropbox
Instagram, Netflix همگی از سرو سهای ابری تجاری استفاده میکنند.
این نا مها شاید به چشم کاربر نهایی قدری پرابهت و ه مسطح با ابرها به نظر
بیایند، اما در واقع به تجهیزات زمینی وابستگی شدیدی دارند. مراکز داده این
شرکتها با ابعادی در اندازه یک زمین فوتبال بسیار پرهزینه و گرا نقیمت است
و عموماً شرکتهای غو لپیکری همچون آمازون، گوگل و مایکروسافت آ نها
را اداره میکنند هر کدام از این شرک تها مد لهای متنوعی از سرویسهایی
با امکانات مختلف را ارائه میدهند که ماهیت آ نها به نحوه تعامل مشتری با
محیط محاسبات ابری بستگی مستقیم دارد. مد لهایی مانند - Platform
as-a-Service Infrastructure as a service, Softwareas-
a-Service آیا این تنها رو شهای هستند که محاسبات ابری قادر
به کار با آنها است؟ در دانشگاه Bologna ایتالیا، تحقیقاتی حول یافتن
راهبر دهای جدید برای استفاده از محاسبات ابری بدون نیاز به مراکز تجهیزاتی
عظیم در جریان است. هدف از این تحقیقات ایجاد فناوری نوین است که بتوان
وظایف محاسبات ابری را همانند عملیات اشترا کگذاری فایلها، به صورت نظیر
به نظیر ) peer-to-peer ( و در بین کاربران به اشتراک گذاشت.
به طور کلی، یک ابر P2P م یتواند با استفاده از تجهیزات محاسباتی،
ذخیره سازی و ارتباطی عادی به وجود آید، همانند آنچه اکنون میتوان در
خانه های کاربران یافت. شبک های که تقریباً با هزینه سرمایه گذاری نزدیک به
صفر ایجاد شده است. چالش اصلی در این میان، به کارگیری تمام این تجهیزات
گوناگون و تبدیل آ نها به یک زیرساخت قابل استفاده ابری و ارائه به مشتریان
است. همچنین، باید اطمینان یافت که در این میان، ویژگ یهای منحصرب هفرد
ابری، یعنی تأمین آنی منابع درخواستی و مقیا سپذیری سرویس نیز حفظ
شود. این کار بسیار دشوار خواهد بود، اما کافی است قدری به فواید آن فکر
کنیم. نخست ای نکه هیچ موجودیت واحد و مستقلی برای کنترل چنین شبکه
ابری وجود نخواهد داشت. همانند دیگر ابزارهای P2P ، ابر نظیر به نظیر نیز
به شکل مالکیت عمومی ایجاد شده و بدون نیاز به اجازه یا صدور مجوز خاص
از جانب هر مرجعی فعالیت خواهند کرد. برای مشارکت در چنین شبکه هایی
کافی است کاربران Client software را به صورت محلی روی دستگاه خود
نصب کنند. ارزش و کارایی چنین شبک های به میزان مشارکت کاربران بستگی
مستقیم دارد. دومین امتیاز ناشی از این واقعیت است که اجزای تشکی لدهنده
یک ابر P2P کوچک است و به همین دلیل مصرف برق پایینی هم دارد. این
موضوع باعث خواهد شد تا مصرف برق و همچنین نگران یهای ناشی از حوادث
طبیعی نیز ب هشدت کاهش یابد. به این ترتیب، دغدغ ههای ایجاد گرما نیز به
حداقل خود خواهد رسید.

مقدمه ای بر توگف 9
1.2 مقدمه ای بر توگف 9:

1.2.1 توگف چیست؟

توگف یک چارچوب معماری سازمانی است. چارچوب معماری سازمانی که توسط Open Group ارائه شده است. توگف ابزاری برای کمک به پذیرش، تولید، استفاده و نگهداری طرح های معماری سازمانی می باشد. توگف بر پایه یک مدل فرآیندی تکرار پذیر می باشد، که توسط بهترین راهکارهای عملی و مجموعه ای از اجزای معماری با قابلیت استفاده مجدد، پشتیبانی می گردد.

توگف توسط انجمن معماری Open Group توسعه و نگهداری می شود. اولین نسخه توگف، در سال 1995، بر پایه چارچوب معماری فنی وزارت دفاع ایالات متحده آمریکا برای مدیریت اطلاعات ([1]TAFIM) ایجاد شد. با شروع کردن از این پایه بی نقص، انجمن معماری Open Group نسخه های موفقی از توگف را در دوره های زمانی معین ایجاد کرد و هر یک را بر روی وب سایت جامع Open Group منتشر ساخت.

این بخش، مفاهیم توگف نسخه 9 را که در کتاب به عنوان توگف 9 به آن اشاره شده، پوشش می دهد. توگف 9 اولین بار در ژانویه سال 2009 منتشر شد.

توگف 9 می تواند برای توسعه گستره وسیعی از معماری های سازمانی مختلف بکار برود. توگف مکمل دیگر چارچوب هایی است که به صورت متمرکز بر خروجی های خاص برای بخش های ویژه ای (نظیر: مخابرات، صنایع دفاع و خزانه داری و...) که در راس یک کشور هستند، در نظر گرفته شده اند. توگف همچنین می تواند در ترکیب با اینگونه چارچوب های خاص نیز استفاده شود. هسته توگف روشی است - تحت عنوان روش توسعه معماری توگف (ADM – Architecture Development Method) و برای توسعه یک معماری سازمانی که به نیازهای سازمان اشاره کامل می کند، به کار می رود.

1.2.2 ساختار راهنمای مرجع توگف:

موسسه Open Group یک راهنمای رسمی جهت استفاده از چارچوب معماری سازمانی خود یعنی توگف ارائه کرده است. این راهنما به صورت رایگان جهت دانلود موجود می باشد و تمامی قسمت های توگف را با جزئیات کامل شرح داده است. جدول 1-1 ساختار کلی این راهنما را نشان می دهد.

جدول 1-1: ساختار سند توگف

بخش توگف
خلاصه
بخش 1: مقدمه
این بخش معرفی سطح بالایی، از مفاهیم کلیدی معماری سازمانی و به طور خاص برای رویکرد توگف ارائه می کند. این بخش شامل تعاریف مربوط به عبارات بکار رفته در سراسر توگف و مطالب منتشر شده توصیف کننده تغییرات بین این نسخه و نسخه قبلی توگف می باشد.
بخش 2: روش توسعه معماری (ADM – Architecture Development Method)
این بخش هسته اصلی توگف است. این بخش روش توسعه معماری توگف (ADM) را تشریح می کند. ADM یک رویکرد گام به گام برای توسعه یک معماری سازمانی می باشد.
بخش 3: دستورالعمل ها و تکنیک های ADM
این بخش شامل مجموعه ای از دستورالعمل ها و تکنیک های قابل دسترس برای استفاده و اعمال بر ADM می باشد.
بخش 4: چارچوب محتوای معماری (Architectural Content Framework)
این بخش، چارچوب محتوای توگف را تشریح می کند، که شامل یک فرا مدل ساختار یافته برای اشیای معماری، استفاده از بخش های سازنده قابل استفاده مجدد معماری (ABB – Architectural Building Blocks ها) و دیدی کلی از خروجی های معمولی معماری می باشد.
بخش 5: زنجیره سازمانی و ابزارها
این بخش طبقه بندی و ابزارهای مناسب برای دسته بندی و ذخیره خروجی های فعالیت معماری در درون یک سازمان را تشریح می کند.
بخش 6: مدل های مرجع توگف (TOGAF Reference Model)
این بخش دو مدل مرجع معماری به نام های مدل مرجع فنی توگف (TRM) و مدل مرجع یکپارچه زیرساخت اطلاعات (III-RM – Integrated Information Infrastructure Reference Model) را ارائه می کند.
بخش 7: چارچوب توانمندی معماری (Architecture Capability Framework)
این بخش سازمان، فرآیندها، مهارت ها، نقش ها و مسئولیت های مورد نیاز برای ایجاد و اجرای یک راهکار عملی معماری در درون سازمان را تشریح می کند.

Cloud Computing رایانش ابری
Big Data کلان داده
NFV (Network Function Virtualization) مجازی سازی توابع شبکه
Job کار
Task وظیفه (زیر مجموعه Job)
Data Science علم داده / مهندسى داده
Data Integrity تمامیت داده
Data Validity اعتبار داده
Data Volume حجم داده
Data Variety تنوع داده
Data Volatility نوسان داده
Data Veracity صحت داده
Data Integration یکپارچه سازی داده
Data Aggregation تجمیع داده
Data Visualization مصورسازی داده
Disaster Recovery بازیابی از سوانح/بازیابی از فاجعه
Consistency سازگاری
Interoperability
Secondary ثانویه
Cache حافظه نهان
Storage حافظه ذخیره سازی
Storage Cache حافظه ذخیره سازی نهان
Mirroring آیینه سازی
Mashup سرویس ترکیبی
On Premise درون ملکی / داخل سازمان
Off Premise بیرون سازمان
Cross Cutting Aspects جنبه های مشترک در چند لایه

شروع با اوبونتو
اوبونتو برای تازه واردها عنوان راهنمای ساده‌ای‌ست که به منظور شروع کار با اوبونتو نوشته شده. اوبونتو سیستم‌عاملی رایگان و آزاد است که با مشارکت کاربران از سراسر جهان ساخته شده و به عنوان پر استفاده‌ترین توزیع گنو / لینوکس شناخته می‌شود.

تصمیم به استفاده از اوبونتو گرفته‌اید اما نمی‌دانید از کجا شروع کنید؟ «اوبونتو برای تازه‌واردها» تمام اطلاعاتی که برای شروع با اوبونتو نیاز دارید را به همراه دارد.

با این کتاب می‌آموزید:

معرفی اوبونتو و فلسفهٔ نرم‌افزارهای آزاد
نصب اوبونتو از دیسک نوری یا حافظه‌های فلش
توضیح رابطهٔ لینوکس و اوبونتو
تشریح محیط Unity
کارهایی که بعد از نصب اوبونتو باید انجام بدهید
راه‌های نصب نرم‌افزار در اوبونتو
فهرستی از نرم‌افزارهای انحصاری و معادل آزاد آن‌ها در اوبونتو
معرفی ترمینال اوبونتو و معرفی دستورهای ضروری

دریافت کتاب از http://ubuntu-book.org/

شروع با اوبونتو
اوبونتو برای تازه واردها عنوان راهنمای ساده‌ای‌ست که به منظور شروع کار با اوبونتو نوشته شده. اوبونتو سیستم‌عاملی رایگان و آزاد است که با مشارکت کاربران از سراسر جهان ساخته شده و به عنوان پر استفاده‌ترین توزیع گنو / لینوکس شناخته می‌شود.

تصمیم به استفاده از اوبونتو گرفته‌اید اما نمی‌دانید از کجا شروع کنید؟ «اوبونتو برای تازه‌واردها» تمام اطلاعاتی که برای شروع با اوبونتو نیاز دارید را به همراه دارد.

با این کتاب می‌آموزید:

معرفی اوبونتو و فلسفهٔ نرم‌افزارهای آزاد
نصب اوبونتو از دیسک نوری یا حافظه‌های فلش
توضیح رابطهٔ لینوکس و اوبونتو
تشریح محیط Unity
کارهایی که بعد از نصب اوبونتو باید انجام بدهید
راه‌های نصب نرم‌افزار در اوبونتو
فهرستی از نرم‌افزارهای انحصاری و معادل آزاد آن‌ها در اوبونتو
معرفی ترمینال اوبونتو و معرفی دستورهای ضروری

دریافت کتاب از http://ubuntu-book.org/

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

خدمات محاسبات ابری معمولا دارای مدل مبتنی بر استفاده هستند که در آن پرداخت فقط بازای منابعی که استفاده می‌شود انجام می‌گیرد. در صورتی که نیاز به منابع بیشتری داشته باشید، تا حد ظرفیت ابر می‌توانید دریافت کنید و هزینه آن را پرداخت نمایید. خدماتی نظیرS3 و EC2 آمازون از این مدل قیمت‌گذاری استفاده می‌کنند. از مزایای این نوع قیمت‌گذاری می‌توان به عدم نیاز به سرمایه گذاری اولیه و دسترسی به ظرفیت مورد نیاز در زمان نیاز اشاره کرد. این مزایا باعث می‌شود که از یک سو تنها وقتی نیاز احساس شد، سرویس را تقاضا کرد و از سوی دیگر بتوان یک روز از 100 کاربر و روز دیگر از 10000 کاربر پشتیبانی کرد. به‌عنوان مثال فرض کنید شما نیاز به 100 سرور برای 3 سال دارید. یک روش این است که هر کدام از آنها را ساعتی 0.6 دلار اجاره کنید که تقریبا هزینه¬ای به این شکل خواهد داشت:

100 servers * $0.60 instance-hour * 3 years * 8,760 hours/year = $1,555,200

حال فرض کنید که هر سرور را به قیمت 1500 دلار خریداری کنید. به این ترتیب 2 نفر برای مدیریت و نگهداری شبکه نیاز دارید که فرض می کنیم سالیانه 100000 دلار دستمزد بگیرند. هر یک از سرورها 150 وات مصرف می‌کنند که با هزینه 0.1 دلار بازای هرکیلووات، سالیانه برای این 100 سرور 13140 دلار خواهد شد. سایر هزینه های مربوط به ایجاد زیرساخت مرکز داده (راک، روتر، سوئیچ، اتصالات، سرمایش، پهنای باند و ...) را 500000 دلار فرض می¬کنیم. به این ترتیب خواهیم داشت:


100 servers * $1,500 + 3 years * $13,140 electricity/year + 3 years * 2 staff * $100,000 salary/year + 500,000 $ other costs = $1,289,420

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

$1,555,200* 0.75% = $1,166,400

لازم به ذکر است که در حالت ابری، این هزینه در طول مدت 3 سال پرداخت خواهد شد ولی در حالت غیرابری، بخش عمده ای از هزینه باید همان ابتدا پرداخت شود. نمودار مقایسه سه حالت فوق در شکل مقابل نشان داده شده است.

اهمیت اصلی رایانش ابری از نظر اقتصادی، مربوط به همین عدم نیاز به سرمایه گذاری اولیه است. اما همانطور که مشاهده می شود، در دراز مدت، اگر منابع به خوبی مدیریت نشوند، مجموع هزینه های ابری بسیار بیشتر خواهد شد.

Cloud native applications are service-oriented.

Computing Paradigm Programming Paradigm
:
Mainframe>>>> Imperative
Client/Server >>>>>Object Oriented
Cloud Computing >>>>>Service Oriented

Characteristics of Cloud-native Applications

A cloud-native application is composed of multiple services and each service is elastic, resilient, and composable. Let’s dissect this a bit:

The Application is composed of multiple services: what looks like a single application to the end user, for example a Software-as-a-Service (SaaS) human resources application, or a streaming music service, is actually delivered by a set of co-operating services. Clients interact with the application as a whole; typically via a single API. However, internally the application is made up of multiple cooperating services, much like an object-oriented application is made up of multiple cooperating objects.

Each service is elastic: this means that each service can scale-up or scale-down independently of other services. Ideally the scaling is automatic, based on load or other defined triggers. Cloud computing costs are typically based on usage, and being able to dynamically manage scalability in a granular manner enables efficient use of the underlying resources.

Each service is resilient: this means that each service is highly-available and can survive infrastructure failures. This characteristic limits the failure domain, due to software bugs or hardware issues.

Each service is composable: this implies that the service is designed to allow it to be part of other applications. At the minimum, each Service has an Application Programming Interface (API) that is uniform and discoverable, and in addition can have well defined behaviors for registration, discovery, and request management.