gb1

@patryk Amazon Linux to tak jak każda inna dystrybucja Linuxa dużo związków ma z kernel.org, tak dalej idąc to dojdziemy do produkcji własnych procków :-) Choć na przykład Qualcomm oraz ARM powoli od lat wchodzą w obszar serwerowy. Jak widać można :-) choć nie zawsze się opłaca. Musisz jednak przyznać, że poskładania, a co ważniejsze utrzymywanie na bieżąco własnej dystrybucji to jest pewne wyzwanie i świadczy o świadomości i poziomie technicznym dostawcy usługi. W szczególności jak porównujesz do rynku usług hostingu gdzie często udostępnianie w rozsądnym czasie do wyboru aktualnych wersji php jest wyzwaniem :-) Tak tylko na marginesie to AMI to skrót od Amazon Machine Image, czyli obrazu dostępnego w ramach AWS, który jak każdy OS w ramach platformy AWS musi posiadać także Amazon Linux.

@Jabunsed przy takich parametrach serwer dedykowany to według mnie jedynie problemy w przyszłości. Sugeruję odpowiednio dobrać usługę chmurową, odpadają Tobie wszystkie kwestie dotyczące poprawnie działającego RAID, sprzętu, kompatybilności, diagnozowania, etc. skupiasz się na tym co istotne dla biznesu czyli: dostępność, wydajność oraz bezpieczeństwo. W przypadku aplikacji biznesowych istotnymi parametrami które są istotne aby biznes ustalił PRZED projektowaniem rozwiązania technicznego to: Recovery Point Objective - czyli za jaki maksymalnie okres dane mogą zostać utracone, Recovery Time Objective - czyli po jakim maksymalnie czasie system powinien powrócić do poprawnego działania, Oczywiście powyższe parametry mogą być różne dla różnych obszarów danych lub części aplikacji. Dla przykładu dla eCommerce dane dotyczące zamówień są istotne i tutaj RPO często jest niskie, natomiast inne dane (np. na temat produktów) są już mniej istotne i tutaj dopuszczalne są często wyższe parametry dla RPO. Dlaczego jest to istotne ? Ponieważ często RPO ma wpływ na wydajność rozwiązania. Znając wartości RPO oraz RTO można przystąpić do planowanie rozwiązania technicznego, gdzie istotnymi informacjami pod względem planowania bezpieczeństwa i ciągłości działania są w szczególności: jak dużo danych posiadamy i w jakich obszarach jaka jest delta za istotny okres czasu (np. dzień) danych w każdym z obszarów Następnym krokiem jest poznanie aplikacji oraz ograniczeń które posiada architektura aplikacji. Wydajność jest istotna, zatem istotne jest poznanie charakterystystki wykorzystania aplikacji: zamknięty kontrolowany krąg użytkowników ? zamknięty krąg użytkowników jednak nie kontrolowany ? publicznie dostępna aplikacja ? Posiadając takie dane, można rozpocząć dopasowanie rozwiązań technicznych. Pisałeś, że jest to krytyczna aplikacja biznesowa, podzielisz się zatem szerszymi informacjami poza tylko technicznymi ? Chętnie podzielę się wiedzą jak odpowiednie podejść do tematu.

Czy w przypadku hostingu który nie określa minimalnych parametrów technicznych pod względem wydajności nie jest to przypadkiem wypadkowa wykorzystania w danym momencie przez licznych użytkowników i będzie się zmieniała wraz z wykorzystaniem danego zasobu fizycznego przez użytkowników ? To że w danym momencie pomiaru są wyniki jakie podałeś, nie oznacza że takie będą rzeczywiste chwilę później. Sytuacja może być odwrotna, więc wystarczy jedynie zamienić nagłówek cytowanych wyników. Jak zapewne sobie także zdajesz sprawę na wyniki tego typu testów będzie miał wpływ w szczególności pod względem operacji "select" ile danych jest nadal przechowywanych w cache (a mamy tutaj cache na różnych poziomach) oraz konfiguracja samej mysql. Pierwsze z wymienionych jest nadal wypadkową wykorzystania zasobów w danym czasie przez wszystkich użytkowników wykorzystujących dany zasób fizyczny. Tutaj należy pamiętać, że nie tylko za pojemność dysku płacisz, ale także za operacje io (czyli operacje na dysku).

