gb1

przetwarzanie to także przechowywanie, art. 4 pkt. 2; podobnie jak w obecnej UODO. Zgadzam się że dla klasycznych systemów rozwiązanie podobne do opisanych w przywołanym artykule są najbardziej rozsądne. Jednak pamiętajmy o tym że rozsądek, a przepisy często nie idą w parze. Uważam że tutaj najlepiej byłoby skorzystać z kodeksów postępowania, stosowanie których daje znacznie wyższe bezpieczeństwo (nie techniczne) i jest przewidziane w zapisach rozporządzenia. Do jakich organizacji należycie lub znacie które pracują nad kodeksami postępowań dla branży hostingu ? Także zachęcam do dyskusji w tym zakresie, może nowy wątek ? Uważam że dyskusja i wymiana wiedzy jest bardzo istotna. Jednak biznesu jak narazie nie uprawiam na forum zatem pozostawię tą kwestię poza nim. Jednak każda rozmowa na temat tego typu rozwiązań zaczyna się tak samo jak pisałem już w wielu wątkach wcześniej czyli ustalenia podstawowych parametrów RPO, RTO, ilości danych oraz delty. Takie informacje pozwalają na dalszą dyskusję i na końcu dobranie rozwiązań technicznych które będą adekwatne do sytuacji. Pytając można zawsze się czegoś nowego dowiedzieć, czy jedna uważasz inaczej ? ;-)

Za wikipedią po wpisaniu do google "ASM programming": An assembly (or assembler) language,[1] often abbreviated asm, is a low-level programming language for a computer, or other programmable device, in which there is a very strong (but often not one-to-one) correspondence between the language and the architecture's machine code instructions. W żadnym wypadku, nie wiem jak wysnułeś takie wnioski Turbo Pascal nie jest wykorzystywany szeroko w biznesie, nie uczy zarządzania pamięcią czy innymi niższymi warstwami, osobiście nie widzę celu nauki tego języka w obecnych czasach. Natomiast w przypadku C nauczy się człowiek zarządzania pamięcią oraz zasad jej działania, w przypadku ASM to same podstawy i fundamenty które w każdym języku się później przydają w szczególności w debuggingu niskopoziomowym :-) Nie wspominając już o tym że znajomość C pozwala na czytanie i poprawianie większości kodu systemów operacyjnych oraz aplikacji systemowych. Akademicki system nauczania to nie technikum które przyucza do zawodu, wymaganie od akademii aby to robiła "uważam za kompletną bzdurę"

Czyli oczekujesz wsparcia dla świadczonej usługi wraz ze wsparciem administracyjnym jak będziesz miał problem którego nie będziesz umiał rozwiązać ? Rozumiem że za wsparcie administracyjne jesteś gotowy dodatkowo zapłacić ? Jakiego czasu reakcji oczekujesz w przypadku wsparcia dla świadczonej usługi oraz wsparcia administracyjnego ? Jakiego godziny wsparcia Cię interesują ? Podany budżet jest w kwotach netto czy brutto ?

Wygląda na rozsądną normalny biznes, myślę że mam ciekawe rozwiązania dla Ciebie wraz z replikacją abyś miał możliwość realizacji całości w ramach rozsądnego budżetu MSP. Zaproś zatem do dyskusji albo dopytaj i podziel się z nami informacjami aby podeprzeć twierdzenie że macie wszystko na bieżąco analizowne Chętnie poznam oraz zapewne inni także Wasze planowane działanie w tym zakresie Dokładnie tak, zatem jako administratorem jak rozwiążesz kwestie zastosowania art. 17 w kopiach bezpieczeństwa które są wykonywane oraz przechowywane przez dostawcę usługi ? W przypadku dedykowanego sprzętu fizycznego jest to dość proste, a w przypadku hostingu współdzielonego lub chmury sytuacja wygląda już inaczej, ale bardzo ciekawe aspekty poruszasz które dla normalnego biznesu są niezwykle istotne.

@matt dokładnie tak, w przypadku kiedy ma to być pierwsze kroki w kierunku programowania i podejście na zasadzie samouka. Oczywiście bardziej rozsądnym uważam rozpoczęcie nauki od C, poźniej poznanie C++ i w międzyczasie poznanie ASM ponieważ daje to mocne podstawy na przyszłość, jednak z mojego doświadczenia wynika, że obecnie większość nie ma odpowiedniego samozaparcia aby samemu się tego uczyć jeśli nie wymagane jest przez szkołę.

