GUI לדסקטופ או ממשק וובי?

[ipv6]

אולי נקודה אבל לדעתי ממש לא מהותית

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

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

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

 

[הפרבולה]

אולי כדאי לממש את זה עם אפליקצית דסקטופ , אבל

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

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

 

[מדינה קטנה]

תודה רבה על כל התשובות!

דבר אחד שלא לגמרי הבנו מהתשובה של BravoMan - אם אנחנו רוצים שרת שיריץ קוד שלנו, נהיה חייבים לשלם על אחד? מה בעצם האפשרויות החינמיות מציעות?
&nbsp
שוב תודה

 

[vinney]

בדרך כלל אירוח חינמי מוגבל מאוד

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

 

[אוהב להתווכח]

Heroku הוא ממש פצצה

והוא נותן שרת אחד (או יותר בחינם).
נותן דטהבייס בחינם, הרצת ג'ובים וכל סוג של קוד.

 

[יבגניי34]

Heroku's free tier is the least attractive

The big 3 (azure, gc, aws) have fantastic free tier offers.
For the "I'm just playing" stage I'm a big cloud9 fan (not suitable for actual test hosting).

 

[vinney]

זה יכול להיות מספיק להם לפרוייקט

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

 

[יבגניי34]

הסיפור הזה מתקבל על הדעת רק אם היה להם outbound של TBs

ה killer pricing של aws זה egress שהוא יקר להחריד (גם אצל המתחרים).

השרת עצמו עולה כלום (10$ לחודש?).

 

[vinney]

לא רק הטראפיק

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

 

[אוהב להתווכח]

די ברור שסקלאביליות עולה כסף

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

 

[user32]

זה אכן משהו שלא תמיד לוקחים בחשבון

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

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

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

 

[יבגניי34]

אני גם לא אוהב את הרעיון אבל יש רעיון שאני אוהב אפילו פחות

וזה לתחזק לבד 2 מסדי נתונים ועוד LB ומערכות אחסון ומיני תורים וקפקאות עדכוני אבטחה vpnים ושרתי dns. זה לא המקצוע שלי וכמו שאני משלם למישהו שיתקן לי את האוטו אני מאושר לשלם לבזוס שכל ה /etc/whatever/ הזה יהיה בעייה שלו.

 

[user32]

לא יודע

בפרוייקטים קטנים (1-2 instances) אני לא רואה בעיה. נצמדים לסטנדרטים ואפילו אני עם יכולות הIT המוגבלות שלי מתחזק כרגע 6 חשבונות AWS ל6 חברות שונות וטרם נתקלתי בבעיה. המקסימום היה לשלם לחברת IT שתסייע בקונפיגורציה מסויימת וגם זה היה לפני בערך 5 שנים.

בנפחים הגדולים, מה שמתחיל להתקרב יותר למה שקרוי "ביג דאטה" וממה שאני ראיתי החברות מנהלות את הדברים שהזכרת בכוחות עצמם גם אם זה בAWS. כלומר, קשה להאמין שתפתח מוצר שרץ על 40 מכונות (לא נחשב למשהו ענק אגב) ופשוט תלחץ על כמה כפתורים בקונסול וזהו. זה תמיד נגמר באנשי IT וDevOps שבין השאר מתמחים בAWS שיכתבו את הסקריפטים, הנהלים, הקונפיגורציות וכל השאר. מכיר כמה וכמה מקומות כאלה.

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

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

 

[eveik]

למה לא לתת לאמאזון לנהל את הדטה בייס שלי?

או להשתמש בqueue שלהם? או בכלים שעוזרים לנהל את האפליקציה (opsworks/beanstalk וכו׳)?
&nbsp
איזה סיבה יש לי לרצות להתעסק בזה ולנהל / לפתח בעצמי אם אני יכול להשתמש במוצר קיים? בעיני זה בסך הכל עוד שירות שאני משתמש בו ואני מחליט באיזה שירותים אני משתמש. במקרה חלק מהשירותים האלו באמאזון אבל באותה מידה זה גם יכל להיות אותו שירות בחברה אחרת שתנהל עבורי.
&nbsp
אולי עבור פרוייקט קטן - תעשה מה שאתה רוצה העיקר שיעבוד. אבל בתור חברה קטנה? אני מעדיף להעביר כמה שיותר אחריות ממני הלאה. לנהל את הדטה בייס זה לא הביזנס שלי, בדיוק כמו שזה לא לנהל את המכונות.

 

