Linkerd עושה עבודה טובה כאשר צוותים רוצים רשת שירותים קלה, ילידת Kubernetes. אך ככל שהמערכות גדלות, סדרי העדיפויות משתנים. מה שמתחיל כפתרון נקי יכול להפוך לשכבה נוספת שצוותים צריכים להפעיל, לאתר באגים ולהסביר. לפתע, אתם לא רק מספקים שירותים – אתם מנהלים התנהגות רשת, מדיניות ומקרים קיצוניים שמאטים את התהליך.

זה בדרך כלל הרגע שבו צוותים מתחילים לחפש חלופות. חלקם רוצים יותר נראות ללא רשת פנימית עמוקה. אחרים זקוקים לבקרת תעבורה פשוטה יותר, יכולת תצפית טובה יותר או פחות חלקים נעים בסך הכל. במדריך זה, אנו בוחנים חלופות ל-Linkerd מנקודת מבט מעשית – כלים המסייעים לצוותים לשמור על אמינות השירותים מבלי להפוך את התשתית לעבודה במשרה מלאה.

1. AppFirst

AppFirst ניגשת לבעיה מזווית שונה מזו של רשת שירותים מסורתית. במקום להתמקד במדיניות התעבורה או בהתנהגות ה-sidecar, הם דוחפים את הצוותים לחשוב פחות על התשתית כולה. הרעיון הוא שהמפתחים מגדירים את צרכי היישום – מעבד, רשת, מסדי נתונים, תמונת מכולה – ו-AppFirst מטפל בכל השאר. בפועל, זה לרוב מושך צוותים שהתחילו עם Kubernetes ו-Linkerd כדי לפשט את הרשת, ואז הבינו שהם עדיין משקיעים זמן רב בבדיקת שינויים בתשתית ובאיתור באגים בבעיות ספציפיות לענן.

מה שבולט הוא האופן שבו AppFirst מתייחסת לתשתית כאל משהו שמפתחים לא צריכים להרכיב חלק אחר חלק. אין ציפייה שהצוותים יכירו את Terraform, YAML או תבניות ספציפיות לענן. עבור צוות שאימץ במקור את Linkerd כדי להפחית את הרעש התפעולי, AppFirst יכול להיתפס כצעד נוסף באותו הכיוון – פחות חלקים נעים, פחות כלים פנימיים ופחות ויכוחים על איך צריך לחבר את הדברים זה לזה. זה פחות קשור לבקרת תעבורה מדויקת ויותר קשור לביטול הצורך לנהל את השכבה הזו בכלל.

נקודות עיקריות:

• מודל "יישום ראשון" במקום תצורה ברמת הרשת
• רישום, ניטור והתראות מובנים ללא צורך בהגדרות נוספות
• נתיב ביקורת מרכזי לשינויים בתשתית
• נראות עלויות מפורטת לפי יישום וסביבה
• פועל ב-AWS, Azure ו-GCP

למי זה מתאים ביותר:

• צוותי מוצר שרוצים להימנע לחלוטין מהפעלת רשת שירותים
• מפתחים שנמאס להם לתחזק את Terraform ותבניות הענן
• צוותים קטנים עד בינוניים ללא קבוצת פלטפורמה ייעודית
• חברות המיישמות סטנדרטיזציה של אופן פריסת האפליקציות בעננים

פרטי קשר:

• אֲתַר אִינטֶרנֶט: www.appfirst.dev

2. Istio

Istio הוא בדרך כלל השם הראשון שעולה כאשר צוותים עוברים מ-Linkerd. זהו רשת שירותים מלאה המרחיבה את Kubernetes עם ניהול תעבורה, אבטחה ונראות, אך היא גם מביאה איתה יותר החלטות ויותר שטח פנים. צוותים מגיעים לרוב לכאן לאחר ש-Linkerd מתחיל להרגיש מגביל, במיוחד כאשר הם זקוקים לכללי ניתוב מתקדמים, הגדרות מרובות-אשכולות או שליטה עמוקה יותר על התנהגות שירות-לשירות.

