W tym artykule wyjaśniam, którą ścieżkę należy wybrać, decydując się między własną infrastrukturą a chmurą.
W pierwszej kolejności rekomenduję zapoznać się z naszą realizacją aplikacji SaaS, z której wywodzi się ten temat.
Sedno sporu
Jeśli zadamy to pytanie szeregowi specjalistów z branży informatycznej, nie otrzymamy jednoznacznej odpowiedzi. Zdania będą mocno podzielone.
Jak mocno są podzielone, można przeczytać w komentarzach do publikacji, którą udostępniłem na LinkedIn.
Na początku warto rozejrzeć się, jakie w ogóle mamy opcje, skąd ten spór się wywodzi i kogo dotyczy.
Gdybyśmy spróbowali zdefiniować grupę podmiotów, przed którymi stoi to pytanie, można powiedzieć, że dotyczy ono każdego, kto zajmuje się wytwarzaniem oprogramowania oraz kto je eksploatuje. Czyli zadajemy to pytanie sobie my, jako software house, oraz nasi klienci, dla których oprogramowanie wytwarzamy.
Niektórzy nasi klienci wolą utrzymywać infrastrukturę serwerową samodzielnie. To znaczy, że biorą za to odpowiedzialność w swoje ręce, a my musimy się do ich wymogów dostosować. Mamy ograniczony wpływ na decyzje podejmowane w tym obszarze po stronie klienta – prowadzimy dyskusje i argumentujemy swoje stanowisko. Natomiast podjęcie ostatecznej decyzji leży w tym przypadku po stronie klienta i musimy się do niej dostosować.
Warto zaznaczyć, że spór ten nie jest zero-jedynkowy i mamy kilka opcji w zakresie infrastruktury:
- Chmura – usługa, dostęp do której jest całkowicie zautomatyzowany, rozliczenie za wykorzystane zasoby, elastyczność w skalowaniu, brak kar za rezygnację z usługi w dowolnym momencie
- Serwer dedykowany – dostęp do zasobów o sztywnych parametrach, z góry określony termin umowy, ręczna aktywacja
- Kolokacja – zakup fizycznego serwera, umieszczenie własnego sprzętu w specjalistycznym centrum danych, wykupienie łącza internetowego do połączenia serwera ze światem
- On-premises – własny sprzęt umieszczony na własnej powierzchni
My, jako Koncewicz Software House, korzystamy wyłącznie z pierwszych dwóch opcji. Uwzględniam tu wyłącznie przypadki, kiedy mamy możliwość decydowania o architekturze infrastruktury i klient nie nakłada na nas własnych ograniczeń.
Uzasadniamy to przede wszystkim kwestią finansową. Z naszego własnego doświadczenia wynika, że utrzymanie własnej infrastruktury – bądź to w kolokacji, bądź on-premises – jest bardzo kosztowne. Można to porównać do zbudowania własnej piekarni przy zapotrzebowaniu na świeże pieczywo na poziomie jednej rodziny.
Poniższa tabela dobrze prezentuje koszty, wyzwania i zagrożenia dla każdej ze wspomnianych opcji:
| Kryterium | Model 01Chmura | Model 02Serwer dedykowany | Model 03Kolokacja | Model 04On-premises |
|---|---|---|---|---|
| Koszt początkowy | ✓Zerowy | ✓Niskiopłata startowa | ✕Wysokizakup sprzętu | ✕Bardzo wysokisprzęt + adaptacja pomieszczenia |
| Koszt bieżący | !Zmiennyrośnie ze skalą | ✓Stałyprzewidywalny | !Abonamentszafa + energia | ✕Wysokiprąd, chłodzenie, łącza, ludzie |
| Model rozliczenia | ✓Pay-as-you-go | !Ryczałtmiesięczny | !Ryczałt + energia | ✕Brakkoszty rozproszone |
| Czas uruchomienia | ✓Minuty | !Godziny-dni | ✕Tygodnie | ✕Tygodnie-miesiące |
| Skalowanie w górę | ✓Automatyczne | ✕Nowa umowa | ✕Zakup sprzętu | ✕Zakup sprzętu |
| Skalowanie w dół | ✓Natychmiastowe | ✕Okres wypowiedzenia | ✕Sprzęt zostaje twój | ✕Koszt utopiony |
| Nakład pracy admina | ✓Minimalny | ✓Niskidostawca wymienia sprzęt | ✕Wysokidojazdy, części zamienne | ✕Bardzo wysoki |
| Kontrola nad sprzętem | ✕Brak | !Ograniczona | ✓Pełna | ✓Pełna |
| Zasilanie, chłodzenie | ✓Po stronie dostawcy | ✓Po stronie dostawcy | ✓Po stronie dostawcy | ✕Po twojej stronie |
| Bezpieczeństwo fizyczne | ✓Certyfikowane DC | ✓Certyfikowane DC | ✓Certyfikowane DC | ✕Zależy od ciebie |
| Suwerenność danych | ✕Dane u dostawcy | !Dane u dostawcy | ✓Dysk fizycznie twój | ✓Dane nie opuszczają firmy |
| Wydajność | ✕Zasoby współdzielone | ✓Sprzęt wyłącznie twój | ✓Sprzęt wyłącznie twój | ✓Sprzęt wyłącznie twój |
| SLA | ✓Umowne, z karami | ✓Umowne | !Tylko na DCnie na twój sprzęt | ✕Brak |
| Wymagane kompetencje | ✓Niskie | !Średnie | ✕Wysokie | ✕Bardzo wysokie |
| Ryzyko vendor lock-in | ✕Wysokie | !Średnie | ✓Niskie | ✓Brak |
| Cykl życia sprzętu | ✓Nie twój problem | ✓Nie twój problem | ✕Twój koszt | ✕Twój koszt |
Infrastruktura dla mass mailingu
W tekście o naszej realizacji projektu EngageMail wspomniałem, że skorzystaliśmy zarówno z chmury – DigitalOcean – jak i z serwerów dedykowanych od OVH. Warto naświetlić to zagadnienie od strony technicznej i pokazać, co miało wpływ na naszą decyzję konkretnie przy tym projekcie.
Skupmy się na DigitalOcean. Decydujemy się na postawienie projektu w tej chmurze, gdy:
- Funkcjonalności chmury pokrywają się z wymaganiami nakładanymi przez projekt
- Chmura ma minimalistyczny interfejs i jest skierowana do konkretnego odbiorcy
- Jest stabilna i przewidywalna
Można stwierdzić, że DigitalOcean został stworzony z myślą o konkretnej grupie odbiorców i jest idealnie dopasowany do projektów, które realizujemy dla naszych klientów.
To niewielkie projekty webowe dla małych i średnich przedsiębiorstw, oparte na technologiach open source: Linux, Docker, MySQL. Chmura ta daje „z pudełka" niezbędne narzędzia do monitoringu, skalowania i automatyzacji.
Wspomniany projekt EngageMail składał się z dwóch odrębnych części: centralnego panelu do przechowywania kontaktów, zarządzania kampaniami i interfejsu API oraz dużej liczby odseparowanych serwerów SMTP wykorzystywanych do masowego dostarczania wiadomości e-mail.
Panel webowy wraz z jego bazami danych jak najbardziej dało się umieścić w DigitalOcean. Natomiast serwery SMTP już nie – miały one kilka dodatkowych wymagań, których DigitalOcean nie był w stanie spełnić.
Wymaganie pierwsze – tolerancja na wychodzący ruch SMTP. DigitalOcean walczy z nadużyciami w zakresie dostarczania wiadomości e-mail, dlatego serwer wysyłkowy może automatycznie otrzymać ograniczenia, które uniemożliwią spełnienie jego głównej funkcji.
Wymaganie drugie – większa kontrola w zakresie adresów IP. Chcieliśmy mieć pewność, że dysponujemy konkretnymi adresami IP, oraz możliwość wykupienia całej podsieci. Niczego z tego DigitalOcean nie oferuje. To nie znaczy, że jest zły — po prostu ta chmura obsługuje inne scenariusze hostowania danych, w których rezerwacja adresów IP nie ma zastosowania. Można próbować obejść to za pomocą tzw. Reserved IP i skonfigurować ruch wychodzący pod konkretny adres IP. Służy to jednak innemu celowi i chmura nie daje gwarancji, że takie rozwiązanie będzie działać zawsze.
Odpowiedź na to zagadnienie znaleźliśmy w OVH. Wykupiliśmy serwer dedykowany i przydzieliliśmy do niego konkretną pulę adresów IP, która cały czas jest w naszym posiadaniu. Oprócz tego OVH pozwala podpiąć zewnętrzne adresy IP, dzierżawione u innych dostawców.
Podsumowanie
Biorąc pod uwagę specyfikę budowanych przez nas projektów, nie widzimy wartości dodanej w posiadaniu własnych serwerów w kolokacji bądź na własnej powierzchni.
Przed podjęciem decyzji w zakresie infrastruktury IT należy dobrze rozumieć wymagania techniczne, być gotowym na zarządzanie ryzykiem i szczegółowo kalkulować koszty związane z dokonaniem wyboru na rzecz chmury, serwera dedykowanego czy własnych serwerów.
