Ohar. itzul.: Artikulu honen egilea (Luc Perkins) CNCF erakundeko garatzaileen defendatzailea da, Linkerd, SMI (Service Mesh Interface) eta Kuma bezalako kode irekiko proiektuak baitaude (bide batez, galdetu al duzu zergatik den Istio? zerrenda honetan ez? .). Berriro ere DevOps komunitateari "zerbitzu-sarea" izeneko modan dagoen hypea hobeto ulertzen saiatzen da, soluzio horiek eskaintzen dituzten 16 gaitasun ezaugarri zerrendatzen ditu.
Gaur ― Software ingeniaritzaren alorreko gairik beroenetako bat (eta arrazoiz!). Teknologia hau izugarri itxaropentsua dela uste dut eta nahiko nuke oso onartua izatea (zentzuzkoa denean, noski). Hala ere, oraindik ere misterio aura batez inguratuta dago jende gehienarentzat. Aldi berean, norberak ere ezagun horrekin, askotan zaila da bere abantailak eta zehazki zer den (zurea barne) adieraztea. Artikulu honetan egoera zuzentzen saiatuko naiz hainbat zerrendatuz erabilera kasuak "zerbitzu-sareak"*.
* Ohar itzul.: hemen eta aurrerago artikuluan itzulpen hori ("zerbitzu-sare") erabiliko da oraindik berria den zerbitzu-sarerako.
Baina lehenik iruzkin batzuk egin nahi ditut:
- Ez dut inoiz zerbitzu-sareekin lan egin edo nire hezkuntzarako hasitako proiektuetatik kanpo erabili. Bestalde, ni izan nintzen 2015ean Twitterren barne zerbitzu-sarerako dokumentazio mordoa idatzi nuena (orduan ez zen "zerbitzu-sare" deitzen ere) eta webgunearen garapenean eta dokumentazioan parte hartu nuena. , beraz, horrek zerbait esan nahi du.
- Nire zerrenda gutxi gorabeherakoa eta osatugabea da. Baliteke niretzat ezezagunak diren erabilera kasuak egotea, eta denborarekin aukera berriak sortuko dira ziurrenik teknologia garatzen den heinean eta bere ospea hazi ahala.
- Aldi berean, lehendik dauden zerbitzu sarearen inplementazio guztiek ez dituzte onartzen zerrendatutako erabilera kasu guztiak. Hori dela eta, "zerbitzu-sareak..." bezalako adierazpenak "banaka, eta agian zerbitzu-sarearen inplementazio ezagun guztiek egin dezakete..." bezala irakurri behar dira.
- Adibideen ordenak ez du inolako alderik eragiten.
Zerrenda laburra:
- zerbitzuaren aurkikuntza;
- enkriptatzea;
- autentifikazioa eta baimena;
- karga orekatzea;
- zirkuitu haustura;
- autoeskalatzea;
- kanariar hedapenak;
- inplementazioak urdin-berdeak;
- osasun azterketa;
- zama kentzea;
- trafikoa islatzea;
- isolamendua;
- eskaera tasa mugatzea, berriro saiakerak eta denbora-muga;
- telemetria;
- auditoria;
- bistaratzea.
1. Zerbitzuaren aurkikuntza
TL;DR: Sareko beste zerbitzu batzuetara konektatu izen sinpleak erabiliz.
Zerbitzuek automatikoki elkar "aurkitzeko" gai izan behar dute izen egokiak erabiliz - adibidez, service.api.production, pets/staging edo cassandra. Hodei-inguruneak elastikoak dira, eta izen bakar batek zerbitzu baten instantzia asko ezkutatu ditzake. Argi dago egoera horretan fisikoki ezinezkoa dela IP helbide guztiak gogor kodetzea.
Gainera, zerbitzu batek beste bat aurkitzen duenean, zerbitzu horretara eskaerak bidaltzeko gai izan beharko luke, hautsitako instantziaren sarreran amaituko ote diren beldurrik gabe. Beste era batera esanda, zerbitzu-sareak zerbitzu-instantzia guztien osasuna kontrolatu behar du eta ostalarien zerrenda ahalik eta eguneratuen mantendu behar du.
Zerbitzu-sare bakoitzak zerbitzuaren aurkikuntza-mekanismoa desberdin inplementatzen du. Momentuz, ohikoena Kubernetes DNS bezalako kanpoko prozesuetan delegatzea da. Iraganean Twitterren izendapen sistema bat erabiltzen genuen horretarako . Horrez gain, zerbitzu sarearen teknologiak izendatzeko mekanismo pertsonalizatuak agertzea ahalbidetzen du (nahiz eta oraindik ez dudan ikusi funtzionaltasun hori duen SM inplementaziorik).
2. Enkriptatzea
TL;DR: Kendu zerbitzuen arteko zifratu gabeko trafikoa eta egin prozesu hau automatizatu eta eskalagarria.
Polita da jakitea erasotzaileek ezin dutela zure barne sarean sartu. Suebakiek lan handia egiten dute horretan. Baina zer gertatzen da hacker bat barrura sartzen bada? Zerbitzu barruko trafikoarekin nahi duena egiteko gai izango al da? Ea azken finean hau ez gertatzea. Egoera hori saihesteko, zerbitzuen arteko trafiko guztia zifratuta dagoen zero-trust sare bat ezarri beharko zenuke. Zerbitzu-sare moderno gehienek elkarren bidez lortzen dute hori (elkarrekiko TLS, mTLS). Zenbait kasutan, mTLS hodei eta kluster osoetan funtzionatzen du (uste dut planeta arteko komunikazioak noizbait antzera antolatuko direla).
Jakina, mTLS zerbitzu sarerako aukerakoa. Zerbitzu bakoitzak bere TLS zaindu dezake, baina horrek esan nahi du ziurtagiriak sortzeko, zerbitzu-ostalarietan banatu eta fitxategietatik ziurtagiri horiek kargatuko dituen aplikazioan kodea sartu beharko duzula. Bai, ez ahaztu ziurtagiri hauek aldizka berritzea. Zerbitzu-sareek mTLS automatizatzen dute bezalako sistemekin , eta, aldi berean, ziurtagiriak emateko eta txandakatzeko prozesua automatizatzen dute.
3. Autentifikazioa eta Baimena
TL;DR: Ezar ezazu eskatzailea nor den eta zehaztu zer egin behar duen eskaera zerbitzura iritsi aurretik.
Zerbitzuek askotan jakin nahi dute nor eskaera egiten du (autentifikazioa), eta informazio hori erabiliz, erabakitzen du duten entitate jakin bati baimena ematen zaio (baimena). Kasu honetan, "nor" izenordainak ezkutatu dezake:
- Beste zerbitzu batzuk. Honi "autentifikazioa" deitzen zaio parekidea" Adibidez, zerbitzua
webzerbitzuan sartu nahi dudb. Zerbitzu-sareek normalean mTLS erabiliz konpontzen dituzte horrelako arazoak: kasu honetan ziurtagiriek beharrezko identifikatzaile gisa jokatzen dute. - Giza erabiltzaile batzuk. Honi "autentifikazioa" deitzen zaio eskaera" Adibidez, erabiltzailea
haxor69lanpara berri bat erosi nahi du. Zerbitzu-sareek hainbat mekanismo eskaintzen dituzte, adibidez. .Gutako askok aplikazioaren kodean egin dugu. Eskaera bat dator, mahaitik begiratzen dugu
users, aurkitu erabiltzailea eta konparatu pasahitza, eta egiaztatu zutabeapermissionsetab. Zerbitzu-sare baten kasuan, eskaera zerbitzura iritsi aurretik gertatzen da.
Eskaera norengandik heldu den zehaztuta, entitate horrek zer egiteko baimena duen zehaztu behar dugu. Zerbitzu-sare batzuek oinarrizko politikak (nork egin dezakeenari buruz) ezartzeko aukera ematen dizute YAML fitxategi gisa edo komando-lerroan, eta beste batzuek, esaterako, esparruekin integratzea eskaintzen dute. . Azken helburua zure zerbitzuek edozein eskaera onartzea da, seguru iturri fidagarri batetik datorrela suposatuz и ekintza hori baimenduta dago.
4. Karga orekatzea
TL;DR: Banatu karga zerbitzu-instantziatan eredu zehatz baten arabera.
Zerbitzu-atal baten barruan "Zerbitzua" askotan instantzia berdin asko ditu. Adibidez, gaur zerbitzua cache 5 alez osatuta dago, eta bihar haien kopurua 11ra igo daiteke. Hona bidalitako eskaerak cache, helburu zehatz baten arabera banatu behar dira. Adibidez, gutxitu latentzia edo maximizatu laneko instantzia batera iristeko probabilitatea. Gehien erabiltzen den algoritmoa Round-robin da, baina beste asko daude, adibidez, ponderatutako metodoa. (haztatua) kontsultak (hobe hobetsiak hauta ditzakezu), jo (eraztuna) hashing (hashing koherentea erabiliz gorako ostalarien artean) edo eskaera gutxieneko metodoa (eskaera gutxien dituen instantziari lehentasuna ematen zaio).
Balantzaile klasikoek beste funtzio batzuk dituzte, hala nola HTTP cachea eta DDoS babesa, baina ez dira oso garrantzitsuak ekialdetik mendebaldeko trafikorako (hau da, datu-zentro baten barruan doan trafikorako - gutxi gorabehera) (zerbitzu-sarearen esparru tipikoa). Jakina, ez da beharrezkoa zerbitzu-sare bat erabiltzea karga orekatzeko, baina zerbitzu bakoitzaren oreka-politikak ezartzeko eta kontrolatzeko aukera ematen du kontrol zentralizatuko geruza batetik, eta, horrela, sareko pilan karga-orekatzaile bereiziak exekutatu eta konfiguratzeko beharra ezabatzen du. .
5. Zirkuitu-haustura
TL;DR: Zerbitzu arazotsurako trafikoa gelditu eta kalteak kontrolatu egoera txarrenetan.
Arrazoiren batengatik zerbitzuak trafikoari aurre egin ezin badio, zerbitzu-sareak hainbat aukera eskaintzen ditu arazo hau konpontzeko (besteak atal egokietan eztabaidatuko dira). Zirkuitu-haustea da zerbitzu bat trafikotik deskonektatzeko aukerarik larriena. Hala ere, berez ez du zentzurik - babes-plan bat behar da. Atzeko presioa eman daiteke () eskaerak egiten dituzten zerbitzuetara (ez ahaztu zure zerbitzu-sarea konfiguratzea horretarako!), edo, adibidez, egoera-orria gorriz margotu eta erabiltzaileak orriaren beste bertsio batera birbideratzea "erortzen den balea" batekin ("Twitter da. behera”).
Zerbitzu-sareek ez dute soilik definitzeko aukera ematen non itzalaldia jarraituko du eta duten hau jarraituko du. Kasu honetan, "noiz"-ek zehaztutako parametroen edozein konbinazio sar dezake: epe jakin bateko eskaerak guztira, konexio paraleloen kopurua, zain dauden eskaerak, saiakera aktiboak, etab.
Ziurrenik ez duzu zirkuitu-hausterik abusatu nahi, baina polita da larrialdi kasuetarako babesko plan bat duzula jakitea.
6. Autoeskalatzea
TL;DR: Zerbitzu-instantzia kopurua handitu edo txikitu zehaztutako irizpideen arabera.
Zerbitzu-sareak ez dira programatzaileak, beraz, ez burutu zeure burua eskalatu. Hala ere, informazioa eman dezakete zein plangintzak oinarrituko dituzten erabakiak. Zerbitzu-sareek zerbitzuen arteko trafiko guztietarako sarbidea dutenez, informazio zabala dute gertatzen ari denari buruz: zein zerbitzu dituzten arazoak, zein zerbitzu oso arin kargatzen diren (esleitzen zaien edukiera alferrik galtzen da), etab.
Adibidez, Kubernetes-ek zerbitzuak eskalatzen ditu pods-en CPUaren eta memoriaren erabileraren arabera (ikus gure txostena ""- gutxi gorabehera. itzul.), baina beste edozein metriketan oinarrituta eskalatzea erabakitzen baduzu (gure kasuan, trafikoari lotutakoa), metrika berezi bat beharko duzu. Kudeaketa hau nola egin erakusten du , и , baina prozesua bera nahiko korapilatsua da. Zerbitzu-sareak hau sinplifikatzea nahiko genuke, "zerbitzu-instantzia kopurua handitu" bezalako baldintzak besterik gabe ezartzea ahalbidetuz. auth, zain dauden eskaeren kopuruak atalasea gainditzen badu minutu batean."
7. Kanariarren hedapenak
TL;DR: Probatu eginbide berriak edo zerbitzuen bertsioak erabiltzaileen azpimultzo batean.
Demagun SaaS produktu bat garatzen ari zarela eta horren bertsio berri berri bat zabaltzeko asmoa duzula. Eszenaratzean probatu zenuten eta bikain aritu zen. Baina egoera errealetan bere jokabideari buruzko kezka batzuk daude oraindik. Beste era batera esanda, bertsio berria benetako arazoetan probatu behar duzu erabiltzaileen konfiantza arriskuan jarri gabe. Kanariarren inplementazioak bikainak dira horretarako. Ezaugarri berri bat erabiltzaileen azpimultzo bati erakusteko aukera ematen dizute. Azpimultzo hau erabiltzaile leialenak edo produktuaren doako bertsioarekin lan egiten dutenek edo "kobaiak" izateko nahia adierazi duten erabiltzaileek izan dezakete.
Zerbitzu-sareek hori inplementatzen dute, aplikazioaren zein bertsio nork ikusiko duen zehazten duten irizpideak zehazteko eta horren arabera trafikoa bideratzeko. Hala ere, ez da ezer aldatzen zerbitzuetarako. Zerbitzuaren 1.0 bertsioak uste du eskaera guztiak ikusi beharko luketen erabiltzaileengandik datozela, eta 1.1 bertsioak bere erabiltzaileentzat berdina uste du. Bitartean, bertsio zaharren eta berrien arteko trafiko-portzentajea alda dezakezu, gero eta erabiltzaile kopuru handiagoa berrira birbideratuz, egonkortasunez funtzionatzen badu eta zure "kobaiak" baimena ematen badute.
8. Ezarpenak urdin-berdeak
TL;DR: Ezaugarri berri polita zabaldu, baina prest egon dena berehala itzultzeko.
esanahia zerbitzu "urdin" berri bat zabaltzea da, "berde" zaharrarekin paraleloan martxan jartzea. Dena ondo badoa eta zerbitzu berriak ondo funtzionatzen badu, zaharra pixkanaka desgaitu daiteke. (Ai, noizbait zerbitzu "urdin" berri honek "berdearen" patua errepikatuko du eta desagertu egingo da...) Berde-urdinen inplementazioak kanariarekiko desberdinak dira, funtzio berriak estaltzen dituelako. denak aldi berean erabiltzaileak (ez dira parte); Kontua hemen "portu segurua" prest egotea da, zerbait gaizki aterako balitz.
Zerbitzu-sareek oso modu erosoa eskaintzen dute zerbitzu "urdina" probatzeko eta berehala funtzionatzen duen "berde" batera aldatzeko arazoak izanez gero. Zer esanik ez, bidean zehar informazio asko ematen dutela (ikus behean "Telemetria") "urdinaren" lanari buruz, eta horrek funtzionamendu osorako prest dagoen ulertzen laguntzen du.
Ohar. itzul.: Kubernetes-en inplementazio-estrategiei buruz gehiago irakur dezakezu (aipatutako kanaria, urdina/berdea eta beste batzuk barne) hemen .
9. Osasun azterketa
TL;DR: Egin jarraipena zein zerbitzu-instantzia diren funtzionalak eta erantzun jada funtzionatzen ez dutenei.
Osasun azterketa (osasun egiaztapena) zerbitzu-instantziak trafikoa onartzeko eta prozesatzeko prest dauden erabakitzen laguntzen du. Adibidez, HTTP zerbitzuen kasuan, osasun-egiaztapen batek amaierako punturako GET eskaera baten itxura izan dezake /health... Erantzun 200 OK instantzia osasuntsua dela esan nahi du, beste edozein - ez dagoela prest trafikoa jasotzeko. Zerbitzu-sareek funtzionaltasuna nola egiaztatuko den eta egiaztapen hori zein maiztasunarekin egingo den zehazteko aukera ematen dute. Informazio hori beste helburu batzuetarako erabil daiteke, adibidez, karga orekatzeko eta zirkuitu hausteko.
Beraz, osasun-egiaztapena ez da erabilera kasu bakar bat, beste helburu batzuk lortzeko erabili ohi da. Gainera, osasun-kontrolen emaitzen arabera, beste zerbitzu-sare-helburu batzuetatik kanpoko ekintzak beharrezkoak izan daitezke: adibidez, egoera orria eguneratzea, GitHub-en arazo bat sortzea edo JIRA txartela betetzea. Eta zerbitzu sareak mekanismo erosoa eskaintzen du hori guztia automatizatzeko.
10. Kargak kentzea
TL;DR: Birbideratu trafikoa erabileraren aldi baterako igoerari erantzunez.
Zerbitzu jakin bat trafikoz gainkargatuta badago, trafiko hori aldi baterako beste toki batera birbideratu dezakezu (hau da, "iraultzea", "transferitu" (estalpea) hura han). Adibidez, babeskopia-zerbitzu edo datu-zentro batera, edo iraunkor batera Gai. Ondorioz, zerbitzuak eskaera batzuk prozesatzen jarraituko du huts egin eta guztia prozesatzeari utzi beharrean. Karga kentzea hobe da zirkuitua haustea baino, baina oraindik ez da komeni gehiegikeriarik egitea. Behean beherako zerbitzuak huts egitea eragiten duten kaskakako hutsegiteak saihesten laguntzen du.
11. Trafikoaren paralelizazioa/ispilua
TL;DR: Bidali eskaera bat hainbat tokitara aldi berean.
Batzuetan, eskaera bat (edo eskaera hautaketa jakin bat) hainbat zerbitzutara aldi berean bidali beharra dago. Adibide tipiko bat ekoizpen-trafikoaren zati bat eszenatze zerbitzu batera bidaltzea da. Produkzioko web zerbitzari nagusiak eskaera bat bidaltzen dio beherako zerbitzura products.production eta berari bakarrik. Eta zerbitzu-sareak modu adimentsuan kopiatzen du eskaera hau eta bertara bidaltzen du products.staging, web zerbitzariak ere ezagutzen ez duena.
Trafikoaren paralelizazioaren gainean inplementa daitekeen zerbitzu sarearen erabilera kasu bat da . Zerbitzuaren bertsio ezberdinetara eskaera berdinak bidaltzea eta bertsio guztiek berdin jokatzen duten egiaztatzea dakar. Oraindik ez dut zerbitzu sarearen inplementaziorik topatu erregresio proba sistema integratua bezalakoa , baina ideiak berak itxaropentsua dirudi.
12. Isolamendua
TL;DR: Apurtu zure zerbitzu-sarea mini-sareetan.
izenez ere ezaguna segmentazioaIsolamendua zerbitzu-sare bat elkarri buruz ezer ez dakiten segmentu logikoki desberdinetan banatzeko artea da. Isolamendua sare pribatu birtualak sortzea bezalakoa da. Funtsezko aldea zera da: oraindik zerbitzu sare baten onura guztiak goza ditzakezula (zerbitzuen aurkikuntza bezala), baina segurtasun gehigarriarekin. Adibidez, erasotzaile batek azpisareetako batean zerbitzu batean sartzea lortzen badu, ezin izango du ikusi zein zerbitzu dauden beste azpisareetan exekutatzen ari diren edo haien trafikoa atzeman.
Horrez gain, onurak antolakuntzakoak ere izan daitezke. Baliteke zure zerbitzuak azpisaretzea zure enpresaren egituran oinarrituta eta garatzaileei zerbitzu-sare osoa kontuan izan behar izatearen karga kognitiboa arintzea.
13. Eskatu tasa mugatzea, berriro saiakera eta denbora-muga
TL;DR: Jada ez dituzu zure kode-oinarrian eskaera kudeatzeko zereginak sartu beharrik.
Gauza hauek guztiak erabilera-kasu bereizitzat har litezke, baina horiek konbinatzea erabaki nuen ezaugarri komun batengatik: aplikazioen liburutegiek normalean kudeatzen dituzten eskaeraren bizi-zikloaren kudeaketa zereginak hartzen dituzte. Ruby on Rails-en web zerbitzari bat garatzen ari bazara (zerbitzu-sare batean integratuta ez dagoena) backend zerbitzuei eskaerak egiten dizkiena. , aplikazioak erabaki beharko du zer egin N eskaerak huts egiten badu. Era berean, zerbitzu hauek parametro horiek prozesatu eta gogor kodetu ahal izango dituzten trafikoa liburutegi berezi bat erabiliz jakin beharko duzu. Gainera, aplikazioak amore emateko ordua den erabaki beharko du eta eskaera amaitu gabe utzi (denbora-mugan oinarrituta). Eta goiko parametroetako bat aldatzeko, web zerbitzaria gelditu, birkonfiguratu eta berriro martxan jarri beharko da.
Zeregin horiek zerbitzu-sare batera deskargatzeak zerbitzu-garatzaileek ez dutela haietaz pentsatu behar izango ez ezik, modu globalago batean ikus daitezkeela esan nahi du. Zerbitzu-kate konplexua erabiltzen bada, esan A -> B -> C -> D -> E, eskaeraren bizi-ziklo osoa hartu behar da kontuan. Egitekoa C zerbitzuan denbora-muga luzatzea bada, logikoa da hori aldi berean egitea, eta ez zatika: zerbitzuaren kodea eguneratuz eta pull eskaera onartu eta CI sistemak eguneratutako zerbitzua zabaltzen duen arte itxaron.
14. Telemetria
TL;DR: Bildu zerbitzuetatik beharrezko informazio guztia (eta ez nahikoa).
Telemetria neurketak, banatutako trazadura eta erregistroak biltzen dituen termino orokorra da. Zerbitzu-sareek hiru datu motak biltzeko eta prozesatzeko mekanismoak eskaintzen dituzte. Hemen gauzak pixka bat lausotzen dira, aukera posibleen kopurua handiegia delako. Neurri biltzeko dago eta erregistroak biltzeko erabil daitezkeen beste tresna batzuk , , eta abar. (adibidez, ClickHouse gure K8rako - gutxi gorabehera. itzul.), trazadura banaturako badago eta abar. Zerbitzu-sare bakoitzak tresna batzuk onar ditzake eta beste batzuk ez. Interesgarria izango da proiektuak ahal duen ikustea konbergentziaren bat eman.
Kasu honetan, zerbitzu sare-teknologiaren abantaila da sidecar-eko edukiontziak, printzipioz, aurreko datu guztiak beren zerbitzuetatik bil ditzaketela. Hau da, telemetria biltzeko sistema bakarra duzu eskura, eta zerbitzu-sareak informazio hori guztia modu ezberdinetan prozesatu dezake. Adibidez:
- CLIko zerbitzu jakin bateko buztanen erregistroak;
- kontrolatu zerbitzu sareko paneleko eskaeren bolumena;
- bildu banatutako aztarnak eta bidali Jaeger bezalako sistema batera.
Arreta, judizio subjektiboa: Orokorrean, telemetria zerbitzu sarearen interferentzia indartsua desiragarria den eremua da. Oinarrizko informazioa biltzea eta hegan urrezko neurketa batzuk jarraitzea, hala nola eskaeraren arrakasta-tasa eta latentzia, ondo dago, baina espero dezagun sistema espezializatuak ordezkatzen saiatzen diren Frankenstein-en pilarik agertzen ez dugula ikusiko, horietako batzuk dagoeneko frogatu eta ondo aztertuta. .
15. Ikuskaritza
TL;DR: Historiako ikasgaiak ahazten dituztenak errepikatzera kondenatuta daude.
Auditoria sistema bateko gertakari garrantzitsuak behatzeko artea da. Zerbitzu-sare baten kasuan, zerbitzu zehatzetarako amaiera-puntu jakin batzuei eskaerak nork egin dizkien edo azken hilabetean segurtasunarekin lotutako gertaeraren bat zenbat aldiz gertatu den jarraitzea esan liteke.
Argi dago auditoria telemetriarekin oso lotuta dagoela. Aldea da telemetria normalean produktibitatea eta osotasun teknikoa bezalako gauzekin lotzen dela, ikuskaritzak, berriz, arlo tekniko hertsikitik haratago doazen legezko eta bestelako gaiekin (adibidez, GDPR betetzea - Datuen babesari buruzko EBko Erregelamendu Orokorra).
16. Aurreikuspena
TL;DR: Bizi luzea React.js - interfaze dotoreen iturri agortezina.
Baliteke termino hobeagorik, baina ez dakit. Zerbitzu-sare baten edo haren osagai batzuen irudikapen grafikoa besterik ez dut esan nahi. Bistaratze hauek batez besteko latentzia, sidecar konfigurazio informazioa, osasun-emaitzak eta alertak izan ditzakete.
Zerbitzuetara bideratutako ingurune batean lan egiteak karga kognitibo askoz handiagoa dakar Bere Maiestate Monolitoarekin alderatuta. Horregatik, kosta ahala kosta murriztu behar da presio kognitiboa. Botoi batean klik egin eta nahi den emaitza lortzeko gaitasuna duen zerbitzu-sare baterako interfaze grafiko sinple bat erabakigarria izan daiteke teknologia honen ospea hazteko.
Ez ziren zerrendan sartu
Hasiera batean erabilera kasu batzuk gehiago sartzeko asmoa nuen zerrendan, baina gero ez egitea erabaki nuen. Hona hemen, nire erabakiaren arrazoiekin batera:
- Datu anitzeko zentroa. Nire ustez, hau ez da erabilera-kasu bat, zerbitzu-sareen aplikazio eremu estu eta zehatza edo zerbitzuen aurkikuntza bezalako funtzio multzo batzuk.
- Sarrera eta irteera. Erlazionatutako arloa da hau, baina "ekialde-mendebaldeko trafikoa" erabilera kasura mugatu naiz (agian artifizialki). Sarrerak eta irteerak aparteko artikulu bat merezi dute.
Ondorioa
Hori da guztia oraingoz! Berriz ere, zerrenda hau oso arbitrarioa da eta ziurrenik osatugabea da. Zerbait galdu dudala edo gaizki egin dudala uste baduzu, jarri harremanetan nirekin Twitter bidez (). Mesedez, errespetatu dezente arauak.
PS itzultzailetik
Artikuluaren izenburuaren ilustrazioa artikuluko irudi batean oinarritzen da."(Gregory MacKinnon-ek). Aplikazioetako funtzionaltasun batzuk (berdez) haien arteko interkonexioak eskaintzen dituen zerbitzu sare batera nola mugitu diren erakusten du (urdinez).
Irakurri ere gure blogean:
- «»;
- «»;
- «'.
Iturria: www.habr.com
