alien

Nie zrozumieliśmy się. Dziś nie ma problemu "100 Mbit łącza" do operatora. Firma hostingowa, która ma określony wolumen ruchu wpina się do węzła lub kilku węzłów. Jest w czym wybierać. Tylko z ważniejszych: AC-X (rozproszony), TPIX (rozproszony), KIX (rozproszony), PLIX, WIX. Najmniejszy port w takim węźle to 1G. Jak jest za mało to bez problemu można przejść na 10G. Istnieje co prawda problem dojścia do węzła, ale większość firm hostingowych jest w centrach danych, więc nie jest to poważny problem. No i teraz. Przyjmijmy, że hoster jest sobie w dwóch węzłach, w każdym ma port 1G. Do tego zagranicy ma 100 Mbit i TP Netu też 100 Mbit. No i powiedz, ile usług z łączem 100 Mbit może Twoim zdaniem sprzedać klientom, aby był "uczciwy"? I czemu akurat tyle? Chcę pokazać, że patrzysz na sprawę zbyt jednowymiarowo.

Na szczęście nasz kraj zaczyna gonić standardy europejskie. Obecnie prędkość w centrach danych nie liczy się już wolumenem łącza od uplinka, ale przepływnością portu w węzłach peeringowych. Ruchu peeringowego idzie już w PL bardzo dużo i miejmy nadzieję będzie jeszcze więcej. Poza peeringiem pozostaje nadal TP/Orange (część usługodawców hostingowych przesyła przez zagranicę) oraz ruch zagraniczny, czasem z rozróżnieniem na tranzyt i peering w europejskich IXach. Ogólnie widać na tym tle bardzo duży postęp na przestrzeni ostatnich 2-3 lat.

Ja tylko zwrócę uwagę, że autor tematu sugerował dyskusję o dużym portalu. Czyli przyjąłem założenie, że wytworzenie kodu będzie kosztować więcej niż 10 tysięcy tak co najmniej o jedno zero.

Nie chodzi o pokazywanie skrajności. Pewien poziom przyzwoitości ze strony programistów jest wymagany. Ale czasem zamiast przebudowywać aplikację szukając po raz kolejny wzrostu wydajności o 10%, lepiej dołożyć kolejną maszynę. Bo te 10% po stronie aplikacji okupione jest dużym wysiłkiem programistów, czasem na wytestowanie, problemami z błędami, których wytestować się nie udało. To trzeba wyczuć - czasem można jeszcze łatwo i szybko osiągnąć duży efekt optymalizacyjny w kodzie. A w pewnym momencie zaczyna się walczyć o pojedyncze punkty procentowe. Ale pamiętajmy też, że żyjemy w czasach, w których nawet całkiem duże projekty informatyczne stawia się na Joomli i innych podobnych samograjach. W Joomlę można włożyć dowolnie dużą ilość czasu na optymalizację, a w pewnym (nieodległym) momencie i tak trzeba będzie dołożyć kolejną maszynę ;-). Jasne, można pisać dedykowane serwisy (i to polecam). Ale żyjemy w czasach, w których potrzeby biznesowe oznaczają za mało czasu dla programistów i zbyt mały budżet dla programistów. A że żyjemy w czasach, w których konkurencja na rynku usług programistycznych prowadzi do licytowania się przed biznesem na złudzenia, a biznes te złudzenia nakręca, to projekt przeważnie kończy w połowie czasu i budżetu. W efekcie miał być dopracowany, zoptymalizowany serwis zgodny z projektem, a wyszło jak zwykle. Przeważnie tnie się na optymalizacjach właśnie. Dopracowanie systemu od strony programistycznej pochłonie kolejnych X tygodni oraz Y złotych i nadal daje niepewny efekt. Tymczasem serwer można dostawić w kilka dni. Wzrost wydajności jest łatwo przewidywalny. Biznes wybiera serwer. A i programista będzie szczęśliwszy mogąc wreszcie zamknąć projekt i wziąć się za coś nowego :-). Zakładanie już na początku prac możliwości dostawiania w przyszłości serwerów nie jest ani lepsze od szlifowania kodu ani gorsze. Takie założenie jest po prostu praktyczne - pozwala na elastyczność. Tylko apeluję - programiści niech w ramach tej realnej części swej pracy przygotują kod tak, aby dostawienie kolejnego serwera było nieskomplikowane.