3. Wydajność Czy gwarantowane są minimalne parametry techniczne usługi w zależności od zakresu usługi: serwer aplikacyjny (np. php) zasobów procesora dostępnej pamięci operacyjnej (ram) operacji io dla dysku baza danych zasobów procesora dostępnej pamięci operacyjnej (ram) operacji io dla dysku serwer poczty maksymalna ilość wiadomości wysłanych / odebranych w okresie czasu maksymalna wielkość wysyłanych / odbieranych wiadomości Należy pamiętać że większość usług są to usługi współdzielone na zasadzie "best effort" i dostępne zasoby serwer są wynikową obecnego wykorzystania przez innych użytkowników. 4. Bezpieczeństwo Czy istnieje możliwość pobrania kopii bezpieczeństwa umożliwiającej odtworzenie w innym środowisku ? W jaki sposób wykonane są kopie bezpieczeństwa ? Pamiętajmy, że "snapshot" nie są zawsze odpowiednim rozwiązaniem. Czy istnieje elastyczność w doborze czasu archiwizacji (przechowywania) kopii bezpieczeństwa ? Jak często dostawca aktualizuje środowisko serwera aplikacji ? Jak wygląda procedura aktualizacji środowiska serwera aplikacji ? czy aktualizacje mogą wymuszać na użytkowniku dostosowanie uruchamianego oprogramowania ? czy mam wybór czy moje środowisko zostanie zaktualizowane ? 6. Elastyczność Obecnie rozwój uruchamianego oprogramowania w ramach usługi hostingu jest stale rozwijane i aktualizowane, a także wymagania względem usługi hostingu stale się zmieniają co stawia nowe wyzwania i wymagania względem usług hosting, w szczególności w zakresie elastyczności: Czy opłaty są pobierane jedynie za wykorzystane usługi w krótkich okresach rozliczeniowych: godzinowych lub dniowych ? Czy istnieje możliwość dowolnej zmiany usług wraz z aktualnymi potrzebami na przykład: zwiększenie wydajności w związku z akcjami promocyjnymi uruchomienie testowych środowisk przed wdrożeniem większych zmian Czy można zrezygnować z usług w dowolnym czasie nie ponosząc dodatkowych opłat ? Czy wykonywanie operacji jest możliwe samodzielnie przez API, CLI oraz panel (strona webowa) bez potrzeby ingerencji ze strony dostawcy ?

Wielu jest rozwija i nawet część udostępnia jako OSS, na przykład Rackspace i Openstack. Dokładnie tak się dzieje, jest to dobry wyznacznik świadomości i poziomu technicznego dostawcy. Tacy liderzy jak AWS, Azure czy GCE mają własną dystrybucją Linuxa, nie wspominając o tym że dość mocno udzielają się w jego rozwoju w różnych zakresach, zwykle w tych które są dla nich istotne. Gdzie to napisałem ? Czy to tylko Twoja subiektywne podsumowanie ? ;-) Kiedy nie byłeś zadowolony ? Należy pamiętać z jakiego powodu powstał w latach 90-tych własny serwer http w ich przypadku. Sprawdzone przez kogo ? Rozwój zatem będzie wykonywany przez kogo ? Czyli jesteś za brakiem innowacji i rozwoju pozostając przy tym co jest ? Nie wierzę :-) Spojrzyj na przykład na taki traefik (https://traefik.io/) nie powstałby przy takim myśleniu jak powyżej przedstawiłeś. Podzielisz się informacją na temat ciekawych rozwiązań jakie zastosowaliście, językami programowania które wykorzystujecie oraz zastosowaną architekturą ?

@SomeGuy w dużej części napisałeś to samo co ja wcześniej :-) Więc powtarzać się nie będę :-) Tutaj jednak zgodzić się nie mogę, DA to znacznie więcej aniżeli tylko GUI.

Patrz na architekturę rozwiązań, czy nie widzisz możliwości zastosowania i wykorzystania ? DA ma założenie (jesli coś sie ostatnio nie zmieniło) że wszystkie usługi znajdują się na jednym serwerze, bez specjalizacji oraz założeń rozproszenia usług. Mocna integracja całości w ramach jednego "konta" w jednym miejscu.

@mariaczi spojrzyj na rozwiązania stosowane w przypadku takich graczy rynkowych jak AWS, GCE, Azure czy mniejszych typu DO.

