S3-compatible, באמת

“S3-compatible” מודפס על כל עמוד object storage באינטרנט. זה כמעט לא אומר כלום. השאלה המעניינת היא לא אם אתם יכולים לעשות PutObject — אלא אם תוכלו אי פעם להוציא את כל האובייקטים שלכם החוצה וללכת.

זה החלק שאף אחד לא שם על עמוד השיווק. אז בואו נדבר עליו.

ה-API של S3 הוא הסטנדרט, וזה בסדר גמור

אין ועדת ISO ל-object storage. מה שקרה במקום זה שאמזון שחררה HTTP API ב-2006, כולם כתבו clients מולו, וה-API הפך לסטנדרט דה-פקטו בכוח הכבידה לבדו. aws s3, boto3, s3cmd, rclone, mc, ה-SDKs של Go ו-Rust ו-JS — כולם מדברים אותו ניב. תכוונו אותם ל-endpoint אחר והם פשוט יעבדו ברובם.

זו תוצאה טובה באמת. פרוטוקול תקשורת יציב שתריסר מימושים עצמאיים מכוונים אליו הוא הדבר שעליו ניידות נבנית. כשמישהו אומר “S3-compatible”, הוא מבטיח לכבד את החוזה הזה.

הבעיה היא שהחוזה גדול, ו”compatible” עושה הרבה עבודה בשקט.

מה תאימות אמיתית באמת אומרת

כל אחד יכול לממש GET, PUT ו-DELETE על bucket. זה תנאי סף, לא תאימות. הפיצ’רים שקובעים אם אתם באמת יכולים לזוז הם המשעממים:

• Clients וחתימות. האם אימות SigV4 עובד עם ה-SDKs הסטנדרטיים, ללא שינוי, רק על ידי החלפת כתובת ה-endpoint? או שאתם צריכים fork מיוחד של הספק?
• Signed URLs. כתובות GET/PUT חתומות מראש הן הדרך שבה חצי מהאינטרנט מעלה קבצים. אם הן לא ממומשות באותו אופן, כל טופס העלאה שכתבתם נשבר במעבר.
• Versioning. אם האפליקציה שלכם נשענת על גרסאות אובייקט והמקום החדש לא חושף אותן, אתם לא רק מעבירים נתונים — אתם מאבדים היסטוריה.
• כללי Lifecycle. תפוגה, מעברים, abort-incomplete-multipart. אלה מקודדים לוגיקה עסקית אמיתית. אם הם לא עוברים, אתם משכתבים מדיניות ביד.
• Multipart uploads. אובייקטים גדולים תלויים בזה. הבדלים עדינים בגבולות גודל ה-part או בהתנהגות ה-ETag צפים כקבצים פגומים בשלוש לפנות בוקר.

תאימות היא כל המשטח שהקוד שלכם כבר נוגע בו — לא שלוש הפעולות שבדמו.

איך ניידות הופכת בשקט למצב של בני ערובה

הנה המהלך. ספק מדבר S3 מספיק טוב כדי להכניס אתכם בדלת. ואז הוא מצמיד פיצ’רים קנייניים של “ערך מוסף” — שכבת query ייעודית, pipeline אירועים מיוחד, הרחבת SDK, גאדג’ט lifecycle שזמין רק ב-console — ומעודד אתכם לבנות עליהם. כל אחד מהם נוח באמת. כל אחד מהם הוא גם חוט שתופר אתכם לאותו ספק.

אתם לא שמים לב עד שאתם מנסים לעזוב. ה-buckets שלכם עדיין “S3-compatible”, בטח. אבל האפליקציה שלכם עכשיו תלויה בשלושה דברים שקיימים רק שם.

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

ניידות שאפשר לבדוק, לא רק לסמוך עליה

בנינו את ה-object storage של Kaligon Cloud להיות משעמם באופן שחשוב. הוא מדבר את ה-API של S3. תכוונו כל S3 client ל-endpoint — aws-cli, rclone, boto3, מה שכבר יש לכם — וזה עובד. Versioning, כללי lifecycle ו-signed URLs מתנהגים כמו שהסטנדרט אומר שהם צריכים, כי הסטנדרט הוא המוצר, לא משבצת סימון בשיווק.

החלק שהופך את הניידות לאמיתית: אין דמי egress בין משאבי Kaligon באותו region, ותעריף שטוח יחיד ל-egress יוצא לאינטרנט. העברת נתונים בין ה-buckets וה-instances שלכם עצמכם לא עולה כלום. עזיבה לא הופכת יקרה יותר ככל שהנתונים שלכם גדלים. התמחור הוא מחיר שטוח אחד למשאב — בלי שכבות committed-use שמעלות בשקט את העלות של שינוי דעתכם. אפשר לראות את זה בעמוד התמחור.

אז אל תסמכו עלינו — בדקו אותנו. הריצו rclone copy מול bucket של Kaligon ושל מתחרה, בשני הכיוונים, וצפו במונה. כל הרעיון של סטנדרט הוא שאתם לא צריכים לסמוך על המילה של אף אחד.