Muszę Wam (czytelnikom, ale też współpracownikom) do czegoś się przyznać. Gdy obejmowałem funkcję CTO (Chief Technology Officer) w Wilda Software i pracowałem między innymi nad infrastrukturą oraz wewnętrznymi systemami wykorzystywanymi w zespole, cały czas miałem na uwadze, że powinniśmy stawiać na self-hosting, czyli samodzielne hostowanie rożnych kawałków oprogramowania. Powodem było przekonanie, że w ten sposób będziemy mieli większą kontrolę, unikniemy problemów wynikających z braku dostępów do usług, możliwych naruszeń bezpieczeństwa (mimo że jak najbardziej korzystamy z zewnętrznych serwerów), ale był jeszcze jeden argument - "przecież jesteśmy firmą IT, a w tej branży się tak robi, bo to świadczy o profesjonalizmie". Prawda? Otóż, nie do końca.

Po kilku latach i nabyciu większego bagażu doświadczenia, dotarło do mnie (i generalnie nas jako zespołu), że owszem, self-hosting ma swoje duże zalety oraz jest po prostu ciekawy dla osób z zewnątrz, ale, niestety, posiada też swoje wady i o ile w wydaniu bardziej amatorskim lub bez planów zarabiania część słabości ma mniejsze znaczenie, o tyle w działającej na rynku organizacji stanowią duże wyzwanie, a czasem nawet i blokują przedsięwzięcia. Słowem - self-hosting nie jest idealnym rozwiązaniem w każdym przypadku, a nawet tam, gdzie wydaje nam się, że jest najlepsze, sytuacja może się zmienić, kiedy mówimy o zespole mającym dostarczać rozwiązania biznesowe dla swoich klientów, których przecież nie interesuje, jaką infrastrukturę ma software house - on ma po prostu wykonać swoją pracę i przynosić wartość.

Zdaję sobie sprawę, że są osoby, które czytając te słowa rwą sobie włosy z głowy, gdyż self-hosting jest szczególnie istotny w kontekście prywatności, uniezależnienia od Big Techów itd.. Przepraszam takich czytelników - dzisiaj będę adwokatem diabła, ale też będę bazował na swoich doświadczeniach. Omówmy sobie dzisiaj zatem problemy, które dotyczą samodzielnego gospodarowania aplikacjami, a o których niektórzy zapominają, entuzjastycznie myśląc, że staną się odporni na wszelkie zło świata technologicznego.

Czym jest self-hosting?

Zacznijmy jednak od kwestii podstawowej, ale być może nie wszystkim znanej - o czym w ogóle dzisiaj będziemy rozmawiać? Self-hosting to korzystanie z oprogramowania, które sami hostujemy, tj. sami je wdrażamy na serwer i konfigurujemy pod nasze potrzeby. Jest to opozycja w stosunku do modelu chmurowego SaaS (Software as a Service), w którym zakładamy konto w usłudze udostępnianej przez zewnętrzną firmę, najczęściej płacąc za to abonament. Najprostszym przykładem może być posiadanie systemu zarządzania zadaniami - można założyć konto na serwerze Jiry i w ten sposób prowadzić projekty w zespole. Ale można też pobrać Redmine'a i postawić go na swoim serwerze. Nieco wybiegając w przyszłość - akurat w tym aspekcie w Wilda Software postawiliśmy na self-hosting, choć poszliśmy jeszcze dalej.

Takie "samogospodarowanie", jak wcześniej napomknąłem, zwykle dotyczy oprogramowania, a więc jest to self-hosting software'owy. W tym modelu bierzemy gotowe oprogramowanie do wdrożenia (najpopularniejszym systemem tego typu jest Wordpress do tworzenia stron), instalujemy zgodnie z instrukcją, a później - w zależności od potrzeb i możliwości - konfigurujemy i modyfikujemy. Zdarzają się jednak sytuacje, w których organizacja chce tak bardzo uniezależnić się od innych dostawców, że decyduje się na self-hosting hardware'owy, przynajmniej częściowy - zwykle oznacza to, że firma kupuje fizyczny serwer i sprowadza go do swojej siedziby, mając nad nim także bardziej manualną kontrolę, nierzadko odcinając go od Internetu. Krótko mówiąc - firma robi sobie małą serwerownię. To zdecydowanie mniej popularna "zabawa", gdyż wiąże się z większymi kosztami, zapewnieniem warunków oraz potrzebną wiedzą, aby to wszystko obsłużyć. Sami spotkaliśmy w trakcie naszych karier i obsługi dziesiątek lub setek klientów bodajże cztery przypadki, w których współpracujące firmy zdecydowały się na taki ruch, co wynikało albo z posiadania odpowiedniego komputera na miejscu i chęci jego wykorzystania, albo konkretnych wskazań związanych z cyberbezpieczeństwem. Natomiast zazwyczaj mówimy wówczas o klientach posiadających swoich specjalistów IT i administratorów na miejscu. Trzeba też jasno powiedzieć, że w niektórych przypadkach kupno takiego serwera było nieuzasadnione.