Zadam przewrotne pytanie - łatwiej o drugi serwer czy o dobry zespół programistów? ;-).

Czy ktoś oprócz mnie pamięta jeszcze zupełnie pierwszy panel kei? :-).

Bardzo ładnie, a technologia zdecydowanie warta polecenia :-). Ale ponieważ nie ma jeszcze takiego zaplecza "klikalnego menedżmentu" jak inne to raczej wciąż dla bardziej doświadczonych administratorów.

Z doświadczenia - warto zacząć od określenia budżetu :-). Wodze fantazji administratora systemów mogą być praktycznie nieograniczone, niestety warto je już na początku skonfrontować z rzeczywistością.

Trudno się tu odnieść do tematu bez dokładnego zgłębienia specyfiki tworzonego systemu. Tworzenie rozwiązań HA i Load Balancing to jest zawsze szukanie indywidualnych kompromisów. Podam przykład - Pawel I chce osiągnąć efekt widoczności tych samych danych na dwóch serwerach aplikacji. Najprostszym rozwiązaniem jest podmontowanie systemu po NFS z jednego serwera aplikacji (A) na drugi serwer aplikacji (B ). Jest to rozwiązanie najprostsze, ale niosące ze sobą stratę wydajności (zależność wydajności na serwerze B od systemu serwera A). Jest też problem niezawodności, ponieważ w razie awarii serwera A, serwer B nie będzie miał dostępu do danych. Chcąc rozwiązać te problemy należałoby sięgnąć po inne rozwiązanie, np. zewnętrzny NAS dostarczający dane na serwer A i B. Rozwiązanie droższe, a do tego podatne na awarię serwera NAS (one point of failure), dlatego chcąc się przed tym zabezpieczyć należałoby sięgnąć po dodatkową redundancję po stronie NAS lub macierz z redundantnymi kontrolerami (ale tylko z systemem plików pozwalającym na jednoczesny dostęp zdalny z dwóch maszyn). To znów podnosi koszty. No i obniża (nieznacznie lub znacznie - zależnie od różnych czynników) wydajność dostępu do danych w porównaniu do systemu dyskowego bezpośrednio na serwerze, więc niekiedy nie warto iść w tę stronę jeśli system jeszcze nie wymaga rozwiązań HA czy load balancingu. Sprawa się jeszcze skomplikuje, jeśli zauważymy, że zwykle rozwiązania w kierunku zapewnienia High Availability niekoniecznie idą w parze z rozwiązaniami w kierunku Load Balancingu (wyjątek: drbd, ale nie bez dodatkowych zastrzeżeń) i wymagają odrębnych nakładów sił i środków w jednym i drugim przypadku. Także w takich tematach nie ma złotego środka. Jedno rozwiązanie będzie dobrym kompromisem dla jednego projektu systemu, ale nie sprawdzi się przy innym systemie. Takie rzeczy trzeba konsultować indywidualnie.

Problemy pozostają te same. Nadal skalujemy VM do rozmiaru jednego serwera, jeśli braknie - dostawiamy kolejny serwer i na nim odrębną VM. To jest kluczowa sprawa na etapie projektowania systemu przede wszystkim w warstwie aplikacji - trzeba założyć, że system będzie musiał obsłużyć wiele serwerów rozumianych jako niezależne systemy. I żaden cloud made by VM Ware, Citrix czy Microsoft przed tym nie uratuje. To są detale, o których się nie myśli gdy projekt jest mały, ale które są problemem przy skalowaniu gdy projekt rośnie ("efekt naszej klasy"). Jeśli aplikacja nie była dostosowana do load balancingu to się może okazać, że po odpaleniu takich skryptów PHP na dodatkowym serwerze coś nie zadziała. Jeśli aplikacja nie wspiera replikacji SQL to znów jest problem. Dlatego load balancing warto przewidywać już na etapie projektowania aplikacji (jeśli oczywiście założenie obejmuje znaczący rozrost serwisu; przy mniejszym rozroście podział funkcjonalny serwerów na np. serwer aplikacji, serwer baz danych, serwer poczty/static powinien być zupełnie wystarczający, a mniej problematyczny). No i dochodzimy do wniosku, że taki Private Cloud OVH nie różni się wiele od zakupu odrębnych serwerów, macierzy i zastosowania wirtualizacji we własnym zakresie, poza tym, że fakturę płacimy w jednym miejscu. No i są też alternatywne sposoby realizacji HA (np. bazujące na drbd). Lepszy? Gorszy? Kwestia rozwiązania.

