לבנות מחדש את היישום שהופך כל שחרור לסיכון
פיתוח Cloud-Native הוא תכנון ובנייה של תוכנה שתרוץ על שירותי ענן מנוהלים, תוך שימוש בקונטיינרים ובגבולות שירותים במקום שבו התכנון דורש אותם. SEYA Group בונה כך מוצרים חדשים ומבצעת ריפקטורינג ליישומים קיימים, עבור צוותים שהתוכנה שלהם עובדת אך הפכה איטית מדי או מסוכנת מדי לשינוי.
למי זה מיועד
מנהלי טכנולוגיות (CTO) וסמנכ"לי הנדסה שבבעלותם יישום שמייצר הכנסות ושכל שחרור שלו נחשב לסיכון. ארכיטקטי פתרונות שהתבקשו לפצל מונוליט ורוצים חוות דעת שנייה על מיקום התפרים. מנהלי IT שהיישום שלהם הועלה לענן כמות שהוא ועדיין נושא את הנחות מרכז הנתונים, כך שחשבון הענן עלה וקצב השחרורים לא השתנה.
אם אתם צריכים להעביר עומסי עבודה רבים בשינוי מינימלי, זו פלטפורמת ענן והגירה. הדף הזה מיועד ליישום שהתכנון שלו צריך להשתנות.
בעיות שאנחנו פותרים
- מוצר שאי אפשר לשנות בבטחה כי כל חלק תלוי בכל חלק אחר.
- בסיס קוד שעוצב סביב שרתים קבועים, דיסקים משותפים או מסד נתונים יחיד שאינו יכול לגדול.
- מסלול שחרור שמניח יחידת פריסה אחת, סביבה אחת וחלון תחזוקה.
- שירות חדש שצריך להיבנות ואין דפוס מוסכם לאופן שבו בונים שירותים אצלכם.
- אינטגרציות מחווטות ידנית שנשברות כשאחד הצדדים משתנה.
מה תקבלו
- תכנון יעד. כיצד היישום מתפצל לשירותים, היכן קונטיינרים, Kubernetes, פונקציות Serverless או סביבת ריצה פשוטה יותר מתאימים, ואילו שירותים מנוהלים מחליפים את מה שאתם מפעילים בעצמכם.
- תוכנה עובדת. המוצר החדש או היישום לאחר הריפקטורינג, שנבנה יחד עם המהנדסים שלכם, במאגרי הקוד שלכם, על חשבונות הענן שלכם.
- מסלול מסירה. ה-Pipeline לבנייה, בדיקה ושחרור של השירותים האלה, כך שכל אחד מהם משתחרר בנפרד.
- ממשקים. גבולות API ואינטגרציה שמערכות אחרות יכולות לקרוא להם באופן עקבי, מתועדים עבור הצוותים שצורכים אותם.
- תוכנית מעבר. בריפקטורינג, הצהרה כתובה אילו התנהגויות חייבות להמשיך לעבוד וכיצד התעבורה עוברת מהישן לחדש.
איך הפרויקט מתנהל
- שיחת ארכיטקטורה. אתם מציגים לנו את היישום, את המגבלה שהוא יוצר ואת ההתנהגות שאסור לה להישבר.
- תכנון. אנחנו קוראים את הקוד ואת ההיסטוריה התפעולית יחד עם הצוות שלכם, מציעים גבולות שירותים וסביבת ריצה, ומסכמים על התוספת הראשונה.
- בנייה בתוספות. השירותים נבנים, נבדקים ומשוחררים אחד אחד, כשהמהנדסים שלכם עובדים בזוגות על העבודה כדי שהדפוסים ייקלטו.
- מעבר ומסירה. התעבורה עוברת לפי התוכנית, המסלול הישן מושבת כשאתם אומרים, והצוות שלכם הבעלים של מה שרץ.
היקף טכני
SEYA בנתה וביצעה ריפקטורינג ליישומים על AWS, Microsoft Azure ו-Google Cloud. עבודת הקונטיינרים השתמשה ב-Docker, ב-Kubernetes (כולל Amazon EKS ו-Google Kubernetes Engine), ב-Istio וב-OpenShift; עבודת ה-Serverless השתמשה ב-AWS Lambda. קוד היישומים כלל Java עם Spring Boot ו-Spring Cloud, Node.js ו-Python. ה-Pipelines למסירה השתמשו ב-Jenkins וב-GitHub Actions, עם Terraform לתשתית שעליה השירותים רצים. Kubernetes מומלץ כשהארכיטקטורה דורשת זאת, וסביבת ריצה פשוטה יותר כשלא.
מה צריך להיות מוכן מצדכם
בעלים של המוצר שיכול לדרג אילו התנהגויות חשובות ביותר, מהנדסים שיעבדו איתנו וייקחו על עצמם את התוצאה, וחשבון ענן שהשירותים יכולים לרוץ בו. אם עדיין אין יסוד, חלק ה-Landing Zone של פלטפורמת ענן והגירה בא קודם. בדיקות אבטחה ב-Pipeline מתוכננות תחת אבטחה ו-DevSecOps, ושינויים באופן שבו הצוותים שלכם מאורגנים הם טרנספורמציה ארגונית.
מחוץ להיקף כאן: תוכנית מודרניזציה של פורטפוליו שלם בתקציר אחד (הפרויקט מכסה את היישום ששמו נקוב בו), עבודת מיתוג או שיווק, ותפעול אשכולות ה-Kubernetes שלכם עבורכם אחרי המסירה.
אבטחה
בדיקות Pipeline, טיפול בסודות וכללי קבלה (Admission) עבור היישום מתוכננים תחת DevSecOps. הדף הזה מכסה את בניית היישום. הוא אינו מחליף את הסקירה הזו ואינו מסמיך את התוצאה.
עבודות קשורות
- Clearly: ריפקטורינג של פלטפורמת מסחר אלקטרוני על AWS עם Autoscaling, גילוי שירותים ו-Pipeline כקוד
- LiveRamp: תכנון GKE ו-Shared VPC לסביבת Google Cloud ראשונה
שאלות נפוצות
האם אנחנו חייבים להשתמש ב-Kubernetes?
לא. Kubernetes הוא אפשרות אחת, והוא נושא עלות תפעולית. שלב התכנון ממליץ על סביבת הריצה שמתאימה ליישום ולצוות שיפעיל אותו, שהיא לפעמים שירות קונטיינרים מנוהל או פונקציות Serverless.
מי הבעלים של הקוד?
אתם. העבודה מתבצעת במאגרי הקוד שלכם, תחת הרישיונות שלכם, מה-Commit הראשון. אין מסגרת של SEYA שאתם הופכים תלויים בה.
איך אתם עובדים עם המהנדסים שלנו?
כצוות אחד. מהנדסי SEYA עובדים בזוגות עם שלכם על תכנון ומימוש, והסקירות עוברות דרך התהליך הרגיל שלכם. הכוונה היא שהצוות שלכם יוכל להמשיך בלעדינו.
האם היישום הישן יכול להמשיך לרוץ במהלך הריפקטורינג?
זו הגישה הרגילה. תוכנית המעבר קובעת אילו התנהגויות חייבות להמשיך לעבוד ומעבירה את התעבורה בשלבים, כך שהעסק ממשיך לפעול בזמן שהשירותים החדשים נכנסים לתפקיד.
כמה זמן אורך שלב התכנון?
זה תלוי בגודל היישום ובכמה מההתנהגות שלו מתועדת או מכוסה בבדיקות. אנחנו מסכמים את היקף שלב התכנון בשיחת הארכיטקטורה ואומרים לכם אם הוא צריך לגדול.
אם יישום אחד מאט את כל מפת הדרכים של המוצר שלכם, תאמו שיחת ארכיטקטורת יישומים ונאמר לכם היכן היינו מתחילים.
צור קשר
שלחו פנייה בנוגע להתקשרות בענן, בפלטפורמה, בנתונים או באמינות. דוא"ל שיווקי הוא בחירה נפרדת בטופס.