Zdecydowanie najczęstszym przykładem self-hostingu jest jednak pobranie wersji instalacyjnej gotowego oprogramowania i wdrożenie go na kupiony gotowy serwer w chmurze - i tak już wtedy mamy dużą kontrolę nad danymi, gdyż zazwyczaj posiadamy dostęp do bazy danych, a z drugiej strony sam serwer jest zabezpieczany przez specjalistów w swoim fachu, czyli firmy hostingowe. Jeśli nie cechują nas jakieś bardzo szczegółowe wymagania lub dane o wysokim stopniu poufności, to w większości przypadków hardware'owy self-hosting będzie zbyt ciężką kulą u nogi.

Co nie znaczy, że software'owy self-hosting (na którym się skupimy w artykule) też nie może być taką kulą.

Self-hosting wymaga zasobów

Na początek dość oczywista rzecz, którą zresztą już wyżej zasygnalizowałem. W przypadku usług SaaS abonament za korzystanie z nich pokrywa wynagrodzenie dla zespołu, ale też koszty stałe i niestałe, które usługodawca ponosi, w tym utrzymanie serwerów. W zamian jako użytkownicy nie musimy przejmować się takimi rzeczami jak konserwacja komputerów, dostawy energii elektrycznej, wymianę dysku itd. Oczywiście, trochę przepłacamy, ale to też trzeba zrozumieć - w zamian kupujemy sobie spokój. To trochę tak, jak inwestowanie w gotowe fundusze, gdzie tylko dajemy pieniądze, a specjaliści za nas nimi zarządzają i biorą za to prowizję.

Gdy decydujemy się na self-hostowanie jakiegoś oprogramowania, to odpowiadamy za instalację, konfigurację oraz monitorowanie danej aplikacji. O tym będzie nieco więcej w kolejnym punkcie, natomiast musimy też mieć serwer, na którym to wszystko uruchomimy. A taką maszynę (wirtualną lub fizyczną) trzeba opłacać niezależnie od tego, ile kosztuje sama obsługa oprogramowania. Jeśli dodatkowo decydujemy się na tzw. zarządzany VPS (ang. VPS managed), to znowu zyskujemy trochę spokoju, ale opłacamy administratorów, którzy za nas wykonują pewne zadania. Krótko mówiąc - musimy zadbać o zasoby na własną rękę, podczas gdy w przypadku usług chmurowych taki koszt może jest większy, ale rozkłada się na większą grupę osób.

A jest jeszcze kwestia plików - wiele aplikacji pozwala je wgrywać i jeśli nie doszacujemy ogromu informacji, które chcemy przechowywać, może się okazać, iż zabraknie nam przestrzeni dyskowej. Wówczas należy albo zrobić przegląd i czyszczenie (czas, nerwy, niepewność), albo dokupić miejsce na dysku u dostawcy (co nie zawsze jest możliwe u wszystkich hostingodawców i czasem trzeba...), albo przenieść się na większy serwer (koszty), albo przerzucić pliki na tzw. storage, czyli "teoretycznie nieograniczoną" przestrzeń dyskową (koszty i czas potrzebny na przekonfigurowanie). Gdybyśmy korzystali z usługi chmurowej, to zajmuje się tym administracja tej usługi i nie musimy się o to martwić (chyba że z góry są postawione limity, ale najczęściej można je zwiększać).

