Skocz do zawartości

gb1

Użytkownicy
  • Postów

    280
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    2

Odpowiedzi opublikowane przez gb1

  1. @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ć. 

  2. @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 :-)

  3. Godzinę temu, Marek607 napisał:

    Na jakiej podstawie to stwierdziłeś?

     

    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.    

  4. 3 godziny temu, sebak napisał:

    Limity zostały ukryte lub zmienione. Limit operacji dyskowych został ukryty w specyfikacji usługi

     

    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.

  5. @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. 

  6. @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ę :-)

  7. @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 ?

  8. 15 minut temu, sebak napisał:

    Mówiłeś, że ZFS on Linux niczego nie brakuje,

     

    Czytaj ze zrozumieniem :-) nigdy czegoś takiego nie twierdziłem. 
     

    15 minut temu, sebak napisał:

    jeden z kilku przykładów Ci podałem.

     

    Podzielisz się pozostałymi ?

  9. 3 godziny temu, daffx napisał:

    przesada brać kasę za cos co nie działa dobrze

     

    rozwiąż to lepiej zatem samodzielnie i będziesz miał problem rozwiązany.

    W dniu 08/12/2017 o 09:13, Rafiki napisał:

    OVH raczej nie musi się "odkuwać"

     

    widziałeś ich wyniki finansowe że tak twierdzisz ?

  10. 16 godzin temu, Archi napisał:

    Obowiązkiem procesu w przypadku awarii jest zakończyć wszystkie swoje procesy i procesy dzieci, nie musi od razu rozwalać całej architektury, to tak jak padnięcie pojedynczego node'a.

     

    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. 

  11. @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.

     

    6 godzin temu, Archi napisał:

    a po 20h masz całą implementację i wdrożenie.

     

    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 :-)

    13 godzin temu, theqkash napisał:

    O tym że cena zwiększa się po okresie promocyjnym dowiesz się tylko wtedy kiedy jesteś mocno dociekliwy. Moim zdaniem to jest mocno nie fair.

     

    Podzielam Twoje zdanie, ale jak widać rynek nie uważa tego za czynnik sprawiający że oferta jest odrzucana.

  12. @mariaczi czystą ciekawością :-) choć także chęcią zweryfikowania lub potwierdzenia posiadanej wiedzy na temat tego segmentu rynku :-) Jaki według Ciebie poziom iops byłby dla takiej usługi odpowiedni ?

     

    Osobiście uważam że oferta jest ciekawa dla segmentu rynku do którego jest kierowana. Jedynie jej "wykonanie" jest niezwykle kiepskie co powoduje, że przestaje być interesująca do rzeczywistego zastosowania.

  13. 12 godzin temu, Pitasato napisał:

    jak prawidłowo napisać koszyk w sklepie "dla niezarejestrowanej osoby"

    oprócz utworzenia zmiennej sesyjnej przeprowadzać walidację czy jest utworzone ciasteczko ?

     

    Tak aby struktury danych odpowiadały całości aplikacji.

     

    Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Torvalds, Linus (2006-06-27)

  14. @Archi zgadzam się z Tobą jednak bierzesz pod uwagę monolityczne aplikacje, trudno aby bardziej złożone aplikacje o architekturze rozproszonej się w taki sposób zachowywały :)

     

    9 godzin temu, Archi napisał:

    jeśli taka aplikacja "zwisa" w miejscu i czeka na killa to jest spieprzona, chyba że działa w trybie debugowania, a takie tryby nie są rozwiązaniami produkcyjnymi.

     

    Tak powinno być, jednak życie pokazuje że teoria znacznie różni się od praktyki :-)

  15. 34 minuty temu, SomeGuy napisał:

    Co boli mnie najbardziej to wyłączenie usługi (poprawcie mnie jeśli się mylę, ale taki zapis w regulaminie jest).

     

    Według mnie gorsze jest to że dostawca nie udostępnia informacji o zużyciu limitu dziennego, użytkownik usługi dowiaduje się o wykorzystaniu limitu po wyłączeniu serwera.

     

    34 minuty temu, SomeGuy napisał:

    kupić tanio sportowe super auto i móc nim jeździć tylko przez 21 dni w miesiąc

     

    bardziej to jak tanio kupić udział w jeżdżeniu autem sportowym przez kilka godzin w miesiącu, a w pozostałym czasie zwykłym. Należy jednak pamiętać że to jest usługa kierowana do segmentu "lubię mieć możliwości" czyli usługa za przystępną cenę umożliwiająca posiadanie możliwości, oraz korzystanie z niej tylko przez ograniczony okres czasu, ponieważ przez większość nie ma potrzeby jej wykorzystywać.

     

    W usługach typu AWS, Azure czy GCE zasób dyskowy z gwarancją wykonania 10k iops kosztuje kilkaset razy więcej.

       

  16. 8 godzin temu, SomeGuy napisał:

    W sposób nieograniczający działania usługi z dnia na dzień

     

    Rozwiązania widzę dwa: throttling - czyli ograniczenie parametrów lub płatność za wykorzystanie ;-) który bardziej przemawia do Twojego zastosowania ? Czy widzisz inne rozwiązania ?

  17. 17 godzin temu, Archi napisał:

    No jeśli aplikacja jest tak spieprzona, że nawet socketu nie umie zamknąć jak się wywali

     

    Wszystko zależy od architektury aplikacji, jeśli składa się z licznych komponentów w formie subsystemów, mikroserwisów lub podobnych to część odpowiedzialna za otwarty socket jest tylko gatewayem, zatem jeśli inny komponent zwraca błąd lub jest "crashed" nie oznacza że musi zwolnić socket. Dobrym przykładem jest serwer http (np. apache lub nginx) i serwer aplikacji php działający osobno (w formie fpm lub podobnej). Błąd aplikacji lub serwera aplikacyjnego nie oznacza w takim przypadku konieczności zwolnienia socketu.

    Jednak coś czuję że to jest jednak aplikacja monolityczna :-)

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.