VM - app kontejner on request #3

Open
opened 2018-11-19 02:34:26 +01:00 by Podhorecky · 14 comments
Podhorecky commented 2018-11-19 02:34:26 +01:00 (Migrated from git.spotter.cz)

Napadlo mne něco, co bych označil jako "distribuční optimalizaci" ...

Řekněme, že později, až bude fáze "rozvíjení do krásy" a bude už nějaká zpětná vazba od uživatelů, bychom do nabídky aplikací vložili kromě těch hotových buildovaných i další, ovšem zatím pouze jako "placeholder" nanejvýš s nějakým minimem informací.
Pokud by přišla nějaká reakce od adminů na využití a chtěli to od nás, pak by se tím teprv někdo zabýval a po nějakých iteracích by vytvořil kontejner. Pokud by nebyl zájem, tak by se nic nedělo.

Týkalo by se to apps, které jsou zjevně méně používané. Pochopitelně, že časové plány na implementaci a případná placenost za takovou službu je ke konkrétní diskusi.

Chci tím jen trochu odlehčit mému vlastnímu úsilí buildovat kdejakou ufo-app. Mít tak víc prostoru na vlastní rozvoj, nebo cokoliv jiného.

Šlo by o tom tak uvažovat?

Napadlo mne něco, co bych označil jako "distribuční optimalizaci" ... Řekněme, že později, až bude fáze "rozvíjení do krásy" a bude už nějaká zpětná vazba od uživatelů, bychom do nabídky aplikací vložili kromě těch hotových buildovaných i další, ovšem zatím pouze jako "placeholder" nanejvýš s nějakým minimem informací. Pokud by přišla nějaká reakce od adminů na využití a chtěli to od nás, pak by se tím teprv někdo zabýval a po nějakých iteracích by vytvořil kontejner. Pokud by nebyl zájem, tak by se nic nedělo. Týkalo by se to apps, které jsou zjevně méně používané. Pochopitelně, že časové plány na implementaci a případná placenost za takovou službu je ke konkrétní diskusi. Chci tím jen trochu odlehčit mému vlastnímu úsilí buildovat kdejakou ufo-app. Mít tak víc prostoru na vlastní rozvoj, nebo cokoliv jiného. Šlo by o tom tak uvažovat?
Disassembler commented 2018-11-19 07:18:53 +01:00 (Migrated from git.spotter.cz)

Přemýšlím, nakolik je užitečné mít v seznamu aplikace, které se nedají nainstalovat, jen proto, aby potenciální zájemce věděl, že existují. Možná bych je nemíchal dohromady s balíky ve VMMgr, u kterých je seznam sestavován z metadat, ale uvedl je odděleně, buď v nějaké promo části nebo klidně úplně mimo aplikaci, na nějakém z Vašich webů, kam by z VMMgr mohl být jen proklik. To by pak řešilo i to, že budete mít plnou kontrolu nad obsahem, můžete se o aplikaci doširoka rozepsat, strukturovat do více stran, přidat případové studie, screenshoty a vůbec klienta pořádně nahypovat.

Přemýšlím, nakolik je užitečné mít v seznamu aplikace, které se nedají nainstalovat, jen proto, aby potenciální zájemce věděl, že existují. Možná bych je nemíchal dohromady s balíky ve VMMgr, u kterých je seznam sestavován z metadat, ale uvedl je odděleně, buď v nějaké *promo* části nebo klidně úplně mimo aplikaci, na nějakém z Vašich webů, kam by z VMMgr mohl být jen proklik. To by pak řešilo i to, že budete mít plnou kontrolu nad obsahem, můžete se o aplikaci doširoka rozepsat, strukturovat do více stran, přidat případové studie, screenshoty a vůbec klienta pořádně nahypovat.
Podhorecky commented 2018-11-20 01:32:39 +01:00 (Migrated from git.spotter.cz)

hm, asi ano.. i použití externího webu je možné.

chtěl bych jen okomentovat svou "polohu" co se týče hledání cesty k výsledku. S vaším přispěním a dost podstatnými návrhy bych tento projekt později rád rozvíjet jako jakousi "svéráznou uživatelskou platformu". To zní vznešeně a ještě to vyžádá hodně práce. Zatím slabým místem je ekonomická udržitelnost, kde jsem ještě moc neřešil jak to má existovat v ekonomicky motivovaném světě, tedy ani nerozhodl. Podněty odjinud přicházejí jen samovolně.

Jedno bych chtěl vědomě krotit - a to je činnost, která by sklouzla do nějaké větší selfpromo, nebo dokonce marketingu nebo jiných běžně konaných sprosťáren. (Lovebranding mi skoro navaluje) Kdykoliv jsem takové činnosti dělal pracovně, nebo i soukromě, mělo to tendenci převzít dominanci v důležitosti a původní smysl se mi vytrácel.

Takže k aplikacím... Pokud bych někde zjevil nějaké apps ve formě placeholderu, netroufám si být u nich nositelem nějakého extra know-how. Protože nevěřím, že bych byl jediný i tady v ČR, který by je dokázal vygooglit. Rád bych zatím zůstal v nějaké roli "technology steward nebo software nurse" alespoň do doby, než bych skutečně měl na víc, než jen to. Časovou a finanční investicí pár let můžu nahnat nějaké body v případné adaptaci, ale samo o sobě to ze mne ještě neudělá exkluzivního majitele výhody.
Placeholdery jsem chtěl jen technicky usmlouvat s ďáblem trochu času a přitom dávat najevo, že moje sdělení směrem k uživateli VM nebude jen "vygoogli si to". (dokud to půjde googlit).
V nejbliší době bude většina těchto apps jen zmíněna ve spících Issue na GitLabu.

Ta drobná informační výhoda (Svět x ČR) kterou jsem vnímal kolem roku 2014 se rychle zmenšuje a možná zcela zmizí. Možná zmizí i lidi, kteří by o něco takového ještě nedávno stáli. Nemyslím fyzicky zmizet, ale prostě jejich profesní/odborný determinant bude jiný. Také operují už různé vyskillované skupiny lidí, korporace se vsírají do charity z které si dělají marketing, a jejich jediným modelem je "kupte si naše služby běžící na našem cloudu". Svět se ale pohne dál. Pak třeba náhle zkolabují, aby se přerodily jejich nástupci.
Jelikož nemám žádný důvod si myslet něco fantasticky nadějného, chci pracovat na vybudování jakési platformy a vědět, že jsem pro to udělal moje osobní maximum.

