W oparciu o nasze obserwacje zebrane w trakcie wielu wdrożeń systemów masowej przepustowości, skonstruowaliśmy własny model budowy takich rozwiązań. U jego podstaw stoi – stworzona przez nas – platforma programistyczna, umożliwiająca tworzenie niezwykle wydajnych i skalowalnych systemów dla szczególnie wymagających klientów. Platforma ta jest fundamentem wielu naszych wdrożeń.
Podstawę naszych rozwiązań stanowi zunifikowana platforma programistyczna (a więc taka sama w wielu instalacjach), na której uruchamiane są mikrousługi (nazywane przez nas kiedyś, zanim powstało pojęcie mikrousługi, modułami lub konwerterami) dostosowane do potrzeb naszego klienta (a więc różne w zależności od instalacji). Z jednej więc strony oznacza to, że nie budujemy systemów od zera, bo korzystamy ze stabilnej, przetestowanej i funkcjonującej w wielu wdrożeniach platformy. Z drugiej strony, taka metoda działania pozwala nam na maksymalne dostosowanie się do potrzeb klienta i tworzenie rozwiązań precyzyjnie zoptymalizowanych pod kątem jego oczekiwań.
Stworzona przez nas platforma Atom jest naszą dumą. Powstała z myślą o wydajności i skalowalności tak, by można było na jej podstawie budować wyrafinowane systemy, w tym w szczególności systemy masowej przepustowości.
Wystarczy powiedzieć, że platforma Atom w typowych przypadkach pozwoli na przetwarzanie w gridzie dziesiątek tysięcy transakcji na sekundę, przy zastosowaniu zupełnie zwyczajnego sprzętu komputerowego. Przy odpowiednim zaprojektowaniu struktur danych i zapewnieniu sprzętu komputerowego do pracy w gridzie, Atom może procesować nawet setki tysięcy i miliony transakcji w ciągu sekundy.
Dowiedz się więcej o platformie Atom:
GENEZA PLATFORMY ATOM
Przy wdrożeniach systemów informatycznych stosować można wiele konkurencyjnych metodologii. Niestety zdecydowana większość tych metodologii jest zupełnie bezużyteczna w systemach masowych przepustowości, którymi się zajmujemy. Ich wady w niektórych wdrożeniach ujawnić się mogą w szczególnie dotkliwy sposób. Zasada jest prosta – tam gdzie potrzeba maksymalnej wydajności i skalowalności, stosowanie zwykłych rozwiązań nie ma sensu.
W trakcie wielu lat rozwoju naszej spółki rozważaliśmy też różne modele tworzenia systemów masowej przepustowości:
| Testowany model tworzenia | Nasze obserwacje |
| Stworzenie jednej gotowej aplikacji “z półki” – dobrej dla wszystkich klientów i bez ograniczeń funkcjonalności | Okazało się jednak, że niemożliwe jest przygotowanie gotowej aplikacji tego typu. Byłaby ona zbyt złożona dla części naszych klientów – a dla części zbyt trywialna. Odmienność wymagań i oczekiwań powodowała całkowitą niemożność znalezienia wspólnego mianownika dla wszystkich klientów. Co więcej, aplikacja taka na pewno nie byłaby systemem masowej przepustowości – nie byłaby w stanie procesować dowolnych danych w zoptymalizowany sposób.Również konfiguracja takiej aplikacji mogła być zadaniem bardzo czasochłonnym. A chcieliśmy uniknąć dość powszechnego zjawiska kiedy konfiguracja niektórych gotowych systemów zajmuje tyle, ile wytworzenie takiego systemu “od zera”. |
| Stworzenie gotowej aplikacji “z półki” – ale z ograniczoną funkcjonalnością, tak aby realizowała podstawowe oczekiwania klientów | To rozwiązanie również ma niewielki sens. Optymalizacja systemów masowej przepustowości oznacza bowiem konieczność konstrukcji struktur danych. Za każdym razem mogą być one inne. Jak więc wybudować nawet trywialny system „pudełkowy” bez struktur danych? To niemożliwe. |
| Tworzenie systemów na zamówienie | To podejście jest nam najbliższe, gdyż od 1995 roku wdrażaliśmy systemy w taki właśnie sposób. Metoda ta umożliwia tworzenie bardzo wydajnych rozwiązań dostosowanych do konkretnych potrzeb. Spełnia więc założenia jakie stawiamy przed systemami masowej przepustowości. Co więcej, klient płaci wyłącznie za to z czego realnie korzysta.Niestety każde takie wdrożenie jest unikalne. Błędy znalezione w jednym systemie są zupełnie inne niż błędy znalezione w systemie drugim. Oznacza to, że wszelkie poprawki (również upgrade’y) trzeba przygotowywać osobno. To powoduje zwiększenie kosztów serwisu i szeroko rozumianego utrzymania aplikacji. |
Porównanie metod tworzenia systemów
Poniżej przedstawiamy porównanie metod tworzenia aplikacji
| Aplikacja z półki o podstawowej funkcjonalności | Rozbudowana aplikacja z półki o pełnej funkcjonalności | Aplikacja tworzona i wdrażana na specjalne zamówienie | Aplikacja na zamówienie z użyciem platformy programistycznej | |
| Wydajność | “-“ | “-“obszerne konfigurowalne środowiska mają spory narzut na ową konfigurowalność – kosztem wydajności | “+”doskonała – system jest projektowany z uwzględnieniem wszystkich oczekiwań wydajnościowych klienta | “+”platforma programistyczna zapewnia maksymalną skalowalność i wydajność (grid/chmura). Zarówno struktury danych, jak i same moduły mogą być dowolnie optymalizowane |
| Funkcjonalność | “+/-“do podstawowych zadań bardzo dobra, ale do bardziej skomplikowanych wdrożeń –niewystarczająca | “+”czasem nawet za dużo | “+”idealnie dopasowana do potrzeb klienta | “+”idealnie dopasowana do potrzeb klienta |
| Łatwość wdrażania | “+” | “+”w rozbudowanych konfigurowalnych systemach, konfiguracja jest osobną dziedziną wiedzy i może (choć nie musi) być równie trudna, jak napisanie systemu od zera; bywa też, że klient musi dostosować się w pewnych rozwiązaniach do systemu | “-“całą aplikację trzeba niestety zaimplementować – łącznie ze wszystkimi nawet standardowymi mechanizmami, z drugiej strony aplikacja dostosowana jest do firmy w której ma działać – lepiej do niej pasuje i łatwiej się ją wdraża (np. szkolenia nie dotyczą nowej metodologii podejścia do systemu, a dotyczą wyłącznie zasad obsługi systemu) | “+”platformy używane przez nas są gotowe. Łącznie ze standardowym interfejsem użytkownika. Trzeba stworzyć nadbudowę |
| Czas wdrażania | “+”bezkonkurencyjny | “-“zdarzają się przypadki, że skonfigurowanie rozbudowanej, konfigurowalnej aplikacji ze względu na poziom komplikacji, zajmuje tyle czasu co napisanie odpowiedniego systemu “od zera” | “-“ | “+”znacznie krótszy niż w przypadku tworzenia systemu od zera, platformy dostępne są od razu. Można się też łatwo oprzeć o już istniejące konfiguracje |
| Klient płaci za to, z czego rzeczywiście korzysta | “-“ | “-“klient i tak płaci za aplikację, w efekcie, jeśli nie życzy sobie pewnej opcji, płaci za nią w standardzie i płaci za jej usunięcie w trakcie konfiguracji… | “+”to jedna z podstawowych zalet | “+”klient kupuje co prawda zawsze całą platformę, ale też praktycznie zawsze całą platformę wykorzystuje |
| Dostęp do uaktualnień / współdzielenie kodu z innymi użytkownikami | “+” | “-/+”(częściowe – zależy od tego jak bardzo konfiguracja zmieniła fundamenty systemu) | “-“ | “+”w zakresie platformy –pełny dostęp, w zakresie nadbudowy – tak, jeśli daną nadbudowę zainstalowano u wielu klientów |