Ja si pamätám keď nebol web, Google, Facebook ani zákon o ochrane osobných údajov. A teraz to je. A je to lepšie.
Asi som nepochopil pointu.
Kedze som v riadiacom projekte a vidim co sa tu deje v tomto projekte, dam tu nejaky maly update.
CAMP je dolezity projekt, lebo je na neho naviazanych viacero inych projektov (napr. SVM).
Ma spristupnovat open api centralne, avsak ukazalo sa, ze neboli uplne dotiahnute niektore scenare (napriklad ako sa budu udelovat opravnenia od koncovych pouzivatelov ak ide o SaaS sluzby, krabicove sluzby…)
Je to postavene na hotovej krabici (Layer 7 od Broadcomu) - co sa da pochvalit.
A MIRRI na moje naliehanie zacina obehavat OVM a rozbieha aktivitu zbierania podnetov pre NOVE open api, ktore by sa mali zverejnovat. Zaroven zacinaju evanjelizovat OVM, ze co im projekt CAMP prinesie. Navrhy mozete pisat aj sem: Pripravujeme zoznam prioritných API, ktoré by mal štát sprístupniť. Napíšte nám vaše návrhy
Prezentaciu so suhlasom zverejnujem tu.
Prezentácia-CAMP-pre-OVM.pdf (1.6 MB)
2 Likes
Ked vidim ten slajd tech. architektura integracnej vrstvy CAMP tak chcem revat.
Vyťahujem z priloženej prezky:
Figma prototyp:
- Vyzerá to na IDSK 3.0.
- Pohral by som sa ešte s informačnou architektúrou (napr. očakávam skôr katalóg ako návody v menu
- nerozumiem úplne rozdielu medzi “informácie a návody” a “podpora” a z čoho vystal dôvod rozdeliť to
- Chcelo by to copýka. Niektoré texty sú síce dobre vysvetľujúce, ale zároveň sú dlhé (hlavne H2/ bloky pod nadpismi
- za Lorem Ipsum kade-tade majú jedno VEĽKÝ ŠPATNÝ!
Dokumentácia:
https://architektura.statneit.sk/wpcontent/uploads/2023/04/DNR-CAMP.zip
Ved sa rozpis viac ako to myslíš.
1 Like
Myslím že toto je ešte len v štádiu grafický návrh a texty nie sú ani draft vlastne.
Jeden dobry kamarat rad hovoril: Nepytaj sa otazky na ktore nechces pocut odpoved 
Ale dobre, skusime
Toto bude dlhe takze TLDR: Cele to je zbytocne komplexne a tazkopadne. Neskaluje to hlavne organizacne. Ti ludia co s tym musia robit musia byt velmi nestastni. Nehovoriac o money ktore sa spalia za udzrbu.
A teraz preco…
Je to uz x-ty slide kde sa eGov rozhodol ist cesotu microservices. Microservices su velmi dynamicke. Inac povedane casto sa pridavaju, casto sa odoberaju. Ak sme nasadzovali jeden monolit 1 mesiac, tak tu sa to multiplikuje x10 - x100. Ludia v SKITe su uz asi chori z toho ked toto pocuju Ale… je to tak. To vyzaduje dynamicku infra - a.k.a aplikacia uz nesedi niekde na jednom fyzickom stroji ale plave v ramci nejakeho flat networku. A to trochu meni cele myslenie.
Takze podme na to:
Ked sa clovek uz len letmo pozrie na tu architekturu a opyta sa sam seba - idem pridat novu sluzbu. Sluzba ma byt dostupna ako interne tak aj public. Co to obnasa?
Z tohto vychadza ze treba robit zmeny na minimalne 3x LB, 2 APIGW. Nehovorim este o FW. Ale opravte ma ak sa mylim.
Dalsia vec (a je skoda ze sa to v ziadnom z tych hi-level dokumentov a prezentacii nepise) - certifikaty. Tym ze je to strasne rozbite tak management/ne-management okolo TLS a certov je one-hell-of-a-ride.
Clovek teda uz nieco ponastavoval a uz by to malo ist ale… Useri dostavaju hromadne 404 Not found. Na kolkych miestach musim skontrolovat ci je vsetko v poriadku? Bohuzial z obrazku je jasne, ze to nieje tak, ze pozriem na API GW a vidim ze bavi. Je to len jeden kusok v skladacke trafficu. Tipujem ze to obnasa nemalo ludskeho casu to prebehnut cele. Trasovanie tam nieje trivialne.
Ono sa to nezda ale to znamena vela vela spaleneho casu a v konecnom dosledku aj money. Dam krk na to ze toto sa berie pri planningu ako - ved NASES nasadi lusknutim prstu. Ci?
Este taka ceresnicka: Nieje to jedno DC. Su 2. Cize niektore hosty a veci okolo nich sa tam multiplikuju.
Interna API gateway - je zbytocna komplexnost. Ludia okolo trafficu poznaju west-east a north-south komunikaciu. Fundamentalny problem tohto je, ze cely eGov na vsetko sa pozera ako north-south komunikaciu. Aj interna komunikacia ktora je defacto west-east sa riesi ako north-south. To je trochu overkill. Prave na west-east sa hodi viac sidecar proxy, nie cez masivny LB a GW.
Pred par rokmi cloud ludia stupli nechtiac do hovienka, kedy na API a traffic pozerali z tehnickej-topo perspektivy. Toto bola chyba. Tento model vytvara enormny tlak len na jednu skupinu - infra. Vsetko co ludia na urovni aplikacii potrebuju sa proste vyleje na infra. A kedze sme si dnes vsetci hrdo povedali - let’s do microservices, tak tento problem si treba multiplikovat 10x 100x.
Conway ich/nas nakopal.
Dnes uz vieme ze je dobre sa na to pozriet z pohladu roli. Cize kto co robi a potrebuje. Ze tu mame nejakych network ludi, ludi co riesia clustre, mame tu nejakych aplikacnych ludi (devs) atd a cely traffic management teda zacali riesit z pohladu ludi. Inac povedane - aplikacni ludia budu potrebovat self-service.
Niekto moze argumentovat ze regulacie a security. Toto je pre mna osobne passe lebo uz aj PCI vydalo usmernenia pre dynamicke infrastruktury, kde netreba uzatvarat veci do roznych zon, loadbalacerov atd. Defacto pre mna to zmamena peciatka od auditora ze takto riesit to uz netreba. Ze mozeme ist jednoduchsiou cesotu. Ze mozeme pouzivat rozne network policies, eBPF, mTLS cez sidecars atd. Tu skor treba si pokecat s regulatorom ako len jednoducho povedat - neda sa, musi to tak byt.
Mne to cele pride ze CAMP je len ciastkove riesenie. Namiesto toho aby riesil traffic komplexne, tak si zobral len jednu cast - API GW a nejak ju riesil izolovane v bubline a dolepil to. Tu sa obcas sam seba pytam ci ludia z MIRRI si na zaciatku nemohli prizvat nejakych 2-ch traffic engineerov co by im robili nejaky advisory? Traffic je velka a dolezita domena. Je to krvny obehovy system.
Za mna fakt len: hugops pre ludi co toto musia udrziavat…
2 Likes
Na zakalde slidu 3, kde sa spomina CSRU, sa opytam nasledovne: API k Open Data mi teda da CSRU alebo CAMP? Pytam sa pre tie pripady, kedy OVM nevie/nechce/nemoze Open Data poskytnut same ale niekto/nieco ich predsa len donutilo poskytnut data do CSRU.
Nadvazujem na toto: Denník NP OpenData 2.0 - #140 by hanecak
A chapem, ze odpoved pripadne moze byt zlozitejsia v tom kontexte, ze “spravna” by bola “aj aj”, t.j. ze napr. CSRU da povedzme API specificky na haverstovanie inkrementov (dobre, ak si chcem udrziavat kopiu dat a apku si robit nad tou kopiou) a CAMP da API na “random access” (dobre, ak chcem apku robit rovno nad statnym API, bez nutnosti mat kopiu).
Ak to ma byt narazka na mna, neberem je X moznosti, ako budovat a udrziavat bezpecnu architekturu. A ziadna z nich by nemala byt na ukor funkcnosti, prinasat prehnane poziadavky na udrzbu a neprijatelne komplikovat situaciu.
Vdaka za rozpisanie.
Vsetko by malo ist cez CAMP. Ale dobra otazka podla mna je, ze ci CSRU vlastne nie je zbytocne ked bude CAMP dobre fungovat.
1 Like
OK, pytal som sa MIRRI, ze ak som OVM a mam data, ktore su aj “Open Data” ale treba ich aj pre G2G tak co a vid MIRRI Pracovná skupina K9.4 Lepšie dáta - #265 by hanecak :
“ano/nie …”
Na zaciatok je to (asi) jasne:
- Open Data ma ist na data.gov.sk
- ale s tym, ze data.gov.sk si okresal scope a teda uz chcu byt iba katalog => OVM si musi samo naimplementovat bulk-download a/alebo API a tie nasledne “skatalogizovat” na data.gov.sk
- citlive udaje pre kontext G2G maju ist cez CSRU (a tym padom aj cez CAMP)
Co jasne nie je: ak su data “aj aj” (t.j. aj Open Data aj G2G):
- CSRU “dava ruky prec” od Open Data: chapu ako scope MIRRI/data.gov.sk/Open Data 2.0
- CAMP to zrejme tiez nevyriesi, lebo “High Value Datasets” maju v scope aj “bulk download”, co na API GW velmi dobre nepasuje
- nie je jasne, ake poziadavky na API od OVM ma CSRU a teda ze ci ak niekto spravi dobre Open Data API, ci to CSRU bude vediet prepouzit
- alebo naopak, ak OVM robi/ma spravene API pre CSRU, tak ci a ako lahko/tazko sa da prepouzit na Open Data
T.j. od cca 2015 (casy Open Data 1.0 = vynoveny data.gov.sk) sme publikovanie Open Data postupne posuvali/odsuvali (najprv “lebo CSRU”, neskor “lebo CAMP”, medzitom “lebo kadeco”), ale vo vysledku sme v tej istej situacii ako v 2015, resp. dokocna horsej:
- to iste ako v 2015: OVM si musi Open Data naimplementovt samo
- horsie ako v 2015: navyse s mensou ponukou centralnych sluzieb, lebo:
- data.gov.sk uz o pridane sluzby (ETL + storage) v projekte Open Data 2.0 nema zaujem
- CSRU a cokolvek za nim to berie ako “mimo scope”
Zaraza to o to viac, lebo pri cene CSRU&co. sa argumentovalo o.i. aj tym, ze budu robit netrivialne cistenie a prepajanie udajov. Z toho sa teda zrejme nic nedostane do Open Data, G2G pojde na “inych a lepsich datach” a Open Data teda ostanu nechcenym a nekvalitnym “produktom” resp. to bude ciastocna duplicitna investicia a implementacia popri (ale pomimo) “datovej integracii” (=CSRU & co.)
Neviem ci to zaradim spravne, ale zaujimave citanie od Chris Posta, pre ludi co ich zaujima API problematika.
Nieje CAMP vlastne tiez silo?
Tu by som aj suhlasil, ale imho ten kontext campu je iny. Ja jasne, ze ked mas devops tim, co potrebuje pre vlastnu appku sekat APIny, tak nejaka klikacia bariera je blbost. Lenze CAMP ma uplne iny kontext a ciel.
- zjednotit pristup k publikovaniu API - teraz mas X api po celom egove a kazda ma inu autentifikaciu, dokumentaciu, portaly… - centralny bod sluzi na zjednotenie (aj ked metodiku bude treba tiez) a zaroven vynucuje nejake pravidla.
- mal by setrit zdroje na publikaciu API - OVM dnes maju z tohto paniku najma kvoli bezpecnosti - co je teda usmevne a siria toto skor dodavatelia lebo tusia, ze open api by im dost kazilo vendor lock. Ak camp dobre zabezpeci bezpecnost, tak producent API len vystavi “hole” biznis endpointy niekde do govnetu, nastavia sa prestupy - politiky a pristupy a ochranu riesi camp ako svoj “biznis”.
- centralny bod je potrebny aj kvoli “moje data”, aby si vedel si pozriet aka appka ma pristup kde. Bez centralnej evidencie to nepojde. Iste da sa to aj decentralizovane niekam posielat ale toto by bolo synchronizacne (a nebezpecne) peklo. Tu vypnes pristup centralne a hotovo.
Ci sa podari naplnit ciele camp… uvidi sa.
Toto su vsetko validne body co davaju zmysel. Ale nejak (rad sa necham opravit) mam pocit ze CAMP ako taky sa tychto bodov moc nedrzi a uletel si trochu na nieco ine.
Teda aby tieto body mohli byt splnene, tak CAMP by mal byt doslova self-service. Podobne ako je napr API Gateway/ALB/CloudFront a ja neviem co v AWS. Neviem sa vsak zbavit pocitu, ze tym mnozstvo F5 LB a prestupov (proste komplikovanym trafficom) toto nieje mozne.
Dokonca by som povedal ze pre OVM musi byt NASES dooost bottleneck. Pretoze ak niekto chce vypublikovat novu sluzbu (nie endpoint), musi zasiahnut armada network a system engineerov asi na kazdej urovni. Ze NASES je tu v podstate to silo. A podla mna ani oni sami nechcu byt tym silom.
Ale ako vravim, rad sa necham opravit…
Toto sa este uvidi pri end2end testovani. Kedze som nemal sancu si “osahat” tie endpointy naozaj, tak netusim co to bude znamenat. Mam tusaka, ze to nebude “tu mas api kluc a ide sa”. Pripadne - a este VPN si nastavime.
Mam tip pre E2E testing…
Nech sa sustredia aj na pridavanie sluzieb, nie len na endpointy. Endpointy sa daju vyasteriskovat. Pridat sluzbu bude podla mna znamenat prechadzat tu celu “network” torturu.
Napr tiez mi nieje jasne na tom celom koncepte… co s DNS Toto podla mna zase bude manualna intervencia NASESu.
1 Like
Jasne, e2e som ja myslel len z pohladu konzumenta (to ma zaujima primarne), ale vsetky procesy treba dobre “prefuknut”.
A vieš ze ani nie?
A coho sa v tomto teda OVM najviac obavaju? Zvedavost
No predsa že ich 'hacknu"