קטגוריות
מערכות מידע משולחן היועץ

השוואת חבילות שרותי דואר בענן

בהמשך לסקירה על המעבר מ-Google Workspace, השוואת המחירים נכונה לאפריל 2022

תכניתעלותנפח
דואר
נפח
קבצים
תכנות
משרד
1Domain אחד בלבדFastMail Basic$32איןלא
FastMail Standard$530איןלא
Zoho Standard$33010ענן
Zoho Professional$6100100ענן
Zoho Mail Light$15איןלא
Zoho Mail Premium$450?לא
Microsoft 365 Business Basic$5501024ענן
Microsoft 365 Business Standard$12.5501024שולחני
וענן
Microsoft Exchange Online (Plan 1)$450איןלא
Google Workspace Starter$6302שטח האיכסון כולל דואר, תמונות וקבציםענן
Google Workspace Standard$1220482שטח האיכסון כולל דואר, תמונות וקבציםענן
1Domain אחד בלבדFastMailMailCow Classic4.9 €20איןלא
3אין הגבלת משתמשיםMailCow Managed39.9 €100איןלא

קטגוריות
מערכות מידע משולחן היועץ אינטרנט

עוזב את Google Workspace

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

אמ;לק: עברתי למיקרוסופט. בעיקר כי קיבלתי הנחה שהפכה את המוצר שלהם לתחרותי.

מה שחיפשתי היה חבילה מנוהלת שכוללת דואר, יומן, אכסון ענן (מה שנקרא Productivity Suite, אני אתייחס לחבילה זו בשם דואר מכאן והלאה). הדגש על מנוהלת מופיע כי ישנם לא מעט מוצרים, מסחרים וקוד פתוח, אותם ניתן להתקין על מערכת בבית או על שרת בענן. שרתי Synology, למשל, כוללים חבילת דואר, מערכת MailCow היא מערכת מבוססת על קוד פתוח אותה ניתן להתקין על שרת לינוקס בענן או בבית.

הכלכליות של פתרונות אלו תלויה בכמות המשתמשים שיש (לי יש ארבע), כמות המתחמים (Domains), הזמן שלכן ועלויות התפעול (שרתי הענן או ה-UPS בבית למשל).

כאמור, ההצעה של מיקרוסופט (לאחר ההנחה) יצאה משתלמת יותר מהפתרונות של FastMail, Zoho, Google או המערכת המנוהלת של MailCow. לטווח ארוך, כמובן, יהיה צורך לבחון את הפתרונות מחדש.

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

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

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

העברת הדואר לא תכלול חוקים (אם הגדרתם כאלו), ויהיה צורך ליצר אותם מחדש.

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

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

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

ישנם דברים אותם לא ניתן להגר:

  1. קבוצות וכתובות דואר חלופיות (Aliases) צריך לייצר מחדש.
  2. התקשרויות ב-Chat לסוגיו. אפשר לייצא את תוכן השיחות כקובצי טקסט, אבל צרופות והדגשות יאבדו.
  3. שימוש בשרות להיכנס לשרות אחר (Login with Google). כדי להיכנס להגדרות החשבון ולראות אלו אתרי צד ג׳ מתבססים על השרות, ולעבור לזיהוי עם סיסמה.
  4. רכישות שנעשו דרך השרות. יתכן כי ניתן להעביר אותם לחשבונות פרטיים.
  5. אלבומי תמונות.

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

חלופות

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

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

קטגוריות
משולחן היועץ

מעונן חלקית