hm, asi ano.. i použití externího webu je možné. chtěl bych jen okomentovat svou "polohu" co se týče hledání cesty k výsledku. S vaším přispěním a dost podstatnými návrhy bych tento projekt později rád rozvíjet jako jakousi "svéráznou uživatelskou platformu". To zní vznešeně a ještě to vyžádá hodně práce. Zatím slabým místem je ekonomická udržitelnost, kde jsem ještě moc neřešil jak to má existovat v ekonomicky motivovaném světě, tedy ani nerozhodl. Podněty odjinud přicházejí jen samovolně. Jedno bych chtěl vědomě krotit - a to je činnost, která by sklouzla do nějaké větší selfpromo, nebo dokonce marketingu nebo jiných běžně konaných sprosťáren. (Lovebranding mi skoro navaluje) Kdykoliv jsem takové činnosti dělal pracovně, nebo i soukromě, mělo to tendenci převzít dominanci v důležitosti a původní smysl se mi vytrácel. Takže k aplikacím... Pokud bych někde zjevil nějaké apps ve formě placeholderu, netroufám si být u nich nositelem nějakého extra know-how. Protože nevěřím, že bych byl jediný i tady v ČR, který by je dokázal vygooglit. Rád bych zatím zůstal v nějaké roli "technology steward nebo software nurse" alespoň do doby, než bych skutečně měl na víc, než jen to. Časovou a finanční investicí pár let můžu nahnat nějaké body v případné adaptaci, ale samo o sobě to ze mne ještě neudělá exkluzivního majitele výhody. Placeholdery jsem chtěl jen technicky usmlouvat s ďáblem trochu času a přitom dávat najevo, že moje sdělení směrem k uživateli VM nebude jen "vygoogli si to". (dokud to půjde googlit). V nejbliší době bude většina těchto apps jen zmíněna ve spících Issue na GitLabu. Ta drobná informační výhoda (Svět x ČR) kterou jsem vnímal kolem roku 2014 se rychle zmenšuje a možná zcela zmizí. Možná zmizí i lidi, kteří by o něco takového ještě nedávno stáli. Nemyslím fyzicky zmizet, ale prostě jejich profesní/odborný determinant bude jiný. Také operují už různé vyskillované skupiny lidí, korporace se vsírají do charity z které si dělají marketing, a jejich jediným modelem je "kupte si naše služby běžící na našem cloudu". Svět se ale pohne dál. Pak třeba náhle zkolabují, aby se přerodily jejich nástupci. Jelikož nemám žádný důvod si myslet něco fantasticky nadějného, chci pracovat na vybudování jakési platformy a vědět, že jsem pro to udělal moje osobní maximum.
Podhorecky commented 2019-06-11 14:04:46 +02:00 (Migrated from git.spotter.cz)

volně navážu na předchozí úvahy...

Dlouho jsem hledal jako komunikovat toto sw řešení s naprosto neznalými lidmi. Jakmile na ně budu mluvit déle než 2 minuty nějakými abstraktními pojmy, tak to nepochopí a neudrží pozornost. Strašný problém.
Náhodně mne postrčila poznámka kamaráda o tom, že dnešní výrobci NASek běžně vybavují toto úložiště vlastním SW ekosystémem, s možností instalovat si aplikace z něčeho jako AppStoru Pochopitelně, že u NASek je to většinou nějaké Linuxové řešení, s výběrem linuxových apps typu Wordpress, Prestashop, Joomla a prohlížení fotek. Pravděpodobně Softaculous nebo podobný klon téhož.
Ve věci obeznámení veřejnosti tedy Apple se svým AppStorem a vůbec všemi těmi iPhony vykonal obrovskou práci a výsledek je, že lidé vůbec neřeší jak něco funguje, hlavně když to funguje. A víc to ani chápat nechtějí.

Jenže je tu obrovské "ALE"...
AppStore je principielně, technologicky, zacílením i v různých detailech jiný než řešení VM a tak je to extrémní zjednodušení možná až příliš velké.
Dále je vidět, že to je skvělý obchodní model, který má jasné cíle, ale i některé nepříliš zjevné. Apple běžně potlačuje konkurenční aplikace a další divoké a rizikové aplikace. Intentivně pracuje na zpeněžení čehokoliv. Nelze to vyčítat. Ale ani v tom se nepodobá VM.

Nicméně zpět k VM.

Přirovnání k AppStore bych použil jen v opravdu krajním případě. Asi bude fakt lepší se prezentovat jako vlastní řešení výběru aplikací za konkrétním účelem.

Inspiraci a nápady možná tak hledat u backendu Distribučního serveru, tady ovšem mám prakticky nula informací, protože to je neveřejná záležitost.

Kdybyste měl nějakou poznámku co se týče výše zmíněného, distribučního serveru, napište prosím.
Jedna z variant budoucího vývoje by byla něco, co už známe odjinud... DS by jako jediný z celého řešení nemohl být open-source... Ale úplně domyšlené to nemám, takže jen uvažuji jestli to nemá nějakou zásadní vadu v naplnění Mise.

