تیم پلتفرم چیست و چه مشکلی را حل می کنند؟

تماشای آرمون دادگر تیم های پلتفرم را در این جلسه تخته سفید توضیح دهید و یاد بگیرید که چگونه آنها در یک مدل بلوغ گسترده تر از پذیرش ابر و نوسازی IT قرار می گیرند.

رونوشت

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

در حالی که مردم در حال بلوغ برنامه های ابری خود هستند ، زیرا آنها در حال فکر کردن در مورد چگونگی انجام ابر در مقیاس هستند ، این ایده از تیم های پلتفرم ، تیم های SRE (مهندسی قابلیت اطمینان سایت) یا تیم های ابری ادامه می یابد. بنابراین من می خواستم کمی در مورد دیدگاه خود و چگونگی فکر کردن در مورد نقش یک تیم پلتفرم به اشتراک بگذارم. مشکلی که آنها برای آن حل می کنند چیست و دامنه آن تیم ها چیست؟

با یک قدم سریع به عقب ، فکر می کنم شروع به کار با این سؤال مفید است: "چگونه ما در مورد تکامل نحوه اتخاذ ابر مردم فکر می کنیم؟"آنچه ما اغلب می بینیم این رویکرد فاز یک به ابر است ، جایی که شما چندین تیم کاربردی دارید و همه آنها سفر خود را به سمت ساخت برنامه های ابری آغاز می کنند.

فاز 1: آن را غیر متمرکز می کند

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

در فاز اول ، این یک بسیار است ، من آن را به صورت موقت یا رویکرد تصادفی می نامم. به معنی تیم یک تیم ، ممکن است همه در آمازون حضور داشته باشند. تیم برنامه دو ، آنها در حال انتخاب و انتخاب هستند. تیم برنامه سه ، آنها خودشان در حال ساختن چیزی هستند. بنابراین این رویکرد هرج و مرج است که در آن هر تیم ابزار خود را انتخاب می کند ، به آن راه خود را نزدیک می کند ، خطوط لوله خود را می سازند و روند خود را برای نحوه پذیرش ابر می سازند. و ما این را خیلی اوقات می بینیم. ما آن را اغلب می بینیم که ما این مرحله را یک یا ابر 1. 0 خوانده ایم.

من فکر می کنم چالش در این مدل تقریباً ناگزیر 12 ماه ، 18 ماه ، 24 ماه از این کار است ، آنچه در پایان می بینیم همه چیزهایی است که انتظار دارید:

• شما بیش از حد هزینه دارید زیرا هر تیم این کار را به روش خود انجام می دهد. هیچ کس به چرخش نمونه های Dev توجه نمی کند. همه چیز بزرگ است.
• شما آسیب پذیری های امنیتی در همه جا دارید زیرا تیم های برنامه واقعاً روی برنامه های خود متمرکز هستند. آنها واقعاً در مورد برخی از نگرانی های روز 2 فکر نمی کنند ، "آیا من واقعاً گروه های امنیتی خود را به درستی تعریف کردم؟ آیا سطل S3 را فقط به خصوصی تنظیم کردم؟"
• سپس انواع چالش های انطباق را دارید. به عنوان یک سازمان امنیتی و انطباق ، هیچ راهی آسان برای شریک زندگی برای حل این مشکلات وجود ندارد زیرا هر تیم در حال حل آن راه خود است.

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

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

فاز 2: پلتفرم به عنوان یک سرویس

این شما را به مرحله دو می رساند ، جایی که شما هنوز هم تمام تیم های برنامه های مختلف را انجام می دهید که کار خود را انجام می دهند. اما اکنون ما می گوییم تیم Application One ، تیم برنامه دو و تیم برنامه سه باید همه رویکرد منحصر به فرد خود را برای انجام پذیرش ابر داشته باشند. در عوض ، ما باید یک تیم سکو مرکزی ایجاد کنیم. سازمان های مختلف ممکن است این را یک چیز متفاوت بدانند. ما آن را یک تیم پلتفرم می نامیم. برخی افراد این را تیم ابری می نامند. این ممکن است تیم DevOps یا تیم SRE باشد.

من فکر می کنم با نام های مختلف ، مرکز تعالی در برخی از سازمان ها همراه است. من فکر می کنم از نظر مفهومی مهم این است که شما این مفهوم را دارید که من تیم های مختلف کاربردی دارم - آنها مشتری هستند. من یک تیم پلتفرم دارم.- آنها ارائه دهنده داخلی هستند و وظیفه آنها استاندارد سازی رویکرد به ابر است. آنها دیافراگم اصلی خواهند بود تا بگویند ، "اینگونه است که ما در هر یک از این محیط های ابری یک برنامه را می سازیم و ارائه می دهیم."

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

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