Istio יכול לפעול במצבים שונים, כולל הגישה הסביבתית החדשה יותר שלו, שמפחיתה את הצורך בסיידקרים. גמישות זו שימושית, אך היא גם מחייבת את הצוותים להבהיר אילו בעיות הם מנסים לפתור בפועל. Istio פועל בצורה הטובה ביותר כאשר כבר קיימת בשלות תפעולית מסוימת. הוא לא מסיר את המורכבות אלא מרכז אותה, מה שיכול להיות יתרון אם אתם זקוקים למדיניות עקבית בכל השירותים והסביבות.

נקודות עיקריות:

• ניתוב תעבורה מתקדם עבור פריסות קנריות ושלביות
• mTLS מובנה ואבטחת שירות מבוססת זהות
• נראות מעמיקה באמצעות מדדים וטלמטריה
• פועל בסביבות Kubernetes, VMs וסביבות היברידיות
• מודלים פריסה מרובים, כולל מצבי sidecar ו-ambient

למי זה מתאים ביותר:

• צוותים המפעילים סביבות Kubernetes גדולות או מרובות אשכולות
• ארגונים עם פלטפורמה ייעודית או בעלות SRE
• עומסי עבודה הדורשים בקרות תנועה ואבטחה מדויקות

פרטי קשר:

• אתר אינטרנט: istio.io
• טוויטר: x.com/IstioMesh
• LinkedIn: www.linkedin.com/company/istio

3. HashiCorp Consul

Consul נמצא איפשהו בין כלי גילוי שירותים קלאסי לרשת שירותים מלאה. אמנם ניתן להשתמש בו עם Kubernetes, אך הוא אינו קשור אליו, וזו לרוב הסיבה העיקרית שבגללה צוותים רואים ב-Consul חלופה ל-Linkerd. מקובל לראות את Consul מאומץ בסביבות שבהן חלק מהשירותים פועלים ב-Kubernetes, אחרים פועלים במכונות וירטואליות, וכמה מהם עדיין פועלים בתצורות ישנות יותר שלא ניתן להעביר בקלות.

תכונות הרשת קיימות, כולל mTLS, פיצול תעבורה ושרתי proxy מבוססי Envoy, אך הן אופציונליות ולא חובה. צוותים מסוימים משתמשים ב-Consul בעיקר לאיתור שירותים ומטמיעים בהדרגה את תכונות הרשת לאורך זמן. גישה הדרגתית זו יכולה להיות שימושית כאשר החלפת Linkerd משמעותה שינוי גדול ודרמטי. החיסרון הוא ש-Consul מציג מושגי מישור בקרה משלו, שלוקח זמן להבין אם הצוותים מגיעים מרקע של Kubernetes בלבד.

נקודות עיקריות:

• גילוי שירותים ותכונות רשת בפלטפורמה אחת
• תומך ב-Kubernetes, מכונות וירטואליות ופריסות היברידיות
• אבטחת שירות מבוססת זהות עם mTLS
• ניהול תעבורה L7 באמצעות פרוקסי Envoy
• פועל בסביבות מקומיות, מרובות עננים והיברידיות

למי זה מתאים ביותר:

• צוותים המפעילים שירותים בסביבות מעורבות
• ארגונים שאינם יכולים לבצע סטנדרטיזציה באמצעות Kubernetes בלבד
• פלטפורמות המעוניינות בשירותי גילוי ורשתות משולבות במערכת אחת

פרטי קשר:

• אתר אינטרנט: developer.hashicorp.com/consul
• פייסבוק: www.facebook.com/HashiCorp
• טוויטר: x.com/hashicorp
• לינקדאין: www.linkedin.com/company/hashicorp

4. קומה

Kuma ממוקמת כרשת שירותים לשימוש כללי, שאינה מניחה שהכל מתקיים בתוך Kubernetes. צוותים נוטים לבחון אותה כאשר Linkerd מתחיל להיראות כמו מוצר המיועד אך ורק ל-Kubernetes, במיוחד אם עדיין קיימים מכונות וירטואליות או עומסי עבודה מעורבים בתמונה. Kuma פועלת על גבי Envoy ומשמשת כמישור בקרה הפועל על פני אשכולות Kubernetes, מכונות וירטואליות או שניהם בו-זמנית. גמישות זו נוטה להיות חשובה יותר בסביבות אמיתיות מאשר בתרשימי ארכיטקטורה.

