تفاوت VVF و VCF در معماری واقعی؛ کدام انتخاب برای سازمان شما مناسب‌تر است؟

در بخش نخست این مقاله، اجزای اصلی VMware vSphere Foundation و VMware Cloud Foundation در نسخه 9.1 را بررسی کردیم و دیدیم که هر پلتفرم دقیقاً چه محصولات و قابلیت‌هایی را در اختیار سازمان قرار می‌دهد. اما دانستن فهرست محصولات به‌تنهایی برای انتخاب میان VVF و VCF کافی نیست.

در یک پروژه واقعی، تصمیم میان VVF یا VCF به تعداد نام‌هایی که داخل هر پکیج قرار گرفته‌اند محدود نمی‌شود. مدل شبکه، شیوه ارائه سرویس، تعداد تیم‌های مصرف‌کننده، مقیاس Kubernetes، نیاز به Automation، روش مدیریت Lifecycle و حتی مهارت‌های تیم فنی همگی روی این انتخاب اثر می‌گذارند.

ممکن است یک سازمان بزرگ با صدها Host همچنان با VVF به نتیجه مناسبی برسد و در مقابل، سازمان کوچک‌تری به‌دلیل Multi-Tenancy، Self-Service و Network Automation واقعاً به VCF نیاز داشته باشد. بنابراین سؤال اصلی این نیست که کدام پکیج قابلیت‌های بیشتری دارد؟

 سؤال درست این است که کدام مدل عملیاتی با معماری و برنامه آینده سازمان هماهنگ‌تر است؟

در این مقاله تفاوت VVF و VCF 9.1 را از منظر معماری واقعی بررسی می‌کنیم؛ از شبکه و VKS گرفته تا سناریوهای سازمانی، مهاجرت از VVF به VCF، جدول تصمیم‌گیری و تأثیر این انتخاب بر عناوین شغلی VMware.

خلاصه سریع؛ VVF یا VCF؟

اگر هدف اصلی سازمان اجرای پایدار ماشین‌های مجازی و Containerها، مدیریت vSphere و vSAN، استفاده کنترل‌شده از Kubernetes و مانیتورینگ زیرساخت باشد، VVF معمولاً انتخاب ساده‌تر و اقتصادی‌تری است.

اگر زیرساخت باید مانند یک Private Cloud داخلی عمل کند و چند تیم یا واحد سازمانی بتوانند از طریق Catalog، API یا Infrastructure as Code سرویس دریافت کنند، VCF انتخاب مناسب‌تری خواهد بود. در این مدل، NSX، Automation، Multi-Tenancy، VPC، Fleet Management و Full-Stack Lifecycle بخشی از نیاز اصلی هستند.

تفاوت اصلی VVF و VCF در مدل عملیاتی است.

در VVF، تیم زیرساخت معمولاً vCenter، Clusterها، ماشین‌های مجازی، Datastoreها، شبکه‌های VLAN-Based و سرویس‌های پایه Kubernetes را مدیریت می‌کند. درخواست‌های جدید نیز اغلب از طریق فرآیندهای داخلی سازمان به تیم زیرساخت ارجاع داده می‌شوند و ادمین‌ها منابع موردنیاز را ایجاد می‌کنند.

VCF زیرساخت را به یک مدل Cloud Operating Model نزدیک می‌کند. در این مدل، تیم مرکزی پلتفرم، ظرفیت، Policy، امنیت، شبکه، Quota، Catalog و محدوده دسترسی را تعریف می‌کند؛ سپس تیم‌های دیگر می‌توانند سرویس‌های مجاز را بدون دسترسی مستقیم به vCenter یا NSX مصرف کنند.

این تفاوت، پیامدهای فنی و سازمانی مهمی دارد. VCF به‌طور معمول به طراحی دقیق‌تر DNS، NTP، Certificate، Management Domain، NSX Fabric، Edge، IP Pool، Routing، IAM، Organization و Project نیاز دارد. در مقابل، VVF می‌تواند با معماری ساده‌تر و تیم کوچک‌تری اداره شود.

پس VCF را نباید صرفاً نسخه‌ای از VVF با چند محصول اضافه در نظر گرفت. VCF یک مدل یکپارچه برای طراحی، استقرار، بهره‌برداری و ارائه زیرساخت است.

تفاوت شبکه در VVF و VCF

