כדי להציע מוצרים ב-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
המוצר כולו, וכל רכיבי התמיכה שלו, פועלים באופן מלא ב-Google Cloud. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
תבנית 2: מישור הבקרה או מישור הנתונים ב- Google Cloud
מישור הנתונים או מישור החישוב של המוצר פועלים ב- Google Cloud, אבל מישורי בקרה קטנים יותר או תשתית תומכת, כמו יומנים או הסקת מסקנות מ-AI, פועלים במקום או בענן אחר. במקרה כזה, המשאב שצריכת המשאבים שלו גדלה הכי מהר כשהמשתמשים מגדילים את הצריכה הוא המשאב שמתארח ב-Google Cloudאו במישור הנתונים. תרשים הארכיטקטורה הבא מספק דוגמה לדפוס הזה.
תבנית 3: אחסון וגיבוי ב- Google Cloud
מוצר האחסון, הגיבוי, השכפול או שחזור הנתונים (DR) חייב לשכפל את כל הנתונים אל Google Cloud, בעוד שמישור הבקרה של המוצר יכול לפעול במקום או בעננים אחרים. תרשים הארכיטקטורה הבא מספק דוגמה לדפוס הזה.
תבנית 4: מעבר אל Google Cloud
המוצר שלכם הוא כלי להעברה ש Google Cloud היעד היחיד שלו להעברה הוא Google Cloud, אבל הוא יכול לפעול בפריסה מקומית או בענן אחר כמקור להעברה. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
תבנית 5: ניתוח נתוני סוכנים ב- Google Cloud
מישור הנתונים או מישור הבקרה של המוצר פועלים ב- Google Cloud. סוכני המעקב או האבטחה של המוצר יכולים לפעול במקום או בענן אחר, אבל הם חייבים לשלוח נתונים לסביבה באירוח Google Cloudלצורך אחסון וניתוח. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
תבנית 6: מערכי נתונים שמתארחים ב Google Cloud
המוצר שלך הוא מערך נתונים שמתארח ב-Google Cloudומועבר דרכו. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
תבנית 7: פריסה ב-Google Distributed Cloud
המוצר שלכם הוא מכונה וירטואלית (VM) או מוצר Kubernetes שנפרס במכשירים שמחוברים ל-Google Distributed Cloud ופועל בהם. יכול להיות שהמוצר שלכם מתחבר לאינטרנט כדי להשתלב עם אפליקציות או שירותים אחרים שמתארחים ב-Google Cloud. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
תבנית 8: סוכני AI שמתארחים ב- Google Cloud
המוצר שלכם הוא סוכן AI כשירות שרשום דרך Gemini Enterprise, וכל רכיבי התמיכה שלו, כולל סוכן ה-AI, פועלים באופן מלא ב- Google Cloud. בתרשים הארכיטקטורה הבא מוצגת דוגמה לדפוס הזה.
תבנית 9: סוכני AI עם תשתית היברידית
המוצר שלכם הוא סוכן AI כשירות שרשום דרך Gemini Enterprise, מוצר הליבה שלכם פועל ב- Google Cloud ומשתמש במודלים בסיסיים של Google או במודלים מ-Model Garden. מישורי בקרה קטנים יותר או תשתית תומכת, פועלים בארגון או בענן אחר. במקרה כזה, סוכןGoogle Cloud-hosted צריך להיות המשאב שצריכת הנתונים שלו גדלה הכי מהר כשהמשתמשים מגדילים את הצריכה. תרשים הארכיטקטורה הבא מספק דוגמה לדפוס הזה.
דרישות נוספות לגבי מוצרים
- אתם צריכים לוודא שלמוצרים שלכם ב-Cloud Marketplace יש את אותן יכולות ותכונות כמו לגרסאות של המוצרים האלה שאתם מציעים מחוץ ל-Cloud Marketplace.
- אתם צריכים לוודא שמוצרי הנתונים שלכם לא מכילים "מידע רגיש שמאפשר זיהוי אישי" כהגדרתו בחוק Protecting Americans' Data from Foreign Adversaries Act (הגנה על נתונים של אמריקאים מפני גורמים זרים עוינים) משנת 2024.
- אתם צריכים לוודא שהמוצרים שלכם עם רכיבים שפרוסים בפרויקטים בבעלות הלקוח Google Cloud מטמיעים מעקב אחר צריכה של דייר לקוח עבור פתרונות SaaS, VM או Kubernetes.
- הרישום שלכם צריך להוביל לצריכה משמעותית Google Cloud על ידי הלקוח שרוכש את הפתרון או משתמש בו.