U firm tworzących lub wdrażających oprogramowanie webowe, prędzej czy później projekt dociera do momentu, w którym trzeba wybrać serwer. Co ciekawe, czasami jest to pewne zaskoczenie - oczywiście, nie dla wykonawców, ale dla klienta, gdyż nierzadko przy planowaniu projektu z jego strony nie jest uwzględniany ten dodatkowy koszt. Jednak to, co jest bardziej zastanawiające to fakt, że bywają sytuacje, w których zleceniodawca nie wie nawet, dlaczego potrzebuje serwer, nie mówiąc już o domenie. Jeśli jesteś taką osobą - ten tekst jest dla Ciebie.

Postanowiłem zebrać w jednym miejscu te wszystkie pojęcia właśnie z myślą o osobach, które z branżą IT (a tym bardziej oprogramowaniem webowym) nie mają na co dzień do czynienia, a nie chcą być zaskoczone przy rozmowach z software housem. Będę starał się tłumaczyć wszystkie terminy bardzo prosto, być może czasem godząc się na pewne znaczne uproszczenia (które na pewno wytkną mi koleżanki i koledzy po fachu), mając na celu przystępne przybliżenie tej tematyki wszystkim zainteresowanym. 

Zacznijmy zatem.

Czym się różni serwer od domeny?

Serwer ma wbrew pozorom dość szerokie pojęcie i w zależności od kontekstu może oznaczać zarówno aplikację "napędzającą" stronę internetową (Apache 2 lub NGINX), ale także oznaczać miejsce, na którym nasza aplikacja zostanie udostępniona użytkownikom. W wielkim uproszczeniu, oznacza to publicznie dostępny (lub o odpowiednio ograniczonym zasięgu) komputer podłączony do Internetu, na którym uruchomiony jest zrealizowany projekt. Natomiast, jak zawsze, diabeł tkwi w szczegółach i niekoniecznie to musi być komputer, jednak do tego dojdziemy później. Dla nas najważniejsze jest to, że jest to maszyna, którą musimy wykupić, aby ktoś mógł skorzystać z aplikacji poprzez przeglądarkę internetową, ew. urządzenia mobilne. I nie ma znaczenia, czy aplikacja jest tworzona dla ogólnodostępnej puli użytkowników, czy dla konkretnej firmy do ich wewnętrznego stosowania.

Wyobraźmy sobie teraz, że serwer jest taką biblioteką, w której znajdują się książki i chcemy, aby ludzie po nie przychodzili. Świetnie - wykupiliśmy dostęp do budynku (biblioteki), zapełniliśmy go książkami (oprogramowaniem) i czekamy na czytelników (użytkowników). Natomiast obecnie ta biblioteka będzie miała bardzo brzydki adres, być może składający się z liczb, oznaczający jego współrzędne geograficzne (w dużym uproszczeniu, ale analogią jest adres IP). Czy którykolwiek czytelnik pokusiłby się o szukanie takiego budynku korzystając ze współrzędnych? Chyba tylko miłośnik gier terenowych (haker). Potrzebujemy zatem porządnego adresu, który będzie łatwiej przyswajalny dla ogółu. I w ten sposób dochodzimy do pojęcia domeny.

Jest to właśnie nic innego, jak ładnie brzmiący adres tekstowy, który służy do znajdowania określonego serwera z naszą aplikacją. Przykładowo, jeśli ktoś powiedziałby Wam "hej, wejdź pod adres 91.185.189.246, ten system na pewno Ci się przyda!", to popukalibyście się w głowę lub stwierdzilibyście, że to jakaś próba oszustwa (zwłaszcza, że wejście pod ten adres bezpośrednio niczym nie zaowocuje). Ale jeśli ktoś by Wam powiedział "wejdź pod adres feedybacky.com", to pewnie byłoby to dla Was już bardziej "zjadliwe", prawda? Właśnie "feedybacky.com" to przykład domeny, która wskazuje na adres IP, jaki wcześniej podałem, a który prowadzi serwera, na którym znajduje się aplikacja. Dzieje się to przez tzw. serwery DNS-y, ale to już trochę inny temat, którego tutaj nie chcę poruszać, choć polecam diagram, na którym świetnie został wyjaśniony.

Oczywiście, z domenami też nie wszystko jest takie proste, czego dowodem jest to, że po wpisaniu powyższego adresu IP nie trafiliście tam, gdzie chcieliście. Wchodzą tutaj w grę jeszcze wirtualne hosty, przekierowania, subdomeny (lub "poddomeny"), natomiast myślę, że tutaj się zatrzymamy, gdyż tekst ma za zadanie jedynie zasygnalizować temat i skrótowo go wyjaśnić. Warto tutaj jedynie wspomnieć, że domenę kupuje się osobno i przedłuża jej ważność co roku (uwaga: jest to zwykle droższe niż samo kupno), a chcąc przekierować adres na serwer, trzeba to zrobić właśnie u dostawcy domeny. Jeśli chcecie rozwinięcia tego tematu - dajcie znać w komentarzach.

