Firmy oferujące chmury dla konkretnego projektu?

[OwiecPL1986 0]

Witam serdecznie,

 

Jestem w trakcie rozważania wyboru rozwiązania technicznego oraz firmy, która je zapewni dla projektu. Ponieważ moje doświadczenie jest ograniczone piszę tutaj z nadzieją, że podzielicie się ze mną konkretnymi informacjami.

 

Projekt to kompleksowe oprogramowanie dla e-commerce, od sklepu internetowego po support, magazyn itd. Każdy z użytkowników musi mieć oddzielne konto ze względów bezpieczeństwa oraz wydajnościowych, tj. mierzenia obciążenia, ograniczania, zwiększania limitów. Jednocześnie chciałbym uniknąć konieczności ciągłej administracji serwerami, dbania o aktualizacje, konfiguracje itd.

 

Problem jest w tym, że każdy komplet oprogramowania dla klienta musi znajdować się na oddzielnym koncie (konto można rozumieć jako oddzielne konto na serwerze, oddzielny wirtualny serwer, a nawet oddzielna maszyna w zależności od rozwiązania). Gdyby np. za każdym razem zakładać oddzielne konto w chmurze dla klienta sporo to wychodzi... szukam najlepszego rozwiązania.

 

Zapomniałem dodać, oprogramowanie jest w PHP. Projekt dopiero startuje.

 

Rozważam kilka możliwości:

1) Własne serwery. Minusem jest duży koszt początkowy oraz konieczność administracji serwerami. Plusem duża możliwość konfiguracji serwerów.

 

2) Chmura bez możliwości logowania się do serwera. Plusem jest brak konieczności administracji serwerami i łatwa skalowalność.

 

3) Chmura jako wirtualny serwer. Plusem jest łatwa skalowalność i swoboda w konfiguracji serwera. Minusem konieczność administracji.

 

Bardzo zależy mi na skalowalności, ponieważ sklepy mają do siebie to, że z założenia mają rosnąć. Oczywiście przeniesienie na inną własną maszynę to też nie jest większy problem, ale czasami jest potrzeba zwiększenia wydajności np. tylko na kilka dni podczas akcji marketingowej.

 

 

Reasumując czy są firmy, które oferują rozwiązania w chmurze bez konieczności administracji serwerem? Jeśli tak to jakie konkretnie polecacie i dlaczego? To samo dotyczy firm, które oferują rozwiązania w chmurze, ale z wirtualnym serwerem.

 

 

Pozdrawiam

[Gość nrm]