מחשוב עננים (cloud computing), אינו חדש, אך תופס תאוצה (והייפ). והסיבות אינן רק טכנולוגיות, אלא יותר עסקיות וכלכליות. המחשבה המנחה: טכנולוגיה הופכת למוצר צריכה, והגיוני יותר לרכוש אותה כמו כל מוצר צריכה או שרות אחר, יתר על כן, חברות אינן רואות את מערכות המידע כמעניקות ערך מוסף לארגון.
מאידך, ישנה רתיעה מהוצאת מערכות המידע מהארגון. לעיתים מתוך חשדנות במוטיבציות של הספקים, לעיתים מתוך דאגה לרמת אבטחת המידע ולעיתים מתוך דאגה על ביצועים.
יתר על כן, תמחור מחשוב העננים עדיין לא מאפשר השוואה מובהקת מספיק לבחון את יתרונותיה או חסרונותיה הכלכליים מול ה-Data center הקלסי.
המודל המתבקש לעתיד הנראה לעין, הוא לפיכך מודל היברידי. והנה דוגמה לכך – מערכת דואר של ארגון בינוני, המפוזר בין מספר אתרים, ואולי גם מספר מדינות.
במודל הקלסי, שרת הדואר הארגוני נמצא במטה הארגון. הסניפים המרוחקים מתחברים דרך קוי תקשורת יעודיים או בתקשורת VPN למרכז. אם הסניף המרוחק גדול במיוחד, יתכן כי יהיה בו שרת משני לטובת המשתמשים של אותו סניף. עובדים מחוץ לאתרי החברה מתחברים באמצעות פורטל Web, קישורי VPN או ניתוב דואר למחשבי כף יד או טלפונים חכמים.
כעת נבחן מספר חלופות של מחשוב עננים:

  • שרות יעודי: במקרה של דואר אלקטרוני, ספקי אינטרנט נתנו שרות זה כבר שנים, וספקי דואר יעודיים (Hotmail למשל) התחרו ומתחרים בהם. כיום שרותים אלו כמעט פסו מן העולם. ספקיות האינטרנט מציעות תיבות דואר זעומות ובסיסיות, וספקי הדואר נבלעו בפורטלים (Hotmail הוא חלק ממערכת Microsoft Live) או נעלמו.
  • שרותים מאורחים (Co-hosted): כאן אפשרו ספקיות אינטרנט ללקוחות להחזיק שרת דואר יעודי באתר הספק, כאשר נטל האחזקה והשרות של החומרה והתוכנה מתחלקים בצורות שונות בין הספק ללקוח. מודל זה כמעט זהה למודל הקלסי, למעט מיקומם הפיזי של השרתים, בעיקר בעסקים קטנים ובינונים, בהם אין יחידת IT מובנית.
  • ענן, או grid: הספק מעניק את תשתית החומרה, התקשורת (ולעיתים גם את מערכת ההפעלה), עליה מתקין הלקוח את מערכת הדואר. דוגמא לכך הוא ה"ענן האלסטי" של אמזון.
  • תוכנה כשרות, או SaaS: כאן מקבל הלקוח סביבת עבודה השייכת במלואה לספק ובאחריותו. הדוגמה המובהקת היא שרותי Google Apps, אך גם ספק תכנה קלסי כמו מיקרוסופט מציעה את שרת הדואר שלה כשרות. לעיתים השרות קיים כחלק מסביבת שרותים נוספת, כמו במקרה של השרות לעסקים קטנים של יאהו.

המודלים של ענן או שרות הם המעניינים ביותר, היות ואלו הם המעניקים את הערך המוסף לעסק. במקרה שלנו (דואר אלקטרוני), ניתן לראות את היתרונות הבאים:

  • חומרה: אין צורך בחומרה יעודית לשרתים בתוך הארגון.
  • עומס תקשורת: ירידה בעומס על התקשורת מחוץ לאתר המרכזי של החברה (מאתרי משנה או ממשתמשים העובדים מבחוץ).
  • מורכבות תקשרות: אין צורך בניהול מערכות  VPN

עם זאת, יש להביא בחשבון מגבלות וסיכונים:

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

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

מספר נקודות שיש לבחון מול כל ספק.

  • תנאי השרות והזמינות, הידועים בראשי התבות SLA או Service Level Agreement: אלו קובעים את קוי הבסיס לזמינות השרות ומה זמן התגובה לתקלה והקנס לאי עמידה בו.
  • יבוא: מה הכלים והאפשרויות של יבוא מידע (המקרה זה דואר קיים) למערכת החדשה
  • יצוא: לא פחות חשוב – מה האפשרויות של יצוא המידע במצב של סיום השרות.
  • שימור ואיחזור מידע: מה הכלים לשימור מידע, גיבויו (האם ניתן למשל לגבות את הדואר למערכת מקומית?)
  • ממשקים: האם קיימים ממשקים למערכות בהם משתמשים בחברה (למשל טלפונים חכמים)

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

קטגוריות
משולחן היועץ אינטרנט

עננה שחורה

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

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

גוגל, כמובן, אינו היחיד. יאהו, מיקרוסופט, AOL ואחרים מעניקים שרותים דומים. ישנן חברות הנותנות שרותים יעודיים, כמו SalesForce ,(קשרי לקוחות) Amazon S3 (איכסון שרותים), ואחרים. השרותים היעודיים אינם מיועדים לרב למשתמשי הקצה, אלא לנותני שרותים אחרים. כל השרותים הללו נכללים תחת הזומילה  SaaS, תכנה כשרות,

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

אך האם לעולם חוסן? תפיסת הספגטי של גוגל נראתה מגניבה בימי ה-Dot.Gone, ולא איבדה מזהרה עד שהופיעה המשבר הנוכחי. כעת גוגל, כמו כל חברה אחרת, משליכה מעבר לסיפון כל משקל עודף1. מתי יהפוך שרות החיוני לך למשקל עודף לחברה?

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

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

  1. או מה שעלול להראות כמשקל עודף בעיני בעלי המניות []
קטגוריות
משולחן המנמ"ר

פגישה, חצי פגישה….

על חחוסר חיבתי ל-Outlook, כבר כתבתי בעבר. כיום אני נאלץ לא רק להתשמש בשיקוץ, אלא גם לנהל אותו, ולעודד את משתמשי החברה להשתמש בו לניהול זמן.

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

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

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