سپس این مسئله به یک سؤال فلسفه می پردازد: "چقدر می خواهید استاندارد کنید؟ دامنه آن تیم ها چه باید باشد؟"بنابراین روشی که من به آن نگاه می کنم از دیدگاه یک برنامه است-الزامات مهم و غیر عملکردی که دارد چیست؟به طوری که برای هر برنامه ای که شما در حال ساخت هستید (اگر با فکر کردن در مورد خط لوله قبل از تولید شروع کنیم) مجموعه مشترکی از چیزها وجود دارد.

VCS

تک تک برنامه ها به یک سیستم کنترل نسخه نیاز دارند. بنابراین ممکن است شما بگویید ، "گیتوبVC های انتخابی من است. "

CI/CD

من می خواهم برخی از سیستم CI (ادغام مداوم) را بخواهم. من ادغام و آزمایش مداوم را انجام می دهم ، و این همان جایی است که من برنامه خود را ساختم. آیا می خواهم 10 راه حل مختلف داشته باشم یا در مورد آن استاندارد می کنم ،دایره CIیاجنکینز?

مدیریت مصنوعی

سپس به مواردی مانند مدیریت Artifact فکر می کنید. من قصد دارم برنامه شغلی خود را بسازم ، یا قصد دارم خودم را بسازماسکلهظرفآیا من 20 ثبت مختلف دارم یا سازگار استمصنوعیبه عنوان مثال استقرار؟

تجزیه و تحلیل کد استاتیک

سپس به مواردی مانند تجزیه و تحلیل کد استاتیک می پردازید ، و این به مواردی مانند امنیت و انطباق برمی گردد. ممکن است بگویم ، "تمام برنامه های من باید مقدار مشخصی از تجزیه و تحلیل کد استاتیک را طی کنند تا به دنبال آسیب پذیری های مختلف یا مشکلات مجوز باشند."

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

تأمین زیرساخت

وقتی به سمت تولید آن فکر می کنیم ، شما به همین ترتیب مجموعه ای از چیزها را نیز دارید. چگونه می توانم در مورد ارائه درخواست خود فکر کنم؟من باید زیرساخت هایی را که در آن اجرا می شود تعریف کنم. چقدر ظرفیت لازم دارم؟آیا به نسخه یا منابع به روزرسانی نیاز دارم؟من یک روش مداوم برای تعریف و مدیریت تهیه آنها می خواهم.

مدیریت اسرار

سپس لایه بعدی این است که چگونه می توانم در مورد امنیت آن برنامه ها فکر کنم؟بسیار عالی. چگونه برنامه نام های کاربری و رمزهای عبور را برای پایگاه داده دریافت می کند؟چگونه می توان گواهینامه هایی را برای ترافیک TLS دریافت کرد؟چگونه می توانم کلیدهای رمزگذاری را برای تأمین اطلاعات خود دریافت کنم؟چگونه می توانم کلیدهای API را برای برنامه های ابری یا Twilio یا ارسال ایمیل انجام دهم؟بنابراین شمامدیریت اسرار، مجموعه مدیریت گواهی مدیریت کلیدی چالش هایی که هر برنامه دارد. تقریباً هر برنامه به اعتبار پایگاه داده یا نشانه API یا موارد دیگر نیاز دارد.

شبکه کاری

سپس مجموعه ای از چالش های شبکه یا اتصال را دارید. هنگامی که برنامه من مستقر شد ، چگونه می توانم Balancer Load ، Firewall ، API Gateway را به روز کنم تا اطمینان حاصل شود که برنامه واقعاً ترافیک می شود؟اگر برنامه A نیاز به صحبت با برنامه B دارد ، آیا باید تغییرات فایروال را به صورت خودکار بدست آورم ، یا آیا چیزی شبیه به آن دارممشبکاین برنامه A و برنامه B را قادر می سازد تا ارتباط برقرار کنند؟تقریباً برای هر برنامه ای که می خواهید مستقر کنید ، چالش شبکه ای وجود دارد ، مگر اینکه هرگز با هیچ سرویس دیگری صحبت نکند.

تنظیم و ارکستراسیون

سپس یک زمان اجرا دارید. برنامه در واقع کجا اجرا می شود؟ممکن است روشن باشدکربن، ممکن است [AWS] باشدلامبداعملکرد ، ممکن است در بالای [hashicorp] باشدنایبشرواقعاً مهم نیستبرنامه باید در جایی اجرا شود.

رعایت