شبکه یکی از روشن‌ترین تفاوت‌های VMware vSphere Foundation و VMware Cloud Foundation است. هر دو پلتفرم قابلیت‌های Enterprise شبکه در سطح vSphere را دارند، اما فقط VCF لایه کامل Software-Defined Networking مبتنی بر NSX را به‌عنوان بخشی از معماری اصلی ارائه می‌کند.

شبکه در VVF 9.1

در VVF، شبکه اصلی Hostها و ماشین‌های مجازی با vSphere Standard Switch یا vSphere Distributed Switch و VLAN طراحی می‌شود. قابلیت‌هایی مانند NIC Teaming، Network I/O Control، LACP، Private VLAN، Port Mirroring، NetFlow و مدیریت متمرکز Port Groupها در اختیار ادمین قرار دارند.

این مدل برای بسیاری از دیتاسنترهای سازمانی کاملاً کافی است. اگر Routing، Firewall، Load Balancing و Segmentation در تجهیزات فیزیکی یا پلتفرم‌های جداگانه انجام شود، سازمان الزاماً به NSX نیاز ندارد.

برای مثال، ممکن است سازمانی سه Cluster، چند صد ماشین مجازی، Storage خارجی و تجهیزات شبکه Cisco یا Arista داشته باشد. اگر شبکه بر اساس VLAN طراحی شده و تیم شبکه تمام Routing و Security را خارج از VMware مدیریت می‌کند، نبود NSX الزاماً یک محدودیت جدی نیست.

VVF از vSphere Kubernetes Service نیز پشتیبانی می‌کند و سرویس‌های شبکه موردنیاز VM Service و VKS را در اختیار قرار می‌دهد؛ اما نباید این قابلیت را با یک پلتفرم کامل Software-Defined Networking یا Multi-Tenant Cloud Network یکسان دانست.

شبکه در VCF 9.1

در VCF، NSX بخشی از معماری اصلی پلتفرم است. در نتیجه می‌توان سرویس‌های شبکه را به‌شکل نرم‌افزاری و Policy-Based تعریف کرد.

قابلیت‌هایی مانند موارد زیر در این مدل اهمیت پیدا می‌کنند:

• Overlay Networking
• Logical Switching و Routing
• Tier-0 و Tier-1 Gateway
• BGP، OSPF و BFD
• NAT و VPN
• DHCP و IPAM Integration
• NSX Projects
• Virtual Private Cloud یا VPC
• Network Segmentation
• Policy، Tagging و Grouping
• شبکه‌های مستقل برای Organizationها و Projectها

در این معماری، ایجاد شبکه جدید الزاماً نیازمند ساخت VLAN روی تمام تجهیزات فیزیکی نیست. تیم Cloud می‌تواند محدوده‌های شبکه، Gatewayها، Policyها و دسترسی هر Project را از طریق NSX و VCF Automation تعریف کند.

این قابلیت برای محیط‌های Multi-Tenant، سرویس‌های Self-Service، تیم‌های متعدد توسعه و زیرساخت‌هایی که تغییرات شبکه زیادی دارند، ارزش قابل‌توجهی ایجاد می‌کند.

البته NSX جایگزین شبکه فیزیکی نیست. Underlay همچنان باید از نظر MTU، Redundancy، Routing، ظرفیت و طراحی Fabric درست پیاده‌سازی شود. NSX لایه منطقی و کنترل نرم‌افزاری شبکه را روی این زیرساخت ایجاد می‌کند.

آیا تمام قابلیت‌های Firewall داخل VCF هستند؟

خیر. وجود NSX در VCF به معنی دریافت کامل تمام قابلیت‌های vDefend نیست.

قابلیت‌های پایه Networking و Segmentation با NSX ارائه می‌شوند، اما برخی امکانات پیشرفته Distributed Firewall، Gateway Firewall، Threat Prevention و سرویس‌های امنیتی به Add-on جداگانه نیاز دارند.

پس هنگام تهیه Bill of Materials باید سه موضوع جداگانه بررسی شوند:

1. شبکه پایه NSX در VCF
2. قابلیت‌های امنیتی موجود در Entitlement اصلی
3. امکانات پیشرفته vDefend یا Advanced Cyber Compliance که لایسنس جدا می‌خواهند

تفاوت VKS در VVF و VCF

یکی از برداشت‌های اشتباه این است که VKS فقط در VCF وجود دارد. VMware vSphere Kubernetes Service در هر دو پلتفرم VVF و VCF ارائه می‌شود.