volně navážu na předchozí úvahy... Dlouho jsem hledal jako komunikovat toto sw řešení s naprosto neznalými lidmi. Jakmile na ně budu mluvit déle než 2 minuty nějakými abstraktními pojmy, tak to nepochopí a neudrží pozornost. Strašný problém. Náhodně mne postrčila poznámka kamaráda o tom, že dnešní výrobci NASek běžně vybavují toto úložiště ***vlastním SW ekosystémem, s možností instalovat si aplikace z něčeho jako AppStoru*** Pochopitelně, že u NASek je to většinou nějaké Linuxové řešení, s výběrem linuxových apps typu Wordpress, Prestashop, Joomla a prohlížení fotek. Pravděpodobně [Softaculous ](https://softaculous.com/)nebo podobný klon téhož. Ve věci obeznámení veřejnosti tedy Apple se svým AppStorem a vůbec všemi těmi iPhony vykonal obrovskou práci a výsledek je, že lidé vůbec neřeší jak něco funguje, hlavně když to funguje. A víc to ani chápat nechtějí. Jenže je tu obrovské "ALE"... AppStore je principielně, technologicky, zacílením i v různých detailech jiný než řešení VM a tak je to extrémní zjednodušení možná až příliš velké. Dále je vidět, že to je skvělý obchodní model, který má jasné cíle, ale i některé nepříliš zjevné. Apple běžně potlačuje konkurenční aplikace a další divoké a rizikové aplikace. Intentivně pracuje na zpeněžení čehokoliv. Nelze to vyčítat. Ale ani v tom se nepodobá VM. Nicméně zpět k VM. Přirovnání k AppStore bych použil jen v opravdu krajním případě. Asi bude fakt lepší se prezentovat jako vlastní řešení výběru aplikací za konkrétním účelem. Inspiraci a nápady možná tak hledat u backendu Distribučního serveru, tady ovšem mám prakticky nula informací, protože to je neveřejná záležitost. Kdybyste měl nějakou poznámku co se týče výše zmíněného, distribučního serveru, napište prosím. Jedna z variant budoucího vývoje by byla něco, co už známe odjinud... DS by jako jediný z celého řešení nemohl být open-source... Ale úplně domyšlené to nemám, takže jen uvažuji jestli to nemá nějakou zásadní vadu v naplnění Mise.
Disassembler commented 2019-06-11 14:45:35 +02:00 (Migrated from git.spotter.cz)

Inspiraci a nápady možná tak hledat u backendu Distribučního serveru, tady ovšem mám prakticky nula informací, protože to je neveřejná záležitost.

Není to neveřejná záležitost. To je na tom celém právě to krásné. Celá platforma je kompletně otevřená a každý si s ní může dělat co chce.

Máme

  1. Virtuálku, která tvoří prostředí pro běh aplikací, resp. kontejnerů (~ Mobilní telefon a jeho OS)
  2. Zdokumentované rozhraní, popisující jak má kontejner zhruba vypadat, co má od prostředí očekávat a jakým způsobem se do něj má integrovat (~ aplikační rozhraní pro programátory)
  3. Aplikační kontejnery (~ Aplikace)
  4. Distribuční server (~ App Store)

A celý vtip je v tom, že distribuční server není nic jiného, než libovolné úložiště, odkud je možno ty aplikace brát a instalovat je anebo je tam po vytvoření nahrávat. Distribučním serverem tedy může být naprosto libovolné úložiště - webový server, souborový server (FTP, SMB, NFS, atd.), externí pevný disk, USB flashka, SD karta z foťáku, DVD, 3.5" disketa. Není tam vůbec žádná logika navíc nebo žádný program nebo služba, která by z obyčejného serveru nebo úložiště nějakým způsobem dělala distribuční. Prostě je to úložiště s hromádkou archivů aplikačních kontejnerů, jedním souborem s metadaty a jedním souborem s digitálním podpisem.

Kdokoliv pak může přijít, přečíst si dokumentaci k rozhraní a vytvořit si vlastní repozitář s vlastním kontejnerem. Ten pak třeba vypálí na CD a oběhne s ním tři instance VM, které má ve správě, a aplikaci si na nich nainstaluje, protože k tomu mu stačí jen platformě ukázat, odkud má ta data brát. Pokud nemá virtuálky tři, ale má jich tisíc anebo chce, aby jeho výtvor byl volně dostupný, sežene si nějaké úložiště dostupné z internetu, třeba nějaký webový server, a vytvořený balík aplikačního kontejneru flákne tam.

Je to úplně ten samý princip jako používají linuxové distribuce. Tam si taky můžete připojit repozitář někoho cizího a nainstalovat si z něj balíčky. A až se na to budete cítit, tak si můžete vyrobit svůj repozitář, s blackjackem a děvkama. (V praxi je to technicky nepatrně složitější, ale principelně je to takto jednoduché).

Jak to přiblížit běžným uživatelům bohužel nevím, ale těch paralel se známými řešeními distribucí aplikací se dá najít hromada, takže možná spíš záleží na tom, co daná cílová skupina zná.

> Inspiraci a nápady možná tak hledat u backendu Distribučního serveru, tady ovšem mám prakticky nula informací, protože to je neveřejná záležitost. Není to neveřejná záležitost. To je na tom celém právě to krásné. Celá platforma je kompletně otevřená a každý si s ní může dělat co chce. Máme 1) Virtuálku, která tvoří prostředí pro běh aplikací, resp. kontejnerů (~ Mobilní telefon a jeho OS) 2) Zdokumentované rozhraní, popisující jak má kontejner zhruba vypadat, co má od prostředí očekávat a jakým způsobem se do něj má integrovat (~ aplikační rozhraní pro programátory) 3) Aplikační kontejnery (~ Aplikace) 4) Distribuční server (~ App Store) A celý vtip je v tom, že *distribuční server* není nic jiného, než libovolné úložiště, odkud je možno ty aplikace brát a instalovat je anebo je tam po vytvoření nahrávat. Distribučním serverem tedy může být naprosto libovolné úložiště - webový server, souborový server (FTP, SMB, NFS, atd.), externí pevný disk, USB flashka, SD karta z foťáku, DVD, 3.5" disketa. Není tam vůbec žádná logika navíc nebo žádný program nebo služba, která by z *obyčejného* serveru nebo úložiště nějakým způsobem dělala *distribuční*. Prostě je to úložiště s hromádkou archivů aplikačních kontejnerů, jedním souborem s metadaty a jedním souborem s digitálním podpisem. Kdokoliv pak může přijít, přečíst si dokumentaci k rozhraní a vytvořit si vlastní repozitář s vlastním kontejnerem. Ten pak třeba vypálí na CD a oběhne s ním tři instance VM, které má ve správě, a aplikaci si na nich nainstaluje, protože k tomu mu stačí jen platformě ukázat, odkud má ta data brát. Pokud nemá virtuálky tři, ale má jich tisíc anebo chce, aby jeho výtvor byl volně dostupný, sežene si nějaké úložiště dostupné z internetu, třeba nějaký webový server, a vytvořený balík aplikačního kontejneru flákne tam. Je to úplně ten samý princip jako používají linuxové distribuce. Tam si taky můžete připojit repozitář někoho cizího a nainstalovat si z něj balíčky. A až se na to budete cítit, tak si můžete vyrobit svůj repozitář, s blackjackem a děvkama. (V praxi je to technicky nepatrně složitější, ale principelně je to takto jednoduché). Jak to přiblížit běžným uživatelům bohužel nevím, ale těch paralel se známými řešeními distribucí aplikací se dá najít hromada, takže možná spíš záleží na tom, co daná cílová skupina zná.
Podhorecky commented 2019-06-11 15:29:40 +02:00 (Migrated from git.spotter.cz)