و در آخر - این همه این لایه ها را شامل می شود - یک چالش مشاهده ، به این معنی که برنامه های من قصد دارند داده های ورود به سیستم را منتشر کنند. آنها قصد دارند از راه دور استفاده کنند ، آنها قصد دارند ردیابی را منتشر کنند. چگونه می توانم همه اینها را مشاهده کنم تا درک کنم برنامه سالم است؟اگر مشکلی وجود داشته باشد چگونه می توانم اشکال زدایی کنم؟

در نهایت برنامه ها سپس در بالای این پشته می نشینند و اجرا می شوند. تقریباً برای هر برنامه ، همه این مشکلات را دارند. این یک برنامه درجه تولید است. شاید بتوانید بگویید ، "من از مشاهده پرش می کنم ، یا CI را انجام نمی دهم ، برنامه را آزمایش نمی کنم."شما می توانید از آن چیزها پرش کنید ، اما من فکر می کنم از نظر عملکردی ، هر برنامه بالغ به همه این قطعات نیاز دارد.

تیم های پلتفرم: چه چیزی در محدوده است؟

بنابراین این سؤال مطرح می شود ، "چه چیزی برای این تیم های پلتفرم وجود دارد؟"در نهایت ، دیدگاه ما این است: همه اینها ، زیرا هدف ارائه سازگاری به این تیم های برنامه است. من نمی خواهم برنامه 1 تا 100 این کار را به روشی متفاوت انجام دهد. بنابراین اگر هر برنامه این مشکلات را داشته باشد ، من نمی خواهم 100 راه حل مختلف CI و 100 خط لوله مختلف داشته باشم که باید مدیریت کنم.

طرف دوم آن قطعه قوام است - چگونه می توانم به همه این گروه ها اهرم تحویل دهم؟به عنوان یک تیم برنامه ، اگر بتوانم سوار شوم و این کار را به عنوان یک سرویس تحویل دهم ، می توانم روی آنچه که واقعاً به آن اهمیت می دهم توجه کنم ، که این برنامه من است. بیشتر این تیم های برنامه به صورت عملکردی در اینجا نیستند زیرا آنها به جزئیات تهیه یا زمان اجرا یا مشاهده اهمیت می دهند. این جزئیات برای پشتیبانی از برنامه بر خلاف هدف نهایی است.

تیم های پلتفرم: از کجا شروع می کنید؟

اکنون این گفته ، این یک دامنه بسیار بزرگ است. بنابراین همانطور که در مورد توالی تیم های پلتفرم فکر می کنید ، از کجا شروع می کنید؟رفتن از صفر به ارائه همه این موارد به عنوان یک سرویس مشترک بسیار سخت است. پاسگاه های مهم در طول مسیر چیست؟و چگونه می توانید به عنوان یک تیم پلتفرم به جای اینکه بگوییم ارزش آن را به صورت تدریجی ارائه دهید ، ما می خواهیم دو سال در یک غار ناپدید شویم تا این کار را انجام دهیم.

پیش تولید

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

به عنوان یک تیم پلتفرم ، آیا می توانم Github و Jenkins را به عنوان یک سرویس استاندارد کنم و ارائه دهم ، و مصنوعی که به طور مرکزی برای داشتن آثار باستانی مشترک اجرا می کنم. من آن را به عنوان یک سرویس مشترک ارائه می دهم که هرکسی بتواند وارد آن شود و در بالای آن بسازد. این حداقل قبل از تولید است.

تهیه و زیرساخت به عنوان کد

من فکر می کنم مرحله بعدی بعد از آن ، من این را به شکل L می نامم ، اضافه کردن ارائه به آن است. اگر ما در مورد چیزی شبیه بهشکل، به عنوان مثال ، من در واقع می توانم یک کامل بسازمزیرساخت به عنوان کدخط لولهمن می توانم تنظیمات خود را به GitHub متعهد کنم. من در CI خود اعتبار می دهم ، و سپس می توانم تغییر خود را از طریق Cloud Terraform اعمال کنم.

و اکنون من این دیدگاه را به عنوان یک تیم پلتفرم از تمام زیرساخت هایی که ارائه می شود ، دارم. من می توانم آن را در یک مکان مرکزی مدیریت کنم. من می توانم همکاری و حمایت صحیح از مدیریت را در این زمینه قرار دهم.