Z tymi chmurami to ja bym zalecał ostrożność. To się fajnie czyta o skalowalności, ale można się zdziwić, gdy się wyskaluje taką wirtualkę w chmurze do rozmiaru jednego mocnego serwera i... dalej się już nie da :-). Albowiem chmury w kontekście e24cloud czy Amazona to nic innego jak VPS zapakowany w trochę elastyczniejszy model rozliczeniowy oraz z większą dostępnością (*). Poza jedną fizyczną maszynę nie wyjdzie. (*) Przy klastrze HA takiego VM Ware czy Hyper-V zachowana zostaje odporność na wypadek awarii serwera, drugi serwer w klastrze powinien przejąć maszynę wirtualną. Wymagane jest natomiast podmontowanie systemu plików z zewnętrznego źródła (macierzy) - kolejny punkt potencjalnej awarii do rozwiązania, choć można zapewnić redundancję elementów macierzy na poziomie kontrolera, dysków.

Ja tylko uzupełnię. Uważam firma.gov.pl za bardzo fajny system, ale jak już ktoś ma firmę. Zmiana wpisu bez wychodzenia z domu - bajka. Proponowałem wizytę w urzędzie, ponieważ przy pierwszej rejestracji działalności człowiek może mieć wiele pytań i lepiej mieć przed sobą żywą osobę, która odpowie. I nie jest konieczny podpis kwalifikowany, wystarczy profil zaufany ePUAP. Do załatwienia bez większych trudności i za darmo.

Nie jestem pewien o co pytasz. firma.gov.pl jest platformą urzędową, pozwalającą na przeglądanie bazy centralnej ewidencji gospodarczej, a także na złożenie wniosków o założenie / zmianę / zawieszenie / usunięcie działalności gospodarczej. Złożenie wniosków nie jest bardziej skomplikowane niż wypełnienie wersji papierowych. Przydaje się profil zaufany w ePUAP. Jednak jeśli chcesz zarejestrować firmę, proponuję wybrać się do urzędu gminy / miasta. Wypełnienie papierowego formularza może jest trochę mniej "web 2.0", ale pomoc pani w okienku może to wynagrodzić.

Z tego co mi wiadomo PLIX nie działa już w Katowicach.

Umowa o pracę nie przewiduje wyjątku dla ucznia/studenta. Z tego powodu w tej grupie popularniejsze są umowy zlecenie.

Jeśli jest to Twoja jedyna umowa o pracę i nie jesteś emerytem to odprowadzić trzeba komplet składek ZUS. Podatek dochodowy to 18% z dochodu brutto minus kwota wolna od podatku, minus koszty uzyskania przychodu (niewielkie). Ogólnie rzecz ujmując, z tego co pracodawca musi wydać na umowę o pracę, pracownik dostaje do ręki ok. 60%.

W Katowicach dodatkowo ATM S.A.

Wiesz co, ale to nie jest kwestia wyboru, bo dyrektywy są dość jednoznaczne. A ZUS nie jest radcą prawnym, tylko instytucją państwową. Proszę też pamiętać, że tropieniem fikcyjnej rzeczywistości zainteresowana jest też druga strona. Dex666 ubezpieczy się w UK, parę razy pójdzie do lekarza w Polsce, za którego rachunek NFZ wyśle na Wyspy i się ktoś zacznie zastanawiać dlaczego osoba mieszkająca w Wielkiej Brytanii tak często bywa u lekarza w Polsce. Ale jeszcze raz podkreślę, niech ktoś się zapyta w ZUS jak to jest z DG, bo w moim zapytaniu był poruszany wyłącznie temat pracy / zlecenia.

No cóż, ZUSu muszę bronić ;-). Ich odpowiedź była bardzo rzeczowa, z cytowaniem dyrektyw unijnych, które te sprawy określają. Zatem myślę, że jest tak jak mówią. Nie wiem tylko czy między tymi dwoma sprawami jest pełna analogia.