در VVF می‌توان Kubernetes Clusterهای مبتنی بر VKS را در کنار ماشین‌های مجازی اجرا کرد و از قابلیت‌هایی مانند Supervisor، VM Service، Storage Service، Container Networking، Harbor و سرویس‌های پایه موردنیاز Workloadهای Cloud-Native استفاده کرد.

برای سازمانی که چند Kubernetes Cluster دارد و تیم زیرساخت همچنان آن‌ها را به‌صورت متمرکز و مستقیم مدیریت می‌کند، VVF می‌تواند نیاز اصلی را پوشش دهد.

تفاوت VCF زمانی مشخص می‌شود که Kubernetes از یک قابلیت جانبی به یک سرویس سازمانی تبدیل شود.

در VCF قابلیت‌هایی مانند این موارد اهمیت بیشتری پیدا می‌کنند:

• مشاهده متمرکز Fleet مربوط به VKS Clusterها
• Multi-Cluster Lifecycle Management
• VKS Policy Management
• مدیریت Add-onها
• Data Protection
• GitOps Integration
• Regional Harbor Registry
• Secret Store Service
• Namespace Class و IaaS Policy
• اتصال Kubernetes به Organization، Project و VPC
• ارائه Cluster از طریق Self-Service Catalog
• اعمال Quota، Approval، Lease و Placement Policy

فرض کنیم یک سازمان فقط دو Cluster آزمایشی Kubernetes دارد. در این شرایط، وجود VCF Automation و Multi-Tenant Networking احتمالاً توجیه اقتصادی و فنی کافی ندارد.

اما اگر چند تیم توسعه به‌طور هم‌زمان Kubernetes Cluster درخواست می‌کنند، هر تیم باید Namespace، شبکه، Quota و Policy مستقل داشته باشد و نسخه Clusterها نیز متمرکز مدیریت شود، VCF انتخاب منطقی‌تری خواهد بود.

پس تفاوت اصلی این نیست که «VVF Kubernetes دارد یا ندارد». هر دو VKS دارند؛ تفاوت در مقیاس مدیریت و شیوه ارائه Kubernetes به مصرف‌کنندگان است.

آیا هر سازمان بزرگی به VCF نیاز دارد؟

خیر. تعداد Host، VM یا Cluster به‌تنهایی تعیین نمی‌کند که VVF مناسب است یا VCF.

یک سازمان ممکن است ۲۰۰ Host داشته باشد، اما معماری آن ثابت باشد، شبکه از طریق VLAN مدیریت شود، سرویس Self-Service نداشته باشد و همه تغییرات توسط تیم مرکزی زیرساخت انجام شوند. در چنین محیطی VVF همچنان می‌تواند انتخاب قابل‌قبولی باشد.

در مقابل، ممکن است یک سازمان فقط ۳۰ Host داشته باشد اما شرایط زیر را تجربه کند:

• چند تیم توسعه مستقل دارد؛
• باید برای هر تیم Project و شبکه مجزا ایجاد کند؛
• VM و Kubernetes را به‌صورت Self-Service ارائه می‌دهد؛
• نیازمند Automation و Infrastructure as Code است؛
• تغییرات شبکه و سرویس‌ها زیاد است؛
• Private AI یا سرویس‌های Cloud-Native بخشی از برنامه سازمان است.

چنین محیطی حتی با تعداد Host کمتر، از نظر مدل عملیاتی به VCF نزدیک‌تر است.

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

بررسی چند سناریوی واقعی

سناریوی اول: زیرساخت مجازی‌سازی سازمانی با شبکه سنتی

سازمان دارای چند Cluster vSphere، تعدادی Datastore مبتنی بر SAN، شبکه VLAN-Based و تیم‌های جداگانه Server، Storage و Network است. ماشین‌های مجازی توسط ادمین‌ها ساخته می‌شوند و نیازی به Self-Service وجود ندارد.

در این سناریو معمولاً VVF انتخاب منطقی‌تری است. سازمان به vSphere، vCenter، Operations، VKS و قابلیت‌های پایه Storage دسترسی دارد و مجبور نیست پیچیدگی NSX و Automation را وارد محیط کند.

سناریوی دوم: Private Cloud برای چند واحد سازمانی

چند واحد سازمانی یا شرکت زیرمجموعه از زیرساخت مشترک استفاده می‌کنند. هر واحد باید شبکه، Quota، Catalog، Policy و دسترسی مستقل داشته باشد. کاربران باید بدون دسترسی مستقیم به vCenter بتوانند VM یا Kubernetes Cluster درخواست کنند.