Dlatego self-hosting ma więcej sensu, kiedy i tak kupujemy serwer lub serwery, na których skonfigurujemy więcej usług, a nie tylko jedną, chyba że jest ona szalenie istotna. A zauważcie, że cały czas mówimy tutaj o samogospodarowaniu oprogramowaniem - jeśli w grę wchodzi postawienie fizycznych maszyn w naszej siedzibie, to koszty (i stres) diametralnie rosną.

Self-hosting wymaga wiedzy i czasu

To chyba najbardziej niedoceniany punkt w zabawie polegającej na hostowaniu usług na swoich zasobach. Wiele osób myśli, że są gotowe kawałki oprogramowania, przygotowane paczki i instrukcje do ich wgrywania, więc wystarczy postępować według kroków na swoim serwerze i mamy piękną usługę, nie musząc płacić tym krwiopijcom ze swoimi usługami w chmurze. Brzmi pięknie? Do czasu.

Pamiętajcie bowiem, że:

• jesteśmy całkowicie odpowiedzialni za oprogramowanie, które hostujemy - nie mamy supportu, który nam pomoże, a jeśli takowy istnieje, to trzeba z nim kontaktować się indywidualnie w ramach naszego planu,
• gotowe paczki czasami są w technologii, w której na co dzień nie działamy, więc wypada ją poznać, na co potrzeba czasu,
• od czasu do czasu trzeba zaktualizować oprogramowanie, co oznacza np. restart usług i wykonywanie określonych komend. A jeśli dana technologia nie jest naszą domeną, to: patrz poprzedni podpunkt,
• prawie nigdy instrukcje dostarczone z oprogramowaniem nie przekładają się idealnie na każde środowisko, szczególnie w przypadku bardziej skomplikowanych systemów (tutaj pewnym ratunkiem jest konteneryzacja) - to oznacza, że trzeba stać się specjalistą od danego systemu, który hostujemy, a z tym jest zawsze trudniej niż w przypadku oprogramowania, które sami sobie napiszemy lub usługi, na którą się zdajemy w chmurze,
• to wszystko wymaga czasu, chęci pracowników (czasem oddelegowania kogoś do opieki) i nierzadko odrywa od właściwej działalności firmy.

I teraz przyznam się do czegoś, do czego nie powinienem, szczególnie jako CTO i współwłaściciel software house'u, ale szczerość jest w cenie. Tak, jak pisałem, w momencie, kiedy rozpoczynaliśmy działalność, nie wyobrażałem sobie, że nie będziemy korzystać z self-hostowanych usług, wśród których było między innymi narzędzie do zarządzania repozytoriami Gogs oraz Redmine do zarządzania projektami (więcej o naszym stosie technologicznym można przeczytać w tym artykule). W tym akapicie pomijamy, czy to były dobre wybory pod kątem jakości - bardziej skupmy się na aspekcie technicznym. Gogs (co też widać po nazwie) został zbudowany w oparciu o język Go, a Redmine - o język Ruby. Tymczasem my w zespole skupiamy się na technologiach związanych z PHP oraz JavaScriptem (w tym Node.js). Oczywiście, jak w większości software house'ów, jesteśmy w stanie przenosić się pomiędzy różnymi językami i frameworkami, jeżeli wymaga tego dany projekt klienta, natomiast nie da się ukryć, że - ponownie, jak każdy zespół - mamy swoje preferencje i punkty, w których jesteśmy najbardziej efektywni. To oznacza, że wsiąkanie w technologie i frameworki związane z Go oraz Ruby tylko po to, aby w razie potrzeby móc naprawić dwa self-hostowane narzędzia (co zdarza się może raz na rok) nie jest czymś opłacalnym. To z kolei sprawia, że wszelkie podbramkowe sytuacje i awarie wiążą się z pewnym stresem, nie tylko ze względu na niedziałającą usługę, ale też niepewność w kwestii samodzielnej obsługi.

Jeśli nie umiemy sami złożyć trzyrzędowej szafy i spędzilibyśmy nad tym wiele godzin, które moglibyśmy spożytkować w inny sposób (np. zarobić na tym, na czym się znamy), to często lepiej jest zapłacić firmie, który zrobi to szybciej, sprawniej i za nas. Tak samo jest z oprogramowaniem i między innymi ze zmianą Gogsa na chmurowego Githuba - po drodze rozważaliśmy choćby samodzielnie postawienie Gitlaba, ale licząc wszystkie koszty oraz konieczność obsługi oprogramowania napisanego nie w naszym macierzystym języku, zrezygnowaliśmy.