pardon, špatně jsem se vyjádřil. Nulovou informaci jsem myslel o řešení typu AppStore backend u kterého nevím jak si to konkrétně pojmenovali a postavili. Nikoliv náš DS, kde je to tak, jak píšete :)

Chtěl jsem naznačit, že možná existují v jiných řešeních bílá místa s jejich "killer technologies". Která nemají zdokumentovaná veřejně, ani se navenek moc neprojevují. Akorát v nestřežený okamžik se mě na ně nějaký BFU bezelstně zeptá... :) Např. něco jako jak nakládat s velkými daty, duplicitami, verzováním, oznamováním o verzích a jánevimco. Přemýšlím malinko dopředu.

třeba jako mají u Googlů Bigtable
nebo jestli dobře chápu kategorii sw jako Parse, Kinvey

Nechci po vás teď žádné změny toho co je, jen se ptám z čeho ještě by se dalo nějak poučit.
Ale jak si o tom píšeme, tak to nejvíc killer vypadá to, že to co nabídneme bude otevřené a zdokumentované.

pardon, špatně jsem se vyjádřil. *Nulovou informaci* jsem myslel o řešení typu AppStore backend u kterého nevím jak si to konkrétně pojmenovali a postavili. Nikoliv náš DS, kde je to tak, jak píšete :) Chtěl jsem naznačit, že možná existují v jiných řešeních bílá místa s jejich "killer technologies". Která nemají zdokumentovaná veřejně, ani se navenek moc neprojevují. Akorát v nestřežený okamžik se mě na ně nějaký BFU bezelstně zeptá... :) Např. něco jako jak nakládat s velkými daty, duplicitami, verzováním, oznamováním o verzích a jánevimco. Přemýšlím malinko dopředu. třeba jako mají u Googlů [Bigtable](https://ai.google/research/pubs/pub27898) nebo jestli dobře chápu kategorii sw jako [Parse](http://parseplatform.org/), [Kinvey](https://www.progress.com/kinvey/serverless-backend) Nechci po vás teď žádné změny toho co je, jen se ptám z čeho ještě by se dalo nějak poučit. Ale jak si o tom píšeme, tak to nejvíc killer vypadá to, že to co nabídneme bude otevřené a zdokumentované.
Podhorecky commented 2019-06-11 16:18:51 +02:00 (Migrated from git.spotter.cz)

jo, ...těmi BFU jsem myslel typicky decision makers, tj. lidi co rozhodují zda se jim něco takového má líbit nebo nemá. Oni nemusí být nutně ti samí, kteří by toto řešení nakonec administrovali. Admini většinou vědí a nepotřebují zjednodušující přirovnávání.

jo, ...těmi BFU jsem myslel typicky decision makers, tj. lidi co rozhodují zda se jim něco takového má líbit nebo nemá. Oni nemusí být nutně ti samí, kteří by toto řešení nakonec administrovali. Admini většinou vědí a nepotřebují zjednodušující přirovnávání.
Disassembler commented 2019-06-11 16:38:43 +02:00 (Migrated from git.spotter.cz)

Teď jsem teda už úplně mimo. :) To jsou všechno cloudoviny. To je úplně jiná liga.

jak nakládat s velkými daty, duplicitami, verzováním, oznamováním o verzích a jánevimco

Tohle přece závisí ne těch jednotlivých aplikacích. Pokud mám VM a v ní mi jede Sahana, SeedDMS a Pandora, tak z nich big data nevyrobím, ani kdybych tu platformu měl sebelepší. K tomu potřebuju další produkt, který potenciálně může být instalován ve VM taky. Třeba Apache Hadoop. Ale ten si musím od píky nastavit, aby mi kutal taková data, která v mém scénáři dávají smysl. Ale big data znamená řád stovek terabytů nebo i více, zpracovávaných v nějakém clusteru nebo gridu. To přece s naší prťavou VM s webovými klikátky pro desítky až stovky uživatelů nemůžeme porovnávat, protože ty naše aplikace se sesypou dávno předtím než by takový množství dat vyprodukovaly. Stejně tak duplicity a verzování - Sahana si umí řešit duplicity, protože je na to připravená a dává to v ní smysl. SeedDMS si řeší verzování, protože to u dokumentů dává smysl.

Bigtable, Parse

Totéž. Platformy pro cloudové zpracování neuvěřitelného množství uživatelských dat. Poskytujeme mobilní aplikace, u kterých ukládáme data pro každou jednotlivou instalaci z naší báze stovek tisíc uživatelů? Nepotřebujeme, protože takovou aplikaci nemáme a ani mít nebudeme.

Applicasa

Tady pro jistotu z popisu ani nechápu o co jde.

Kinvey

A zase, tohle je cloudová platforma pro vývoj aplikací. My na té naší platformě aplikace nevyvíjíme. My už je máme vyvinuté a jen je umisťujeme do unifikovaného běhového prostředí. Pokud se někdy někde bude dít něco s mikroservicami nebo s nějakou integrací na téhle úrovni, bavíme se opět o zpracování dat na takové škále, kde je prudce neefektivní používat nějakou univerzální prefabrikovanou VM stavěnou do polních podmínek.

Sečteno podtrženo, ten hlavní rozdíl je, že my nevyvíjíme platformu pro sběr dat a jejich zpracování, ale platformu pro běh webových aplikací. Pokud tedy někdo bude chtít nějaký aplikační kontejner "on-demand", pak se vždycky musí jednat o aplikaci u které má taková integrace mezi jiné aplikace podobného typu smysl. Když někdo přijde s tím, že má 30 petabajtů fotek mrtvol horolezců z Himalájí a potřebuje to prohnat nějakou deep learning umělou inteligencí, aby zjistil jména jejich babiček za svobodna, tak určitě první myšlenka nebude "Hele, rozjedeme na Spotterově staré čtyřiomšestce virtuálku a uděláme to v ní."