Czy nie uważasz że usługa cron dla przeciętnego użytkownika usługi w wymienionych wcześniej firmach nie stanowi dość dużej magii i mam wątpliwości czy większość ma nawet świadomość że istnieje. Według mnie klient korzystający z usług EIG to zupełnie inna grupa aniżeli użytkownik DA czy cPanel. Patrząc na GCE to mają własną obsługę większości funkcjonalności. Użytkownikiem takiej usługi zwykle jest już bardziej świadomy developer, któremu zwykle łatwiej podłączyć się do bazy z własnego komputera korzystając z oprogramowania i wersji która jest dla niego najbardziej odpowiednia. Przyznam że osobiście tylko kilka razy w życiu skorzystałem z phpmyadmina. Jednak chyba nie jest tak do końca, ponieważ panele które były dotychczas wymieniane jak DA czy cPanel nie są jedynie nakładką ale całym systemem także do realizacji tego co "klient sobie wyklikał". Panel narzuca nie tylko wygląd frontendu w którym klient "klika" ale cała architekturę rozwiązania, a oba wymienione panele mają architekturę pamiętającą jakieś ostatnie 15 lat i daleko im do współcześnie projektowanych rozwiązań. Z ciekawości zapytam się ponieważ nie śledzę na bieżąco rozwoju DA i cPanel, czy oba są nadal monolitycznymi rozwiązaniami ? Czy jednak już dokonały zwrotu i udostępniają jedynie API, które jest konsumowane przez aplikację webową, cli oraz umożliwia pełną integrację programistyczną ? Tutaj zależy od sytuacji, pamiętajmy że rzetelny dostawca usługi może odmówić ponieważ zdaje sobie sprawę z konieczności utrzymania długoterminowego takiego rozwiązania, a wszelkie rozwiązania nietypowe znacząco zwiększają koszty utrzymania lub to co zwykle bywa nie są utrzymywane. Na codzień widzę rozwiązania w których, "ktoś" kilka lat temu coś zainstalował nietypowego, napisał rozszerzenie, etc. po czym zaprzestał tego utrzymywania, co powoduje brak możliwości ciągłej aktualizacji całości rozwiązania. Takie podejście można stosować w przypadku rozwiązań dedykowanych gdzie klient płaci dodatkowo za utrzymanie rozwiażania, w innym wypadku jest to mało opłacalne, w szczególności w skali o której wspomina @patryk.

@patryk ludzi z wiedzą zawsze brakuje więc jeśli ktoś chętny i rzeczywiście wiedzę posiada aby wnieść do r&d to polecam się i faktury przyjmę z chęcią :-) Znasz jakieś zestawienie które zawiera szersze informacje na temat udziałów w rynku tych podmiotów ? Przyznam że o części z wymienionych marek / podmiotów nawet nigdy wcześniej nie słyszałem. Nie twierdzę, że nie można prowadzić zyskownego lub dużego biznesu hostingowego bazując na standardowych panelach. Twierdzę jedynie, że taka sytuacja pokazuje świadomość techniczną, posiadaną wiedzę i chęć inwestowania w r&d przez dostawcę usługi. Ostatnio w celach poznawczych zakupiłem usługę u jednego z lokalnych dużych dostawców usług hostingowych, może mam za mała wiedzę ale trzykrotnie musiałem kontaktować się ze wsparciem aby ustalić dość podstawowe sprawy. Przyznam, że doświadczenie było dość traumatyczne i rozumiem dlaczego duża część klientów godzi się płacić stawki po promocyjne aby tylko nie przechodzić przez cały proces ponownie :-) Uprzedzając pytanie, to były trzy różne panele, każdy do czego innego, jednak widać, że po stronie dostawcy brak chęci do inwestowania w r&d w celu ujednolicenia całości choć patrząc na wyniki finansowe to środki posiada aby inwestować.

@Rafiki dużo słów, ale brak odpowiedzi. Pamiętajmy że wartość przychodów to tylko jeden z parametrów wyników finansowych. Tak na marginesie to jakieś 12 lat temu na wht była duża dyskusja na temat obrotów jednego z dostawców hostingu (także obecny na tym forum), nikt jednak nie zauważył że wynikało to z niestandardowej jednorazowej operacji nie związanej z podstawową działalnością :-) Jednak wrażenie było bardzo pozytywne dla większości :-)

Sam sobie odpowiedziałeś :-) Zgadzam się w całości, że rzetelne świadczenie usług wymaga odpowiedniej wiedzy, jednak patrząc na rynek to odnoszę wrażenie, że nie jest tak różowo jakby mogło się wydawać. Jednak posiadając wiedzę utrzymaniową korzystając ze standardowych paneli pozwala na świadczenie usługi na rozsądnym poziomie, jednak ograniczając ją do tego co panel pozwala oraz dynamiki rozwoju panelu. Posiadanie własnego oprogramowania wymaga znacznie wyższych kosztów oraz zasobów wiedzy na potrzeby r&d. Poprzez budowę własnych rozwiązań buduje się znacznie większą wartość wiedzy i doświadczenia, aniżeli wyłącznie świadcząc usługi na bazie standardowego oprogramowania.

Wskażesz gdzie widzisz te limity obecnie ? Przyznam że jeśli istnieją to tak dobrze schowali że nie potrafię ich znaleźć. Kiedyś znajdowały się w tabelce ze specyfikacją usługi, obecnie ich tam nie ma.