Oczywiście, to tylko jedna strona medalu - czasem warto wyjść ze strefy komfortu, poznać coś nowego, nabyć dodatkowe umiejętności, a także zwrócić uwagę na inne aspekty niż pieniądze (np. prywatność danych), jednak generalnie należy rozważyć wszystkie punkty i wziąć pod uwagę, do czego nam to będzie służyć. Gdyż, jak już pisałem, perspektywa zmienia się w momencie, kiedy mówimy o profesjonalnym środowisku, w którym nie chodzi już tylko o dobrą zabawę i naukę, ale o zawodowe świadczenie usług, do których trzeba posiadać pewne i funkcjonalne środowisko.

Self-hosting nie jest dostępny dla wszystkich rozwiązań

Wróćmy na chwilę do kwestii Gogsa - rozważenie jego zmiany nie wiązało się tylko z technologią, w której powstał, ale też ograniczonymi możliwościami względem Gitlaba czy Githuba, które zwyczajnie zaczęły nam ciążyć wraz z rozwojem firmy (z tego powodu w grę nie wchodziła też np. Gitea). Do tego dochodzą wymagania zespołów technicznych części klientów. To prowadzi nas do kolejnego punktu - w większości obszarów znajdą się odpowiedniki możliwe do self-hostowania, ale czy zawsze będą równie funkcjonalnym zamiennikiem względem komercyjnych usług? Szczerze mówiąc, rzadko.

Oczywiście, nie każda firma potrzebuje rozwiązania najlepszego i najbardziej rozbudowanego w swojej klasie. Nie każdy dział sprzedażowy wykorzystuje wszystkie moduły swojego CRM-a, nie każda firma IT potrzebuje wszystkie fajerwerki Gitlaba, a nie każdy duży zespół potrzebuje komunikatora "all-in-one". Nie bez powodu istnieją różne plany abonamentowe czy zwyczajnie inne usługi, gdyż po prostu każdy ma swoje potrzeby. Jak to się wiąże z self-hostingiem?

To prawda, że nie wszystkie tego typu usługi są darmowe, ale duża część z nich faktycznie jest. Czasem są to uproszczone wersje znanych aplikacji dostępnych w chmurze, a czasem oprogramowanie open source tworzone przez pasjonatów z nadzieją na osiągnięcie czegoś więcej. I choć nie można tego przekładać jeden do jednego, to jednak nie bez powodu najbardziej dopracowane pod kątem biznesowym rozwiązania są dostępne w formie abonamentowej i obsługiwane przez większe firmy. Prawda jest taka, że jeśli budżet jest większy, to (przy dobrym zarządzaniu i chęciach) można robić większe rzeczy. Ale też wówczas oczekiwana jest za to odpowiednia gratyfikacja.

Tutaj uwaga - to nie oznacza, że self-hostowe rozwiązania nie są godne rozważenia, bo z automatu wszystkie są gorsze. Absolutnie nie - ich przewagą często jest to, że są opensource'owe i rozwijane przez społeczność, która wzajemnie poprawia oprogramowanie i wskazuje sobie rzeczy do rozwoju. Dobry CRM udostępniony do self-hostowania jest lepszy niż kiepski CRM w chmurze. Tym niemniej, trzeba mieć świadomość, że nikt pracujący tysiące godzin nad czymś, co wypuści potem do samodzielnego postawienia, nie będzie tego robił za darmo, chyba że kierują nim bardziej szczytne idee (którymi, niestety, nie da się nakarmić rodziny). Wiem, że jestem teraz cyniczny, bo w życiu nie chodzi tylko o pieniądze i to też jest prawda. Ale na palcach jednej ręki można policzyć rozwiązania, które realnie, pod każdym (funkcjonalnym i pozafunkcjonalnym) względem dorównują tuzom każdego obszaru. Są takie systemy, a i nawet te prostsze ich wersje są często wystarczające, ale umówmy się - nie bez powodu w większości firm widzimy np. Jirę, Asanę, Monday.com czy coś podobnego, a nie OpenProject oraz Redmine. Większym wzięciem cieszy się Slack czy Microsoft Teams niż Rocket.Chat.