Teď jsem teda už úplně mimo. :) To jsou všechno cloudoviny. To je úplně jiná liga. > jak nakládat s velkými daty, duplicitami, verzováním, oznamováním o verzích a jánevimco Tohle přece závisí ne těch jednotlivých aplikacích. Pokud mám VM a v ní mi jede Sahana, SeedDMS a Pandora, tak z nich big data nevyrobím, ani kdybych tu platformu měl sebelepší. K tomu potřebuju další produkt, který potenciálně může být instalován ve VM taky. Třeba Apache Hadoop. Ale ten si musím od píky nastavit, aby mi kutal taková data, která v mém scénáři dávají smysl. Ale big data znamená řád stovek terabytů nebo i více, zpracovávaných v nějakém clusteru nebo gridu. To přece s naší prťavou VM s webovými klikátky pro desítky až stovky uživatelů nemůžeme porovnávat, protože ty naše aplikace se sesypou dávno předtím než by takový množství dat vyprodukovaly. Stejně tak duplicity a verzování - Sahana si umí řešit duplicity, protože je na to připravená a dává to v ní smysl. SeedDMS si řeší verzování, protože to u dokumentů dává smysl. > Bigtable, Parse Totéž. Platformy pro cloudové zpracování neuvěřitelného množství uživatelských dat. Poskytujeme mobilní aplikace, u kterých ukládáme data pro každou jednotlivou instalaci z naší báze stovek tisíc uživatelů? Nepotřebujeme, protože takovou aplikaci nemáme a ani mít nebudeme. > Applicasa Tady pro jistotu z popisu ani nechápu o co jde. > Kinvey A zase, tohle je cloudová platforma pro vývoj aplikací. My na té naší platformě aplikace nevyvíjíme. My už je máme vyvinuté a jen je umisťujeme do unifikovaného běhového prostředí. Pokud se někdy někde bude dít něco s mikroservicami nebo s nějakou integrací na téhle úrovni, bavíme se opět o zpracování dat na takové škále, kde je prudce neefektivní používat nějakou univerzální prefabrikovanou VM stavěnou do polních podmínek. Sečteno podtrženo, ten hlavní rozdíl je, že my nevyvíjíme platformu pro sběr dat a jejich zpracování, ale platformu pro běh webových aplikací. Pokud tedy někdo bude chtít nějaký aplikační kontejner "on-demand", pak se vždycky musí jednat o aplikaci u které má taková integrace mezi jiné aplikace podobného typu smysl. Když někdo přijde s tím, že má 30 petabajtů fotek mrtvol horolezců z Himalájí a potřebuje to prohnat nějakou deep learning umělou inteligencí, aby zjistil jména jejich babiček za svobodna, tak určitě první myšlenka nebude "Hele, rozjedeme na Spotterově staré čtyřiomšestce virtuálku a uděláme to v ní."
Podhorecky commented 2019-06-11 17:30:31 +02:00 (Migrated from git.spotter.cz)

Applicasa byl nějaký bullshit link, jsem se nechal nachytat, pak jsem si to přečetl, uff.

aha, ano... jsou to cloudoviny, zabýváme aplikacemi, to jo. Když jsem úplně na začátku zvažoval záměry a cíle, tak jsem přemýšlel jak o aplikacích, tak o struktuře, i o datech z těch aplikací. Když jsem se pak rozhlídnul, tak jen některé aplikace mají schopnosti verzovat svoje výstupy, aby v tom nebyl chaos. Dobře, řekněme, že zatím vyhoví.

Přemýšlel jsem, jakou službu by náš vlastní soft měl ještě poskytnout, aby to uživatel vnímal jako přidanou hodnotu od spottera. Napadla mne tedy notifikace o verzi samotné VM. Možná že to je nadbytečná služba pro konkrétní apps, pokud taková informace pujde přímo od zdroje toho sw. Ale zase stav VM bude struktura kde nelze mít vždy jen nejnovější aplikace. Bude ještě mnoho uvažování jak to udělat co nejméně otravné.

Duplicity jsem myslel v případě, že by DS mohl poskytovat aplikacím ke stažení některá data, která mohou být teoreticky i duplicitní, byť jsou používána různými aplikacemi a možná i ukládána různě. Když to naroste do velkých objemů, začne problém.

Už dřív jsem pochopil, že přímo datově integrovat aplikace mezi sebou v rámci jedné VM a i přes různé běžící instance VM je nadlidský úkol, takže uvažuji o možnosti, že DS by byl prostředníkem pro datovou výměnu OpenDat. Pak by tedy byl nejen úložištěm balíčkovaných apps, ale i výběrovým úložištěm některých konkrétních dat od aplikací běžících na různých VM. Poskytoval by tedy jim dostupné konektory k OpenDatům.

User case:

  • VM-1 bude používat NGO-1 a jejich výstupem budou privátní Data-1 uložená v jejich DB a sdílená OpenData-1, která vloží na DS.

  • VM-2 bude používat NGO-2 a jejich výstupem budou privátní Data-2 uložená v jejich DB a sdílená OpenData-2, která vloží na DS.

  • VM-3 bude používat NGO-3 a bude vědět, že na DS jsou OpenData-1 a OpenData-2. Stáhne je z místa, které bude vědět díky tomu že ví, že je tam má hledat. A z nich ve svém SW vygeneruje OpenData-3

Jeden ze Softwarů který se v této věci tváří velmi vychytaně je GeoNetwork

Typicky jde o geodata, mapové vrstvy, lokalizované datasety, která by se mohla shodovat polohou, časem, možná nějakým stadnartizovaným metadata formátem. Možná nějaká envirodata, sociologická data, taxonomie. Jak data zpracovat tímto hypotetickým způsobem je asi pak otázka na ty další specializované SW, které jsem ještě nezkoumal. Něco jako soft "R" nebo Pentaho, nebo Carto a podobně.

Moje úvahy jsou trochu spekulativní a já jsem poněkud v nouzi, protože nevím s kým konkrétním je konzultovat.
Objevil jsem tragickou věc... lidé, včetně těch velkých odborníků, kteří se projevují veřejně o svých odborných tématech, jsou málokdy ochotni diskutovat o věcech jinak, než způsobem "konstatující selfpromo". A to ještě pouze v oblasti, na kterou se specializují. Když jde o mezioborový přesah, hned je potíž.