در این شرایط VCF مناسب‌تر است؛ زیرا NSX، VPC، Organization، Project، IAM، Catalog و Automation بخش اصلی نیاز سازمان هستند.

سناریوی سوم: ارائه VKS به چند تیم توسعه

اگر Kubernetes فقط برای یک پروژه محدود استفاده شود، VVF می‌تواند کافی باشد. اما وقتی ده‌ها Cluster، چند محیط توسعه و عملیاتی، Registry مشترک، GitOps، Secret Management، Policy و مدیریت Lifecycle متمرکز نیاز داریم، VCF مزیت عملیاتی بیشتری ایجاد می‌کند.

سناریوی چهارم: سازمان چنددیتاسنتری

اگر هدف فقط اجرای VM در چند vCenter باشد، VVF همچنان قابل بررسی است. اما اگر سازمان به مدیریت Fleet، دید متمرکز شبکه، جابه‌جایی گسترده Workload، HCX، Automation و استانداردسازی Lifecycle تمام اجزا نیاز داشته باشد، VCF گزینه کامل‌تری خواهد بود.

باید توجه داشت که Disaster Recovery پیشرفته، VMware Live Recovery و Site Recovery Manager همچنان ممکن است لایسنس جداگانه بخواهند.

سناریوی پنجم: زیرساخت Private AI

اجرای یک VM دارای GPU الزاماً به VCF نیاز ندارد. vSphere در هر دو پلتفرم می‌تواند زیرساخت محاسباتی موردنیاز GPU Workloadها را فراهم کند.

VCF زمانی ارزش بیشتری پیدا می‌کند که سازمان بخواهد GPU، Kubernetes، Model Runtime، Model Store، Vector Database، Automation، Catalog و Policy را به‌عنوان یک سرویس Private AI یکپارچه ارائه کند.

حتی در این حالت نیز سخت‌افزار GPU، طراحی شبکه و Storage و Entitlement سرویس‌های تکمیلی باید جداگانه بررسی شوند.

آیا می‌توان ابتدا VVF خرید و بعد به VCF مهاجرت کرد؟

از نظر معماری و مسیر محصول، حرکت از یک محیط vSphere یا VVF به VCF امکان‌پذیر است؛ اما این کار یک تغییر ساده License File نیست.

برای رفتن به VCF باید موارد زیر بررسی شوند:

• Entitlement و قرارداد مناسب VCF
• نسخه دقیق vCenter، ESX، vSAN و سایر اجزا
• سازگاری سخت‌افزار با Compatibility Guide
• ساختار vSphere Distributed Switch
• معماری Management Network
• وضعیت DNS، NTP، Certificate و FQDNها
• طراحی NSX و IP Poolها
• شرایط Management Domain
• وضعیت VCF Operations و VCF Installer
• سازگاری Aria Operations، NSX یا Aria Automation موجود
• ظرفیت زیرساخت برای Applianceهای مدیریتی جدید
• نتیجه Precheckها و محدودیت‌های Brownfield Conversion

Broadcom برای محیط‌های موجود، فرآیند Converge و Import را از طریق VCF Installer ارائه می‌کند. مسیر دقیق به اجزای فعلی محیط بستگی دارد. برای نمونه، محیطی که فقط vCenter و ESX دارد با محیطی که از قبل NSX 4.x یا Aria Automation دارد، Workflow یکسانی نخواهد داشت.

براساس راهنمای رسمی Upgrade و Converge نسخه 9.1، محیط‌هایی که NSX 4.x یا Aria Automation دارند باید از Workflowهای Convert و Import در VCF Installer استفاده کنند و ارتقای مستقل اجزا برای آن‌ها مسیر معتبری نیست.

همچنین NSX 9.x فقط در قالب محیط VCF 9.x پشتیبانی می‌شود. بنابراین نمی‌توان NSX 9 را به‌صورت مستقل کنار یک VVF قرار داد و انتظار پشتیبانی رسمی داشت.

پیش‌نیاز مهم شبکه برای Converge

در VCF 9 استفاده از vSphere Distributed Switch برای شبکه‌های مدیریتی الزامی است. وجود VMkernelهای Management، vMotion یا vSAN روی vSphere Standard Switch می‌تواند Precheck مربوط به Upgrade یا Brownfield Import را متوقف کند.

Broadcom در راهنمای الزامات vDS برای VCF 9 تأکید کرده است که VSS قابلیت‌های API و Automation موردنیاز VCF را در اختیار پلتفرم قرار نمی‌دهد.