Wreszcie, są obszary, w których własnoręczne hostowanie wiąże się naprawdę z dużymi zasobami. Przykładem może być własna instancja PeerTube, czyli fediwersowa wersja YouTube'a, w której - jak można się domyślić - hostujemy też nasze filmy. A biorąc pod uwagę ich rozmiar, w tym przypadku naprawdę trzeba dobrze przemyśleć krok w kierunku self-hostingu.

Self-hosting wymaga zabezpieczeń technicznych i prawnych

Wiemy już, że self-hosting wymaga odpowiednich zasobów, większych lub mniejszych w zależności od oprogramowania i stopnia self-hostingu. To też automatycznie pociąga za sobą konieczność odpowiedniego zabezpieczenia tych zasobów - reguły firewalla, prawa dostępu, czasem VPN i generalnie coś, co nazywa się "hardeningiem". Niby wszyscy o tym wiedzą, choć czasem lekceważą. Natomiast nie łudźmy się - nie każdy informatyk jest w stanie prawidłowo ustawić całe środowisko serwerowe i zadbać o nie. Czasem wynika to z braku wiedzy (co nie jest niczym wstydliwym, gdyż ta dziedzina jest ogromna, a będzie coraz większa), a czasem z przywoływanego już często braku czasu. Wybierając usługę w chmurze, zawierzamy usługodawcy, że potrafią dbać o nasze dane oraz odpowiednio je chronić. Oczywiście, często robimy to nie mając pojęcia, jak wyglądają realne procedury wewnątrz zespołu i to jest argument fanów self-hostingu. Niebezpodstawny, dodajmy. Tym niemniej, komuś trzeba zaufać i należy przy tym wziąć pod uwagę zarówno chęci, jak i umiejętności.

Bywają też sytuacje, w których występują konkretne obostrzenia prawne dla organizacji udostępniającej usługę. W przypadku, kiedy self-hostujemy coś nie tylko dla siebie, ale także osób trzecich, dotyka to także nas. Jeszcze bardziej dotyczy to sytuacji, w której udostępniamy własnoręcznie wykonany system. W zależności od poziomu zabezpieczeń prawnych, które są potrzebne, self-hosting może się wiązać ze zbyt dużym ryzykiem pod kątem regulaminowym.

Self-hosting wymaga szybkiego działania w przypadku awarii

Ten wątek został wspomniany przy okazji poprzednich punktów, ale powiedzmy to sobie jasno - oprogramowanie czasem przestaje działać. Może mieć to związek z błędami w samej aplikacji, może to być kwestia zewnętrznych usług (np. serwera pocztowego), czasem problem wynika z samej maszyny, na której działa aplikacja. Ostatnio mieliśmy też przypadek, kiedy koparka działająca niedaleko klienta, przy okazji kopania w ziemi (co zwykle takie pojazdy robią), przecięła światłowód i z tego powodu przestały działać usługi hostowane w infrastrukturze tej firmy. Przypadki są różne, ale łączy je jedno - trzeba coś z tym zrobić.

W momencie, kiedy hostujemy taką usługę, to na nas spada obowiązek naprawienia jej. Czasem jest to proste i wystarczy zrestartować maszynę lub odpowiedni serwis... o ile wie się, jak to zrobić. Często w dokumentacji znajdują się recepty na najczęstsze problemy. Ale niekiedy konieczne jest diagnozowanie czegoś bardziej specyficznego i wówczas bez wiedzy o technologii i samym systemie IT taka osoba jeszcze bardziej przeklina pomysł o self-hostingu.

Oczywiście, przedstawiam to trochę w czarnych barwach, ale nadal pamiętajmy, że nie każdy jest administratorem i ma wystarczająco dużo czasu, aby oprócz podstawowych obowiązków ogarnąć jeszcze obce oprogramowanie. Owszem, może się to przydać (o czym za chwilę), ale pamiętajmy, że awarie się zdarzają i lepiej być wówczas po stronie tylko narzekających na to, a nie próbujących w pocie czoła sobie z tym poradzić.

Czy zatem self-hosting jest zły?

