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

הערה. תרגום: מאמר זה, שהפך ללהיט ב-Medium, הוא סקירה כללית של השינויים המרכזיים (2010-2019) בעולם שפות התכנות והאקולוגית הטכנולוגית הקשורה (עם התמקדות מיוחדת ב-Docker ו-Kubernetes). המחברת המקורית שלו היא סינדי סרידהארן, המתמחה בכלי מפתחים ומערכות מבוזרות - בפרט, היא כתבה את הספר "Distributed Systems Observability" - והיא פופולרית למדי באינטרנט בקרב מומחי IT, המתעניינים במיוחד בנושא native בענן.

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

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

ההקלדה מכה בחזרה

אחת המגמות החיוביות ביותר של שנות ה-2010 הייתה התעוררותן המחודשת של שפות מוקלדות סטטיות. אמנם שפות כאלה לא נעלמו לשום מקום (C++ ו-Java מבוקשות היום; הן שלטו לפני עשר שנים), אבל שפות עם הקלדה דינמית (דינמית) חוו עלייה משמעותית בפופולריות לאחר הופעת ה-Ruby on Rails תנועה ב-2005. צמיחה זו הגיעה לשיא ב-2009 עם גילוי קוד המקור של Node.js, שהפך את Javascript-על-השרת למציאות.

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

Rust, שהוצג ב-2010, כלל הישגים ב תורת הסוג בניסיון להפוך לשפה בטוחה ומוקלדת. במחצית הראשונה של העשור, היחס ל-Rust בענף היה פושר למדי, אך הפופולריות שלו עלתה משמעותית במחצית השנייה של העשור. דוגמאות בולטות לאופן השימוש בחלודה כוללות את השימוש בו כיס קסם בדרופבוקס, חזיז של AWS (דיברנו על זה ב מאמר זה - משוער. תרגום), מהדר WebAssembly מוקדם Lucet מ-Fastly (כיום חלק מ-bytecodealliance) ואחרים. כשמיקרוסופט שוקלת לשכתב חלקים מסוימים ממערכת ההפעלה של Windows ב-Rust, בטוח לומר שלשפה הזו יש עתיד מזהיר בשנות ה-2020.

אפילו שפות דינמיות קיבלו תכונות חדשות כמו סוגים אופציונליים (סוגים אופציונליים). הם יושמו לראשונה ב-TypeScript, שפה המאפשרת ליצור קוד מודפס ולהדר אותו ל-JavaScript. ל-PHP, Ruby ו-Python יש מערכות הקלדה אופציונליות משלהם (mypy, גרזן), אשר שימשו בהצלחה ב הפקה.

החזרת SQL ל-NoSQL

NoSQL היא טכנולוגיה נוספת שהייתה הרבה יותר פופולרית בתחילת העשור מאשר בסוף. אני חושב שיש לכך שתי סיבות.

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

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

הסיבה השנייה קשורה לצמיחה של מסדי נתונים מבוזרים של SQL "ניתנים להרחבה" (כגון מפתח ברגים и AWS אורורה) בענן הציבורי, כמו גם חלופות קוד פתוח כמו CockroachDB (אנחנו מדברים גם עליה писали - משוער. תרגום), אשר פותרות רבות מהבעיות הטכניות שגרמו למסדי נתונים מסורתיים של SQL "לא להתרחב". אפילו MongoDB, פעם התגלמות תנועת NoSQL, היא עכשיו מציע עסקאות מבוזרות.

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

הזרמה מוחלטת

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

אינטגרציה רציפה (ובמידה פחותה פריסה רציפה)

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

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

מיכלים

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

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

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

ללא שרת

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

אוטומציה

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

אוניברסלי API-Fication

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

בנוסף, API-fiction הוא הצעד הראשון לקראת SaaS-fiction של פונקציונליות או כלי כלשהו. מגמה זו גם הלכה בקנה אחד עם הפופולריות הגוברת של שירותי מיקרו: SaaS הפך לעוד שירות שאפשר לעבוד איתו באמצעות API. יש כיום כלים רבים של SaaS ו-FOSS בתחומים כמו ניטור, תשלומים, איזון עומסים, אינטגרציה רציפה, התראות, החלפת פונקציונליות (סימון תכונה), CDN, הנדסת תנועה (כמו DNS) וכו', שגשגו בעשור האחרון.

יכולת צפייה

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