بنابراین اگر احتمال می‌دهید در آینده از VVF به VCF بروید، بهتر است از ابتدا معماری شبکه، Naming، Distributed Switchها، DNS، NTP و Cluster Design را با استانداردهای قابل‌همگرایی VCF طراحی کنید. این تصمیم هزینه و ریسک مهاجرت آینده را کاهش می‌دهد.

مسیر پیشنهادی برای مهاجرت از VVF به VCF

فرآیند دقیق باید با مستندات Build مورد استفاده تطبیق داده شود، اما مسیر منطقی ارزیابی شامل مراحل زیر است:

1. تهیه Inventory کامل از Hostها، Clusterها، vCenterها، Storageها و محصولات مدیریتی
2. بررسی Entitlement و تعیین نسخه مقصد VCF
3. کنترل Hardware Compatibility و Firmware
4. بررسی vDS، VLAN، MTU، Uplink، LACP و VMkernelها
5. طراحی Management Domain، NSX و شبکه‌های Overlay
6. آماده‌سازی DNS، NTP، Certificate، IP Pool و Routeها
7. تهیه Backup معتبر از اجزای مدیریتی
8. استقرار و اتصال VCF Installer به Online یا Offline Depot
9. اجرای Precheck و رفع کامل خطاها
10. اجرای Workflow مناسب Converge، Convert یا Import
11. کنترل Inventory و Lifecycle پس از همگرایی
12. اضافه‌کردن Automation، Fleet Management و سایر سرویس‌ها طبق طراحی

نباید پیش از اجرای Precheck درباره Downtime یا عدم نیاز به Migration وعده قطعی داد. نتیجه به معماری موجود و سرویس‌هایی که باید وارد VCF شوند بستگی دارد.

جدول تصمیم‌گیری VVF یا VCF

اشتباهات رایج هنگام انتخاب VVF یا VCF

انتخاب فقط براساس تعداد Host

تعداد Host معیار مهمی برای محاسبه لایسنس و ظرفیت است، اما مشخص نمی‌کند سازمان به Private Cloud Platform نیاز دارد یا نه.

انتخاب VCF فقط به‌دلیل وجود NSX

اگر سازمان استفاده واقعی و برنامه مشخصی برای NSX، VPC، Automation و Multi-Tenancy نداشته باشد، ممکن است بخش زیادی از قابلیت‌های VCF بدون استفاده باقی بماند.

انتخاب VVF فقط به‌دلیل هزینه اولیه کمتر

اگر سازمان در آینده نزدیک به Self-Service، Kubernetes در مقیاس بالا یا Network Automation نیاز پیدا کند، مهاجرت بعدی می‌تواند هزینه طراحی و عملیات بیشتری ایجاد کند.

فرض اینکه تمام محصولات داخل VCF رایگان و نامحدود هستند

Avi، vDefend، Live Recovery، Advanced Cyber Compliance، ظرفیت اضافه vSAN و برخی سرویس‌های پیشرفته در دسته Add-on قرار می‌گیرند.

نادیده‌گرفتن هزینه عملیاتی VCF

VCF به دانش NSX، Automation، Lifecycle، IAM، Kubernetes و Cloud Operations نیاز دارد. هزینه آموزش، نیروی متخصص و نگهداری باید در تصمیم لحاظ شود.

پرسش‌های پرتکرار

آیا VVF برای دیتاسنترهای بزرگ مناسب است؟

بله. اگر مدل عملیاتی سازمان مبتنی بر Virtualization، شبکه VLAN-Based و مدیریت متمرکز توسط تیم زیرساخت باشد، VVF می‌تواند حتی در محیط‌های بزرگ نیز مناسب باشد.

آیا VVF از Kubernetes پشتیبانی می‌کند؟

بله. VKS بخشی از VVF 9.1 است. محدودیت اصلی در اجرای Kubernetes نیست؛ تفاوت در مدیریت Fleet، Self-Service، Multi-Tenancy و سرویس‌های Cloud-Native گسترده‌تر است.

آیا VCF بدون vSAN قابل استفاده است؟

VCF از چند مدل Storage شامل vSAN و برخی گزینه‌های External Storage پشتیبانی می‌کند. با این حال نوع Principal و Supplemental Storage و سازگاری آن با Workflowهای VCF باید براساس مستندات نسخه و Compatibility Guide بررسی شود.