Absolutnie nie. Ten artykuł nie ma na celu udowodnienia, że samodzielne hostowanie oprogramowania wiąże się tylko i wyłącznie z negatywami, bo tak nie jest. Są też pozytywne strony, gdyż w końcu z jakiegoś powodu takie rozwiązania nadal powstają. Natomiast chciałbym zwrócić uwagę, że nie należy przesuwać wajchy w drugą stronę - self-hosting to nie tylko cud, miód, orzeszki i uniezależnienie się od wszelkich fluktuacji w dużych firmach. To po prostu wzięcie na siebie obowiązku, na który nie wszyscy są i będą gotowi. W teorii posiadanie wszystkiego na swoich serwerach brzmi fantastycznie, ale istnieją też praktyka i - przede wszystkim - warunki, w jakich działamy.

Tym niemniej, na pewno można wymienić zalety self-hostingu:

• uniezależnienie się od zewnętrznej firmy lub (częściej w dzisiejszych czasach) zmian w oprogramowaniu w usłudze chmurowej,
• kontrola nad danymi, zarówno w bazie, jak i plikach,
• psychologiczne poczucie niezależności (tak, to też bywa ważne),
• potencjalnie niższe koszty (zależnie od usługi i formy zorganizowania jej działania),
• możliwość wykorzystania tego PR-owo,
• kontrolę nad aktualizacjami i potencjalnie bardziej stabilne oprogramowanie - jeśli coś postawimy i działa, to sami decydujemy, kiedy zmodernizować wersję systemu.

Jest też inna potencjalna przewaga, którą można wziąć pod uwagę w momencie, kiedy mówimy o środowisku firmowym - znajomość konkretnego oprogramowania, które można samemu skonfigurować, pozwala świadczyć dodatkowe usługi dla klientów. Wyobraźmy sobie sytuację, w której ktoś widzi w naszym środowisku całkiem sympatycznie wyglądający system CRM (ang. Customer Relationship Management) i dowiaduje się, że też może mieć taki u siebie. Wówczas pada sakramentalnie pytanie "a zrobicie to też u nas? Zapłacimy wam za to!". Jeśli zespół ma odpowiednią wiedzę na temat danego oprogramowania i jest w stanie nim zarządzić, to zyskuje potencjalną przewagę konkurencyjną w postaci możliwości konfigurowania pewnego typu oprogramowania (a czasem nawet modyfikacji) u klienta lub po prostu udostępnienia swoich zasobów.

Self-hosting na przykładzie Wilda Software

Wspominałem o tym, że o ile na początku działalności mieliśmy ściśle self-hostingowe zacięcie i poczucie, że "tak się po prostu robi", tak z biegiem lat zaczęło się to u nas zmieniać. Spędzając lata nad projektami klientów zaczęliśmy mieć refleksje na temat tego, gdzie rzeczywiście warto było postawić na swoje, a gdzie nie. Natomiast nie da się ukryć - taka wiedza przychodzi z doświadczeniem, a to pojawia się wraz z czasem. Dlatego, jeśli czytacie teraz te słowa i wydaje Wam się, że tylko nienormalny rezygnowałby z self-hostingu, jeśli już się na niego zdecydował, to albo macie większe zacięcie do tego, albo... po prostu wszystko przed Wami.

W przypadku systemu do zarządzania repozytoriami na początku samodzielnie hostowaliśmy Gogsa, który ma tę zaletę, że jest prosty, mały, a jednocześnie funkcjonalny. Niestety, z czasem fakt napisania go w języku Go (z którym na co dzień nie pracujemy), ale przede wszystkim brak pewnych funkcji CI/CD i dotyczących pull requestów sprawił, że musieliśmy pomyśleć o alternatywie i o ile przez długi czas był rozważany self-hostowany Gitlab, to po przeliczeniu wszystkiego (nie tylko kosztów) zdecydowaliśmy się jednak na Githuba.

Komunikatorem u nas nadal jest Slack, a więc chmurowe rozwiązanie, aczkolwiek były już przymiarki do innych rozwiązań, w tym także self-hostowych. Jednakże na ten moment nadal korzystamy z oprogramowania przedstawianego białą ikonką z różnymi kolorami.