Podsumowując tę część - przy aplikacji webowej serwer potrzebny jest praktycznie zawsze, natomiast domena bardzo często, choć nie jest ona wymagana. Zazwyczaj jakaś domena (choć nie tak ładnie brzmiąca) jest dostarczana wraz z serwerem, a i niekiedy można korzystać z aplikacji przez sam adres IP. Tym niemniej, jeśli tworzysz stronę wizytówkową lub aplikację, którą chcesz zawojować świat, to kupna domeny nie unikniesz.

Po co mi serwer testowy?

Czasami możesz spotkać się z określeniem "serwer testowy" lub "serwer deweloperski", o który proszą programiści. Czasami nawet tych serwerów testowych jest więcej. Po co komukolwiek one są potrzebne?

Wdrażanie aplikacji, która dotychczas działała na specjalnie przygotowanych komputerach programistów, nad którymi mają pełną kontrolę, na serwer produkcyjny jest zwykle krytycznym momentem, w którym okazuje się, że coś nie jest takie, jakie sobie wymarzyliśmy. Pomijam tutaj przypadki, kiedy serwer nie jest przygotowany na przyjęcie technologii, w której napisano oprogramowanie, bo to zwykle kwestia niedogadania się pomiędzy Tobą a zespołem IT. Natomiast serwery z założenia są skonfigurowane trochę inaczej, bardziej "sztywno" i czasem trzeba coś dopieścić, zmienić jakiś parametr, pogadać o czymś z administratorem itd. Słowem - będzie pewien okres, w którym nic nie będzie działać i nikt nie będzie do końca wiedział, dlaczego.

Druga, ważniejsza sprawa jest taka, że na pewno będziesz chciał dostać swoją aplikację wcześniej do testów. A żeby z tego skorzystać, musisz mieć ją gdzieś opublikowaną. Do tego właśnie służą serwery testowe - są one jak najbardziej pełnoprawną kopią aplikacji, ale z próbnymi danymi, gdzie można "psuć" ile wlezie i w ten sposób testować oprogramowanie zarówno funkcjonalnie, jak i pod kątem stabilności na maszynie. Zaleca się, aby taki serwer był jak najbardziej podobny (a wręcz identyczny) do tego, na którym aplikacja będzie działać produkcyjnie - właśnie po to, aby później spotkało nas jak najmniej niespodzianek. Nierzadko można kupić jeden serwer i utworzyć na nim dwa osobne miejsca - jedno na wersję testową, a drugie na docelową.

Przy dużych projektach bywa, że potrzebne jest więcej takich serwerów, na których testuje się różne ustawienia bądź jeden jest typowo do weryfikacji funkcji, a drugi np. do sprawdzenia integracji poszczególnych komponentów.

Hosting, wirtualki, VPS-y, dedyki, chmury...

Już wiesz, że musisz mieć serwer. Świetnie - masz pieniądze, stwierdzasz, że kupisz odpowiednią usługę... No właśnie - jaka jest odpowiednia?

Serwer serwerowi nierówny i teraz doszliśmy do tego, o czym wspomniałem już wcześniej - niekoniecznie oznacza to fizyczny komputer. Mało tego - zwykle właśnie nie oznacza. Na rynku jest wiele usług serwerowych w różnych cenach i osoba, która się na tym nie zna, może dostać zawrotu głowy, próbując dojść do tego, czego faktycznie potrzebuje. Dlatego zanim przejdziemy do opisu poszczególnych rodzajów usług, rekomenduję, abyś kwestię serwera przedyskutował z zespołem IT jeszcze PRZED rozpoczęciem projektu. Nie dość, że bez tego kroku możesz kupić nieodpowiedni serwer i niepotrzebnie wydać pieniądze, to jeszcze może się okazać, że software house (jeśli nie ma wsparcia administratorów) będzie miał kłopoty z prawidłowym wykorzystaniem kupionej "maszyny". Nie mówiąc już o tym, że technologię tworzenia oprogramowania programiści dobierają nie tylko pod projekt, ale także pod serwer, na którym to będzie działać. 