[user32]

כמה סיבות

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

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

שוב, אין לי התנגדות גורפת אני פשוט מעדיף שלא, כל עוד אני יכול להסתדר בלי. בעבר תמיד נשמעו טענות דומות בעיקר בהקשר של מיקרוסופט: למה לא להשתמש בתוכנה עם UI נוח ולא להתעסק עם כל הפרטים? למה לא לקנות מוצר X וAPI כזה או אחר במקום לפתח בעצמך? עברנו כברת דרך ארוכה מאז והיום אני יכול לפתח מוצרים שלמים עם 100% שליטה על כל חלק בתוכנה החל מהקרנל ועד אחרון הספריות. שילוב שירותים קנייניים שלגמרי לא בשליטתי זה בעיה.
אין לי בעיה עם קונפיגורציה שאמזון הקימו ומנהלים כשמדובר בstack שבנוי ממוצרים סטנדרטיים. אם זה מוצר של אמזון כמו פלטפורת הmap-reduce שלהם, הדאטבייסים, ושאר השירותים אז אני מוותר.

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

 

[eveik]

מסכים לגבי DynamoDB

זה באמת חתונה קתולית, אבל יש הבל עצום בעיניי בין DynamoDB לבין שירות הRDS שבו אתה בוחר איזה דטהבייס אתה רוצה (MySQL למשל). מחר אני רוצה שירות אחר שינהל לי את הדטהבייס? אעבור אליו, אבל עדיין אני נשאר עם אותו דטהבייס והקוד שלי לא מושפע כמעט מהסיפור (ברור שזה ידרוש עבודת DevOps..).
&nbsp
לא צריך להכיר את כל מאות השירותים, אבל זה נחמד מידי פעם לנסות את השירותים שלהם ולהחליט. בלי להכיר את השירותים נורא קל לפסול - לפחות אתה מודה בזה.
&nbsp
באופן אישי אני מעדיף להשתמש בשירותים מוכרים בתעשייה שנראים לי סבבה כדי להוריד ממני כמה שיותר אחריות. אני לא רוצה להתעסק עם תשלומים - אני משתמש ב Stripe. אני לא רוצה לנהל לוגים - יש לי שירות שמנהל לי את זה, וכנ״ל שירות לשלוח מיילים, ופקסים, ועוד הרבה דברים אחרים שאני צריך.
&nbsp
אתה מעדיף לבנות את השירותים האלו בעצמך? נשמע לי מטורף. ברור שדברים שהם core של המוצר שלי אני אשאיר בפנים, אבל דברים שהם לא? נשמע לי בזבוז זמן לפתח. אם אגיע ליום ששירות מסויים מגביל אותי - אעבור עליו, אבל עדיין נראה לי הרבה יותר יעיל להתחיל עם שירות קיים ובהמשך לצאת אם צריך.
&nbsp
premature optimization is the root of all evil, אבל זאת רק דעתי

 

[user32]

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

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

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

הפתרון הוא כמובן אופן סורס ולא לפתח לבד. חשבתי שזה מובן מאליו, לא ככה?

 

[יבגניי34]

הוא לא דיבר על לפתח לבד אלא על ״self hosting״

יענו במקום ElasticCache הוא יתחזק רדיס קלאסטר משלו על ec2, במקום EMR הוא יריץ ספארק קלאסטר משלו וכיו״ב.

לי זה עדיין נשמע טירוף (בעיקר כי הייתי שם) אבל עובדתית יש אנשים שעובדים ככה.

 

[eveik]

נשמע סיפור מאוד מוזר..

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

 

[vinney]

רוב הסטארטאפים גומרים כך.

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