Například někteří klimatologové najeli na svůj informativní kánon. Nedokážu je oslovit tak, že by začli reagovat a pak kooperativně myslet. Všichni jen informují a přesvědčují... myslí si, že nikdo jiný, než neseznámený čtenář je nečte. :( Nebo se pak odmlčí.

*Applicasa byl nějaký bullshit link, jsem se nechal nachytat, pak jsem si to přečetl, uff.* aha, ano... jsou to cloudoviny, zabýváme aplikacemi, to jo. Když jsem úplně na začátku zvažoval záměry a cíle, tak jsem přemýšlel jak o aplikacích, tak o struktuře, i o datech z těch aplikací. Když jsem se pak rozhlídnul, tak jen některé aplikace mají schopnosti verzovat svoje výstupy, aby v tom nebyl chaos. Dobře, řekněme, že zatím vyhoví. Přemýšlel jsem, jakou službu by náš vlastní soft měl ještě poskytnout, aby to uživatel vnímal jako přidanou hodnotu od spottera. Napadla mne tedy notifikace o verzi samotné VM. Možná že to je nadbytečná služba pro konkrétní apps, pokud taková informace pujde přímo od zdroje toho sw. Ale zase stav VM bude struktura kde nelze mít vždy jen nejnovější aplikace. Bude ještě mnoho uvažování jak to udělat co nejméně otravné. Duplicity jsem myslel v případě, že by DS mohl poskytovat aplikacím ke stažení některá data, která mohou být teoreticky i duplicitní, byť jsou používána různými aplikacemi a možná i ukládána různě. Když to naroste do velkých objemů, začne problém. Už dřív jsem pochopil, že přímo datově integrovat aplikace mezi sebou v rámci jedné VM a i přes různé běžící instance VM je nadlidský úkol, takže uvažuji o možnosti, že DS by byl prostředníkem pro datovou výměnu OpenDat. Pak by tedy byl nejen úložištěm balíčkovaných apps, ale i výběrovým úložištěm některých konkrétních dat od aplikací běžících na různých VM. Poskytoval by tedy jim dostupné konektory k OpenDatům. **User case:** * VM-1 bude používat NGO-1 a jejich výstupem budou privátní Data-1 uložená v jejich DB a sdílená OpenData-1, která vloží na DS. * VM-2 bude používat NGO-2 a jejich výstupem budou privátní Data-2 uložená v jejich DB a sdílená OpenData-2, která vloží na DS. * VM-3 bude používat NGO-3 a bude vědět, že na DS jsou OpenData-1 a OpenData-2. Stáhne je z místa, které bude vědět díky tomu že ví, že je tam má hledat. A z nich ve svém SW vygeneruje OpenData-3 Jeden ze Softwarů který se v této věci tváří velmi vychytaně je [GeoNetwork](https://geonetwork-opensource.org/) Typicky jde o geodata, mapové vrstvy, lokalizované datasety, která by se mohla shodovat polohou, časem, možná nějakým stadnartizovaným metadata formátem. Možná nějaká envirodata, sociologická data, taxonomie. Jak data zpracovat tímto hypotetickým způsobem je asi pak otázka na ty další specializované SW, které jsem ještě nezkoumal. Něco jako soft "R" nebo Pentaho, nebo Carto a podobně. Moje úvahy jsou trochu spekulativní a já jsem poněkud v nouzi, protože nevím s kým konkrétním je konzultovat. Objevil jsem tragickou věc... lidé, včetně těch velkých odborníků, kteří se projevují veřejně o svých odborných tématech, jsou málokdy ochotni diskutovat o věcech jinak, než způsobem "konstatující selfpromo". A to ještě pouze v oblasti, na kterou se specializují. Když jde o mezioborový přesah, hned je potíž. Například někteří klimatologové najeli na svůj informativní kánon. Nedokážu je oslovit tak, že by začli reagovat a pak kooperativně myslet. Všichni jen informují a přesvědčují... myslí si, že nikdo jiný, než neseznámený čtenář je nečte. :( Nebo se pak odmlčí.
Podhorecky commented 2019-06-11 18:26:25 +02:00 (Migrated from git.spotter.cz)

co se týče zpracování big dat, tu námitku se spotterovou virtuálkou přijímám jako "nejsme přeci takoví pitomci, abychom svou veledůležitou analýzu XY bastlili na téhle divné virtuálce" ... což se určitě může stát. V tuto chvíli zcela jistě :)

Mam i nějakou zpětnou vazbu, kdy začínající spolek by rád něco vykonal, zná různé čerstvě spuštěné SW, jako ClimateView ale jakmile zjistí kolik cloudová služba stojí peněz, tak začne zuřivě brečet do polštáře.

Já si to vyslechnu, vlastně rozumím argumentům z obou stran, ale je mi to celé strašně líto, že diskuse skončí jen na tomhle. A tak si řikám, že zatím tahle spotterova virtuálka je takový pokus, ale když budu dostatečně dlouho vyfukovat cigaretový dým do vody, tak z něj nakonec to zlato vyrobím... Sakra!!! :D

co se týče zpracování big dat, tu námitku se spotterovou virtuálkou přijímám jako "nejsme přeci takoví pitomci, abychom svou veledůležitou analýzu XY bastlili na téhle divné virtuálce" ... což se určitě může stát. V tuto chvíli zcela jistě :) Mam i nějakou zpětnou vazbu, kdy začínající spolek by rád něco vykonal, zná různé čerstvě spuštěné SW, jako [ClimateView](https://www.climateview.global/) ale jakmile zjistí kolik cloudová služba stojí peněz, tak začne zuřivě brečet do polštáře. Já si to vyslechnu, vlastně rozumím argumentům z obou stran, ale je mi to celé strašně líto, že diskuse skončí jen na tomhle. A tak si řikám, že zatím tahle spotterova virtuálka je takový pokus, ale když budu dostatečně dlouho vyfukovat cigaretový dým do vody, tak z něj nakonec to zlato vyrobím... Sakra!!! :D
Disassembler commented 2019-06-11 18:42:48 +02:00 (Migrated from git.spotter.cz)

notifikace o verzi samotné VM

Tohle se dá celkem dobře zašít i do rozhraní pro správu VM. Alpine umí in-place upgrade, takže někdy od verze 3.0 (léta páně 2014) až do 3.10, která zanedlouho vyjde, se dá upgradovat bez nutnosti úplné ruční výměny podvozku. Předpoklad je, že to tak půjde i nadále.

...že by DS mohl poskytovat aplikacím ke stažení některá data...

Jo, tak tohle už by opravdu mohl být byl Spotter VIP klub a přidaná hodnota. Něco takového máme v plánu zašít přímo do kontejneru Sahany, ne? Mám na mysli všelijaké ty kontakty na organizace atd.

že DS by byl prostředníkem pro datovou výměnu OpenDat

Nemožné to samozřejmě není, ale pak by záleželo na tom, jak moc se chcete v hierarchii nebo propojení oněch NGO angažovat. Totéž by se totiž dalo udělat i pomocí té WireGuard VPN bez účasti serveru. Ale pokud se bavíme o opravdu open datech, která se postupem času vylepšují, přidávají nebo zpřesňují, pak to smysl dává.

co se týče zpracování big dat

Mě šlo spíš o to, že big data neznamená "hodně dat", ale spíš "fakt kurevsky hodně dat", takže už jen úložiště a výpočetní výkon, který je pro jejich zpracování potřeba, je o několik řádů mimo jakýkoliv hardware pro který je naše VM zamýšlena. Třeba taková kompletní mapa světa v OSM, která má nějakých srandovních 800 GB je pořád tak setina toho, kde začínají opravdu big data. Tím nechci říct, že by s naší VM nešlo, ale tuším, že držitel takových dat asi nebude mít problém pustit chlup, když už vyplázl tunu zlata jen za hardware, na kterém jsou ta data uložena. Na ta menší data pak stačí nějaké Business Intelligence softwary a ty už by se do VM napasovat daly, kdyby na věc přišlo.

> notifikace o verzi samotné VM Tohle se dá celkem dobře zašít i do rozhraní pro správu VM. Alpine umí in-place upgrade, takže někdy od verze 3.0 (léta páně 2014) až do 3.10, která zanedlouho vyjde, se dá upgradovat bez nutnosti úplné ruční výměny podvozku. Předpoklad je, že to tak půjde i nadále. > ...že by DS mohl poskytovat aplikacím ke stažení některá data... Jo, tak tohle už by opravdu mohl být byl Spotter VIP klub a přidaná hodnota. Něco takového máme v plánu zašít přímo do kontejneru Sahany, ne? Mám na mysli všelijaké ty kontakty na organizace atd. > že DS by byl prostředníkem pro datovou výměnu OpenDat Nemožné to samozřejmě není, ale pak by záleželo na tom, jak moc se chcete v hierarchii nebo propojení oněch NGO angažovat. Totéž by se totiž dalo udělat i pomocí té WireGuard VPN bez účasti serveru. Ale pokud se bavíme o opravdu *open* datech, která se postupem času vylepšují, přidávají nebo zpřesňují, pak to smysl dává. > co se týče zpracování big dat Mě šlo spíš o to, že big data neznamená "hodně dat", ale spíš "fakt **kurevsky** hodně dat", takže už jen úložiště a výpočetní výkon, který je pro jejich zpracování potřeba, je o několik řádů mimo jakýkoliv hardware pro který je naše VM zamýšlena. Třeba taková kompletní mapa světa v OSM, která má nějakých srandovních 800 GB je pořád tak setina toho, kde začínají opravdu **big** data. Tím nechci říct, že by s naší VM nešlo, ale tuším, že držitel takových dat asi nebude mít problém pustit chlup, když už vyplázl tunu zlata jen za hardware, na kterém jsou ta data uložena. Na ta menší data pak stačí nějaké Business Intelligence softwary a ty už by se do VM napasovat daly, kdyby na věc přišlo.
Podhorecky commented 2019-06-11 20:38:47 +02:00 (Migrated from git.spotter.cz)

jo, já myslím že jmenované nějak vyzkoušíme, vyhodnotíme :) Ano, u Sahany mám v plánu nějaká tabulková data přilepit. Ještě je čas domyslet jak přesně to udělat, aby to bylo zároveň praktické, ale v případě, že by to někoho fakt nezajímalo, tak aby mu to nekomplikovalo počátek vlastní činnosti.