Pierwsza rzecz, o której musisz wiedzieć, to fakt, że serwery dzielą się na wirtualne i fizyczne. Jeśli chodzi o te drugie, to pewnie słusznie się spodziewasz, że w tym przypadku serwer jest faktycznym komputerem (bardzo potężnym), który jest przeznaczony w całości dla Ciebie. Jednak popularniejszym rozwiązaniem (choćby ze względu na cenę) jest maszyna wirtualna, czyli wydzielona dla Ciebie część jednego fizycznego komputera, z wirtualizowanym systemem dzięki odpowiedniemu programowi. I właśnie od tych wirtualnych jednostek zaczniemy.

Najpopularniejszym i najtańszym rodzajem hostingu są usługi nazywające się... właśnie hostingiem, ew. hostingiem WWW. W jej ramach dostajesz do dyspozycji określone miejsce, dostęp do systemu plików, baz danych, panel do zarządzania parametrami i ew. do konsoli. Zaletą w tym przypadku jest cena i prostota - są to hostingi najpopularniejsze zarówno wśród osób nietechnicznych, jak i programistów do prostych projektów, gdyż po prostu jest z nimi najmniej problemów przy standardowym oprogramowaniu. Jeśli chcesz postawić stronę wizytówkową na Wordpressie, to tak naprawdę wystarczy Ci taka opcja. Problem zaczyna się w momencie, kiedy oprogramowanie zainstalowane na takim serwerze nie jest dla Ciebie wystarczające - bardzo często jest to PHP, MySQL, poczta i niewiele więcej. Co prawda, są hostingodawcy umożliwiający znacznie więcej, a i wspierający Cię przy trudniejszych kwestiach. Musisz jednak pamiętać, aby przy takim rodzaju usługi liczyć się z ograniczeniami (o których wiadomo przed kupowaniem hostingu, więc to żadna niespodzianka) lub dodatkowymi kosztami.

Dla bardziej wymagających istnieją rozwiązania nazywane skrótowo VPS, a nieskrótowo Virtual Private Server. Tak naprawdę jest to rozwinięta wersja powyżej opisanego hostingu, tylko z jedną, bardzo ważną różnicą - zazwyczaj dostajesz pełny dostęp do wirtualnej maszyny, łącznie z uprawnieniami roota (czyli głównego użytkownika Linuxa). Nadal musisz mieć świadomość, że masz do czynienia z nierzeczywistym systemem postawionym na innej maszynie, ale to Twój system. Zaletą jest tutaj, oczywiście, dużo większa swoboda, a właściwie jej pełnia - nie jesteśmy ograniczeni pod kątem software'u, który zainstalujemy na takim serwerze (pomijając szczególne przypadki godzące w prawo) i poza PHP-em możemy doinstalować serwery dla Node.js, Pythona, Ruby... Od wyboru, do koloru. Tylko właśnie to, poza większą ceną, może też być wadą - musimy sami o wszystko zadbać i wiedzieć, jak zainstalować poszczególne komponenty oraz je skonfigurować. Nie zawsze jest to takie proste, zwłaszcza, gdy w grę wchodzi odpowiednie zabezpieczanie serwera. Tutaj też zwykle pomogą nam w tym pracownicy od strony hostingodawcy, jednak licz się z tym, że przy VPS-ie jest potrzebne więcej pracy.

Z tej racji większość usług VPS-owych jest czymś pomiędzy dwiema omówionymi formami - np. nie masz pełnej kontroli nad serwerem (mają ją doświadczeni administratorzy ze strony hostingodawcy), ale za to na Twoją prośbę zainstalują i skonfigurują wszystkie potrzebne komponenty lub dostarczą Ci serwer z preinstalowanymi paczkami. Najważniejsze jednak jest to, że to nadal maszyny wirtualne, które są dość łatwe w zarządzaniu i tańsze, ale też wolniejsze od...

...fizycznych maszyn, czyli tzw. hostingu dedykowanego (w skrócie zwanego "dedykiem"). Tutaj już faktycznie mamy do dyspozycji komputer dla siebie, co z miejsca podwyższa koszt i nieco wydłuża czas startu usługi (tzn. nie jest dostępna od razu, tylko np. po 24 godzinach), ponieważ taką maszynę trzeba po prostu zainstalować w serwerowni. Natomiast parametrycznie było to do niedawna najlepsze rozwiązanie, gdyż zasoby takiego serwera wykorzystujesz tylko Ty. A że, jak już zdążyłem wspomnieć, są to całkiem potężne urządzenia, to możesz się spodziewać dużej szybkości działania Twojego oprogramowania. Jeśli chodzi o dostęp konfiguracyjny, to tutaj niezbyt różni się to od VPS-ów - możesz (i zwykle masz) pełen dostęp roota do konsoli, ale także pomoc administratorów w razie potrzeby. Różnica jest taka, że np. dodanie RAM-u do serwera (co zdarza się rzadko) nie jest takie proste, ponieważ administratorzy rzeczywiście muszą ten RAM fizycznie dołożyć. Choć, w przeciwieństwie do wielu VPS-ów, tutaj jest zazwyczaj możliwe.