Zmiany zupełnie zaprzeczające wydźwiękowi tego artykułu dzieją się u nas w obszarze zarządzania projektami. Do tej pory korzystaliśmy z Redmine'a oraz - nieco później - z własnoręcznie napisanego Feedybacky'ego. Z czasem ten drugi, z pierwotnej funkcji systemu obsługi zgłoszeń od klientów zaczął być pierwszorzędnym narzędziem, którego potrzebujemy i wykorzystujemy do naszych przedsięwzięć. Dlatego w tym obszarze rozwijamy nie tylko self-hostingowe rozwiązanie, ale wręcz pod każdym względem nasze. Co nie oznacza, że zatrzymujemy je tylko na siebie - jeśli tylko chcesz cieszyć się z chmurowej wersji Feedybacky'ego lub postawić go i dostosować pod siebie, to zachęcamy do kontaktu.

Self-hostingowa skrzynka pocztowa to nie jest rozwiązanie, na które byśmy się zdecydowali bez posiadania solidnego działu administratorów, dlatego tutaj korzystamy z rozwiązania chmurowego. Z kolei, w przypadku strony firmowej, podobnie jak u większości firm, stworzyliśmy ją całkowicie sami i samodzielnie hostujemy. Aczkolwiek akurat tutaj inne podejście jest rzadkością (w kwestii serwera - jeśli chodzi o samo stworzenie witryny, to zleca się różnym firmom. Mamy przypomnieć, do kogo możecie się zgłosić? ;)

W przypadku CRM-a eksperymentujemy z self-hostingiem i oceniamy, na ile takie narzędzie rzeczywiście by nam się przydało. Pierwsze próby są obiecujące, a nawet mogą skutkować przynajmniej fragmentarycznie napisanym oprogramowaniem.

Pliki przechowywane i udostępniane w chmurze - po analizie i niekoniecznie pozytywnych głosach pytanych osób nie zdecydowaliśmy się na samodzielnie hostowanego Nextclouda i nadal korzystamy z komercyjnych i dobrze znanych usługodawców.

Wreszcie, serwer Mastodona - eksperyment z samym Fediverse wyszedł jak najbardziej pozytywnie, jednak początkowa decyzja o własnej instancji social.wildasoftware.pl nie okazała się właściwa dla jednego konta. Z perspektywy czasu twierdzimy, że jeśli nadal byśmy chcieli utrzymać self-hosting, to dużo lepsza byłaby instancja na np. dużo prostszym i szybszym GoToSocial. Tym niemniej, to nadal konieczność zaadaptowania dodatkowego serwera i zajmowania się oprogramowaniem w innej technologii niż nasze nominalne, a w dodatku Mastodon jako platforma jest dla nas ważna. Dlatego przeszliśmy na największy, oficjalny serwer mastodon.social (i wiemy, że niektórym zgrzytają od tego zęby, ale to była przemyślana decyzja).

Podsumowanie

Self-hosting ma swoje mocne strony, ale nie zapominajmy, że miewa również swoje słabości. Posiadanie własnych usług i umiejętności ich zarządzania to niewątpliwy powód do dumy i chwalenia się. Jednak, należy wziąć poprawkę na to, że czytając o samodzielnym hostowaniu oprogramowania, najczęściej mamy do czynienia z aż podejrzanie jednoznacznie pozytywnymi artykułami na ten temat, rekomendującymi to podejście ze względu na prywatność, uniezależnienie się od GAFAM i inne wzniosłe hasła. I o ile trudno z tym dyskutować, to każdy kij ma dwa końce, więc chciałem pokazać też cienie takiej decyzji, które nie są widoczne na samym początku i pojawiają się z biegiem czasu. Pamiętajcie też, że piszę z perspektywy software house'u, który skupia się na rozwoju oprogramowania - inaczej do tego podejdzie grupa przyjaciół prowadząca startup, inaczej organizacja non-profit, swoją opinię będzie miała instytucja publiczna, a zupełnie inne zapatrywanie na sprawę przedstawi korporacja lub firma specjalizująca się w hostingu. Jak głosi stara prawda: "punkt widzenia zależy od punktu siedzenia". Jeszcze można dodać, że także od stopnia zaawansowania i profilu krzesła, na którym się siedzi.

Pozdrawiam i dziękuję - Jakub Rojek.