-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.P
OSTED!not-for-mail
From: Marek Wodzinski <m...@O...mamy.to>
Newsgroups: pl.misc.elektronika
Subject: Re: A teraz z innej beczki... bazy danych
Date: Thu, 17 May 2018 14:07:31 +0200
Organization: ATMAN - ATM S.A.
Lines: 83
Message-ID: <a...@t...pilczyce.net>
References: <pd9jtj$7a1$1@node2.news.atman.pl> <pd9kou$832$1@node2.news.atman.pl>
<pd9ndc$aen$1@node2.news.atman.pl> <pd9nso$atr$1@node2.news.atman.pl>
<pdaa3b$rnl$1@node2.news.atman.pl>
<a...@t...pilczyce.net>
<pdffvc$no2$1@node1.news.atman.pl> <pdhrj1$lq5$1@node2.news.atman.pl>
<pdht2p$nll$1@node2.news.atman.pl> <pdhuhf$ook$2@node2.news.atman.pl>
<pdi73e$1fk$1@node2.news.atman.pl> <pdj83c$bcc$1@node1.news.atman.pl>
NNTP-Posting-Host: h82-143-151-130-static.e-wro.net.pl
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-2
Content-Transfer-Encoding: 8BIT
X-Trace: node1.news.atman.pl 1526558854 32144 82.143.151.130 (17 May 2018 12:07:34
GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Thu, 17 May 2018 12:07:34 +0000 (UTC)
User-Agent: Alpine 2.11 (LNX 23 2013-08-11)
In-Reply-To: <pdj83c$bcc$1@node1.news.atman.pl>
X-Odpowiedz: odspamiacz...
X-Beer: Holba
Xref: news-archive.icm.edu.pl pl.misc.elektronika:732113
[ ukryj nagłówki ]On Thu, 17 May 2018, BQB wrote:
>> Wydaje mi się, że każdy z Nas myśli o innej skali biznesu ;-)
>
> Daleko nie trzeba szukać, co zrobisz, jak w firmie w której są dane stanie
> się coś takiego:
> https://niebezpiecznik.pl/post/wlamanie-do-serwerown
i-2be-pl-od-5-dni-klienci-sa-pozbawieni-wszystkich-u
slug-i-traca-dziesiatki-tysiecy-zlotych-kazdego-dnia
/
Firmie 'Krzak' się nie powierza danych, na których nam zależy :-)
Ale odpowiadając na pytanie, to klikam 'kup' u innego dostawcy, robię
'ansible-playbook costam.yml' i za 20 minut mam to samo odpalone gdzieś
indziej :-)
Do prawdziwej chmury najczęściej używa się Serverless Framework,
Terraforma czy natywnych rozwiązać jak np. CloudFormation w AWS.
> albo coś takiego:
> https://niebezpiecznik.pl/post/wybuch-gazu-w-serwero
wni-netii/
>
> albo też takiego:
> https://niebezpiecznik.pl/post/awaria-w-nazwa-pl-kli
enci-stracili-dane-takze-z-backupow/
>
> albo i to:
> https://niebezpiecznik.pl/post/domena-pl-przestala-d
zialac/
Te powyższe, to takie 'chmury' marketingowe. Zwykły hosting w globalnie
niezauważalnych firmach. Próba zestawienia tego z AWS, Azure czy GCP, to
jakby porównywać Pana Zdzicha, który pożycza kasę kolegom, z bankiem PKO
BP.
> Nawet, jak masz kopię bazy lokalnie, to i tak nie przywrócisz jej, bo nie ma
> na co, trzeba na nowo postawić lokalnie albo zdalnie gdzieś cały system.
> Chyba, że masz lokalnie kopię całego wirtualnego serwera, ale IMO mało
> prawdopodobne, bo człowiek myśli "chmura ma bakapy" albo mamy kopię lokalnie
> która jest dosyć stara.
Czyli opisujesz typową sytuację, gdzie właśnie 'Kowalski' bierze się za
robotę.
Obecnie jak 'normalnie' korzystasz z chmury, to masz to zautomatyzowane,
bo nikt ręcznie nie robi nic bardziej skomplikowanego niż wyklikanie
storage na AWS S3, a i to można zrobić źle.
Jak masz zrobioną automatykę, to całą infrastrukturę możesz odpalić w
dowolnym regionie w ciągu kilku minut.
Pozostaje wrzucić tam dane z backupu. Ale tu znowu trzeba zwalczyć
podejście 'Kowalskiego', bo żeby powiedzieć że ma się backup, to
można dopiero po tym jak przetestuje się jego odzyskanie.
Po prostu jedną z nieodłącznych części backupu jest test i plan jak z
niego skorzystać. Gdyby ludzie testowali odzyskanie danych w innym
regionie czy u innego dostawcy, to nie byłoby żadnych problemów.
Backup danych u tego samego dostawcy znowu może się skończyć jak w
linkach które podałeś.
Jak komuś rzeczywiście zależy na danych i ma świadomość ich
rzeczywistej wartości, to robi backupy na zewnątrz (inny dostawca, czy
nawet na jakiś dysk w domu, a minimum inny region).
I backupy robi się automatycznie, żeby właśnie nie było problemu, że
lokalna kopia jest 'dosyć stara'.
Złota zasada: jak robisz coś ręcznie, to robisz to źle :-)
A to jak bardzo chcesz się związać z danym dostawcą to osobna sprawa. Jak
używasz zwykłego hostingu czy VM-ek, to provisioning tego można zrobić
gdziekolwiek w każdej chwili i jedyne co musisz mieć, żeby się przenieść
gdzieś indziej, to definicja w automatyce co i jak ma być skonfigurowane i
świeża kopia danych do wrzucenia.
Ale w większości wypadków taniej jest jednak się uzależnić od jednego
dużego dostawcy i używać chmury jako PaaS/SaaS, bo zaczynasz płacić za
ruch, a nie za to, że maszyna przez większość czasu stoi odłogiem, i
odpada Ci cała robota sysopsa - wrzucasz kod, dane i reszta Cię nie
interesuje.
Tak czy siak - czasy 'ręcznej' konfiguracji serwerów czy chmury już
minęły.
Pozdrawiam
Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg
Następne wpisy z tego wątku
- 17.05.18 15:02 Adam
- 17.05.18 15:24 J.F.
- 17.05.18 17:00 Marek
- 17.05.18 17:05 Marek
- 17.05.18 17:49 Piotr Gałka
- 17.05.18 20:02 Irek.N.
- 17.05.18 20:05 Irek.N.
- 17.05.18 20:09 Irek.N.
- 17.05.18 20:18 Irek.N.
- 17.05.18 20:18 Adam
- 17.05.18 20:21 Irek.N.
- 17.05.18 20:25 Irek.N.
- 17.05.18 20:35 Marek
- 17.05.18 22:21 J.F.
- 17.05.18 22:29 Marek
Najnowsze wątki z tej grupy
- ciekawy układ magnetofonu
- Mikroskop 3D
- Jak być bezpiecznym z Li-Ion?
- Szukam monitora HDMI ok. 4"
- Obcinaczki z łapaczem
- termostat do lodowki
- SEP 1 kV E
- Aku LiPo źródło dostaw - ktoś poleci ?
- starość nie radość
- Ataki hakerskie
- Akumulatorki Ni-MH AA i AAA Green Cell
- Dławik CM
- JDG i utylizacja sprzetu
- Identyfikacja układ SO8 w sterowniku migających światełek choinkowych
- DS1813-10 się psuje
Najnowsze wątki
- 2024-12-23 Riga => Specjalista ds. public relations <=
- 2024-12-23 Łódź => Specjalista ds. Sprzedaży <=
- 2024-12-23 Kraków => International Freight Forwarder <=
- 2024-12-23 Co nalezy do Cinkciarza, a co do Conotoxia ?
- 2024-12-23 Poznań => Key Account Manager <=
- 2024-12-23 Warszawa => Presales / Inżynier Wsparcia Technicznego IT <=
- 2024-12-23 Rzeszów => Spedytor Międzynarodowy <=
- 2024-12-23 Warszawa => Infrastructure Automation Engineer <=
- 2024-12-23 Białystok => Analityk w dziale Trade Development (doświadczenie z Po
- 2024-12-23 Warszawa => Site Reliability Engineer (SRE) <=
- 2024-12-23 Warszawa => DevOps Engineer <=
- 2024-12-23 Warszawa => Senior Account Manager <=
- 2024-12-23 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-12-23 Katowice => Administrator IT - Wirtualizacja i Konteneryzacja <=
- 2024-12-23 Mińsk Mazowiecki => Spedytor Międzynarodowy <=