Odoo Online czy Odoo.sh - co wybrać?

Przy wyborze Odoo prędzej czy później pojawia się pytanie: Odoo Online czy Odoo.sh?

Na pierwszy rzut oka może wyglądać to jak zwykły wybór hostingu. W obu przypadkach Odoo działa w chmurze, nie trzeba stawiać własnego serwera, a użytkownicy korzystają z systemu przez przeglądarkę. Różnica jest jednak znacznie większa.

Odoo Online jest gotowym środowiskiem utrzymywanym przez producenta. Odoo.sh daje dodatkowo możliwość rozwijania systemu własnym kodem i instalowania niestandardowych modułów. I to właśnie od tego powinna zaczynać się decyzja.

Odoo Online - kiedy standard wystarcza

Odoo Online to najprostszy sposób korzystania z systemu. Serwer, aktualizacje, monitoring i kopie zapasowe są po stronie Odoo. Firma nie musi zajmować się infrastrukturą ani utrzymywaniem własnego środowiska - po prostu wchodzisz przez przeglądarkę i pracujesz.

Dla wielu firm właśnie na tym polega największa zaleta Odoo Online. Jeżeli potrzebujesz CRM, sprzedaży, projektów, magazynu, fakturowania czy helpdesku i jesteś w stanie zbudować swoje procesy na standardowych możliwościach Odoo, dokładanie bardziej skomplikowanej infrastruktury mija się z celem.

Odoo Online można też skutecznie dostosowywać. W planie Custom dostępne jest Odoo Studio, które pozwala między innymi dodawać pola, zmieniać widoki czy budować automatyzacje bez tworzenia klasycznego modułu programistycznego. Plan ten daje również dostęp do zewnętrznego API i obsługi środowiska wielofirmowego. „Odoo Online” nie oznacza więc automatycznie „Odoo bez możliwości modyfikacji”.

Czego NIE zrobimy na Odoo Online?

Najważniejsze ograniczenie jest proste: na Odoo Online nie można instalować własnych modułów wymagających niestandardowego kodu w Pythonie ani standardowo korzystać z gotowych rozwiązań zewnętrznych twórców dostępnych w Odoo Apps Store.

Wyobraźmy sobie firmę, która potrzebuje nietypowego mechanizmu wyceny, gdzie cena nie wynika z cennika, ale jest obliczana na podstawie kilkunastu parametrów podanych przez klienta. Albo proces wymaga zaawansowanej integracji z systemem produkcyjnym.

Wtedy nie mówimy już o konfiguracji. Mówimy o rozwoju oprogramowania. I do tego potrzebujemy środowiska, które pozwala uruchamiać własny kod.

Odoo.sh - rozwiązanie dla projektów wymagających developmentu

Odoo.sh to platforma typu PaaS (Platform as a Service), stworzona specjalnie pod wdrożenia wymagające własnego kodu. Projekt jest zintegrowany z repozytorium GitHub. Po wysłaniu zmian do repozytorium Odoo.sh automatycznie buduje lub aktualizuje odpowiednie środowisko.

To całkowicie zmienia model pracy:

1. Programista rozwija nową funkcję we własnym module.
2. Kod trafia do repozytorium.
3. Zmiana jest testowana na osobnym środowisku.
4. Dopiero po akceptacji trafia na produkcję.

Development, Staging i Production

Jedną z największych zalet Odoo.sh jest podział na trzy rodzaje środowisk:

• Development - miejsce do rozwijania i technicznego sprawdzania kodu.
• Staging - środowisko testowe. Odoo.sh może przygotować je na podstawie sklonowanej produkcyjnej bazy danych. Kopia jest neutralizowana, dzięki czemu można testować procesy na danych zbliżonych do produkcyjnych bez ryzyka, że system wyśle prawdziwym klientom maile z ofertami albo uruchomi rzeczywiste płatności.
• Production - właściwy system używany na co dzień przez firmę.

Jeżeli zmieniamy tylko kolor przycisku, środowisko testowe nie wydaje się niezbędne. Ale jeżeli modyfikujemy sposób generowania zamówień, dokumentów albo stanów magazynowych - sytuacja wygląda inaczej. System ERP jest jednym z ostatnich miejsc, w których chcemy testować kod bezpośrednio na żywym organizmie.

Odoo.sh nie oznacza utrzymywania własnego serwera

To częste nieporozumienie. Odoo.sh daje dużo większą kontrolę nad aplikacją, ale infrastruktura nadal jest zarządzana przez Odoo. Nie jest to więc klasyczny model on-premise, w którym firma sama odpowiada za serwer, aktualizacje systemu operacyjnego czy konfigurację całej infrastruktury.