מבחינה תפעולית, Kuma נוטה להגדרות מונחות מדיניות ולא לכוונון מתמיד. מדיניות L4 ו-L7 מובנות בתוכנה, וצוותים אינם צריכים להיות מומחים ב-Envoy כדי להגדיר ניתוב, אבטחה או נראות בסיסיים. דפוס נפוץ הוא צוות פלטפורמה המפעיל מישור בקרה אחד, בעוד צוותי מוצר שונים פועלים בתוך רשתות נפרדות. זו אינה האפשרות הקלה ביותר, אך היא נבחרת לעתים קרובות כאשר יש צורך להגדיל את הפשטות מעבר לאשכול בודד.

נקודות עיקריות:

• פועל בסביבות Kubernetes, VMs וסביבות היברידיות
• מדיניות תעבורה L4 ו-L7 מובנית
• תמיכה ברשתות מרובות ממטוס בקרה יחיד
• Envoy כלול כברירת מחדל, ללא הגדרת פרוקסי נפרדת
• GUI, CLI ו-REST API זמינים

למי זה מתאים ביותר:

• צוותים המפעילים הן Kubernetes והן שירותים מבוססי VM
• ארגונים הזקוקים להגדרות מרובות אשכולות או מרובות אזורים
• צוותי פלטפורמה התומכים במספר קבוצות מוצרים
• סביבות שבהן Linkerd מרגיש צר מדי בהיקפו

פרטי קשר:

• אתר אינטרנט: kuma.io
• טוויטר: x.com/KumaMesh

5. רשת Traefik

Traefik Mesh נוקט בגישה שונה באופן ניכר בהשוואה ל-Linkerd ולרשתות אחרות. במקום הזרקת sidecar, הוא מסתמך על מודל אופציונלי יותר, המונע את הצורך בשינוי כל פוד. הדבר הופך אותו לאטרקטיבי עבור צוותים המעוניינים בנראות של תעבורת השירות מבלי להתחייב לפריסה מלאה של הרשת בכל האשכול. ההתקנה נוטה להיות מהירה, וזה לרוב הדבר הראשון שאנשים מבחינים בו כאשר הם בודקים את התוכנה.

מערכת התכונות מתמקדת בנראות התעבורה, ניתוב ואבטחה בסיסית, ולא באכיפת מדיניות מעמיקה. Traefik Mesh מבוסס על Traefik Proxy, ולכן הוא מרגיש מוכר לצוותים שכבר משתמשים ב-Traefik עבור כניסה. הוא לא תוכנן לניהול מורכב של ריבוי אשכולות, אך הוא עובד היטב כשכבה קלה כאשר Linkerd מרגיש כמו מכונה גדולה יותר ממה שהצוות באמת צריך.

נקודות עיקריות:

• אין צורך בהזרקת סירה
• נבנה על גבי Traefik Proxy
• תמיכה מובנית בתעבורת HTTP ו-TCP
• מדדים ומעקב עם Prometheus ו-Grafana
• בקרת תנועה וגישה תואמת SMI
• התקנה פשוטה מבוססת Helm

למי זה מתאים ביותר:

• צוותים המעוניינים ברשת שירותים עם מחויבות נמוכה
• אשכולות Kubernetes שבהם יש חשש לבעיות עם sidecars
• פלטפורמות קטנות יותר שהתמקדו בנראות התעבורה על פני עומק המדיניות

פרטי קשר:

• אתר אינטרנט: traefik.io
• טוויטר: x.com/traefik
• LinkedIn: www.linkedin.com/company/traefik

6. רשת VPC של אמזון

Amazon VPC Lattice נוקט בגישה שונה מרוב החלופות ל-Linkerd. במקום לפעול כמו רשת שירותים מסורתית עם sidecars, הוא פועל כשכבת רשת שירותים המנוהלת על ידי AWS. הוא מחבר שירותים בין VPCs, חשבונות וסוגי מחשוב מבלי לדרוש הזרקת פרוקסי לכל עומס עבודה. דבר זה לבדו משנה את האופן שבו צוותים תופסים את התקשורת בין שירותים.

בפועל, VPC Lattice מושך לעתים קרובות צוותים המעוניינים בהתנהגות דמוית רשת מבלי להפעיל רשת. ניתוב תעבורה, מדיניות גישה וניטור מטופלים באמצעות מבנים מקוריים של AWS, מה שמבטיח עקביות עם IAM ושירותי AWS אחרים. החיסרון הוא שהמערכת נשארת בתוך AWS. עבור צוותים שכבר מחויבים לשירות זה, הדבר מקובל בדרך כלל.