آیا VCF جایگزین تجهیزات شبکه فیزیکی می‌شود؟

خیر. VCF و NSX لایه شبکه نرم‌افزاری را ارائه می‌کنند، اما به Underlay فیزیکی پایدار، پرظرفیت و درست طراحی‌شده نیاز دارند.

آیا VCF شامل Avi Load Balancer است؟

قابلیت‌های Foundational Load Balancing برای اجزای مشخص پلتفرم وجود دارند، اما VMware Avi Load Balancer به‌عنوان سرویس پیشرفته Application Delivery در دسته Add-on قرار می‌گیرد.

آیا می‌توان ابتدا VVF تهیه کرد و بعد به VCF رفت؟

بله، مسیر فنی برای Converge و Import محیط‌های موجود وجود دارد؛ اما باید Entitlement جدید، معماری شبکه، VCF Installer، پیش‌نیازهای Management Domain و Compatibility محیط بررسی شوند. این فرآیند صرفاً تعویض لایسنس نیست.

تفاوت VVF Admin و VCF Admin چیست؟

VVF Admin بیشتر روی مدیریت vSphere، vCenter، vSAN، عملیات زیرساخت و سرویس‌های پایه Kubernetes تمرکز دارد. VCF Admin علاوه بر این مهارت‌ها باید با NSX، Automation، Multi-Tenancy، Fleet Management و مدیریت یکپارچه Private Cloud نیز آشنا باشد.

بااین‌حال، این دو عنوان تنها نام‌های موجود در بازار کار VMware نیستند. شرکت‌ها ممکن است برای مسئولیت‌های مشابه از عنوان‌هایی مانند VMware Administrator، Virtualization Engineer، Private Cloud Engineer یا Cloud Platform Engineer استفاده کنند. تفاوت دقیق این نقش‌ها و مسیر یادگیری هرکدام را در قسمت سوم بررسی خواهیم کرد.

جمع‌بندی؛ انتخاب VVF یا VCF چه اثری بر مسیر شغلی دارد؟

انتخاب میان VVF و VCF فقط یک تصمیم فنی یا مربوط به لایسنس VMware نیست. این انتخاب مشخص می‌کند تیم زیرساخت باید چه مهارت‌هایی داشته باشد و متخصصان VMware در آینده به سمت چه نقش‌هایی حرکت کنند.

اگر تمرکز یک محیط روی مدیریت vSphere، vCenter، vSAN، ماشین‌های مجازی، عملیات زیرساخت و تعداد محدودی سرویس Kubernetes باشد، VVF معمولاً انتخاب متناسب‌تری است. در چنین محیطی عناوینی مانند VMware Administrator، Virtualization Engineer، VMware Infrastructure Engineer و VVF Admin بیشتر دیده می‌شوند.

در مقابل، وقتی سازمان به NSX، شبکه‌های نرم‌افزاری، Multi-Tenancy، Automation، Self-Service، مدیریت چندین Kubernetes Cluster و Full-Stack Lifecycle نیاز دارد، دامنه مسئولیت‌ها گسترده‌تر می‌شود. در این شرایط عناوینی مانند VCF Administrator، Private Cloud Engineer، Cloud Platform Engineer و Private Cloud Platform Engineer معنای جدی‌تری پیدا می‌کنند.

در کنار این دو مسیر اصلی، نقش‌های تخصصی‌تری نیز شکل می‌گیرند:

• vSAN Administrator یا Storage Virtualization Engineer
• NSX Engineer یا Network Virtualization Engineer
• VKS Administrator یا Kubernetes Platform Engineer
• VCF Operations Engineer
• Cloud Automation Engineer
• VMware Cloud Architect یا VCF Architect

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

در قسمت سوم این مجموعه، عناوین شغلی مرتبط با VMware را دقیق‌تر بررسی می‌کنیم و برای هرکدام مشخص خواهیم کرد:

1. مسئولیت‌های اصلی آن موقعیت شغلی چیست؛
2. چه مهارت‌ها و محصولات VMware باید یاد گرفته شوند؛
3. تفاوت نقش‌های VVF Admin، VCF Admin و Cloud Platform Engineer چیست؛
4. افراد تازه‌کار و متخصصان باتجربه باید از کدام نقطه شروع کنند؛
5. مسیر پیشرفت از VMware Administrator تا VCF Architect چگونه است؛
6. هر نقش با کدام دوره‌های مسیر آموزشی ابرکلاس ارتباط دارد.

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