כשמערכות יחסים עם (שירות טכנולוגי) לא מצליחות

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

החיים היו מדהימים… עד שזה לא היה כך יותר.

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

תאמין או לא, הקשר שלנו עם טכנולוגיה לא כל כך שונה.

להתפרק משירות

היה זמן כשחלטת לאמץ שירות – אולי זה היה SaaS, או PaaS, או משהו יותר כללי. בזמנו, האם לקחת את ההחלטה כשגם לקחת בחשבון את הזמן שבו כבר לא תתכוון להשתמש בשירות יותר? כנראה שלא. פשוט חשבת על כל האפשרויות הנפלאות לעתיד.

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

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

עוצמת חיבור ה-VPC

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

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

המושג הזה נקרא חיבור VPC, והוא מאפשר להקים חיבור פרטי מרשת אחרת.

דוגמת העברת שירותים

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

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

כך ייראה ההסדר החדש:

חיבור VPC עם הרוקו

כדי שהשירות החדש שלך (אפליקציית הרוקו) יוכל לגשת למקור הנתונים המקורי ב-AWS, תצטרך קודם להריץ את האפליקציה שלך בתוך חלל פרטי. למידע נוסף, תוכל לקרוא על אימוץ ענן מאובטח וגילוי חללי הרוקו הפרטיים שלי.

בהמשך, תצטרך לעמוד בדרישות הרשת הפשוטות הבאות:

• ה-VPC חייב להשתמש בחסימת CIDR IPv4 תואמת בהגדרת הרשת שלו.
• ה-VPC חייב להשתמש בחסימת CIDR RFC1918 (10.0.0.0/8, 172.16.0.0/12, או 192.168.0.0/16).
• חסימת ה-CIDR של ה-VPC לא יכולה לחפוף עם טווחי ה-CIDR של חלל הפרטי שלך. הטווחים המוגדרים כברירת מחדל הם 10.0.0.0/16, 10.1.0.0/16, ו-172.17.0.0/16.

עם חלל הפרטי שלך פעיל, תצטרך לאסוף את המידע על החיבור שלו:

$ heroku spaces:peering:info our-new-app

=== our-new-app Peering Info

AWS Account ID:    647xxxxxx317

AWS Region:        us-east-1

AWS VPC ID:        vpc-e285ab73

AWS VPC CIDR:      10.0.0.0/16

Space CIDRs:       10.0.128.0/20, 10.0.144.0/20, 10.0.0.0/20, 10.0.16.0/20

Unavailable CIDRs: 10.1.0.0/16

רשום את מספר חשבון AWS (647xxxxxx317) ואת מספר ה-VPC של AWS (vpc-e285ab73). תצטרך למסור את המידע הזה לספק צד שלישי ששולט במקור הנתונים של AWS. משם, הם יכולים להשתמש או בקונסולת AWS או ב-CLI כדי ליצור חיבור בין רשתות. הפעולה שלהם תיראה כך:

$ aws ec2 create-vpc-peering-connection \ 

  --vpc-id vpc-e527bb17 \

  --peer-vpc-id vpc-e285ab73 \

  --peer-owner-id 647xxxxxx317

{

    "VpcPeeringConnection": {

        "Status": {

            "Message": "Initiating Request to 647xxxxxx317",

            "Code": "initiating-request"

        },

        "Tags": [],

        "RequesterVpcInfo": {

            "OwnerId": "714xxxxxx214",

            "VpcId": "vpc-e527bb17",

            "CidrBlock": "10.100.0.0/16"

        },

        "VpcPeeringConnectionId": "pcx-123abc456",

        "ExpirationTime": "2025-04-23T22:05:27.000Z",

        "AccepterVpcInfo": {

            "OwnerId": "647xxxxxx317",

            "VpcId": "vpc-e285ab73"

        }

    }

}

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

$ heroku spaces:peerings our-new-app

בצילום המסך למטה, ניתן לראות את מצב קבלת הבקשה עבור החיבור בין הרשתות.

משם, תוכל לקבל את בקשת החיבור:

$ heroku spaces:peerings:accept pcx-123abc456 --space our-new-app

Accepting and configuring peering connection pcx-123abc456

נבדוק את מצב הבקשה בפעם השנייה:

$ heroku spaces:peerings our-new-app

אנו רואים שהחיבור פעיל.

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

סיכום

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

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

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

אימוץ גישה זו יאפשר לשירות החדש שלך לשגשג מבלי להפריע לשירות לצרכן.