Na niniejszym forum większość interesuje się aspektami technicznymi, zatem tutaj polecam artykuł 17 wspomnianego rozporządzenia czyli („prawo do bycia zapomnianym” i jego stosowanie w przypadku kopii bezpieczeństwa. @Poziomecki Czy podzielisz się Waszymi przemyśleniami i planami dostosowania się do art. 17 w kontekście kopii bezpieczeństwa ?

Nie wątpię że wstępnie weryfikowaliście jak także żę zapewne zdążycie wszystko przygotować, jednak jak sam stwierdziłeś nie znasz szczegółów jednak stwierdziłeś że "jest spełnienie wymagań RODO" co wydawało mi się dość dziwne. Różnica znacząca pomiędzy pracami wstępnymi, a zakończeniem realizacji To nie ustawa to jedynie rozporządzenie PE. https://legislacja.rcl.gov.pl/projekt/12302950 Ustawa o ochronie danych osobowych jest nadal w drodze, a jej zapisy będą istotne, zatem na tym etapie można się przygotowywać, trudno jednak mówić o wdrożeniu RODO. Takie wymaganie wynika z obecnej ustawy o ochronie danych osobowych obowiązującej od lat. Polecam lekturę art. 31 ustawy o ochronie danych osobowych, wymóg jest aby umowa była zawarta na piśmie. Wraz z nowymi przepisami wymóg posiadania umowy na piśmie zniknie z tego powodu według mnie na wejście w życie nowych przepisów niezmiernie oczekują globalni gracze typu GCE, AWS, Azure, etc. Możesz wskazać takie zapisy ? Zgadzam się w całości, z tego powodu jak wcześniej pisałem strona formalna jest tutaj najbardziej istotna pod względem nowych przepisów, w stosunku do stosowanych adekwatnych środków technicznych. Moim zdaniem bardzo rozsądne podejście i zapewne najbardziej ekonomiczne, odezwij się na PW myślę że jeśli reprezentujesz normalny biznes to będę miał ciekawe propozycje.

Możesz doprecyzować które elementy / parametry wsparcia oraz usługi są dla Ciebie istotne ? Możliwe że sytuacja wymagała trzech ticketów aby zrozumieć zgłaszaną sytuację.

Z ciekawości zapytam, jak spełniacie wymagania RODO jeśli jeszcze nie są uchwalone przepisy ustawowe, wykonawcze i administracyjne niezbędne do wykonania tej dyrektywy ? Także z ciekawości zapytam, czy stosujecie zapisy kodeksów potępowania lub się do tego przygotowujecie ? jeśli tak to których organizacji ? Czyli wymagań RODO nie ma jeszcze spełnionych :-) należy pamiętać że RODO to w większości właśnie "papierki", a nie stosowane środki techniczne Podobnie jak kiedyś z telewizorami HD i HD Ready, prawie to samo, a jednak różnica wielka :-) Sugerowałbym tutaj wybór dwóch różnych dostawców ,znacznie wyższy stopień bezpieczeństwa i ciągłości działania przy dobrze dobranym oraz testowanym DRP.

Jeśli masz doświadczenie w C++ to GO jest naturalnym wyborem. Jeśli posiadasz dobre fundamenty w programowaniu w wielu językach (np. rozsądne studia) to GO będzie także rozsądnym wyborem. Jednak jako pierwszy język to znacznie lepszy wybór aniżeli C / C++ :-) Jednak jeśli to ma być pierwszy język do nauki programowania jako samouk to lepiej sugerowałbym Javascript (być może TypeScript) jako nodeJS.

Nigdzie nie twierdziłem, że musi :-) tak samo jak nie musi mieć większych kompetencji technicznych , wystarczą przeciętne, a może nawet podstawowe :-) A teraz zdefiniuj pojęcie "dobra" :-) Nie doszukuj się drugiego dna tam gdzie go nie ma Jednak przyznam, że chętniej poznałbym Waszą opinię na temat mojego ostatniego akapitu w poprzedniej wiadomości.

Twierdzisz że nie może ? patrząc na rynek mam wrażenie że są takie firmy Według mnie większość oprogramowania OSS z którego korzystasz nigdy nie dostało dofinansowania lub wsparcia finansowego. Panel akurat jest znaczącym wyróżnikiem dla firmy hostingowej, pozwalający wyróżnić się od pozostałych graczy. Być może :-) jednak rozróżnijmy potencjał techniczny od biznesowego, dwie różne sprawy. Uważam że jak najbardziej możliwe jest prowadzenie bardzo zyskownego biznesu posiadając podstawową wiedzę techniczną w firmie. Pierwsze pod jakim względem ? Dostarczenia usług na bazie kontenerów ? Obecnie wygląda na to że firm hostingowych które posiadają ofertę masowego wehostingu (nie vps) bazującą na kontenerach to jest mało lub nawet bardzo mało. Chętnie poznałbym opinię dlaczego wśród firm hostingowych jest taka mała adaptacji rozwiązań bazujących na Openstack lub kontenerach ? Czy po części nie wynika to z braku standardowych paneli które to wspierają i nie wymagają większej wiedzy technicznej ?