נקודות עיקריות:

• אין צורך בפרוקסי סיידקאר
• קישוריות מנוהלת בין שירותים ב-AWS
• פועל על פני VPC, חשבונות וסוגי מחשוב
• משולב עם AWS IAM לבקרת גישה
• תומך ב-TCP ובניתוב שכבת היישום

למי זה מתאים ביותר:

• ארגונים המתקדמים מבלי לאמץ תוספות
• סביבות המשלבות מכולות, מופעים ושרתים ללא שרתים
• צוותים המחליפים את Linkerd כדי להפחית את עלויות התפעול

פרטי קשר:

• אתר אינטרנט: aws.amazon.com
• פייסבוק: www.facebook.com/amazonwebservices
• טוויטר: x.com/awscloud
• לינקדאין: www.linkedin.com/company/amazon-web-services
• אינסטגרם: www.instagram.com/amazonwebservices

7. ריסים

Cilium ניגש לבעיית רשת השירותים מנקודת מבט של "רשתות תחילה" ולא מנקודת מבט של "פרוקסי תחילה". במקום להסתמך לחלוטין על פרוקסי סיידקאר, הוא משתמש ב-eBPF בתוך קרנל לינוקס כדי לטפל בקישוריות השירותים, באבטחה ובנראות. זו הסיבה שבגללה Cilium נכנס לתמונה כאשר צוותים מרגישים ש-Linkerd מוסיף עומס או חביון יתר על המידה, במיוחד באשכולות עם נפחי תעבורה גבוהים.

מה שהופך את Cilium למעניין כחלופה ל-Linkerd הוא שתכונות רשת השירות הן אופציונליות וגמישות. צוותים מסוימים מתחילים להשתמש בו עבור רשתות Kubernetes ומדיניות רשת, ולאחר מכן מפעילים בהדרגה את יכולות הרשת. אחרים מאמצים אותו במיוחד כדי להימנע לחלוטין משימוש ב-sidecars. עם זאת, עקומת הלמידה שונה. איתור באגים מתקרב לרמת הקרנל, מה שחלק מהצוותים אוהבים ואחרים מוצאים לא נוח בהתחלה.

נקודות עיקריות:

• רשת שירות מבוססת eBPF ללא sidecars חובה
• מטפל בפרוטוקולי רשת ויישומים יחד
• פועל ב-L3 עד L7 בהתאם לתצורה
• אפשרויות גמישות של מישור הבקרה, כולל שילוב Istio

למי זה מתאים ביותר:

• צוותים הרגישים לעומס פרוקסי
• פלטפורמות Kubernetes שכבר משתמשות ב-Cilium לצורך תקשורת
• סביבות עם אשכולות גדולים או תפוקה גבוהה
• מהנדסים שמרגישים בנוח לעבוד קרוב יותר לשכבת מערכת ההפעלה

פרטי קשר:

• אתר אינטרנט: cilium.io
• LinkedIn: www.linkedin.com/company/cilium

8. קונג מש

Kong Mesh מבוסס על Kuma ומציע גישה מובנית יותר לתפעול רשת שירותים. הוא תומך בעומסי עבודה מבוססי Kubernetes ו-VM ומתמקד בבקרה מרכזית על פני אזורים או סביבות מרובים. צוותים נוטים לפנות ל-Kong Mesh כאשר Linkerd מתחיל להיראות מוגבל מדי עבור תצורות בין-אשכולות או היברידיות, במיוחד כאשר בקרה וניהול גישה הופכים לדאגות יומיומיות.

מבחינה תפעולית, Kong Mesh מרגיש כבד יותר מ-Linkerd, אך גם מחושב יותר. מדיניות לגבי ניסיונות חוזרים, mTLS וניתוב תעבורה מתבצעת ברמת הפלטפורמה, במקום שכל צוות יפתור אותה שוב ושוב. ארגונים מסוימים משתמשים בו יחד עם Kong Gateway, בעוד שאחרים מתייחסים אליו כאל רשת בלבד. כך או כך, הוא נוטה להופיע בסביבות שבהן צוותי הפלטפורמה מעדיפים עקביות על פני מינימליזם.

נקודות עיקריות:

