על שני פרויקטים מוצלחים – ולקחים

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

באותם פרויקטים שהקמתי, היו מספר רב של שרתים שהריצו מערכת DB שהיא Scale Out ובחלק מהשרתים רצות אפליקציות שונות שמשתמשות ב-DB כדי להעביר פנימה והחוצה נתונים לשם ניתוח. בנוסף רצו מכונות VM שונות לתשתית שנתנו שרותים שונים על מערכות הפעלה שונות.

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

  • מיישם הפרויקט – צריך להשתתף בפרויקט עוד בשלבים המוקדמים: במקרים רבים מתבצעת התקשרות עם איש מקצוע להקמת תשתית/פתרון אחרי שנבחרה חומרה שתריץ את הדברים. ההחלטות לגבי החומרה מתקבלות ע"י האיש המקצועי בחברה או שמוגשות המלצות ע"י אנשי השיווק של יצרן החומרה ואז אחד הקודקודים בחברה מחליט אם לרכוש או לא ומה לשנות (פקטור של מחיר וכו'). אני מבין את התהליך, אולם לעיתים יש דברים שניתן לשנות מבלי להרים את תקרת המחיר – שנותנים ביצועים יותר גבוהים או שרידות גבוהה, ולכן כדאי לשכור את האיש מקצוע לפני קבלת ההחלטות לגבי הברזלים.
  • תוכנות בקוד פתוח מסחרי או רגיל: אחת הנקודות שחשוב לתת עליה את הדעת עוד בשלב החישובים הכספיים, היא ההחלטה אם במערכת החדשה יוטמע פתרון מבוסס קוד פתוח חינמי שמורידים מהאינטרנט, או שרוכשים פתרון קוד פתוח עם תמיכה מסחרית מיצרן התוכנה. דוגמאות לכך לא חסר: OpenStack, Ceph, GlusterFS, RHV ועוד ועוד. אפשר כמובן להוריד מהאינטרנט ולהתקין בלי לשלם שקל, אולם מה קורה כאשר המערכת הזו תהיה פרודקשן ויש תקלה באפליקציה המרכזית? במקרים כמו OpenStack או Ceph לדוגמא, כמות האנשים בארץ שיכולים "לחטט" בקוד ולתקן באגים מאוד קטנה וללא תמיכה מסחרית רשמית – מערכת פרודקשן כזו יכולה להיות מושבתת למשך ימים, ולכן אם מדובר במערכת פרודקשן שתיצור הכנסות – מומלץ לבחור בדרך המסחרית. זה יותר יקר מבחינה כספית – אבל זה נותן שקט ומענה לבעיות בטווח הארוך.
  • כמה שפחות תלויות: לא משנה מי הפרילאנסר או החברה שמקימה עבורכם את הפתרון, חשוב לכלול כמות שעות מסויימת שתוקדש לתיעוד והדרכה של הצוות בחברה, ובמיוחד Troubleshooting. אם לדוגמא המערכת מנותקת מהאינטרנט ויש תקלה, הצוות בחברה (בהינתן הידע) יכול לטפל בתקלה הרבה יותר מהר מאשר פתיחת טיקט, המתנה, ולאחר מכן עבודה בשיטה של copy/paste מהטיקט למכונות.
  • חיבור אינטרנט למערכת: לא מעט לקוחות מבקשים להקים מערכת שבמצב פרודקשן תהיה מנותקת לחלוטין מהאינטרנט. זהו דבר מובן ומקובל, אבל עדיין חשוב לבנות חיבור אינטרנט (ישיר או עקיף, ע"י הקמת Proxy או VPN לדוגמא) לעדכונים ותיקונים חשובים. ראיתי לא מעט מקרים בהם אנשים הורידו קבצי RPM וחשבו שהם יוכלו להתקין אותם ישירות בפרודקשן מדיסק און קי, ואז הם ראו דרישה מהמערכת לערימת קבצי RPM נוספים כתלויות. על מנת לאבטח את המערכת, חיבור כזה צריך להיות מופעל ידנית כמובן כך שלא ניתן להיכנס אוטומטית מרחוק.
  • דאגו ל-Gateway: נניח שיש לי 50 שרתים, כולם תחת אותו Class של כתובות (נניח 24/). מטבע הדברים יספיק שרת DNS פנימי פשוט כדי שהמכונות יכולות לשוחח בינן לבין עצמן ואין צורך בשום Gateway, אבל הבעיה מתחילה בכך שאם נניח מכונות 3,8,10,14,30 צריכות עכשיו להתחבר לאינטרנט להוריד דברים מסוימים (ואין Proxy), בלי Gateway זה יהיה בעייתי, ולכן מומלץ שאפילו ה-Switch המקומי ישמש כ-Gateway מקומי.
  • לוח זמנים – בחיים ניתן לשלוט על דברים רבים, אך יש דברים שאין עליהם שליטה. פרויקט אמור להימסר ללקוח בעוד חודשיים אך עדין לא מצאו איש מקצוע בתחום מסוים. יש צורך בהחלפת רכיב מסוים בכל השרתים. יש צורך בשינוי דחוף בארכיטקטורה. הלקוח לא מרוצה מהביצועים – קחו טווח זמן יותר ארוך ממה שאתם חושבים שתצטרכו.

יש מישהו אחד שלימד אותי על אופטימיות ו"תהיה אופטימי" – יוחאי אזולאי, מנכ"ל קבוצת OMC ואת השיעור הזה אני מנסה ליישם כל יום. אישית, אני אבצע את הפרויקט גם אם מדובר בשרת עתיק (וביצעתי בשנה שעברה לדוגמא פרויקט על שרתי Xeon הראשונים שיצאו לפני עשור), ואני אעשה הכל על מנת שהכל ירוץ בצורה חלקה ומהירה ואני יכול לאמר שרוב מוחלט של הפרויקטים שביצעתי – הלקוחות היו מרוצים, אבל כשיש מגבלות חומרה או מגבלת זמן סופר קצרה, קשה לעקוף זאת ואין זה משנה מי יבצע את הפרויקט, ולכן על מנת שהלקוח יהיה מרוצה, כדאי לעניות דעתי לקחת לתשומת הלב את הדברים שכתבתי לעיל.

להתקדם בתחום

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

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

בעבר, החיים היו הרבה יותר פשוטים. אם היית רוצה "להתמקצע" בתחום של מיקרוסופט, אז היית לוקח איזה קורס MCSE (או איך שזה נקרא כיום, סורי, אני לא עוקב אחר שינויי השמות), לומד כלים משלימים של מיקרוסופט כמו SCCM, אקסצ'יינג', אולי PowerShell, ועם זה היית הולך לחפש עבודה. אחרים הלכו לתחומים כמו לינוקס ושלל השרותים שנמצאים בלינוקס, יש כאלו שהיו הולכים ללמוד CCNA בשביל תקשורת מחשבים, ויש כאלו שלמדו קורס כלשהו על סטורג', אחרים למדו VCP בשביל וירטואליזציה. בחברות גדולות היו מחפשים יותר דברים ספציפיים כמו אחד מהנושאים שציינתי לעיל (לדוגמא – איש וירטואליזציה), ובמקומות יותר קטנים היו מצפים שתכיר את כל הנושאים שציינתי על מנת להתקבל למקום העבודה.

אבל היום הכל משתנה. היום גם החברות הגדולות מעוניינות באנשים שיש להם ידע ונסיון במספר תחומים, גם אם העבודה היא בעקרון להתעסק בתחום מסוים. אם קובי מעולה לדוגמא בתחום סטורג' (וזה התחום שהם מחפשים אליו עובד) ורוני מכיר לא רק סטורג' אלא גם מכיר לינוקס בצורה כזו מעולה שהוא יכול להסביר תוך כדי שינה מה זה Magic SysRq key בלינוקס – אז רוני יקבל את העבודה, גם אם לרוני יש שליש מהזמן נסיון בסטורג' בהשוואה לקובי. הסיבה? לרוני יש יותר ידע שסביר להניח שיצטרכו בחברה להתגבר על אתגרים עתידיים.

אז מה אתה יכול לעשות כדי לשפר את סיכוייך למצוא עבודה טובה בעתיד?

יש כמה דברים.

אם אתה רוצה להישאר בתחום ה-IT הקלאסי (לפני כניסת הענן) אז מה שמומלץ לך זה ללמוד את התחומים "השכנים": אתה איש סיסטם מיקרוסופט? תכיר יותר את תחום הסטורג' הרגיל, תכיר יותר נטוורק לעומק (אתה יכול להשתמש בכלי כמו GNS3 לבצע סימולציות), והכי חשוב – להכיר את מערכת ההפעלה ה"מתחרה" לינוקס במובן הטרמינל (לא במובן הגרפי. ברוב המקרים אתה לא תעבוד מול תצוגה גרפית במכונות לינוקס) – מה זה לינוקס, איך הוא בנוי, פקודות לינוקס בסיסיות, כתיבת סקריפטים בסיסיים ב-BASH, הגדרות ציודים שונים, ניתובים, ניהול חבילות תוכנה, ועוד. אם אתה רוצה, יש אתר בשם Linux Academy שמלמד את הדברים (יש מנוי חודשים שעולה 50$ לחודש, שבוע ראשון בחינם). אם אתה יותר טיפוס של ספרים – יש לא מעט ספרים שמלמדים על לינוקס ויש כמובן גם קורסים בבתי הספר המקצועיים השונים שמלמדים לינוקס. לגבי סטורג' ונטוורקינג – אני ממליץ ללמוד לבד.

במקומות גדולים החל לצוץ לו תפקיד חדש לאחרונה (לא באופן רשמי, לפחות ממה שאני יודע) והוא "Cloud Admin" – מה שאתה עושה מקומית, עכשיו בענן, רק שבענן לא יחכה לך איזה סטורג' של Netapp/EMC, אין לך סוויצ'ים, אין לך פיירוול (את זה אפשר להוסיף, כ-Appliance) והכל בעצם נעשה בתוכנה, בין אם דרך ממשק ווב, אבל יותר דרך ממשק CLI וכאן כבר צריך ללמוד איך להגדיר דברים, החל ממכונות VM, נטוורקינג, דיסקים קשיחים וירטואליים ועוד ועוד. בלינק שפירסמתי לעיל יש גם קורסים לכל ספקי הענן הגדולים, כך שאפשר ללמוד שם גם איך להשתמש בענן ואיך לנהל משאבים. העננים הפופולריים ביותר הם של אמזון (AWS) ו-Azure של מיקרוסופט. קצת פחות פופולרי (והרבה יותר טכני) הוא הענן של גוגל, לכן מומלץ ללמוד לפחות את הענן שבו החברה משתמשת ואולי את הענן השני הפופולרי.

ויש את "איש ה-Devops" (זה לא תפקיד, Devops אלו מתודות עבודה, אבל בגלל כל מיני מחלקות כ"א, קוראים לאחד שמתעסק בזה – "איש Devops").

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

איש ה-Devops טוב צריך לדעת כמה דברים חשובים:

  • הוא צריך להכיר טוב לינוקס, ברמה של כתיבת סקריפטים, הגדרות לינוקס, ניהול חבילות
  • הוא צריך להכיר את עולם הקונטיינרים – החל משימוש ב-Docker כדי לבנות Images, והוא צריך להכיר Kubernetes (או OpenShift או Caas) כדי לבצע אורקסטרציה בין הקונטיינרים השונים שירוצו, שרותים, רשתות, Scaling ועוד.
  • הוא צריך להכיר כלי CI/CD על מנת לאפשר ביצוע Build אוטומטי דרך כלים כמו Jenkins או Teamcity לדוגמא.
  • הוא צריך להכיר כלי ניהול קוד טוב. כל כלי שיודע לעבוד עם GIT זה טוב, בין אם מדובר ב-Bit Bucket או GitLab או כלי אחר, וכדאי להכיר את הדברים לא רק ברמת ממשק הווב אלא גם להכיר את GIT עצמו.
  • "קוד כתשתית" – אחד הדברים ש"רצים חזק" כיום הם כלים שכותבים איתם "קוד" לניהול תשתית כמו הענן הפנימי שלכם בענן הציבורי, כלי כמו Terraform או Ansible או SALT הם כלים מעולים לכך.
  • שפות – BASH מאוד יעזור לכתיבת סקריפטים פשוטים, מומלץ להכיר גם Python.
  • שרותים – כל ספק ענן ציבורי מספק מאות שרותים שונים. תצטרכו עם הכלים הנ"ל להגדיר ולהשתמש בשרותים הנ"ל ואצל כל ספק ענן זה שונה. כן. Not Fun.
  • ניטור באופן שונה – מכיוון שיש הרבה שרותים שספק הענן מציע ולך אין גישה לתשתית השרותים, תצטרך להשתמש בכלים שונים לניטור, סביר להניח דרך כלי הניטור של ספק הענן.

כמו שאתם רואים – ערימה לא קטנה של דברים. אגב, כמעט את כולם ניתן ללמוד ב-Linux Academy בלינק שנתתי לעיל.

חשוב להבין – אף אחד לא מצפה שתכירו את כל מה שציינתי לעיל בעל פה ו"על השפיץ", אלא להבין את עקרון הדברים ואיך דברים עובדים ואולי שתוכל לתת דוגמא קטנה. אם לדוגמא אתה מכיר כלי כמו Bit Bucket ואין לך מושג ירוק ב-GitLab, או אם אתה לא מכיר מהזה Federation ב-Kubernetes אף אחד לא יפסול אותך בגלל זה.

לסיכום: לא לכל אחד מתאים להיות Devops, וזה בהחלט מובן. יחד עם זאת, חשוב לעדכן את הידע כדי להישאר רלוונטיים בשוק העבודה כשכירים. תמיד מומלץ לנסות ללמוד דברים חדשים ולהתנסות, וכיום לדוגמא רוב ספקי הענן יתנו לך איזו חבילה חינמית לכמה חודשים ואם אתם לומדים דרך ה-Linux Academy אז הם נותנים לכם 6 שרתים וירטואליים להתנסות (זמנית, השרתים נכבים אחרי שעה, אבל זה מספיק בשביל לבדוק פקודות או הגדרות מסויימות).

בהצלחה.

קצת על בנקים, מודרניזציה ותשובות למר איל מוסקל

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

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

אז נתחיל עם ה-Mainframe. רבים מהקוראים בוודאי חושבים שמדובר על טכנולוגיה עתיקה וישנהאך אין הדבר כך. נכון, IBM שומרת בקנאות פנאטית על תאימות כמה דורות אחורה, אבל מערכות Mainframe מתעדכנות מבחינת חומרה נון-סטופ ומבחינת ביצועים, מעבד כמו ה-Power9 "מרביץ" למעבדים כמו Xeon-SP בכל מובן שתבחרו. בנוסף, אחד היתרונות הגדולים של מערכות Mainframe הוא תחזוקת חומרה. בשרתים רגילים, אנחנו יכולים להחליף דיסק קשיח מבלי לכבות את השרת או ספק כח, ב-Mainframe אתה יכול להחליף כמעט הכל – מעבדים, כרטיסי PCIE, זכרונות בזמן שהמערכת פעילה והיציבות של המערכת היא אחד הדברים ש-IBM בהחלט יכולים להתגאות בו. זה פשוט לא נופל.

בעבר רוב האפליקציות שנכתבו ל-Mainframe אכן היו ב-COBOL ויש חלק לא קטן מהקוד שעדיין רץ ב-COBOL, אבל בשנים האחרונות בנקים שיש להם Mainframe החלו להשתמש בפונקציונאליות חדשה ש-IBM הכניסו: להריץ מכונות Linux כ-VM על ה-Mainframe בצורה טבעית (ללא אמולציה של X86) עם ביצועים מאוד מהירים בעזרת כרטיסים יעודיים עם מעבדי Power8 (ובזמן האחרון Power9) שמיועדים להריץ Linux. כך הבנקים נהנים מ-2 יתרונות גדולים: אפליקציות Linux שרצות באופן טבעי על Mainframe ובנוסף מערכת ה-Mainframe יציבה מאין כמוה.

לגבי שפת COBOL – נכון, היא שפת תכנות עתיקה (משנות ה-50) אולם היא עברה עדכונים רבים וסטנדרט ה-COBOL גם עבר עדכונים וכיום הסטנדרט ב-COBOL הוא ISO/IEC 1989:2014 – כלומר יש בהחלט עדכונים לשפה. נכון, היא שונה משפות כמו Python, Go, Perl וכו' אך מצד שני היא לא כזו קשה ללימוד, זו שפה שיותר מבוססת על השפה האנגלית.

אחד הדברים שמר מוסקל לא מתייחס אליהם הוא נושא פרויקטים שהבנקים (כל הבנקים) מבצעים: שכתוב מחדש של קוד COBOL ישן ל-Java מודרני. אף בנק לא מעוניין "להיתקע" עם מערכת ישנה שאין לה אף אחד שיתחזק אותה, ולכן מבוצעים הפרויקטים הנ"ל, ובבנקים נכנסים יותר ויותר לעבודה עם כלים סטדנרטיים כמו GIT, יש גם Jenkins שיודע להתחבר ל-zOS (מערכת ההפעלה העדכנית של ה-Mainframe של IBM) וגירסת Docker Enterprise Edition 17.06 יודעת להתחבר למערכות System Z (ה-Mainframe) להריץ קונטיינרים על Linux שרץ ב-Mainframe.

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

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

ונקודה אחרונה מבחינה טכנית: למיטב ידיעתי, כל בנק בישראל החל "לפזול" לכיוון קונטיינרים כפתרון Scale Out כדי לעמוד בעומסים שונים, כך שמצד אחד הבנק "מגייר" אפליקציות מ-COBOL ומצד שני הבנק בודק טכנולוגיות קונטיינרים שונות. כיום, אם בנק ישאל "חץ, האם לעבור לקונטיינרים לפרודקשן?" תשובתי תהיה: "בשלב זה, התשובה היא לא" מכיוון שלדעתי בנקים יצטרכו פתרונות קונטיינרים יותר מאובטחים כמו Clear Containers של אינטל וטכנולוגיה זו היא צעירה ועדיין לא בוגרת מספיק כדי לזרוק אותה לפרודקשן.

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

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

לסיכום: נכון, דברים זזים לאט בבנקים. מתי בדיוק הייתם בסופרמרקט והעברתם את הסלולרי שלכם לשלם עם חשבון הבנק או כרטיס האשראי הבנקאי בארץ? זה עדיין לא זמין ובחו"ל זה זמין עם הטלפון הסלולרי ועם השעונים החכמים מבוססי Android Wear, Tizen או ה-Apple Watch והאשמה דווקא אינה תלויה לפתחם של הבנקים בישראל (הם יכולים בתוך חודשיים שלושה להפעיל את זה) אלא בבנק ישראל. לבנקים לוקח זמן לעבור לשיטות פיתוח חדשות אבל פנימית הם בהחלט מתעדכנים. יצא לי לא פעם להציע פתרונות שונים כרעיון לקדם משהו ובמקרים רבים הופתעתי מכך שאין תשובה שלילית מיידית. בקיצור – בניגוד לרושם שנוצר מגורמים שונים, הבנקים לא נמצאים בעידן האבן. לוקח להם זמן להתקדם – אבל הם מתקדמים.