Witam, Mam wrażenie, że to nie zadziała. Zadałem kiedyś ZUSowi pytanie o podobną sprawę składek przy zatrudnieniu w Polsce i zagranicą (tylko wtedy nie chodziło o prowadzenie firmy, a zwykły etat i umowę zlecenie). Odnalazłem nawet maila z odpowiedzią, ale oszczędzę Szanownym WHTowcom wklejania całości ;-). No w każdym razie wymowa (przynajmniej w tamtej konkretnej sprawie) była taka, że jeśli pracujesz tylko zagranicą to płacisz składki zagranicą. A jeśli pracujesz tutaj i tutaj (uważam, że prowadzenie firmy w Polsce pod to podejdzie) to ważne jest gdzie mieszkasz, a to z kolei definiują dyrektywy unijne. Liczy się w każdym razie nie gdzie mieszkasz "na papierze", ale gdzie faktycznie przebywasz przez większą część roku. Wszystko zakładając, że oba kraje są w UE. Tak więc jeśli nie zamierzasz się przeprowadzić do UK, nic z tego - od firmy prowadzonej w Polsce wedle mojej interpretacji odpowiedzi ZUS - należą się składki na normalnych zasadach. Przy czym te zasady są na tyle skomplikowane przy ubezpieczeniach międzynarodowych, że proponuję po prostu kontakt z ZUSem z opisaniem sytuacji. Na privie podam adres e-mail. Można też skontaktować się z ZUSem przez dowolny serwis społecznościowy (serio, serio). Odpowiadają sprawnie.

W UE usługi hostingu i domen są opodatkowane w kraju nabywcy (jeśli nabywca jest VAT-owcem). Czyli jeśli firma kupuje na Cyprze to na Cyprze wystawiają fakturę VAT 0%, a nabywca w Polsce nalicza sam sobie VAT 23% i go odlicza (podatek przezroczysty). Nie ma tu żadnego uciekania od VAT-u. Jeśli na Cyprze ktoś kupi polski hosting to zasada pozostanie taka sama - polski usługodawca naliczy VAT 0%. Jeśli ktoś nie jest VAT-owcem i kupuje na Cyprze, będzie mieć naliczony cypryjski VAT 15%. Ot cała magia. Nie ma tu żadnej oszczędności VAT, poza tym, że dla NIE-Vatowców w Polsce VAT jest te 8 procent droższy. Z kolei księgowa ma trochę więcej roboty, bo musi wystawić fakturę wewnętrzną dla każdej faktury z Cypru. Ale nie jest to jakiś istotny problem, trzeba tylko o tym pamiętać (zwracam uwagę zwłaszcza osobom prowadzącym księgowość samodzielnie).

Dzięki ;-). Jeszcze raz to napiszę - nie notujemy żadnych problemów ze strony Dotpay. Czy polecę? Nie wiem. Wobec wielu głosów krytycznych polecę przeanalizowanie sprawy.

Nie odpowiem na pytania dotyczące kosztów instalacyjnych, gdyż zwyczajnie nie pamiętam. Jeśli nie prowadzisz DG, przygotuj się na wyższe koszty, gdyż będą musieli opodatkować przychód przy wypłacie. Nie potrafię też nic powiedzieć o Premium SMS, gdyż nie korzystamy z tego rozwiązania w dotpay.

1. Nie pamiętam czy była jakaś opłata. Coś mi świta, że jakiś przelew weryfikujący rachunek bankowy na kwotę rzędu 1 zł, ale nie chcę w błąd wprowadzać. 2. Nie ma minimalnego progu wypłaty, ale trzeba pamiętać, że za każdy przelew obciążają 1 zł, więc minimalny próg wypłaty określa zdrowy rozsądek. 3. Wieloletnią współpracę z dotpay oceniamy pozytywnie. Czas oczekiwania na wypłatę środków ok. 2-3 dni od złożenia dyspozycji. 4. Warto zwrócić uwagę, aby podpisywać umowę z Dotpay SA, ponieważ swego czasu operowali też przez brytyjski Dotpay Ltd, ale to ogólnie komplikowało rozliczenia.

Dotyczy tylko firm, które są czynnymi płatnikami VAT, zarejestrowanymi w VAT UE. Firmy takie opodatkowują VAT 23% z faktur dropped same w Polsce. A więc tę ofertę dropped należy porównywać z cenami netto firm działających w PL, ponieważ dla firmy "Vat-owca" podatek VAT jest w praktyce przezroczysty.