U těch velkých dat... ok, big data nebudeme dráždit, úplně bude stačit "spousta dat v divné formě" :) vidím to jako mraky CSV a jiných XML nedejbože snímky z dronů, možná nějaká videa.

Otázka jak se já mám angažovat v zájmech NGO. To je good point a trochu to naznačuji v té microsite https://spotter.ngo kde jsem se pokusil o FAQ.
Přemýšlel jsem totiž o tom chvilku dřív, než jsem došel k vzniku VM.

Aby mě někdo z NGO vzal na vědomí, musím za ním přijít s konkrétní Vizí a Misí. Zároveň abych nelezl do jejich zelí. Přichystaný software je jen lopatou a není úplným naplněním Mise. Ale bez VM bych k nim přišel jen s nějakým teoretickým blábolem, kterému by nikdo z nich neuvěřil.

Moje angažmá by mělo být jako diskuse o nastartování nových projektů v konkrétních organizacích, posbírání zpětné vazby od nich. Pak se uvidí, jak se to vyvine. Péče o SW a další rozvoj by měla být moje "železná koule na noze", ale chci to chápat jako základ vlastní Mise.

Náš postup je zatím dobrý, za zásery s konkrétními apps nemůžeme, to je prostě okolnost.

jo, já myslím že jmenované nějak vyzkoušíme, vyhodnotíme :) Ano, u Sahany mám v plánu nějaká tabulková data přilepit. Ještě je čas domyslet jak přesně to udělat, aby to bylo zároveň praktické, ale v případě, že by to někoho fakt nezajímalo, tak aby mu to nekomplikovalo počátek vlastní činnosti. U těch velkých dat... ok, big data nebudeme dráždit, úplně bude stačit "spousta dat v divné formě" :) vidím to jako mraky CSV a jiných XML nedejbože snímky z dronů, možná nějaká videa. Otázka jak se já mám angažovat v zájmech NGO. To je good point a trochu to naznačuji v té microsite https://spotter.ngo kde jsem se pokusil o FAQ. Přemýšlel jsem totiž o tom chvilku dřív, než jsem došel k vzniku VM. Aby mě někdo z NGO vzal na vědomí, musím za ním přijít s konkrétní Vizí a Misí. Zároveň abych nelezl do jejich zelí. Přichystaný software je jen lopatou a není úplným naplněním Mise. Ale bez VM bych k nim přišel jen s nějakým teoretickým blábolem, kterému by nikdo z nich neuvěřil. Moje angažmá by mělo být jako diskuse o nastartování nových projektů v konkrétních organizacích, posbírání zpětné vazby od nich. Pak se uvidí, jak se to vyvine. Péče o SW a další rozvoj by měla být moje "železná koule na noze", ale chci to chápat jako základ vlastní Mise. Náš postup je zatím dobrý, za zásery s konkrétními apps nemůžeme, to je prostě okolnost.
Podhorecky commented 2019-06-13 11:19:50 +02:00 (Migrated from git.spotter.cz)