מעקב מבוזר הפך לטכנולוגיה נוספת שהפכה למיינסטרים בשנות ה-2010 הודות ליוזמות כמו OpenTracing (ויורשתו OpenTelemetry). למרות שהמעקב עדיין קשה לשימוש, חלק מההתפתחויות האחרונות נותנות תקווה שנפתח את הפוטנציאל האמיתי שלה בשנות ה-2020. (הערת תרגום: קרא גם בבלוג שלנו את התרגום של המאמר "מעקב מבוזר: עשינו את זה לא נכוןמאת אותו מחבר.)

מסתכלים אל העתיד

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

פתרון בעיית חוק מור

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

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

CI / CD

בעוד שעליית ה-CI הייתה אחת הטרנדים הגדולים ביותר של שנות ה-2010, ג'נקינס היא עדיין תקן הזהב עבור CI.

מרחב זה זקוק מאוד לחדשנות בתחומים הבאים:

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

כלים למפתחים

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

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

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

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

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

מחשוב (העתיד של PaaS)

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

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

אפשר רק לקנא במי שמשתמש בפתרונות הענן האלה. בתיאוריה, הצעות הענן של Kubernetes (GKE, EKS, EKS on Fargate וכו') מספקות ממשקי API עצמאיים של ספקי ענן להפעלת עומסי עבודה. אם אתם משתמשים במוצרים דומים (ECS, Fargate, Google Cloud Run וכו'), אז כנראה שאתם כבר מנצלים את המרב מהתכונות המעניינות ביותר שמציע ספק השירות. כמו כן, כאשר מוצרים חדשים או פרדיגמות מחשוב צצות, ההגירה צפויה להיות קלה וללא טרחה.

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

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

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

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

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

ממשק API ברמה העליונה הנכון

Docker הוא דוגמה מצוינת לצורך בהפרדה טובה יותר של דאגות במקביל יישום נכון של ה-API ברמה הגבוהה ביותר.

הבעיה עם Docker היא ש(לפחות) בהתחלה, לפרויקט נקבעו יעדים גלובליים מדי: הכל למען פתרון בעיית התאימות ("עובד על המחשב שלי") באמצעות טכנולוגיית קונטיינר. Docker היה גם פורמט תמונה וגם זמן ריצה עם רשת וירטואלית משלו, וכלי CLI, ודמון שרץ כשורש ועוד הרבה יותר. בכל מקרה, ההודעות היו יותר מבלבל, שלא לדבר על "VMs קל משקל", cgroups, מרחבי שמות, בעיות אבטחה ותכונות רבות המעורבבים בקריאה השיווקית "לבנות, לשלוח, להפעיל כל יישום בכל מקום".

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

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

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

כלי השירות Dockerfile ו-CLI docker צריך להוות דוגמה לבניית "ממשק משתמש ברמה הגבוהה ביותר". מפתח ממוצע יכול להתחיל עם Docker מבלי לדעת דבר על המורכבויות יישומים התורמים לניסיון התפעולי, כגון מרחבי שמות, cgroups, מגבלות זיכרון ו-CPU וכו'. בסופו של דבר, כתיבת Dockerfile אינה שונה בהרבה מכתיבת סקריפט מעטפת.

Kubernetes מיועד לקבוצות יעד שונות:

• מנהלי אשכולות;
• מהנדסי תוכנה המעורבים בנושאי תשתית, הרחבת היכולות של Kubernetes ויצירת פלטפורמות המבוססות עליה;
• משתמשי קצה המקיימים אינטראקציה עם Kubernetes דרך kubectl.

גישת "ממשק API אחד מתאים לכולם" שננקטה על ידי Kubernetes היא הר מורכבות חסרת קיבולת ללא אינדיקציה כיצד להרחיב אותה. כל זה מוביל למסלול למידה ארוך שלא לצורך. אֵיך כותב אדם ג'ייקוב, "דוקר הביא חווית משתמש טרנספורמטיבית שעדיין לא התעלתה עליה. שאל כל מי שמשתמש ב-K8s אם הוא רוצה שזה יעבוד כמו הראשון שלהם. docker run. התשובה תהיה חיובית":

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

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

קמעונאות

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

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

עיתונות

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

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

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

רשתות חברתיות

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

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

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

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

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

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

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «טרנספורמציה של Docker: מכירת Docker Enterprise ל-Mirantis ונתיב מעודכן";
• «העבר, ההווה והעתיד של Docker וזמני ריצה אחרים של מיכלים ב-Kubernetes";
• «סטטיסטיקות חדשות של CNCF על קונטיינרים, מקורי ענן ו-Kubernetes";
• «כמה מפתחים חושבים שאין צורך ב-Continuous Integration?".

מקור: www.habr.com