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

אתרי תוכן משמעותיים מתאפייינים בדרך כלל במספר תכונות

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

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

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

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

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

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

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

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

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

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

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

הארכיטקטורה הזו הצריכה שינויים גם לתהליך ה CI/CD ו ALM אשר מתאימים לכתבה נוספת.