Wróć do bloga

Czy warto posiadać własne serwery w branży e-mail marketingu?

Marek KoncewiczMarek Koncewicz
2 stycznia 20265 min czytania
Czy warto posiadać własne serwery w branży e-mail marketingu?

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.

Nie posiadamy żadnego fizycznego serwera. Sądzimy, że infrastrukturą powinni zajmować się wyspecjalizowani w tym inżynierowie. Zarządzanie infrastrukturą serwerową jest na tyle skomplikowane i… | Marek Koncewicz | 31 comments
Nie posiadamy żadnego fizycznego serwera. Sądzimy, że infrastrukturą powinni zajmować się wyspecjalizowani w tym inżynierowie. Zarządzanie infrastrukturą serwerową jest na tyle skomplikowane i kosztowne, że w skali krajowych projektów prawie nigdy nie opłaca się posiadanie własnego sprzętu. Niech zajmują się tym najwięksi – AWS, Azure, Google Cloud, OVH itd. Na obrazku — pożar w jednej z serwerowni OVH 5 lat temu. Wyobraź sobie, że to była by twoja własna infrastruktura. Jak dużo problemów miałbyś rozwiązać po takim incydencie? | 31 comments on 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.

Marek Koncewicz
Marek KoncewiczFullstack Engineer

Ewangelista Laravela. Zwolennik produktowego podejścia do rozwoju aplikacji webowych.