• פועל בסביבות Kubernetes ו-VM
• mTLS מובנה, ניהול תעבורה וגילוי שירותים
• תמיכה ברשת רב-אזורית ורב-דיירית
• אפשרויות מישור בקרה מרכזי, כולל SaaS או אירוח עצמי

למי זה מתאים ביותר:

• צוותי פלטפורמה המנהלים מספר אשכולות או אזורים
• ארגונים עם עומסי עבודה היברידיים או מבוססי VM
• סביבות הזקוקות לניהול חזק יותר מזה שמציע Linkerd
• צוותים שמוכנים להחליף פשטות תמורת שליטה מרכזית

פרטי קשר:

• אתר אינטרנט: konghq.com
• טוויטר: x.com/kong
• LinkedIn: www.linkedin.com/company/konghq

9. רשת השירותים OpenShift של Red Hat

OpenShift Service Mesh קשור קשר הדוק לפלטפורמת OpenShift ועוקב אחר דפוס מוכר לצוותים שכבר מריצים שם עומסי עבודה. מאחורי הקלעים, הוא מבוסס על Istio, Envoy ו-Kiali, אך ארוז באופן המתאים לתפיסתה של Red Hat לגבי פעולות אשכולות. עבור צוותים שעוברים מ-Linkerd, לעתים קרובות זה מרגיש פחות כמו מעבר בין כלים ויותר כמו כניסה לבחירה רחבה יותר של פלטפורמות.

בפועל, השאלה העולה בדרך כלל היא כמה ממחזור החיים של הרשת כבר משולב ב-OpenShift עצמו. ההתקנה, השדרוגים והנראות מתקיימים לצד תכונות אחרות של OpenShift, מה שיכול לצמצם את מספר לוחות המחוונים הנפרדים שצוותים צריכים לבדוק. במקביל, הדבר מניח שאתם מרגישים בנוח להתחייב ל-OpenShift כסביבת הריצה. פשרה זו מתאימה לצוותים מסוימים, אך מגבילה צוותים אחרים.

נקודות עיקריות:

• מבוסס על Istio ו-Envoy עם אינטגרציה מקורית של OpenShift
• לוחות מחוונים מרכזיים באמצעות OpenShift ו-Kiali
• תומך בהגדרות רשת שירות מרובות אשכולות
• מדיניות mTLS וניהול תעבורה מובנית

למי זה מתאים ביותר:

• ארגונים המעוניינים בפעולות רשת המותאמות לכלי הפלטפורמה
• סביבות שבהן מחזור החיים של אשכולות נמצא תחת בקרה הדוקה
• קבוצות המחליפות את Linkerd כחלק מהשקת OpenShift רחבה יותר

פרטי קשר:

• אתר אינטרנט: www.redhat.com
• דוא"ל: apac@redhat.com
• פייסבוק: www.facebook.com/RedHat
• טוויטר: x.com/RedHat
• לינקדאין: www.linkedin.com/company/red-hat
• כתובת: 100 E. Davie Street Raleigh, NC 27601, ארה"ב
• טלפון: 888 733 4281

10. רשת Gloo

Gloo Mesh מתמקד פחות בהיותו רשת עצמה ויותר בניהול רשתות מבוססות Istio על פני אשכולות וסביבות. הוא נכנס לתמונה לעתים קרובות כאשר Linkerd מתחיל להרגיש מוגבל מדי עבור הגדרות מרובות אשכולות או כאשר צוותים מתקשים לשמור על עקביות בפריסות Istio. במקום לשכתב את אופן פעולת הרשת, Gloo Mesh יושב מעל ומטפל במחזור החיים, הנראות והמדיניות על פני סביבות.

דבר אחד שבולט הוא האופן שבו הוא תומך הן בדגמים עם סיידקאר והן בדגמים ללא סיידקאר באמצעות מצב הסביבה של Istio. גמישות זו נוטה למשוך צוותי פלטפורמה המתמודדים עם צרכים שונים של יישומים בו-זמנית. בשימוש יומיומי, Gloo Mesh נמצא בדרך כלל בבעלות צוות מרכזי ולא צוותי שירות בודדים, מה שמשנה את אופן קבלת ההחלטות בנוגע לניתוב ואבטחה.

נקודות עיקריות:

• נראות רב-אשכולית ורב-סביבתית
• ניהול מרכזי של מדיניות ושל מחזור החיים
• תומך בדגמים עם סירה ובדגמים ללא סירה
• דגש חזק על עקביות תפעולית

למי זה מתאים ביותר:

• צוותי פלטפורמה המפעילים Istio בקנה מידה גדול
• ארגונים המנהלים אשכולות או אזורים רבים
• צוותים שעוברים מ-Linkerd לטופולוגיות מורכבות יותר

פרטי קשר:

• אתר אינטרנט: www.solo.io
• טוויטר: x.com/soloio_inc
• LinkedIn: www.linkedin.com/company/solo.io

11. רשת השירותים Flomesh

Flomesh Service Mesh, המכונה לעתים FSM, נועד לצוותים שמעניקים חשיבות רבה לביצועים ולגמישות חומרה. הוא משתמש בפרוקסי מישור נתונים בשם Pipy, שנכתב ב-C++, אשר מופיע במהירות כאשר צוותים מריצים אשכולות צפופים או עומסי עבודה בקצה, שבהם השימוש במשאבים הוא בעל חשיבות רבה. בהשוואה ל-Linkerd, FSM נוטה להיות יותר מעשי וניתן להגדרה, במיוחד כאשר צוותים מתחילים לעבוד עם תעבורה מעבר ל-HTTP בסיסי.

פרט נוסף המשפיע על אופן השימוש ב-FSM הוא הפתיחות שלו להרחבה. מישור הנתונים כולל מנוע JavaScript, מה שאומר שצוותים יכולים לשנות את ההתנהגות מבלי לבנות מחדש את כל הרשת. זה אטרקטיבי בסביבות שבהן כללי הרשת משתנים לעתים קרובות או שבהן נעשה שימוש בפרוטוקולים יוצאי דופן. FSM מתאים גם להתקנות Kubernetes מרובות-אשכולות, ולכן הוא מופיע בדרך כלל בשיחות שבהן אשכול אחד כבר אינו מספיק ודפוסי התעבורה מתחילים להתפשט.

נקודות עיקריות:

• פרוקסי Pipy המיועד לשימוש נמוך במשאבים
• תומך ב-x86, ARM64 וארכיטקטורות אחרות
• תמיכה ב-Kubernetes רב-אשכולית באמצעות MCS-API
• בקרי API מובנים לכניסה, יציאה ושער
• תמיכה בפרוטוקולים רחבה מעבר ל-HTTP סטנדרטי

למי זה מתאים ביותר:

• צוותים המפעילים אשכולות Kubernetes גדולים או בצפיפות גבוהה
• סביבות עם ARM או חומרה מעורבת
• פלטפורמות הדורשות התנהגות תנועה מותאמת אישית

פרטי קשר:

• אתר אינטרנט: flomesh.io
• דוא"ל: contact@flomesh.cn
• טוויטר: x.com/pipyproxy

12. רשת אספן

Aspen Mesh הוא רשת שירותים מבוססת Istio שתוכננה עם דגש על ספקי שירותים, במיוחד אלה הפועלים בתחום התקשורת ובסביבות מוסדרות. היא מופיעה לרוב בפרויקטים של מעבר מ-4G ל-5G, שבהם מיקרו-שירותים הם חלק ממערכת גדולה בהרבה ונראות התעבורה אינה אופציונלית. בהשוואה ל-Linkerd, Aspen Mesh מתמקדת פחות בקלות המשקל ויותר ביכולת החיזוי והבדיקה.

אחד ההבדלים המעשיים יותר הוא ההתמקדות בבדיקת תעבורה וניהול אישורים. Aspen Mesh כולל כלים המאפשרים למפעילים לראות את התעבורה ברמת השירות וברמת המנוי, דבר החשוב כאשר תאימות, חיוב או פתרון בעיות קשורים להתנהגות הרשת. בדרך כלל הוא מופעל על ידי צוותי פלטפורמה או רשת מרכזיים ולא על ידי מפתחי יישומים, והוא מתאים יותר לסביבות שבהן Kubernetes הוא רק חלק מתשתית גדולה יותר.

נקודות עיקריות:

• מבוסס על Istio עם כלים תפעוליים נוספים
• מיועד להתקנות מרובות אשכולות ומרובות דיירים
• בדיקת מנות לתצוגה מפורטת של התעבורה
• דגש חזק על ניהול תעודות וזהויות
• תומך ברשתות IPv4 ו-IPv6 עם ערימה כפולה