Otrzymujemy gotowe środowisko do developmentu, z obsługą baz testowych, logów, buildów i branchy w Gicie, bez konieczności samodzielnego utrzymywania serwera. Produkcyjna baza danych jest również automatycznie backupowana.

Retencja produkcyjnej bazy obejmuje:

• 7 kopii dziennych,
• 4 kopie tygodniowe,
• 3 kopie miesięczne.

Środowiska developerskie i stagingowe należy traktować inaczej - nie są przeznaczone do trwałego przechowywania danych produkcyjnych.

Szybkie porównanie: Odoo Online vs Odoo.sh

Koszty: kiedy oszczędności stają się pułapką?

Na Odoo Online hosting jest wliczony w cenę subskrypcji. W przypadku Odoo.sh system wymaga planu Custom, a hosting jest rozliczany oddzielnie. Jego koszt zależy między innymi od przydzielonej mocy obliczeniowej, przestrzeni dyskowej oraz liczby środowisk testowych.

Wybieranie Odoo.sh „na zapas”, jeśli firma opiera się głównie na standardowych funkcjach, to generowanie kosztów, których projekt może zwyczajnie nie potrzebować.

Z drugiej strony wybór Odoo Online dla projektu, który od początku wymaga pisania własnego kodu, szybko prowadzi do tworzenia karkołomnych obejść systemowych. A takie obejścia często okazują się bardziej skomplikowane i droższe niż wybór właściwego środowiska na początku.

Kiedy wybralibyśmy Odoo Online?

Rozpoczęcie od Odoo Online ma sens, jeżeli:

• standardowe aplikacje pokrywają zdecydowaną większość procesów w firmie,
• zmiany da się wykonać w konfiguracji lub stworzyć w Odoo Studio,
• zależy Ci na najprostszym możliwym utrzymaniu,
• nie potrzebujesz własnych modułów Python,
• nie korzystasz z modułów zewnętrznych wymagających instalacji kodu,
• nie planujesz rozbudowanego developmentu bezpośrednio wewnątrz Odoo.

Czasami delikatna zmiana procesu w firmie jest prostsza, szybsza i tańsza niż napisanie 3000 linii kodu tylko po to, by system działał tak, jak Excel sprzed dziesięciu lat.

Kiedy Odoo.sh staje się naturalnym wyborem?

Jeżeli chcemy pozostać przy infrastrukturze zarządzanej przez Odoo, Odoo.sh staje się naturalnym wyborem, gdy:

• trzeba napisać własną, bardziej złożoną logikę biznesową,
• potrzebne są własne moduły Python,
• korzystamy z rozwiązań zewnętrznych wymagających instalacji dodatkowych modułów,
• potrzebujemy specyficznych integracji z innymi systemami,
• nad Odoo pracuje zespół programistyczny,
• potrzebne jest wersjonowanie kodu w Git,
• firma wymaga osobnego środowiska testowego przed wdrożeniem zmian na produkcję.

Nie oznacza to jednak, że Odoo.sh jest jedyną opcją dla własnego kodu. Odoo można również hostować samodzielnie w modelu on-premise. Wtedy firma zyskuje jeszcze większą kontrolę nad infrastrukturą, ale bierze też na siebie odpowiedzialność za jej utrzymanie. Odoo.sh jest więc rozwiązaniem pośrednim: pozwala rozwijać własny kod bez konieczności samodzielnego zarządzania całym środowiskiem serwerowym.

Czy można zacząć od Online i później przejść na Odoo.sh?

Tak. Baza danych z Odoo Online może zostać wyeksportowana i przeniesiona do środowiska Odoo.sh.

Przy mniejszych wdrożeniach nie trzeba od razu podejmować decyzji zabezpieczającej firmę na pięć lat do przodu. Można wystartować w prostszym wariancie. Jeżeli po pewnym czasie okaże się, że standard i Studio przestają wystarczać, środowisko można zmigrować i rozpocząć własny development.

To często lepsze podejście niż rozpoczynanie wdrożenia od kilkunastu dedykowanych modułów, zanim użytkownicy w ogóle zaczną pracować z systemem.

Odoo Online czy Odoo.sh? Najprostsza odpowiedź

Jeżeli proces firmy można zrealizować przy pomocy standardowych aplikacji Odoo, konfiguracji i Studio - zaczęlibyśmy od Odoo Online. Jeżeli potrzebny jest własny kod, dodatkowe moduły i kontrolowany proces developmentu - Odoo.sh staje się naturalnym wyborem.

Nie chodzi więc o to, który wariant jest „lepszy”. Chodzi o to, ile swobody rzeczywiście potrzebuje konkretne wdrożenie. Większa możliwość modyfikowania systemu jest zaletą tylko wtedy, kiedy faktycznie mamy powód, żeby z niej korzystać.