Úvaha k myšlence "DS = výběrové úložiště pro OpenData"

to je sice hezky nadhozeno, ale uvažuji, že tu vzniknou jakési komplikace:

Technicky bude pro provozovatele DS dost nemožné kontrolovat jakého původu jsou takzvaná Opendata vložená uživateli VM. A zda taková "Opendata" něco neporušují, ať už GDPR tím, že by obsahovala citlivé osobní údaje, nebo neotevřené části dat s jinou licencí ke zdrojům a podobně.

Možná že východiskem je, umožnit přes DS pouze přístup k těmto OpenDatům přes směrové konektory.
Konektory by byly generované uživateli jednotlivých VM a datasety by byly stále na jejich úložištích a pod jejich kontrolou. Do DS by se posílal a syncoval pouze odkaz. Odkaz by byl dynamický, tj. při změně prostředí VM by měly být aktualizovány i konektory dostupné na DS.
Při změně obsahu OpenDat by měl být aktualizován i konektor, pokud to je nutné pro přístup k datům. Tady by mi asi významně pomohl SW Geonetwork... Který pro takové věci byl sestrojen. Jen ho nemám osahaný.

Úkolem a nutným řešením v DS by pak bylo mít konkrétní a aktuálně živý výpis dostupných konektorů od všech živých VM. Cosi, jako má vyřešen BIBBOX se svým výpisem žijících instancí BIBBOXu.

ano... zde už se pohybujeme v "advanced services" a už zde hraje roli silná a dlouhodobá vazba po síti mezi klientskými VM a DS.

DS by pak byl skutečně jakýmsi HUBem pro apps a pro OpenData, která by však stále byla pod kontrolou jednotlivých VM. Vize decentralizace by snad stále byla naplněna, co myslíte?

Potřeby přístupu k OpenDatům tu v ČR dlouhodobě jsou... jedním z evangelistů je Jan Cibulka z ČRo, který po takových datech dlouhodobě jede. Teď si udělal i seznam Repo na Githubu. https://github.com/datastory/dzp
Cibulka je můj další "černý kůň" v dlouhodobých plánech, snad mu to vydrží a snad se my někdy staneme rovnocenným partnerem.

Technické řešení s konektory už pokládám jako "řešitelné"... nebo přinejmenším možné najít způsob.

Úvaha k myšlence "DS = výběrové úložiště pro OpenData" to je sice hezky nadhozeno, ale uvažuji, že tu vzniknou jakési komplikace: Technicky bude pro provozovatele DS dost nemožné kontrolovat jakého původu jsou takzvaná Opendata vložená uživateli VM. A zda taková "Opendata" něco neporušují, ať už GDPR tím, že by obsahovala citlivé osobní údaje, nebo neotevřené části dat s jinou licencí ke zdrojům a podobně. Možná že východiskem je, **umožnit přes DS pouze přístup k těmto OpenDatům přes směrové konektory**. Konektory by byly generované uživateli jednotlivých VM a datasety by byly stále na jejich úložištích a pod jejich kontrolou. Do DS by se posílal a syncoval pouze odkaz. Odkaz by byl dynamický, tj. při změně prostředí VM by měly být aktualizovány i konektory dostupné na DS. Při změně obsahu OpenDat by měl být aktualizován i konektor, pokud to je nutné pro přístup k datům. **Tady by mi asi významně pomohl SW Geonetwork...** Který pro takové věci byl sestrojen. Jen ho nemám osahaný. Úkolem a nutným řešením v DS by pak bylo mít konkrétní a aktuálně živý výpis dostupných konektorů od všech živých VM. Cosi, jako má vyřešen BIBBOX se svým výpisem žijících instancí BIBBOXu. ano... zde už se pohybujeme v "advanced services" a už zde hraje roli silná a dlouhodobá vazba po síti mezi klientskými VM a DS. DS by pak byl skutečně jakýmsi HUBem pro apps a pro OpenData, která by však stále byla pod kontrolou jednotlivých VM. Vize decentralizace by snad stále byla naplněna, co myslíte? Potřeby přístupu k OpenDatům tu v ČR dlouhodobě jsou... jedním z evangelistů je Jan Cibulka z ČRo, který po takových datech dlouhodobě jede. Teď si udělal i seznam Repo na Githubu. https://github.com/datastory/dzp Cibulka je můj další "černý kůň" v dlouhodobých plánech, snad mu to vydrží a snad se my někdy staneme rovnocenným partnerem. Technické řešení s konektory už pokládám jako "řešitelné"... nebo přinejmenším možné najít způsob.
Podhorecky commented 2019-06-13 11:50:00 +02:00 (Migrated from git.spotter.cz)

... navazuji v brainstormu. Pan.do/ra umí embeddovat videa do světa, nebo nabídnout download.
takže co se týče pouze sdílení videí mezi VM pro účely Mise, mohlo by být řešitelné ani ne její komplikovanou integrací, možná jen slabou integrací překladem URL z Pandory do konektorů viditelných v DS. Tim obejít největší bolest = datový prostor nutný pro potencíální terrabajty zastaralých dat... Tyhle TB si bude muset vyřešit každý VM klient sám :)

YouTube Sucks.

... navazuji v brainstormu. Pan.do/ra umí embeddovat videa do světa, nebo nabídnout download. takže co se týče pouze sdílení videí mezi VM pro účely Mise, mohlo by být řešitelné ani ne její komplikovanou integrací, možná jen slabou integrací překladem URL z Pandory do konektorů viditelných v DS. Tim obejít největší bolest = datový prostor nutný pro potencíální terrabajty zastaralých dat... Tyhle TB si bude muset vyřešit každý VM klient sám :) YouTube Sucks.
Disassembler commented 2021-01-19 19:09:21 +01:00 (Migrated from git.spotter.cz)

mentioned in issue #9

mentioned in issue #9
Sign in to join this conversation.
No description provided.