למי זה מתאים ביותר:

• פלטפורמות של ספקי שירותי תקשורת
• סביבות מוסדרות עם דרישות נראות קפדניות
• צוותים המנהלים מעבר מ-4G ל-5G
• ארגונים המפעילים אשכולות גדולים מרובי דיירים

פרטי קשר:

• אתר אינטרנט: www.f5.com/products/aspen-mesh
• פייסבוק: www.facebook.com/f5incorporated
• טוויטר: x.com/f5
• לינקדאין: www.linkedin.com/company/f5
• אינסטגרם: www.instagram.com/f5.global
• כתובת: 801 5th Ave Seattle, Washington 98104 ארצות הברית
• טלפון: 800 11275 435

13. חומר אפור

Greymatter ניגשת לרשת השירותים מזווית שונה מזו של רוב החלופות ל-Linkerd. במקום להתחיל עם פרוקסי וכללי ניתוב, היא מתמקדת בקישוריות ובאבטחה ברמת עומסי העבודה בסביבות שכבר מפוצלות. זה קורה בדרך כלל בארגונים גדולים יותר, שבהם השירותים פועלים בעננים מרובים, במערכות מקומיות או בסביבות מוסדרות, שבהן תצורה ידנית פשוט אינה ניתנת להרחבה. במקרים אלה, Greymatter מחליפה לעתים קרובות שילוב של רשתות חלקיות, סקריפטים מותאמים אישית וכלי רשת קצה, במקום תצורה אחת נקייה.

מה שבולט בשימוש היומיומי הוא עד כמה התנהגות הרשת מונעת על ידי אוטומציה במקום על ידי כוונון מתמיד. מדיניות, אישורים וחיבורי שירות מנוהלים באופן מרכזי, מה שמפחית את הצורך של הצוותים להתעסק עם הפנים של הרשת. בהשוואה ל-Linkerd, זה מרגיש פחות מכוון למפתחים ויותר מונע על ידי תשתית. זה לא מנסה להיות קל משקל או בלתי נראה. זה מיועד לסביבות שבהן נראות, יכולת ביקורת ועקביות חשובות יותר מאשר שמירה על טביעת רגל קטנה.

נקודות עיקריות:

• קישוריות שירות מרכזית בסביבות ענן ובסביבות מקומיות
• זהות ברמת עומס העבודה ותקשורת שירות מוצפנת
• ניהול אוטומטי של אישורים ומדיניות
• נראות מעמיקה המתמקדת בהתנהגות היישומים ולא בתעבורת הקצה
• מיועד לפריסות מרובות עננים והיברידיות

למי זה מתאים ביותר:

• ארגונים המפעילים שירותים בעננים מרובים
• סביבות עם דרישות אבטחה או תאימות מחמירות
• צוותי פלטפורמה המחליפים פעולות רשת ידניות

פרטי קשר:

• אתר אינטרנט: greymatter.io
• פייסבוק: www.facebook.com/greymatterio
• טוויטר: x.com/greymatterio
• LinkedIn: www.linkedin.com/company/greymatterio
• כתובת: 4201 Wilson Blvd, קומה 3, ארלינגטון, VA 22203

 

מַסְקָנָה

Linkerd הוא לרוב המקום שבו צוותים מתחילים, ולא המקום שבו הם מסיימים. ככל שהמערכות גדלות, השאלות משתנות. צוותים מסוימים זקוקים לשליטה הדוקה יותר על פני אשכולות. אחרים מעוניינים בפחות חלקים נעים, או בפחות עבודה ברמת הפלטפורמה. החלופות המוצגות כאן משקפות את היתרונות והחסרונות הללו יותר מאשר כל רעיון בודד לגבי מה שצריך להיות רשת שירותים.

הדבר החשוב ביותר הוא להיות כנה לגבי אופן העבודה של הצוות שלך כיום. אם הרשת דורשת תשומת לב מתמדת, היא מפסיקה להיות לעזר. אם היא נעלמת ברקע ועדיין מבצעת את תפקידה, זה בדרך כלל סימן שבחרת בכיוון הנכון. אין כאן אפשרות מושלמת, רק כלים שמתאימים לסביבות מסוימות יותר מאשר לאחרים.