اما مهمتر از این که من این کار را در این سطح پایه انجام می دهم ، زیرساخت ها را به عنوان کدهای انجام شده با Terraform می گیرم ، می توانم به طور موثری از این لایه های دیگر پشتیبانی کنم. اکنون می توانم یک الگوی Terraform ایجاد کنم ، بیایید بگوییم ، برنامه مبتنی بر جاوا من در حال اجرا استEC های آمازونبشرمن می توانم یک ماژول برای آن ایجاد کنم و آن ماژول استاندارد سازی مواردی از این دست است: چگونه این کار در حال اجرا است ، وقتی برنامه مستقر می شود ، آیا به DataDog متصل است؟آیا مشاهده در آن پخته شده است؟آیا من به [hashicorp] وصل می شومطاقبرای انجام مدیریت اسرار من؟

مزایای PAAS

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

این امر به من این امکان را می دهد تا شروع به راهپیمایی در پشته کنم تا به طور فزاینده ای این خدمات دیگر را به عنوان یک سرویس مدیریت شده تیم پلتفرم ارائه دهم. بنابراین می توانید یک جهان را تصور کنید که می گویید ، "سلام ، هر یک از تیم های برنامه من ، خوشه طاق خود را اجرا می کنند ، راه حل مدیریت مخفی خودشان."این اهرم فوق العاده بالا نیست. هر یک از این تیم ها آن را به روشی متفاوت مدیریت می کنند و با به روزرسانی ها و نسخه ها و نسخه های پشتیبان برخورد می کنند. به عنوان یک تیم پلتفرم ، آیا می توانم یک سرویس طاق مشترک را ارائه دهم یا می توانم یک سرویس DataDog مشترک را ارائه دهم که در آن یک قرارداد با Datadog ، یک حساب داشته باشم ، من آن را مدیریت می کنم ، و سپس هر یک از این تیم های برنامه می توانند کاربر باشند/مشتری آنو به همین ترتیب، و غیره.

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

سپس با گذشت زمان ، همانطور که من بیشتر و بیشتر از این قابلیت ها اضافه می کنم ، آنچه که من واقعاً قدم می زنم ، انتزاع یک پلت فرم به عنوان سرویس (PAAS) است. اگر به این فکر می کنید که همه این قطعات به چه معادل می رسد ، این یک پلت فرم تمام عیار است-به عنوان یک سرویس که اکنون من به توسعه دهندگان خود می گویم ، "آنچه شما واقعاً به من می دهید کد منبع برنامه شما است. وسپس به عنوان یک تیم پلتفرم ، (کد منبع شما در کنترل نسخه زندگی می کند) ما می توانیم به طور خودکار آن را بسازیم ، مصنوعات را تولید می کنیم ، می توانیم آن را بر روی ECS یا Kubeetes مستقر کنیم. نظارت در آنجاست ، امنیت و شبکه ساخته شده است-in. این یک سکوی کامل است.

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

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

فاز 3: سیستم عامل های ترکیبی و چند ابر

اکنون ، قطعه نهایی این امر در حالی است که ما در انجام این کار بالغ می شویم ، اکنون ما در حال ارائه یک سکوی ثابت ، مجموعه ای از خطوط لوله ثابت در همه این تیم های برنامه در ابر هستیم. سپس به فاز سوم بروید ، و من فکر می کنم گسترش از فاز دو به فاز سوم این است که ما واقعاً به آنها نگاه می کنیم و می گوییم ، "خوب ، چه چیزی در مورد دیتاسنتر خصوصی تفاوت دارد؟ چرا نمی توانم این رویکرد را دقیقاً انجام دهم ، آن را گسترش دهمو بگویید Datacenter خصوصی من همان ابر به نظر می رسد ، هنوز هم API محور است. این همه مشکلات اساسی را دارد. "

اگر من فقط می توانم کاری را که در ابر به دیتاسنتر خود انجام می دهم گسترش دهم ، عالی. من می توانم terraform ، طاق را اعمال کنمکنسولبشرمن می توانم برنامه ها را در بالا مستقر کنمظریفیاباز کردنبشرمن می توانم DataDog را برای کار در محل کار گسترش دهم یا از یک راه حل متفاوت استفاده کنم. شاید باشدحرص، شاید این AppDynamics باشد. اما اساساً ، من می توانم همین تصویر را دقیقاً در دیتاسنتر خصوصی خود اعمال کنم. بنابراین این تیم پلتفرم سپس به روشی مداوم برای ارائه زیرساخت ها در همه چیز تبدیل می شود ، نه فقط ابر ، بلکه دیتاسنتر خصوصی و چند ابر.

یک مدل بلوغ برای تیم های پلتفرم و تیم های ابری

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

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

زیرساخت ها به عنوان استاندارد سازی کد ، استاندارد سازی پلتفرم و پس از داشتن آن ، می توانید به مرحله سوم برسید ، که واقعاً گسترش به دیتاسنتر خصوصی است و این یک رویکرد مداوم برای انجام همه این کارها به شما می دهد.

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