Zgadzam się w zupełności. Jak od samego początku twierdzę, że własny panel świadczy jedynie o świadomości technicznej, wiedzy i potencjale dostawcy usługi. Ś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. Czy można wykorzystać gotowe standardowe panele do świadczenia usługi i prowadzenia zyskownego biznesu ? Uważam że jak najbardziej, jest to możliwe, jedynie świadczy to o firmie i jej potencjale technicznym. Wracając jednak do rozwoju i oprogramowania, to jeśli prześledzisz większość oprogramowania z którego korzystasz to duża część powstaje przy udziale jedynie 1-2 osób, niezbyt często małych zespołów. Polecam na przykład śledzenie rozwoju istotnych ze względu na hosting modułów kernela Linuxa, myślę że będziesz zdziwiony jak mało osób rzeczywiście czynnie rozwija dane obszary i jak wiele zależy od małych firm lub pojedynczych osób. Wymieniłeś Openstacka i liczne firmy bazując na danych z wikipedia, akurat ten projekt bardzo blisko znam, ponieważ jako jedna z pierwszych firm podpisaliśmy umowę na współtworzenia Openstacka. Jednak z tych dużych firm to rzeczywiście jedynie nieliczne osoby biorą czynny udział, większość bazuje na znacznie mniejszych developerach lub firmach. Ciekawym przykładem projektu który powstał na potrzeby hostingu jest CEPH o którym kilkukrotnie była na forum mowa. Polecam historię powstania i rozwoju do czasu otrzymania wsparcia i promocji od RH (podpowiedź: DreamHost). Nie będę wspominać o Openstack Swift jednak warto wspomnieć początki PHP, czyli języka programowania który dla wielu na tym forum jest podstawowym językiem. W latach 90-tych pewien człowiek stwierdził, że pomimo tego że wszyscy korzystali z Perla, skryptów bashowych czy innych wynalazków to on napisze własne toporne narzędzie do obsługi formularzy (FI) i tak rozpoczeła się era PHP :-) Pominę już mSQL i początki mySQL Obecnie warto się interesować tym co dzieje się od kilku lat w obszarze kontenerów, a w szczególności w zakresie obsługi sieci w architekturach rozproszonych i "multi-tenant" (czyli istotne zagadnienia dla dostawców usług hostingowych). Tak jak obecnie tam "kombinują" to czasami ręce opadają, jednak mozolnie i powoli ale idzie do przodu. Era hostingu jaki obecnie znamy powoli dobiega końca, choć tak jak PHP długo jeszcze będzie żyła zanim umrze na dobrze :-) Innowacja i rozwój powstaje poprzez negowanie tego co jest i próby tworzenia czegoś nowego bardziej odpowiedniego do potrzeb.

Bardziej aby było tak jak tego są realne potrzeby świadczenia usług, a przy okazji ekonomiczne podejście. W nawiązaniu do linków do zdjęć, dziwisz się że większość tych którzy w dużej skali operują mają podobne przemyślenia? Ekonomia zawsze jest istotna, jednak mam przeświadczenie że w przypadku tych dużych są także inne cele równie ważne. Myślę że przykład płacenia za "subskrypcje" RH jest mało trafiony, śledząc rozwój tej dystrybucji widać gołym okiem że nadrzędnym celem było posiadanie dystrybucji która będzie pasowała do potrzeb i bieżących wymagań AWS jako platformy podstawowej. Mogli spokojnie tak samo ekonomicznie wybrać jedną z wielu obecnych dystrybucji dla których brak opłat za "subskrypcję". Jak wcześniej wspominałem, według mnie nie tylko ekonomia jest tutaj istotna, a znacznie bardziej istotny w przypadku OCP jest element dostosowania sprzętu do realnych potrzeb technicznych oczywiście uwzględniając element ekonomiczny. Zupełnie na marginesie to centra przetwarzania danych jako kontenery to już przeszłość dla dużej skali, to był tylko taki epizod jakieś 7-8 lat temu :-)

@patryk gołe płyty to jednak jedynie etap był, "obudowa" w większości rozwiązań występuje jednak zwykle nie w takiej formie jaką większość zna. W kwestii pasywnego chłodzenia to całość centrów danych idzie w tym kierunku od wielu lat, w szczególności po zmianie w zaleceniach ASHRAE w 2011 roku. Słynne "kurniki" Yahoo były jednym z pierwszych podejść jednak obecnie technologia i rozwiązania znacznie poszły do przodu w tym zakresie. Większość budowanych dużych (skala mega) centrów przetwarzania danych mało ma wspólnego z tym co większość wyobraża sobie W zakresie zmian dot. serwerów polecam lekturę OCP, http://www.opencompute.org/ Operacje są synchroniczne czy async ? z ciekawości zapytam się jak rozwiązaliście powtarzanie operacji jeśli zwróci błąd ? jakieś ciekawe rozwiązania w przypadku rozwiązywania zależności pomiędzy operacjami składającymi się na podstawową operację ? skorzystaliście z jakiegoś gotowego rozwiązania ?

Tam gdzie jest to uzasadnione :-) Dla przykładu duzi światowi dostawcy usług w ostatnich latach zmienili zupełnie rynek serwerów na świecie co powoduje że firmy typu Dell, HPE i podobne muszą mocno redefiniować swoje założenia i plany w tych obszarach.

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