Problem jest w tym, że każdy komplet oprogramowania dla klienta musi znajdować się na oddzielnym koncie (konto można rozumieć jako oddzielne konto na serwerze

To mi wygląda na zupełnie błędne założenia, które dalej generują kolejne. Jest jakiś rozsądny powód takich kombinacji? To jest jakiś sklepowy SaaS?

[OwiecPL1986 0]

Tak, klient nie ma dostępu do serwera, plików itd. Płaci abonament i dostaje dostęp do oprogramowania online przez przeglądarkę.

Edytowano Styczeń 16, 2013 przez OwiecPL1986 (zobacz historię edycji)

[Gość]

Edytowano Marzec 26, 2018 przez Gość (zobacz historię edycji)

[Gość nrm]

Tak, klient nie ma dostępu do serwera, plików itd. Płaci abonament i dostaje dostęp do oprogramowania online przez przeglądarkę.

To wiadomo. Ale w jakim celu chcesz robić jednego klienta per jedną maszynę (obojętnie fizyczną czy wirtualną)? Przecież to absurd.

[theONE 526]

Chmury są fajne tylko jeżeli cały projekt jest mały ale ma szansę bardzo szybko urosnąć w sposób niekontrolowany a potem ulec redukcji albo w bardzo niewielkich okresach czasu spodziewasz się dużego ruchu (np przez 5 dni w roku) a potem nic się nie będzie dziać na stronie.

 

Jeżeli budujesz środowisko na 3-4 serwery dedykowane po którym porozbijasz set klientów małych to zawsze lepiej wynajmować serwery albo mieć własne i kolokować (zależy od modelu biznesowego) a nie iść w obcą chmurę.

 

Obce chmury są świetne jak potrzeba stabilnego miejsca na serwowanie niewrażliwych danych (multimediów) albo kiedy nie wiesz jak szybko i kiedy coś urośnie. Ale kosztują za dużo przy średnich środowiskach.

[OwiecPL1986 0]

@nrm tak jak napisałem z powodów bezpieczeństwa oraz wydajnościowych. Jeżeli ktoś znajdzie jakiś błąd w sklepie A będzie miał dostęp tylko do danych ze sklepu A. Błąd może dotyczyć przecież czegoś od strony panelu administracyjnego, a nie tylko od detalicznego klienta sklpeu. To po pierwsze, a po drugie to ze względów wydajnościowych. Przecież kampania sklepu A i zwiększony ruch nie może zaburzać pracy sklepu B. Jeśli krytykujesz to proszę o konstruktywną krytykę.

 

@theONE niekontrolowany rozrost, redukcja itd. to właśnie cecha charakterystyczna dla sklepów internetowych jeśli rozpatrywać je każdy z osobna. Jeśli zaś spojrzeć na to z perspektywy zbioru sklepów, którym udostępniam oprogramowanie faktycznie tutaj raczej powinno rosnąc to stabilnie, chociaż tego nigdy nie da się przewidzieć przy nowych projektach. W każdym razie zawsze można to kontrolować i ograniczać ilość nowych sklepów, aby nadążyć z dostawianiem sprzętu.

 

Hmm czyli w takim razie nie chmury?

 

To może zapytam inaczej: jak w takim razie konkretnie proponujecie rozwiązać to od strony sprzętowej tak aby było bezpiecznie i wydajnie z założeniem, że poszczególne sklepy, na krótkie okresy czasu (akcje marketingowe) potrzebują więcej zasobów, a później chcą wrócić do mniejszych. Jeśli serwery dedykowane to w jakiej konfiguracji przy takich założeniach?

[maniack 403]

.

Edytowano Wrzesień 9, 2017 przez maniack (zobacz historię edycji)

[Gość nrm]

@nrm tak jak napisałem z powodów bezpieczeństwa oraz wydajnościowych. Jeżeli ktoś znajdzie jakiś błąd w sklepie A będzie miał dostęp tylko do danych ze sklepu A. Błąd może dotyczyć przecież czegoś od strony panelu administracyjnego, a nie tylko od detalicznego klienta sklpeu. To po pierwsze, a po drugie to ze względów wydajnościowych. Przecież kampania sklepu A i zwiększony ruch nie może zaburzać pracy sklepu B. Jeśli krytykujesz to proszę o konstruktywną krytykę.

 

Czyli tak jak napisałem to na samym początku: błędnie przyjęte założenia generują kolejne błędne decyzje.

 

Tu nie chodzi o krytykowanie tylko o wskazanie, że sugerowane rozwiązania nie mają sensu. Nie tak produkuje się oprogramowanie typu SaaS. Zresztą napisałeś, że dla każdego klienta chciałeś osobne konto czyli osobna instancje oprogramowania - to znaczy, że docelowo chciałbyś zarządzać setkami czy tysiącami instancji z osobna?

 

Jeżeli takie są założenia softu to najlepiej rozwiązać to podobnie jak hosting współdzielony - cgroups i przydzielanie zasobów, monitorowanie i przenoszenie na inną maszynę fizyczną w momencie przekroczenia zasobów ponad możliwości głównego serwera. Jednak musisz się przygotować na ogrom pracy administracyjnej (nie zrozumiałem czemu w pierwszym poście napisałeś "chmura - nie muszę administrować").

[OwiecPL1986 0]

@manciak różnica byłaby taka, że na czas kampanii mógłbym "przesunąć suwak" dla konkretnego sklepu w górę aby miał na kilka dni więcej zasobów do dyspozycji. To samo jak będzie systematycznie rósł, nie będzie trzeba go za każdym razem przenosić fizycznie na inną maszynę, a tylko się "przesunie suwak" w chmurze. Chyba, że źle myślę?

 

@nrm Podsumowując doradzasz aby wyposażyć się we własne/dzierżawione maszyny i zrobić na nich hosting z kontami, które mają ograniczony dostęp do CPU, RAMu itd.?

 

Prawda jest taka, że nie mam żadnego sensownego doświadczenia z chmurami. Wydawało mi się, że z założenia powinno być to o wiele lepsze rozwiązanie, bo odciąża mnie z dbania o sprzęt i daje bardzo duże możliwości zmniejszania/zwiększania zasobów według potrzeby w danej chwili. Widziałem to tak jak w we własnych serwerach z limitami do CPU itd. z tym, że to nie ja musiałbym się martwić o zarządzanie tym. Czyli sam miałbym jedną dużą chmurę, którą dzieliłbym na małe chmurki ale może po prostu nikt czegoś takiego nie daje w sensownych cenach?

 

Sprzętem serwerowym nie zajmuję się od 5 lat i już nie ogarniam tak jak kiedyś...

 

No ale ok, doszliśmy do tego, że tak jest źle.

 

 

Czyli potrzebuję własnych/dzierżawionych serwerów w serwerowni. Najchętniej wziąłbym to razem z opieką administratora. Polecacie jakąś konkretną firmę z uzasadnieniem dlaczego właśnie ta firma?

[Gość nrm]

To niestety nie jest do końca tak jak myślałeś. Ów suwak dotyczy jednej wirtualnej maszyny - musiałbyś zestawiać pełne środowisko per każdy klient. Zdajesz sobie sprawy jakie to są koszty utrzymania? A pomijając koszty zostaje Ci problem zestawienia i utrzymywania setek serwerów. Oczywiście jest oprogramowanie to ułatwiające, ale podkreślam _ułatwiające_, problem zarządzania ogromną flotą nadal zostaje. To by była masakra.

 

Co doradzam? Ja to bym w ogóle zrobił jako typowy SaaS czyli jedna instancja oprogramowania i jedno środowisko, które jest odpowiednio skalowane w zależności od potrzeb i możliwości. Sama oszczędność na każdym etapie (utrzymywanie sprzętu, środowiska, monitoringu, czasu, ludzi etc.).

 

No ale rozumiem, że ten soft już jest zaprojektowany jako stawiany w kopiach. W takim razie tak jak napisałeś: zrobiłbym to na zbliżonej zasadzie do hostingu współdzielonego. Każdy klient = osobne konto, limitowanie zasobów. W momencie przekraczania zasobów per klient - można mu je zwiększyć do wartości, które obsłuży serwer. Dla dużo większych klientów drugi serwer/dodatkowe serwery wg. zapotrzebowania. Pewnie jak w całym życiu sprawdzi się zasada pareto 80/20 - 80% wejdzie na shared, a 20% będzie ew. potrzebowało czegoś więcej. Ze swojego doświadczenia byłbym skłonny zaryzykować, że to nawet może być 90/10.

 

Jeżeli ten soft jest dobrze napisany + nie wymaga dużych zasobów = to stosując odpowiednią konfiguracje i soft dodatkowy (cache na różnych poziomach) jesteś w stanie na jednym dobrym serwerze utrzymać tego sporą ilość. Nie ma jakby porównania w kosztach bezpośrednich i pośrednich utrzymania 100 klientów współdzielonych, a 100 fizycznych/wirtualnych serwerów.

 

Jeżeli potrzebujesz serwerów & PRO wsparcia to zapraszam na PW.

[OwiecPL1986 0]

@nrm hmm ale czy przy jednej instancji i jednym środowisku nie rośnie zagrożenie włamania? Nie oszukujmy się oprogramowania wolne od błędów nie istnieją. Jeśli już mają wykraść dane sklepu A to trudno, ale gdyby mieli wykraść wszystkim na raz... Druga kwestia to jak wtedy limitować i mierzyć obciążenie, które generują poszczególne sklepy? Czy istnieją rozwiązania systemowe, które w sposób skuteczny rozwiążą moje 2 główne problemy w przypadku jednej instancji i jednego środowiska?

 

Soft dopiero jest pisany i jest tak zaprojektowany, że będzie działał w dowolnej konfiguracji i zawsze będzie można wyrzucić jakąś część podsystemu na inny serwer jeśli będzie taka potrzeba. Także żadna nawet drastyczna zmiana na tym etapie nie stanowi problemu.

[Pan Kot 1535]

Powiem tak... Po pierwsze jeśli to jest dziura "w skrypcie" to tak czy siak skoro wszystko będzie jechać na tym samym to i wszystko polegnie, nie masz na to wpływu. Po drugie jeśli chodzi o maszynę to dobry administrator załatwi takie podstawowe rzeczy jak jaile, IDS'a, NIDS'a, kontrolę zasobów i milion innych rzeczy, które będą specjalnie przygotowane pod tą aplikację. Mówisz o włamaniu - Obecnie trzymam na własnym serwerze każdego usera "osobno", pomimo że jest to jeden serwer. Co mam na myśli? Ano to, że każdy user jest zamknięty w JAIL'u w swoim home, ma dostęp jedynie do SFTP, a na jego koncie odpalona jest instancja (worker) nginxa + php-fpm. Dodatkowo user ma dostęp do bazy danych, a konkretniej jedynie swojego usera i swojej bazy. Efekt? W przypadku przejęcia nawet wszystkich tych rzeczy nie ma opcji dostępu do reszty serwera, z jaila nie ma opcji wyjść, do tego grsecurity & pax + CSF i parę dodatkowych autorskich skryptów przykłada rękę do tego, żeby wszystko działało zgodnie z przeznaczeniem. Limity CPU, RAM'u etc są przydzielane per-user, a poszczególni workerzy są również z danego usera odpalani. Przypominam, że jest to jeden serwer dedykowany i nic poza tym, żadnej wirtualizacji.

Edytowano Styczeń 17, 2013 przez Archi (zobacz historię edycji)

[Gość nrm]

@nrm hmm ale czy przy jednej instancji i jednym środowisku nie rośnie zagrożenie włamania?

Rośnie/maleje - to kwestia przyjętej perspektywy. Można by się tu sprzeczać w nieskończoność. Moim zdaniem, jesteś w stanie zwiększyć bezpieczeństwo na jednym (kilku) serwerach - masz możliwość ich jaknajlepszej konfiguracji i zarządzania nimi, czego nie można powiedzieć o setkach serwerów (jest to dużo bardziej czasochłonne, tym samym znowu mnoży koszty do kosmicznych wartości).

 

Masz rację, że teoretycznie przejęcie jednej maszyny robi więcej szkody, ale praktycznie skoro znalazłem dziurę w jednym to lecę sprawdzić kolejne serwery bo mam OGROMNE szanse na to, że i one są podatne na to samo (a umówmy się: mając setki serwerów, korzystasz z oprogramowania do zarządzania pakietami i konfiguracją na wszystkich w ten sam sposób i powielasz ten sam błąd). I znowu: różnica w kosztach: KOSMICZNA!

Druga kwestia to jak wtedy limitować i mierzyć obciążenie, które generują poszczególne sklepy? Czy istnieją rozwiązania systemowe, które w sposób skuteczny rozwiążą moje 2 główne problemy w przypadku jednej instancji i jednego środowiska?

Tak jak pisałem wcześniej, choćby cgroups. To wszystko można oskryptować, napisać własne procedury do zarządzania tym, zwiększania parametrów etc. Coś w stylu jak @Archi napisał, choć akurat robienie httpd/sql wydzielonego OSOBNO per kontener to spory narzut, jak dla mnie to zbyt duży jak na taki projekt.

[OwiecPL1986 0]

@Archi Nie polegnie wszystko. Największe zagrożenie jest raczej w aplikacjach, do których mają dostęp pracownicy sklepu A, a nie tym co widzą jego klienci detaliczni. Wtedy ktoś mógłby założyć fałszywy sklep tylko po to aby wykryć w nim błąd i wykraść dane ze wszystkich pozostałych sklepów. To jest jakieś tam realne zagrożenie jakby nie patrzeć.

 

Z tym, że przykład który opisałeś u siebie nie jest już jedną instancją?

 

@nrm odnośnie włamania to co napisałem do @Archi.

 

Może moje pytanie idzie za daleko, bo to Twoje doświadczenie i Twój czas ale zapytam.

 

Czy możesz w takim razie zaproponować bardziej konkretnie jakaś przykładową konfigurację? Nie mogę ogarnąć tego jak na jednej instancji, co rozumiem przez jedną i tylko jedną aplikację fizycznie na serwerze, do której logują się wszyscy mogę mierzyć zużycie zasobów poszczególnych sklepów i limitować te zasoby? Dodam, że obciążenie generuje nie tylko wchodzenie klientów detalicznych na stronę sklepu, ale także np. synchronizacje systemów magazynowo-księgowych itd.

[Pan Kot 1535]

W moim przypadku każdy user ma swój katalog. Nie wiem /home/klient789/www/. Każdy folder przypisujesz pod konkretnego vhosta np. klient789.mojsklep.pl. Każdego vhosta odpalasz przez osobnego workera, który działa z prawami danego klienta. Efekt jest taki, że wszystkie requesty do klient789 są wykonywane przez klient789, więc w przypadku hacka tracisz tylko ten konkretny profil.

 

Jeśli masz jedną aplikację, jako jakieś skrypty php czy coś takiego to jest to fizycznie niemożliwe, to znaczy jest możliwe, ale trzeba by było pisać skrypty, które oddzielają każdą stronę i na tej bazie generować statystyki. Wg mnie jest to strasznie słabe rozwiązanie i o ile taka jedna aplikacja, która ma sobie działać jest OK, to można w niej właśnie zrobić przycisk "dodaj nowy sklep", która działa dokładnie tak, jak napisałem na początku.

 

Funkcja "dodaj nowy sklep" tworzy nowego klienta, katalog, workera i całą resztę praw dostępu, user może sobie z poziomu Twojego panelu wyedytować co tam chce, ale fizycznie pliki (czyli jego sklep) nie są odpalane przez roota, a przez konkretnego workera.

Edytowano Styczeń 17, 2013 przez Archi (zobacz historię edycji)

[Gość nrm]

Tutaj pomieszaliśmy teraz kilka rozwiązań - każde jest dobre ale do czegoś innego.

 

To co opisuje @Archi to świetna sprawa ale bardziej się sprawdzi do jakiegoś shareda dla developerów (w sensie: każdy user = osobna instancja softu typu httpd/sql/etc.).

 

To co ja opisuje w skrócie jako SaaS: tutaj nie zmierzysz takiego obciążenia bo jeden user, dajmy na to apache odpala i obsługuje wszystko. Ale też nikt takich rzeczy w SaaSach nie mierzy! Owszem w niektórych limituje się powierzchnie na cośtam (da się), w innych mierzy się zużyty transfer (tez po vhostach da się zliczyć), ale nikt nie mierzy obciążenia bo to już sprawa dostawcy usługi aby wykonał tak skalowalne środowisko aby wszystko grało. Z kolei usługodawca zawsze ma po czym billingować więc z pewnością tych bardzo intensywnie działających zbilinguje w taki czy inny sposób.

 

I na koniec wersja nr 3 czyli Twoje osobne instancje oprogramowania. Tutaj nie pasuje wersja SaaSowa, ani wersja Archiego - bo dla najbardziej optymalnej i wydajnej wersji powinieneś mieć tego jednego httpd/sql i go idealnie skonfigurować dla całego środowiska. Oczywiście, możesz to zrobić w wersji setek kontenerów, a każdy z swoimi instancjami ale to jest OGROMNY narzut na serwer i ten sam ból w kwestiach konfiguracyjnych. Moim zdaniem w tej opcji zostaje coś a'la hosting współdzielony.

 

--

 

"fałszywy sklep, wykrywanie dziur" - nikt nie powiedział, że masz dawać do tego dostęp FTP. Skoro tym zarządzasz i dostarczasz jako usługę to nie ma takiej potrzeby.

 

 

[OwiecPL1986 0]

@nrm oczywiście ftpa nie będzie, ale co to ma do tego? Równie dobrze można znaleźć dziurę w panelu CMS pozwalającym zmieniać wygląd sklepu tak aby odczytać inne pliki itd.

 

Dobra rozrysowałem sobie wszystko na kartce i mam nową idee. Powiedzcie mi czy coś znowu pominąłem.

 

Każdy ze sklepów wymaga swojego katalogu z plikami oraz podpięcia własnych domen. Będzie także potrzebował dostępu do bazy danych. Chcę aby kod systemu był w możliwie najmniejszej ilości kopii, najlepiej w jednym miejscu.

 

Problem jest taki, że za każdym razem kiedy klient detaliczny będzie odwiedzał sklep (a właściwie przy każdym zapytaniu przeglądarki) lub pracownik sklepu będzie korzystał z systemu, to system musi odnieść się do właściwych danych w bazie danych oraz plików na dysku. Gdyby wszystko było zawsze uruchamiane przez jeden skrypt, odnajdywanie w bazie danych po domenie co należy wczytać każdorazowo wydaje mi się niepotrzebnym obciążeniem i może być dość problematyczne. Sklep może mieć kilka domen, a także może mieć wspólny koszyk i pod każdą domeną wyświetlać inny sklep.

 

Pomyślałem, więc o odwrotnym podejściu. Wszystkie pliki powtarzalne czyli kod systemu wrzucić w jedno miejsce na serwerze, aby można było nim łatwo zarządzać i go aktualizować. Dla każdego sklepu tworzyć nowego usera z katalogiem, a w nim umieszczać konfiguracje dla systemu oraz wszystkie pliki niepowtarzalne. Do tego katalogu przypisywać również domeny w apache, nginx czy też innym serwerze.

 

Otwierając stronę strona.pl uruchamiałby się np. plik index.php, który ładowałby konfigurację i ładował moduł (z jednego stałego miejsca na serwerze) wyświetlający sklep dla usera. Tak samo gdyby ktoś otworzył strona.pl/panel/support wczytałaby się odpowiednia konfiguracja i został załadowany analogicznie moduł.

 

Rozwiązanie wydaje mi się na pierwszy rzut oka całkiem elastyczne i optymalne?

Edytowano Styczeń 17, 2013 przez OwiecPL1986 (zobacz historię edycji)

[Pan Kot 1535]

Owszem, tylko kłóci się z Twoim podejściem do security. Jeśli skrypt sklepu może "odczytać" tak naprawdę cokolwiek z samego dedyka to już masz dziurę, która nawet dobrze zabezpieczona jednak zezwala na komunikację vhost klienta => panel. Albo robisz wszystko niezależne i dany vhost ma dostęp tylko do swoich rzeczy i w nim operuje, a panel ewentualnie może coś wyedytować (nie działa to w drugą stronę więc security zachowane), albo robisz koncepcję podobną do @nrm'a, która również ma swoje zalety i wady, ale jednocześnie stwarza ryzyko większej liczby dziur, bo w tym wypadku jednak mając dostęp do jak to mówisz "modułu" można w nim pogrzebać, nawet jak jest read only to jednak stwarzasz dziurę na poziomie wykonania dziurawego kodu => panel.

 

Pomysłów jest dużo, musisz tylko albo nastawić się na security i sporo "roboty", może niekoniecznie stałej, ale wymagającej albo typowy model Saas, jak wspomniał nrm, który jest na pewno łatwiejszy w obsłudze, ale stwarza kilka dodatkowych zagrożeń. Wybór należy do Ciebie, zarówno jedno jak i drugie rozwiązanie ma swoje wady i zalety.

[Gość nrm]

@nrm oczywiście ftpa nie będzie, ale co to ma do tego? Równie dobrze można znaleźć dziurę w panelu CMS pozwalającym zmieniać wygląd sklepu tak aby odczytać inne pliki itd.

Dziury możesz znaleźć wszędzie. Na każdym poziomie od serwerowego po aplikacje. Przecież nie da się w 100% wykluczyć tego jakiegokolwiek sposobu byś nie wybrał.

 

Problem jest taki, że za każdym razem kiedy klient detaliczny będzie odwiedzał sklep lub pracownik sklepu będzie korzystał z systemu, to system musi odnieść się do właściwych danych w bazie danych oraz plików na dysku.

To żaden problem. Nie jest to też żadnym obciążeniem - to zwykłe działanie.

[OwiecPL1986 0]

@nrm a jakie według Ciebie rozwiązanie jest lepsze? Nie tylko pod względem sprzętowym, ale także funkcjonalnym i do zarządzania.

 

To co opisałem post wyżej? Czy każdorazowe szukanie w bazie danych do jakiego katalogu i jakiej bazy danych się odwołać, czyli wszystkie odwołania do sklepów zawsze przechodzą fizycznie przez ten sam jeden plik? Już nawet nie chodzi mi o to szukanie odpowiedniego katalogu, ale o to czy nie komplikuje to niepotrzebnie kodu, czy nie jest tym trudniej zarządzać. Ciężko mi w tej chwili wszystko przewidzieć i o wszystkim pomyśleć. Niestety wychodzi trochę brak doświadczenia w pisaniu tego typu aplikacji.

Edytowano Styczeń 17, 2013 przez Gość (zobacz historię edycji)

[Gość nrm]

Wiesz, dla mnie to dosyć abstrakcyjne pytanie biorąc pod uwagę, że framework to jeden, duży system odpalany jednym indexem.

 

Dla mnie oczywiście jedynym rozsądnym rozwiązaniem jest typowy SaaS: jedna aplikacja obsługuje wszystko i wszystkich. Tak działają setki tysięcy aplikacji, które codziennie widzisz albo z nich korzystasz w necie. Tak też pewnie działa Twoja przyszła konkurencja, tak działają te wszystkie popularne teraz sklepy, itd. itd. To są same zalety (dlatego tylu z takiego modelu korzysta), a zaoszczędzone pieniądze i inne środki możesz przeznaczyć na testy, hacking i ogólne podnoszenie poziomu bezpieczeństwa zarówno aplikacji jak i platformy. WIN-WIN.

 

To co nazywasz "każdorazowym szukaniem" to jest milisekundowy pryszcz - na podstawie vhosta pytasz o config. 0.005s A jak jakimś cudem miało to by być problemem to zrzucasz to do pamięci i w ogóle nie ma o czym rozmawiać 0.000000001s

[OwiecPL1986 0]

Gdybym odpalał jeden sklep dla siebie nie miałbym wątpliwości. Na 100% byłby do tego tylko "jeden plik", ale w momencie kiedy każdy klient ma mieć swój sklep, w którym będzie miał swoich klientów w sposób intuicyjny chce go funkcjonalnie wydzielić. Może to po prostu intuicja mnie zawodzi i źle myślę, ale może jednak to ma sens...

 

No tak ale jeśli vhost to znaczy, że odwołuję się do innego katalogu przy każdej domenie? Czy jak miałoby to działać?

 

Szkoda, że nie jesteś z Poznania to bym się z Tobą spotkał. Opowiedział Ci jaki mam pomysł na system z punktu widzenia funkcjonalności, bo takiego systemu sklepu jeszcze nie widziałem, a Ty byś mi doradził jak to rozwiązać sprzętowo/systemowo.

 

Zaliczmy, że liczba klientów rośnie i potrzeba dajmy na to 10 serwerów. Rozumiem, że każdy serwer ma jednak swoją własną kopię systemu czy da się to rozwiązać jakoś dobrze tak aby system był tylko na jednej z maszyn?

 

W sumie sam sobie odpowiedziałem na to pytanie: po prostu należałoby wydzielać pewne części systemu, które się da jako oddzielne aplikacje na inne serwery i łączyć całość przez API.

 

Chyba muszę się z tym przespać...

Edytowano Styczeń 17, 2013 przez OwiecPL1986 (zobacz historię edycji)

[Gość nrm]

Gdybym odpalał jeden sklep dla siebie nie miałbym wątpliwości. Na 100% byłby do tego tylko "jeden plik", ale w momencie kiedy każdy klient ma mieć swój sklep, w którym będzie miał swoich klientów w sposób intuicyjny chce go funkcjonalnie wydzielić.

Wyobrażasz sobie sytuacje kiedy każdy użytkownik gmaila ma swoja kopię aplikacji? Albo każdy z 10 miliardów ludzi z fejsa ma swoją kopię fejsa?

 

No tak ale jeśli vhost to znaczy, że odwołuję się do innego katalogu przy każdej domenie? Czy jak miałoby to działać?

Nie wiem jak wygląda Twoja aplikacja, co dokładnie robi więc ciężko mi dokładnie powiedzieć. Mogę jedynie coś przypuszczać i/lub stosować uproszczenia. Mi aplikacja po vhoście odczyta config takiego usera i już będę wiedział co i gdzie dla niego leży (o ile jest w ogóle potrzeba aby w taki sposób rozdzielać statyke bo na ogół tego się nie robi, wystarczy samo user_id).

 

 

Zaliczmy, że liczba klientów rośnie i potrzeba dajmy na to 10 serwerów. Rozumiem, że każdy serwer ma jednak swoją własną kopię systemu czy da się to rozwiązać jakoś dobrze tak aby system był tylko na jednej z maszyn?

Każdy ma kopię. Znaczy się jest osobnym systemem. W zależności od potrzeb i architektury stosuje się skalowanie poziome lub pionowe, z baz robi się różne ustawienia typu master/slave, a nawet robi sharding. To kolejne baaardzo szerokie zagadnienie.

 

Dla ułatwienia powiem Ci, że (zakładając, że ta aplikacja będzie zupełnie normalna i nie zabije serwera) jeden porządny serwer z dobrymi ustawieniami wytrzyma Ci bardzo dużo tych sklepów. Sytuacja z 10 serwerami to już na prawdę ogromne środowisko na tysiące klientów - czego oczywiście Ci życzę, ale mimo wszystko, nawet przy intensywnym rozwoju - to długa droga.

 

No niestety, w Poznaniu dawno nie byłem i na razie nie zanosi się na tamten kierunek. Najbliżej to Wrocław pod koniec lutego

 

Swoją drogą właśnie robię pewna apkę do której będzie można podpiąć zew. domeny - każda definiuje innego usera. Jedna apka obsłuży wszystkich. Klasyczny przykład.

[VPS365.eu 17]

Może najrozsądniejszym rozwiązaniem będzie prywatna chmura postawiona na początek na VPSach a potem na dzierżawionych dedykach? Stawiając każdą instancje klienta jako osobną maszynę wirtualną (albo więcej - osobno baza, osobno frontend itd) mamy możliwość fajnie to skalować i przerzucać pomiędzy różnymi maszynami. Małe sklepy mogą w ilości kilkuset szt pracować na jednym serwerze, a jak rosną to dostaną swój jeden lub kilka. Przeniesienie na inną maszynę to 1 kliknięcie lub nawet nie (jeżeli zrobi to automat).