Rozmowa o własnej aplikacji dla firmy zwykle kończy się na tym, co aplikacja ma robić. Pytanie, na czym będzie stała i ile będzie kosztowała za rok, pada rzadziej, a to ono decyduje, czy projekt się obroni.
Ten tekst jest o tej drugiej części. Bez porównywania dostawców, bo to i tak zmienia się co pół roku. O decyzjach, które trzeba podjąć, i o kosztach, które się z nich biorą.
Trzy pytania, od których to się zaczyna
Ile osób będzie z tego korzystało jednocześnie? Nie ile ma kont, tylko ile klika w tej samej chwili. Aplikacja dla ośmiu osób w biurze i aplikacja dla dwustu przedstawicieli w terenie to dwa różne projekty, choć funkcje mogą być te same.
Co się stanie, jeśli to przestanie działać na dzień? Jeśli odpowiedź brzmi „ktoś poczeka", wystarczy prosta konfiguracja i kopia raz na dobę. Jeśli brzmi „stanie sprzedaż", potrzebne jest odtwarzanie do wybranego momentu i monitorowanie, a to kosztuje więcej.
Kto będzie to utrzymywał za rok? To pytanie decyduje o wyborze technologii bardziej niż wydajność. Rozwiązanie, którego nikt poza autorem nie umie ruszyć, jest tanie w budowie i drogie potem.
Serwer: wirtualny wystarcza dłużej, niż się wydaje
Przy typowej aplikacji firmowej, obsługującej od kilku do kilkudziesięciu osób, zwykły serwer wirtualny z kilkoma rdzeniami i kilkoma gigabajtami pamięci wystarcza z zapasem. Koszt zaczyna się od kilkudziesięciu złotych miesięcznie.
Usługi zarządzane, w których nie zajmujesz się systemem, mają sens w dwóch przypadkach: gdy nie chcesz mieć na głowie aktualizacji i kopii, albo gdy potrzebujesz gwarancji dostępności, których na własnym serwerze nie zorganizujesz. Płacisz wtedy za zdjęcie z siebie obowiązków, nie za moc obliczeniową. To bywa uczciwy zakup, ale warto wiedzieć, za co się płaci.
Czego bym unikał na starcie: rozwiązań, które działają wyłącznie u jednego dostawcy. Nie dlatego, że są złe, tylko dlatego, że wpisują w projekt decyzję, której nie da się później tanio cofnąć.
Baza danych: prostota kończy się szybciej, niż myślisz
Najczęstsza ścieżka wygląda tak: aplikacja startuje z bazą w pojedynczym pliku, bo to najprostsze, a po roku okazuje się, że trzeba przejść na serwer bazodanowy.
Warto wiedzieć, gdzie ta granica leży. Baza plikowa jest w porządku, dopóki pisze do niej jeden proces i nie potrzebujesz odtwarzania do wybranej minuty. Serwer bazodanowy staje się potrzebny, gdy pojawia się kilka procesów naraz, kopie zapasowe mają być robione bez zatrzymywania aplikacji albo dane zaczynają być na tyle ważne, że utrata kilku godzin pracy jest problemem.
Jedna pułapka, na którą warto uważać przy takiej migracji. Bazy różnią się w rzeczach, które wychodzą dopiero na produkcji: porównywanie tekstu z uwzględnieniem wielkości liter i znaków diakrytycznych działa inaczej. Zdarza się, że komplet testów przechodzi na bazie plikowej, a to samo zapytanie na serwerze zwraca inny wynik albo się wywraca. Dlatego testy warto uruchamiać na tej bazie, która stoi na produkcji, a nie na wygodniejszej.
Kopie zapasowe: kopia nieodtworzona to założenie
Trzy rzeczy, które trzeba ustalić, i żadna nie jest techniczna.
Jak dużo pracy możesz stracić. Kopia raz na dobę znaczy, że w najgorszym razie tracisz dzień. Odtwarzanie do wybranego momentu, które oferują serwery bazodanowe, skraca to do minut, ale kosztuje.
Gdzie kopia leży. Kopia na tej samej maszynie co aplikacja chroni przed pomyłką człowieka i nie chroni przed awarią maszyny. To dwa różne zagrożenia i tylko drugie z nich kończy się rozmową z klientem.
Czy ktoś ją kiedykolwiek odtworzył. To jest pytanie, na które w większości firm odpowiedź brzmi „nie". Katalog z kopiami, do którego nikt nigdy nie zajrzał, jest dokumentem, nie zabezpieczeniem. Odtworzenie próbne zajmuje godzinę i jest jedynym sposobem, żeby się dowiedzieć.
Aktualizacje: miejsce, w którym najłatwiej o awarię
Przy jednej aplikacji sprawa jest prosta. Przy kilku instalacjach tej samej aplikacji, na przykład dla kilku oddziałów albo kilku klientów, zaczyna się miejsce na kosztowną pomyłkę.
Konkretny przykład, który wart jest zapamiętania. Jeśli wszystkie instalacje korzystają ze wspólnej etykiety wskazującej „najnowszą wersję", to podmiana tej etykiety oznacza, że każde kolejne uruchomienie czegokolwiek na tym serwerze przeciąga wszystkie instalacje na nową wersję naraz. Wystarczy restart maszyny albo rutynowe polecenie i zamiast jednej aktualizacji masz siedem, w tym u klientów, którzy nie byli o tym uprzedzeni.
Sposób, który to zamyka: każda instalacja ma wskazaną konkretną wersję, a aktualizacja polega na zmianie tej jednej wartości u jednego odbiorcy. Najpierw jedna instalacja, potwierdzenie, że działa, potem pozostałe pojedynczo. Awaria zatrzymuje się wtedy na jednym miejscu zamiast położyć wszystkie.
Druga rzecz z tej samej rodziny: migracje bazy uruchamiane przy starcie aplikacji. Wygodne, bo nie trzeba o nich pamiętać. Ryzykowne, bo jeśli migracja przestawia coś, czego nie da się cofnąć, a nowa wersja nie wstaje, jesteś w połowie drogi bez powrotu. Kopia przed migracją nie jest przesadną ostrożnością.
Bezpieczeństwo: pięć rzeczy, które ustawia się raz
Bez wywodu, lista do odhaczenia:
- szyfrowane połączenie z bazą, ze sprawdzaniem certyfikatu. Samo szyfrowanie bez weryfikacji tożsamości serwera chroni w połowie;
- oddzielne konta o minimalnych uprawnieniach. Aplikacja nie potrzebuje konta administratora bazy do zapisywania zamówień;
- hasła i klucze poza kodem, w konfiguracji środowiska, a nie w repozytorium. To jest najczęstszy wyciek, jaki widuję;
- dziennik zdarzeń, który nie zapisuje danych osobowych ponad to, co konieczne. Dziennik też jest zbiorem danych;
- aktualizacje bibliotek przeglądane co kilka miesięcy. Nie po każdej nowej wersji, ale też nie raz na trzy lata. Punkt odniesienia, co sprawdzać w pierwszej kolejności, daje lista najczęstszych zagrożeń OWASP.
Ile to realnie kosztuje
Dla typowej aplikacji firmowej obsługującej kilkanaście osób, przy jednym serwerze wirtualnym i bazie na tej samej maszynie, rachunek za infrastrukturę zamyka się w kilkudziesięciu do stu kilkudziesięciu złotych miesięcznie. Przy bazie jako usłudze zarządzanej, z odtwarzaniem do wybranego momentu, koszt rośnie kilkukrotnie.
To i tak nie jest największa pozycja. Największą jest czas na przeglądy i poprawki, gdy zmieni się proces w firmie albo pojawi się luka w bibliotece. Jeśli w budżecie na projekt nie ma miejsca na tę pozycję, warto to policzyć jeszcze raz przed startem, a nie po roku.
Kiedy odradzam własną infrastrukturę
Nikt w firmie nie będzie tego pilnował i nie ma na to umowy. Aplikacja bez opiekuna działa do pierwszej awarii, a potem staje się czyimś problemem w najgorszym możliwym momencie.
Aplikacja ma być używana przez trzy osoby raz w tygodniu. Wtedy gotowe narzędzie w abonamencie prawie zawsze wygrywa, nawet jeśli trzeba obejść jego ograniczenia.
Proces jeszcze się układa. Budowanie infrastruktury pod sposób pracy, który zmienia się co miesiąc, kończy się przestawianiem tego samego kilka razy. Najpierw ustalcie, jak to ma działać.
O tym, kiedy w ogóle warto budować własne narzędzie zamiast kupować gotowe, pisałem osobno we wpisie o tym, kiedy warto zbudować własny CRM.