@patryk możesz wymienić te duże hostingi niemieckie wraz z porównaniem jakie udziały posiadają w rynku ? pozwoli to ocenić czy rzeczywiście co rozumiane jest przez "duże" z punktu widzenia lokalnego rynku w Niemczech ? przyznam że nie znam rynku niemieckiego zupełnie, zatem chętnie czegoś nowego się dowiem. Patrząc się jednak na dużych graczy światowych to nie widzę takich którzy korzystają ze standardowych paneli. Musisz przyznać, że świadczenie usługi za pomocą standardowego panelu nie wymaga zbytnio dużej wiedzy i świadomości technicznej, a tym bardziej nakładów na r&d.

@Rafiki dokonałeś stwierdzenia "OVH raczej nie musi się "odkuwać"", zatem byłem ciekawy czy takiego stwierdzenia dokonałeś na podstawie wiedzy która uzyskałeś z wyników finansowych wymienionej Spółki czy tylko na podstawie swojej subiektywnej oceny. Dwa razy unikałeś odpowiedzi na proste pytanie, zatem widocznie to druga opcja. Miałem nadzieję na bardziej merytoryczną dyskusję :-)

@Rafiki ciekawe podejście przedstawiasz, choć mało konkretne i zgodne z rzeczywistością. Tylko tak na marginesie należy dodać, że znajomość marki i wielkość firmy nie oznacza że nie muszą się "odkuwać". Dobrym przykładem jest Nokia. Wracając do meritum, widziałeś wyniki finansowe ?

Wiedza tajemna :-) podziela się zatem prywatnie :-)

Czytaj ze zrozumieniem :-) nigdy czegoś takiego nie twierdziłem. Podzielisz się pozostałymi ?

Czy to nie ilustruje wiedzę i chęć inwestowania w r&d przez lokalnych dostawców usług hostingu ?

a co z limitami ?

rozwiąż to lepiej zatem samodzielnie i będziesz miał problem rozwiązany. widziałeś ich wyniki finansowe że tak twierdzisz ?

W mainline nie ma, ale dwa różne podejścia od wielu lat są, jedno to port (chyba) z FreeBSD. Jeśli brakuje Tobie TRIM to stań się maintainerem :-) jestem pewien że przyjmą pomoc z otwartymi ramionami

https://jwt.io/ Pomyśl ile serwisów korzysta z tego rozwiązania rzeczywiście trzymając poufne dane w cookies.

Czyli jednak gra rolę czy aplikacja jest monolityczna czy rozproszona :-) Z powyższym się jak najbardziej zgadzam, jednak zaprzecza to Twojemu pierwszemu zdaniu. Jeśli jeden "node" w aplikacji się "crashuje" nie oznacza że socket na którym przyszło zapytanie musi zostać zwolniony, zatem monitorowanie tego socketu nie jest zbytnio istotne. Pamiętajmy jakiego konkretnego przypadku dyskusja dotyczy.

@Archi Według mnie to co sugerujesz jest naturalnym rozwiązaniem, jednak musisz przyznać że zadziwiające jest że obecne rozwiązanie które jest opisywane w przypadku tego wymienionego dostawcy jest dość kuriozalne i z mojego powodu mało przydatne do realnego wykorzystania. Pytanie pozostaje jedynie jaki procent użytkowników z tego segmentu zdaje sobie sprawę, że jakieś limity istnieją. Większość z nich nawet nie zbliży się zapewne do tych limitów. Pamiętajmy że usługa nie jest kierowana do jak to ująłeś "POWAŻNYCH" klientów biznesowych, większość z poważnych klientów biznesowych nie zawierzy swoich danych usłudze za kilka złotych miesięcznie czyli zapewne znacznie poniżej wartości obiadu który zjada przeciętny pracownik firmy. Inny segment rynku, inna oferta, inny odbiorca z innymi oczekiwaniami. Nie zgodzę się jednak z Tobą, że "POWAŻNY" klient godzi się na otrzymanie dodatkowych opłat, z mojego doświadczenia większość klientów woli wyższą wartość miesięczna ale stałą która w większości przypadków zaspokoi ich potrzeby. Według mnie rynek biznesowy w Polsce nie jest zbytnio gotowy mentalnie na zasadę elastycznych płatności od rzeczywistego wykorzystania jak w przypadku chmur publicznych typu Azure, GCE, czy AWS. Myślę że tutaj podajesz czas jedynie za pracę techniczne, pomijając wszelkie inne, a które zwykle zajmują znacznie więcej czasu. Ale szacunek za realne podejście przynajmniej w zakresie technicznym :-) Podzielam Twoje zdanie, ale jak widać rynek nie uważa tego za czynnik sprawiający że oferta jest odrzucana.