כדי להציע מוצרים ב-Google Cloud Marketplace, אתם צריכים לעמוד בדרישות הבאות לפרסום מוצרים. בנוסף, עליכם לעמוד בדרישות התפעול שחלות על סוגי המוצרים שאתם מציעים.
אם אתם מבצעים שינויים במוצר או בארגון שמשפיעים על העמידה בדרישות האלה לפרסום כרטיסי מוצר או מבטלים מסמכים שסיפקתם ל-Google במהלך ההצטרפות, אתם צריכים להודיע ל-Google ולשלוח את המוצר לבדיקה מחדש ולאישור מחדש.
דרישות לארגון
הארגון שלכם צריך להצטרף לGoogle Cloud Partner Network ולשמור על סטטוס תקין בו.
אחרי שהארגון שלכם מצטרף ל Google Cloud Partner Network, אתם מקבלים גישה ל-Partner Network Hub.
הארגון שלכם צריך להיות רשום באחד מהאזורים הנתמכים.
לארגון שלכם צריך להיות חשבון ספק ב-Cloud Marketplace ופרופיל תשלומים במצב תקין.
הדרישות לגבי המוצר
כדי שהמוצר שלכם יוכל להיות רשום ב-Cloud Marketplace ולהימכר דרכו, הוא צריך להיות מוכן לייצור (לא אלפא או בטא).
המוצר שלכם צריך להיות מוכן לשימוש בארגונים, כולל נוכחות מקצועית באינטרנט, אסטרטגיה לקידום מכירות מוגדרת, תמיכת לקוחות ועמידה בשיטות המומלצות לאבטחה.
המוצר שלכם לא יכול לכלול פגיעויות ידועות, וירוסים, רוגלות, סוסים טרויאניים או קוד זדוני אחר מכל סוג.
במהלך תהליך ההצטרפות, תצטרכו לעבור תהליך אישור כדי לאמת שאתם מארחים את מוצר התוכנה שלכם בעיקר ב-Google Cloud. Google Cloud אלה כמה תרחישי שימוש נפוצים שאושרו:
תבנית 1: המוצר כולו, וכל רכיבי התמיכה שלו, פועלים באופן מלא על Google Cloud. תרשים הארכיטקטורה הבא מספק דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 2: מישור הנתונים או מישור החישוב של המוצר פועלים ב-Google Cloud, אבל מישורי בקרה קטנים יותר או תשתית תמיכה, כמו רישום ביומן או הסקת מסקנות מ-AI, פועלים במקום או בענן אחר. במקרה כזה, המשאב שצריכת המשאבים שלו גדלה הכי מהר כשהמשתמשים מגדילים את הצריכה הוא המשאב שמתארח ב-Google Cloudאו במישור הנתונים. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 3: המוצר לאחסון, גיבוי, שכפול או שחזור נתונים (DR) חייב לשכפל את כל הנתונים אל Google Cloud, בעוד מישור הבקרה של המוצר יכול לפעול במקום או בעננים אחרים. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 4: המוצר שלכם הוא כלי להעברת נתונים ש-Google Cloud הוא היעד היחיד להעברה, אבל אפשר להפעיל אותו במקום או בענן אחר כמקור להעברה. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 5: מישור הנתונים או מישור הבקרה של המוצר פועל ב-Google Cloud. סוכני המעקב או האבטחה של המוצר יכולים לפעול במקום או בענן אחר, אבל הם צריכים לשלוח נתונים לסביבה שמארחת אתGoogle Cloudלצורך אחסון וניתוח. תרשים הארכיטקטורה הבא מספק דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 6: המוצר שלכם הוא מערך נתונים שמתארח ב-Google Cloudומועבר דרכו. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 7: המוצר שלכם הוא מכונה וירטואלית (VM) או מוצר Kubernetes שנפרס ופועל במכשירים שמחוברים ל-Google Distributed Cloud. יכול להיות שהמוצר שלכם מתחבר לאינטרנט כדי להשתלב עם אפליקציות או שירותים אחרים שמתארחים ב- Google Cloud. תרשים הארכיטקטורה הבא מספק דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 8: המוצר שלכם הוא סוכן AI כשירות שרשום דרך Gemini Enterprise, וכל רכיבי התמיכה שלו, כולל סוכן ה-AI, פועלים באופן מלא ב- Google Cloud. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
תבנית 9: המוצר שלכם הוא סוכן AI כשירות שרשום דרך Gemini Enterprise, מוצר הליבה שלכם פועל ב- Google Cloud ומשתמש ב-Google foundational models או במודלים מ-Model Garden. מישורי בקרה קטנים יותר או תשתית תומכת, פועלים בארגון או בענן אחר. במקרה כזה, סוכןGoogle Cloud-hosted צריך להיות המשאב שצריכת הנתונים שלו גדלה הכי מהר כשהמשתמשים מגדילים את הצריכה. תרשים הארכיטקטורה הבא מספק דוגמה לדפוס הזה.
אפשר ללחוץ על התמונה כדי להגדיל אותה.
אתם צריכים לוודא שלמוצרים שלכם ב-Cloud Marketplace יש את אותן היכולות והתכונות כמו לגרסאות של המוצרים האלה שאתם מציעים מחוץ ל-Cloud Marketplace.
אתם צריכים לוודא שמוצרי הנתונים שלכם לא מכילים 'מידע רגיש שמאפשר זיהוי אישי' כהגדרתו בחוק להגנה על נתונים של אמריקאים מפני גורמים זרים עוינים משנת 2024.
אתם צריכים לוודא שהמוצרים שלכם עם רכיבים שפרוסים בפרויקטים בבעלות הלקוח ב- Google Cloud מיישמים מעקב אחר צריכה של דיירים של לקוחות בפתרונות SaaS, VM או Kubernetes.
הכרטיס שלכם צריך להוביל לצריכה משמעותית Google Cloud של הפתרון על ידי הלקוח שרוכש את הפתרון או משתמש בו.