W tym miejscu możesz się zastanawiać, dlaczego nie iść na całość i nie kupić fizycznej maszyny do biura i mieć nad serwerem dedykowanym kontrolę nie tylko software'ową, ale i hardware'ową. Są specyficzne przypadki, w których się to praktykuje, jednak wbrew pozorom wiąże się z tym więcej problemów niż korzyści. Opieka nad fizycznym serwerem faktycznie oznacza opiekę - reagowanie, gdy zabraknie prądu (lub w przypadku pożaru), samodzielne dbanie o wymianę zużytych podzespołów, zapewnienie infrastruktury sieciowej, bezpiecznego dostępu na zewnątrz (nawet, jeśli serwer będzie udostępniał oprogramowanie tylko dla wewnętrznych potrzeb firmy, to choćby programiści wgrywający poprawki powinni mieć dostęp z zewnątrz, nie mówiąc już o sposobności pracy zdalnej), wykupieniu publicznego adresu IP... Wierz mi - firmy hostingowe mają te tematy w małym paluszku, odpowiednio przygotowane mechanizmy tworzenia kopii zapasowych, a nawet warunki budowlane. Zapewniają Ci też bezpieczeństwo danych, gdyż są po prostu specjalistami w swoim fachu - poza nielicznymi przypadkami lub chęcią samodzielnego "majsterkowania" nie ma sensu tworzyć pełnej serwerowni u siebie.

Została nam jednak jeszcze jedna forma serwerów, bardzo popularna w ostatnich latach i również przybierająca różne formy - chmura (ang. cloud). W wielkim skrócie oznacza to, że nie kupujemy dostępu do konkretnego serwera (wirtualnego czy fizycznego), tylko do całej infrastruktury, w ramach której możemy korzystać z usług, wykorzystując hosting, maszyny wirtualne, silniki bazodanowe, przestrzeń dyskową itd. To wszystko znajduje się na wielkich farmach serwerów dostawcy (np. Amazona, Google'a czy Microsoftu) i nasze oprogramowanie jest dynamicznie między nimi przełączane, w efekcie czego płacimy za faktyczny czas pracy maszyny. To w konsekwencji oznacza, że trudno (mimo kalkulatorów udostępnionych przez firmy) wyliczyć, ile faktycznie będziemy płacić za miesiąc, gdyż będzie to zmienna wartość. Trzeba też przyzwyczaić się do zasad panującej w danej infrastrukturze i specyficznego nazewnictwa. Gdzie zatem zalety, pewnie zapytacie. Otóż, ta infrastruktura zapewni nam największą wydajność i stabilność ze wszystkich wymienionych (przynajmniej w przeciętnym przypadku) - z uwagi na farmy serwerów i wewnętrzne mechanizmy zarządzania nimi, w chmurze naturalnie zyskujemy kopiowanie serwerów, tzw. load balancing (wyrównywanie obciążenia w przypadku wielu użytkowników), elastyczność, czasowe zwiększanie mocy aktualnie obleganej usługi, a także praktycznie nieograniczone miejsce na dysku. Owszem, zwykle to wszystko miesięcznie wyniesie nieco więcej pieniędzy niż serwer dedykowany (zwłaszcza, że musi być osoba, która odpowiednio zaprojektuje infrastrukturę i ją utrzyma), jednak w zamian mamy te wszystkie mechanizmy zwiększające wydajność i odtwarzalność usługi, co jest opcją wartą rozważenia w przypadku naprawdę dużych serwisów. Warto jednak pamiętać, że te muszą być odpowiednio przygotowane do bycia umieszczonymi w chmurze.

Podsumowanie

Na pytanie "jaki serwer kupić" nie ma jednej dobrej odpowiedzi, gdyż wszystko zależy od rozmiaru oprogramowania, które tworzymy, naszego budżetu i używanej technologii. Czasem nie ma potrzeby wychodzić poza zwykły hosting WWW, a czasem warto zainteresować się technologiami chmurowymi. Przede wszystkim mam jednak nadzieję, że teraz rozumiesz już czym się różni serwer od domeny i kiedy potrzebujesz jednego i/lub drugiego. Taki był cel tego tekstu - jedynie wskazać najważniejsze cechy każdego z rozwiązań, abyś mógł orientować się w terminach i wiedzieć "mniej więcej", o co tu chodzi.

Jednocześnie zachęcam koleżanki i kolegów z branży IT o uzupełnianie tekstu w komentarzach i wytykanie ewentualnych błędów - zawsze lepiej mieć pełen obraz sytuacji.

Pozdrawiam - Jakub Rojek