Patrząc na świat Systemów zarządzania treścią (ang. Content Management Systems, CMS), który napędza większość stron internetowych, dobrze znany WordPress jest niekwestionowanym liderem, jeżeli chodzi o udział w rynku. Wykorzystuje się go w ponad 40% wszystkich stron internetowych (wliczając również te, które nie opierają się na żadnym systemie CMS) oraz pokrywa więcej niż 60% pełnego rynku (w 2023 roku, dokładne wartości są nawet wyższe, ale zależą od źródła). Dodatkowo, inne – mniej popularne, ale wciąż rozpoznawalne silniki CMS jak Joomla czy Drupal, wciąż są dostępne.
Wszystkie mają pewną wspólną charakterystykę i funkcjonalności – są już całkiem dojrzałe. Pierwsze ich wersje były wydawane między 2001 a 2005 rokiem jako darmowe, rozszerzalne i otwartoźródłowe (ang. open source) systemy CMS. Wszystkie zostały napisane w języku programowania PHP, który był (i wciąż jest) świetnie wspierany przez większość tanich usług hostingowych. Podsumowując – darmowe oprogramowanie, tani hosting i rozszerzalne funkcjonalności. Wszystkie to brzmi fantastycznie. Jaki jest więc w ogóle sens rozważać komercyjny CMS, który wymaga opłat licencyjnych?
Dobry CMS, czyli jaki?
Są przynajmniej dwa aspekty, którym z pewnością warto się przyjrzeć: wydajność i bezpieczeństwo.
Wysoka wydajność jest absolutnie krytyczna dla biznesów internetowych. Zmuszając użytkowników, żeby poczekali jeszcze jedną sekundę, możemy łatwo doprowadzić do utraty klientów, którzy przełączą się do szybciej działającej konkurencji. Posiadanie całego systemu CMS ze wszystkimi funkcjonalnościami edycji, plug-inami, rozszerzeniami i zewnętrznymi integracjami na jednej maszynie zawsze doprowadzi do pewnych strat wydajności – niezależnie od tego jak dobrze zoptymalizowany jest system.
Bezpieczeństwo to kolejny krytyczny aspekt, który każdy poważny biznes musi brać pod uwagę. Wciąż jest wiele stron internetowych korzystających z darmowych silników CMS, które zostały zhakowane przez jakąś dziurę bezpieczeństwa w samym CMS-ie lub przez niezabezpieczony plug-in lub rozszerzenie zainstalowane w CMS-ie jako dodatek. Takie strony mogą dystrybuować wirusy, kopać kryptowaluty na serwerze lub komputerze użytkownika, wysyłać niechciane notyfikacje do użytkowników albo przekierowywać ich na inne strony internetowe.
Zaatakowane strony, używając wielu trików, mogą nawet przez długi czas wyglądać normalnie oraz zachowywać się naturalnie dla autorów treści i administratorów, dopóki prawdziwi użytkownicy nie zgłoszą problemu. Jednakże – nie mając łatwego sposobu na zgłoszenie sytuacji, przeniosą się raczej do konkurencji. Co bardziej przerażające, wiele stron internetowych wciąż przechowuje prywatne dane użytkowników w tej samej bazie danych, która jest używana bezpośrednio przez System zarządzania treścią – co oznacza, że zhakowany CMS daje hakerom dostęp do tych wszystkich wrażliwych danych.
Środowisko tworzenia i publikacji treści w AEM
I to są właśnie aspekty, gdzie Adobe Experience Manager (AEM), komercyjny CMS dla biznesu, naprawdę błyszczy w porównaniu do innych rozwiązań. Jego architektura rozwiązuje wiele problemów już na poziomie projektu i po prostu nie pozwala na robienie błędów tak łatwo, jak w alternatywnych systemach.
AEM oferuje znaczącą przewagę, zapewniając dwa różne typy instancji:
- środowisko tworzenia treści (zwane również autoringiem, ang. „Authoring”/„Author”) – głównym celem posiadania dedykowanej instancji do tworzenia treści jest zapewnienie funkcji edycyjnych dla autorów treści, podczas gdy instancje publikujące mają być znacznie prostsze (w kategorii dostępnych funkcjonalności),
- środowisko publikacji (ang. „Publishing”/„Publish”) – instancje publikujące powinny głównie renderować strony internetowe, używając danych wypchniętych przez instancję tworzenia treści (operacja zwana „publikowaniem”). Takie instancje nie powinny posiadać funkcjonalności do edycji treści, jak również nie powinny wykonywać niepotrzebnych działań w tle, które mogą być wykonane w instancji dedykowanej do tworzenia treści.
Ta wyraźna linia wprowadza coś, co nazywamy w informatyce separacją zagadnień lub podziałem odpowiedzialności (ang. „Separation of Concerns”).
Wykorzystanie ograniczonych instancji przeznaczonych wyłącznie do publikowania treści, które nie ładują funkcji edycyjnych i które używają opublikowanych danych przeprocesowanych wcześniej przez instancję tworzenia treści, daje wyraźny wzrost wydajności. Co więcej, większość procesów działających w tle jak:
- automatyczne przepływy pracy (ang. „workflows”),
- synchronizacje,
- integracje z zewnętrznymi serwisami,
- procesowanie importu danych oraz eksportu danych
może być wykonane na środowisku tworzenia treści bez wpływu na wydajność środowiska publikującego. Czyni je więc niezauważalnym dla końcowych użytkowników w kategorii prędkości dostarczania strony.
Dodatkowo, architektura AEM definiuje, że instancje autorskie oraz publikujące są sparowane z Dyspozytorami (ang. „Dispatchers”), czyli specyficznymi serwerami Apache z zainstalowanymi modułami AEM Dispatcher. Kiedy następuje żądanie (ang. „request”) z przeglądarki użytkownika o konkretną stronę internetową, Dyspozytor prosi AEM o wyrenderowanie tej strony (w sensie wygenerowania finalnego kodu HTML). Następnie Dyspozytor zapisuje rezultat w pamięci podręcznej (ang. „cache”) i wykorzystuje go do obsługi następnych żądań. Oczywiście, kiedy nowa treść jest publikowana, wtedy zapisy w pamięci podręcznej są poprawnie unieważniane (ang. „invalidated”).
AEM działa naprawdę dobrze z wieloma głównymi Sieciami dostarczania treści (ang. Content Delivery Network, CDN), więc jest możliwe dodanie dodatkowej geograficznej warstwy dystrybucji pamięci podręcznej, aby jeszcze szybciej serwować strony internetowe dla końcowych użytkowników.
Różnice pomiędzy środowiskami w AEM
Instancja autorska (tworzenia treści) działa zazwyczaj w chronionym środowisku – w prywatnej chmurze lub prywatnej sieci korporacyjnej, niedostępnej publicznie w Internecie, ale przez Wirtualną sieć prywatną (ang. Virtual Private Network, VPN). Zazwyczaj taka instancja nie jest łatwo dostępna przez Internet, więc nie wystawia ona możliwości edycyjnych i dodatkowych funkcjonalności tworzenia treści dla hakerów. Nawet jeśli przyjmiemy podobną szansę znalezienia dziury bezpieczeństwa jak w innych Systemach zarządzania treścią, to nie są one wyeksponowane publicznie.
Na instancjach publikujących, które teoretycznie są bliżej sieci publicznej, wiele funkcjonalności nie jest dostępnych, co ogranicza potencjalną powierzchnię do ataku. Sekrety konfiguracji potrzebne do przetwarzania w tle, takie jak dane logowania do źródeł danych czy klucze dostępowe do zewnętrznych usług, mogą być trzymane tylko na „Autorze”, ponieważ nie są one potrzebne na instancjach publikujących. Nie zapominajmy jednak o Dyspozytorach, które są „frontowymi drzwiami” do AEM-a i które mogą filtrować część niechcianego ruchu, dodawać kolejny poziom bezpieczeństwa oraz odporność na rozproszony atak w celu odmowy usługi (ang. Distributed Denial Of Service, DDoS).
Inne aspekty dobrego CMS-a
Poza wydajnością i bezpieczeństwem, są jeszcze inne ważne aspekty takie jak:
- łatwość użycia,
- wbudowane i gotowe do użycia funkcjonalności,
- łatwość w utrzymaniu,
- użyte technologie,
- integracje z zewnętrznymi usługami,
- umowa o gwarantowanym poziomie świadczenia usług (ang. Service Level Agreement, SLA),
- wsparcie techniczne i wiele więcej.
Większość z nich, jeśli nie wszystkie, mogą wyraźnie wykazać przewagę Adobe Experience Manager nad innymi popularnymi silnikami CMS, zarówno darmowymi jak i komercyjnymi. Co więcej, AEM jako usługa chmurowa (AEM as a Cloud Service) wznosi to wszystko na zupełnie nowy poziom. Więcej w tym temacie możesz przeczytać tutaj.
Podsumowanie
Jako inżynier oprogramowania, który spędził 8 lat budując i rozwijając strony internetowe w Adobe Experience Manager dla wielu ogólnie znanych globalnych firm, muszę przyznać, że wciąż podziwiam, jak dobrze został on zaprojektowany w swych fundamentach. Zapewnia naprawdę świetny system CMS, który łatwo dostosować do potrzeb klienta, zachowując przy tym wysoki poziom jakości kodu, jego czytelność oraz ogólną stabilność.
I choć wiele świetnych technologii użytych w AEM-ie zostało stworzonych z myślą o dedykowanym zastosowaniu ich w tym CMS-ie, zostały one później wydane w formie otwartych kodów źródłowych (m.in.: JCR, Jackrabbit i Sling), a wokół nich utworzyła się wyraźna społeczność i postęp rozwojowy, poza samym AEM-em. To dlatego świat Adobe Experience Managera może być tak fascynujący dla programistów, jako coś kompletnie innego od tego, co już znają, w bardzo pozytywnym sensie.
Artykuł nie jest sponsorowany przez Adobe* Wszystko powyżej jest moją szczerą opinią, bazującą na własnym doświadczeniu z AEM-em 😊
Sii jest profesjonalnym partnerem Adobe, który zapewnia dedykowane rozwiązania z zakresu Adobe Experience, niestandardowe rozwiązania w zakresie oprogramowania idealnie dostosowane do potrzeb klienta i całodobowe utrzymanie i zarządzanie platformami, pomagając międzynarodowym biznesom osiągać sukces.
***
* Żaden artykuł na naszym blogu nie jest sponsorowany
***
Jeśli interesuje Cię tematyka AEM, zajrzyj również koniecznie do innych artykułów naszych ekspertów:
Zostaw komentarz