🥇Servaj maŝuzaj kazoj

Notu. transl.: La verkinto de ĉi tiu artikolo (Luc Perkins) estas programisto-rekomendanto ĉe la CNCF-organizo, kiu estas hejmo al tiaj Open Source projektoj kiel Linkerd, SMI (Service Mesh Interface) kaj Kuma (cetere, ĉu vi ankaŭ scivolis kial Istio estas ne estas en ĉi tiu listo? .). Denove provante alporti al la DevOps-komunumo pli bonan komprenon pri la laŭmoda ekzaltiĝo nomata "serva maŝo", li listigas 16 karakterizajn kapablojn, kiujn tiaj solvoj provizas.

hodiaŭ servmaŝo ― unu el la plej varmaj temoj en la kampo de programaro (kaj prave!). Mi pensas, ke ĉi tiu teknologio estas nekredeble promesplena kaj ŝatus vidi ĝin vaste adoptita (kiam ĝi havas sencon, kompreneble). Tamen, ĝi ankoraŭ estas ĉirkaŭita de aŭro de mistero por plej multaj homoj. Samtempe, eĉ tiuj, kiuj bone konata kun ĝi, estas ofte malfacile eldiri ĝiajn avantaĝojn kaj kio ĝuste ĝi estas (inkluzive de via vere). En ĉi tiu artikolo mi provos korekti la situacion listigante diversajn uzkazoj "servaj maŝoj"*.

* Notu transl.: ĉi tie kaj plu en la artikolo ĝuste ĉi tiu traduko (“servomaŝo”) estos uzata por la ankoraŭ nova termino servomaŝo.

Sed unue mi volas fari kelkajn komentojn:

Mi neniam laboris kun servaj retoj aŭ uzis ilin ekster projektoj komencitaj por mia propra edukado. Aliflanke, mi estis tiu, kiu verkis amason da dokumentaro por la interna servomaŝo de Twitter en 2015 (ĝi eĉ ne estis nomita "serva maŝo" tiam) kaj partoprenis en la evoluo de la retejo kaj dokumentado por Linkerd, do tio signifas ion.
Mia listo estas proksimuma kaj nekompleta. Eble estas uzkazoj nekonataj al mi, kaj novaj opcioj probable aperos kun la tempo dum la teknologio disvolviĝas kaj ĝia populareco kreskos.
Samtempe, ne ĉiu ekzistanta servo-mesh-efektivigo subtenas ĉiujn listigitajn uzkazojn. Tial, miaj deklaroj kiel "servo mesh povas..." devus esti legitaj kiel "individua, kaj eble ĉiuj popularaj servo mesh efektivigoj povas...".
La ordo de la ekzemploj ne faras ajnan diferencon.

Mallonga listo:

servo malkovro;
ĉifrado;
aŭtentikigo kaj rajtigo;
ŝarĝo-ekvilibro;
cirkvito-rompiĝo;
aŭtoskalo;
kanariaj deplojoj;
bluverdaj deplojoj;
sankontrolo;
forigo de ŝarĝo;
trafiko spegulado;
izolado;
peto-indico-limigo, reprovoj kaj tempo-tempoj;
telemetrio;
revizio;
bildigo.

1. Serva malkovro

TL;DR: Konektu al aliaj servoj en la reto uzante simplajn nomojn.

Servoj devus povi aŭtomate "trovi" unu la alian uzante taŭgajn nomojn - ekzemple, service.api.production, pets/staging aŭ cassandra. Nubaj medioj estas elastaj, kaj ununura nomo povas kaŝi multajn okazojn de servo. Estas klare, ke en tia situacio estas fizike neeble malmola kodi ĉiujn IP-adresojn.

Krome, kiam unu servo trovas alian, ĝi devus povi sendi petojn al tiu servo sen timo, ke ili finiĝos ĉe la enigo de ĝia rompita kazo. Alivorte, la servomaŝo devas kontroli la sanon de ĉiuj servaj petskriboj kaj konservi la liston de gastigantoj kiel eble plej ĝisdatigita.

Ĉiu servomaŝo efektivigas la servomalkovran mekanismon alimaniere. Nuntempe, la plej ofta maniero estas delegi al eksteraj procezoj kiel DNS Kubernetes. En la pasinteco en Twitter ni uzis nomsistemon por tiu celo Finagle. Krome, servo mesh-teknologio ebligas aperi kutimajn nommekanismojn (kvankam mi ankoraŭ ne vidis ajnan SM-efektivigon kun tia funkcieco).

2. Ĉifrado

TL;DR: Forigu neĉifritan trafikon inter servoj kaj faru ĉi tiun procezon aŭtomatigita kaj skalebla.

Estas agrable scii, ke atakantoj ne povas penetri vian internan reton. Fajromuroj faras bonegan laboron. Sed kio okazas se hakisto eniras? Ĉu li povos fari ĉion, kion li volas kun en-serva trafiko? Ni esperu, ke tio finfine ne okazos. Por malhelpi ĉi tiun scenaron, vi devus efektivigi nul-fidan reton, en kiu la tuta trafiko inter servoj estas ĉifrita. Plej modernaj servaj retoj atingas tion per reciproka TLS (reciproka TLS, mTLS). En iuj kazoj, mTLS funkcias en tutaj nuboj kaj aretoj (mi pensas, ke interplanedaj komunikadoj iam estos aranĝitaj simile).

Kompreneble, por mTLS-servo maŝo nedeviga. Ĉiu servo povas prizorgi sian propran TLS, sed ĉi tio signifas, ke vi devos trovi manieron generi atestojn, distribui ilin tra servaj gastigantoj kaj inkluzivi kodon en la aplikaĵo, kiu ŝarĝos ĉi tiujn atestojn el dosieroj. Jes, ne forgesu renovigi ĉi tiujn atestojn je regulaj intervaloj. Servaj maŝoj aŭtomatigas mTLS kun sistemoj kiel SPIFFE, kiuj, siavice, aŭtomatigas la procezon de emisiado kaj turnado de atestiloj.

3. Aŭtentikigo kaj rajtigo

TL;DR: Establi kiu estas la petanto kaj difini kion ili rajtas fari antaŭ ol la peto eĉ atingas la servon.

Servoj ofte volas scii kiu plenumas la peton (aŭtentikigon), kaj uzante ĉi tiun informon, decidas ke donita ento rajtas fari (rajtigo). En ĉi tiu kazo, la pronomo "kiu" povas kaŝi:

Aliaj servoj. Ĉi tio nomiĝas "aŭtentikigo" samulo" Ekzemple, servo web volas aliri la servon db. Servaj retoj kutime solvas tiajn problemojn per mTLS: atestiloj ĉi-kaze funkcias kiel la necesa identigilo.
Iuj homaj uzantoj. Ĉi tio nomiĝas "aŭtentikigo" peto" Ekzemple, uzanto haxor69 volas aĉeti novan lampon. Servaj maŝoj disponigas diversajn mekanismojn, ekz. Retaj Webetonoj de JSON.
Multaj el ni faris tion en aplika kodo. Envenas peto, ni trarigardas la tablon users, trovu la uzanton kaj komparu la pasvorton, poste kontrolu la kolumnon permissions ktp. En la kazo de servomaŝo, ĉi tio okazas antaŭ ol la peto eĉ atingas la servon.

Post kiam ni konstatis, de kiu venis la peto, ni devas determini, kion ĉi tiu ento rajtas fari. Iuj servaj retoj permesas vin agordi bazajn politikojn (pri kiu povas fari kion) kiel YAML-dosieroj aŭ en la komandlinio, dum aliaj ofertas integriĝon kun kadroj kiel Malfermu Politikan Agenton. La fina celo estas, ke viaj servoj akceptu ajnan peton, sekure supozante, ke ĝi venas de fidinda fonto и ĉi tiu ago estas permesita.

4. Ŝarĝbalancado

TL;DR: Distribuu la ŝarĝon tra servaj okazoj laŭ specifa ŝablono.

"Servo" ene de servosekcio tre ofte konsistas el multaj identaj kazoj. Ekzemple, hodiaŭ la servo cache konsistas el 5 ekzempleroj, kaj morgaŭ ilia nombro povas pliiĝi al 11. Petoj senditaj al cache, devas esti distribuita konforme al specifa celo. Ekzemple, por minimumigi latencian aŭ maksimumigi la probablecon atingi funkciantan petskribon. La plej ofte uzata algoritmo estas Round-robin, sed ekzistas multaj aliaj - ekzemple la pezbalancita metodo (pezigita) demandoj (vi povas elekti preferatajn celojn), sonori (ringo) hashing (uzante konsekvencan hashing trans kontraŭfluaj gastigantoj) aŭ malplej-peta metodo (prefero estas donita al la petskribo kun la plej malmultaj petoj).

Klasikaj balanciloj havas aliajn funkciojn, kiel HTTP-kaŝmemoron kaj DDoS-protekton, sed ili ne tre gravas por orient-okcidenta trafiko (tio estas, por trafiko fluanta ene de datumcentro - ĉ. transl.) (tipa amplekso de servomaŝo). Kompreneble, ne necesas uzi servan reton por ŝarĝbalancado, sed ĝi permesas vin agordi kaj kontroli ekvilibrajn politikojn por ĉiu servo de centralizita kontroltavolo, tiel forigante la bezonon funkcii kaj agordi apartajn ŝarĝbalancilojn en la reto-stako. .

5. Circuit breaking

TL;DR: Ĉesigu trafikon al la problema servo kaj kontrolu la damaĝon en plej malbonaj okazoj.

Se ial la servo ne povas elteni la trafikon, la servomaŝo provizas plurajn eblojn por solvi ĉi tiun problemon (aliaj estos diskutitaj en la taŭgaj sekcioj). Cirkvita paŭzo estas la plej severa elekto por malkonekti servon de trafiko. Tamen, per si mem ĝi ne havas sencon - rezerva plano estas necesa. Malantaŭa premo povas esti disponigita (kontraŭpremo) al servoj, kiuj faras petojn (nur ne forgesu agordi vian servoreton por ĉi tio!), aŭ, ekzemple, ruĝe kolorigi la statuspaĝon kaj redirekti uzantojn al alia versio de la paĝo kun "falanta baleno" ("Twitter estas malsupren”).

Servaj maŝoj ne nur permesas vin difini kiam malŝalto sekvos kaj ke ĉi tio sekvos. En ĉi tiu kazo, "kiam" povas inkluzivi ajnan kombinaĵon de specifitaj parametroj: la totala nombro da petoj por certa periodo, la nombro da paralelaj konektoj, pritraktataj petoj, aktivaj reprovoj, ktp.

Vi verŝajne ne volas misuzi cirkuladon, sed estas agrable scii, ke vi havas rezervan planon en kazo de kriz-okazo.

6. Aŭtoskalo

TL;DR: Pliigi aŭ malpliigi la nombron da servokazoj depende de la specifitaj kriterioj.

Servaj maŝoj ne estas planiloj, do ili ne efektivigi grimpi vin. Tamen ili povas doni informojn pri kiuj planistoj bazos siajn decidojn. Ĉar servaj retoj havas aliron al la tuta trafiko inter servoj, ili havas ampleksajn informojn pri tio, kio okazas: kiuj servoj spertas problemojn, kiuj servoj estas tre malpeze ŝarĝitaj (la kapablo asignita al ili estas malŝparita), ktp.

Ekzemple, Kubernetes skalas servojn bazitajn sur la CPU kaj memoruzo de podoj (vidu nian raporton "Aŭtoskalado kaj administrado de rimedoj en Kubernetes"- ĉ. traduk.), sed se vi decidas grimpi surbaze de iu ajn alia metriko (en nia kazo, trafikrilata), vi bezonos specialan metrikon. Administrado kiel tio montras kiel fari tion per sendita, Istio и Prometeo, sed la procezo mem estas sufiĉe komplika. Ni ŝatus, ke la servomaŝo simpligu ĉi tion permesante al ni simple agordi kondiĉojn kiel "pliigi la nombron da servokazoj. auth, se la nombro da pritraktataj petoj superas la sojlon ene de minuto."

7. Kanariaj deplojoj

TL;DR: Testu novajn funkciojn aŭ servoversiojn sur subaro de uzantoj.

Ni diru, ke vi disvolvas SaaS-produkton kaj intencas lanĉi bonegan novan version de ĝi. Vi testis ĝin en surscenigo kaj ĝi bonege funkciis. Sed ankoraŭ estas certaj zorgoj pri ŝia konduto en realaj kondiĉoj. Alivorte, vi devas testi la novan version pri realaj problemoj sen riski la fidon de la uzanto. Kanariaj deplojoj estas bonegaj por ĉi tio. Ili permesas vin montri novan funkcion al subaro de uzantoj. Ĉi tiu subaro povas konsisti el la plej lojalaj uzantoj aŭ tiuj, kiuj laboras kun la senpaga versio de la produkto, aŭ uzantoj, kiuj esprimis deziron esti "kobajoj".

Servaj retoj efektivigas ĉi tion permesante al vi specifi kriteriojn, kiuj determinas, kiu vidos kiun version de la aplikaĵo, kaj direktante trafikon laŭe. Tamen nenio ŝanĝiĝas por la servoj mem. Versio 1.0 de la servo opinias, ke ĉiuj petoj venas de uzantoj, kiuj devus vidi ĝin, kaj versio 1.1 kredas same por siaj uzantoj. Dume, vi povas ŝanĝi la procenton de trafiko inter la malnovaj kaj novaj versioj, redirektante kreskantan nombron da uzantoj al la nova se ĝi funkcias stabile kaj viaj "kobajoj" donas la permeson.

8. Bluverdaj deplojoj

TL;DR: Disvolvu bonegan novan funkcion, sed estu preta tuj repreni ĉion.

Signifo bluverdaj deplojoj estas lanĉi novan "bluan" servon, lanĉante ĝin paralele kun la malnova, "verda". Se ĉio iras glate kaj la nova servo funkcias bone, tiam la malnova povas esti iom post iom malŝaltita. (Ve, iam ĉi tiu nova “blua” servo ripetos la sorton de la “verda” kaj malaperos...) Bluverdaj deplojoj diferencas de kanariaj pro tio, ke la nova funkcio kovras ĉiuj samtempe uzantoj (ne parto); La punkto ĉi tie estas havi "sekuran havenon" preta se io misfunkcias.

Servaj retoj ofertas tre oportunan manieron testi "bluan" servon kaj tuj ŝanĝi al funkcianta "verda" en kazo de problemoj. Sen mencii la fakton, ke survoje ili donas multajn informojn (vidu "Telemetrio" sube) pri la laboro de la "bluo", kio helpas kompreni ĉu ĝi estas preta por plena funkciado.

Notu. transl.: Vi povas legi pli pri malsamaj deplojstrategioj en Kubernetes (inkluzive de la menciita kanario, blua/verda kaj aliaj) en ĉi tiu artikolo.

9. Sankontrolo

TL;DR: Observu kiuj servo-instancoj estas funkciaj kaj respondu al tiuj, kiuj ne plu funkcias.

Sankontrolo (sankontrolo) helpas decidi ĉu servaj petskriboj estas pretaj akcepti kaj prilabori trafikon. Ekzemple, en la kazo de HTTP-servoj, sankontrolo povus aspekti kiel GET-peto al la finpunkto /health. Respondu 200 OK signifos, ke la instanco estas sana, ajna alia - ke ĝi ne estas preta ricevi trafikon. Servaj maŝoj permesas al vi specifi kaj la manieron en kiu funkcieco estos kontrolita kaj la ofteco kun kiu ĉi tiu kontrolo estos farita. Ĉi tiuj informoj tiam povas esti uzataj por aliaj celoj - ekzemple por ŝarĝoekvilibro kaj cirkvito-rompado.

Tiel, sankontrolado ne estas memstara uzkazo, sed kutime estas uzata por atingi aliajn celojn. Ankaŭ, depende de la rezultoj de sankontroloj, agoj eksteraj al aliaj servaj retceloj povas esti postulataj: ekzemple, ĝisdatigi la statuspaĝon, krei problemon en GitHub aŭ plenigi JIRA-bileton. Kaj servo mesh ofertas oportunan mekanismon por aŭtomatigi ĉion ĉi.

10. Ŝarĝo deŝargi

TL;DR: Alidirekta trafiko responde al provizora piko en uzado.

Se certa servo estas troŝarĝita per trafiko, vi povas provizore redirekti iom da ĉi tiu trafiko al alia loko (tio estas, "forĵeto", "translokigo" (ŝedo) lin tie). Ekzemple, al rezerva servo aŭ datumcentro, aŭ al konstanta Pulsi temo. Kiel rezulto, la servo daŭre prilaboros iujn petojn anstataŭ kraŝi kaj ĉesigi ĉion entute. Ŝarĝdeŝargi estas preferinda ol rompi la cirkviton, sed ankoraŭ ne estas konsilinde misuzi ĝin. Ĝi helpas malhelpi kaskadajn fiaskojn, kiuj igas kontraŭfluajn servojn kraŝi.

11. Trafika paraleligo/spegulado

TL;DR: Sendu unu peton al pluraj lokoj samtempe.

Kelkfoje necesas sendi peton (aŭ certan elekton de petoj) al pluraj servoj samtempe. Tipa ekzemplo estas sendi parton de produktada trafiko al sursceniga servo. La ĉefa produktada retservilo sendas peton al la kontraŭflua servo products.production kaj nur al li. Kaj la servomaŝo inteligente kopias ĉi tiun peton kaj sendas ĝin al products.staging, pri kiu la retservilo eĉ ne konscias.

Alia rilata servo-maŝo uzkazo kiu povas esti efektivigita aldone al trafika paraleligo estas regrestestado. Ĝi implikas sendi la samajn petojn al malsamaj versioj de la servo kaj kontroli ĉu ĉiuj versioj kondutas same. Mi ankoraŭ ne renkontis servon mesh-efektivigon kun integra regresa testa sistemo kiel Malfaciligi, sed la ideo mem ŝajnas promesplena.

12. Izolaĵo

TL;DR: Rompi vian servoreton en mini-retojn.

Ankaŭ konata kiel segmentigoIzoliteco estas la arto dividi servomaŝon en logike apartajn segmentojn, kiuj scias nenion pri unu la alian. Izoliĝo estas iom kiel krei virtualajn privatajn retojn. La fundamenta diferenco estas, ke vi ankoraŭ povas ĝui ĉiujn avantaĝojn de servomaŝo (kiel servo-malkovro), sed kun plia sekureco. Ekzemple, se atakanto kapablas penetri servon en unu subreto, li ne povos vidi, kiaj servoj funkcias en aliaj subretoj aŭ kapti ilian trafikon.

Krome, la avantaĝoj ankaŭ povas esti organizaj. Vi eble volas subretigi viajn servojn surbaze de via firmaostrukturo kaj malpezigi programistojn de la kogna ŝarĝo devi konservi la tutan servan reton en menso.

13. Petu indicon limigadon, reprovoj kaj timeouts

TL;DR: Vi ne plu bezonas inkluzivi la plej gravajn petadministrajn taskojn en via kodbazo.

Ĉiuj ĉi tiuj aferoj povus esti konsiderataj apartaj uzkazoj, sed mi decidis kombini ilin pro unu komuna trajto: ili transprenas la petajn vivciklajn administradtaskojn kutime pritraktatajn de aplikaĵbibliotekoj. Se vi disvolvas retservilon en Ruby on Rails (ne integrita kun servomaŝo) kiu faras petojn al backend servoj per gRPC, la aplikaĵo devos decidi kion fari se N petoj malsukcesas. Vi ankaŭ devos ekscii kiom da trafiko ĉi tiuj servoj povos prilabori kaj malmola kodi ĉi tiujn parametrojn uzante specialan bibliotekon. Plie, la aplikaĵo devos decidi kiam estas tempo rezigni kaj lasi la peton malplenigi (surbaze de tempodaŭro). Kaj por ŝanĝi iun el la supraj parametroj, la retservilo devos esti haltigita, reagordita kaj rekomencita.

Malŝarĝi ĉi tiujn taskojn al servomaŝo ne nur signifas, ke servaj programistoj ne devos pensi pri ili, sed ankaŭ ke ili povas esti rigardataj en pli tutmonda maniero. Se oni uzas kompleksan ĉenon de servoj, diru A -> B -> C -> D -> E, la tuta vivociklo de la peto devas esti konsiderata. Se la tasko estas plilongigi tempodaŭrojn en servo C, estas logike fari ĉi tion samtempe, kaj ne en partoj: ĝisdatigante la servkodon kaj atendante ĝis la tirpeto estas akceptita kaj la CI-sistemo deplojas la ĝisdatigitan servon.

14. Telemetrio

TL;DR: Kolektu ĉiujn necesajn (kaj ne tute) informojn de servoj.

Telemetrio estas ĝenerala termino kiu inkluzivas metrikojn, distribuitan spuradon kaj protokolojn. Servaj retoj ofertas mekanismojn por kolekti kaj prilabori ĉiujn tri specojn de datumoj. Ĉi tie aferoj iom malklariĝas ĉar la nombro da eblaj opcioj estas tro granda. Por kolekti metrikojn ekzistas Prometeo kaj aliaj iloj uzeblaj por kolekti ŝtipojn fluad, Loki, vektoro kaj aliaj. (ekzemple ClickHouse kun nia ŝtipdomo por K8s - ĉ. traduk.), por distribuita spurado ekzistas Jaeger kaj tiel plu. Ĉiu servomaŝo povas subteni iujn ilojn kaj ne aliajn. Estos interese vidi ĉu la projekto povas Malfermu Telemetrion havigi iom da konverĝo.

En ĉi tiu kazo, la avantaĝo de serva mesh-teknologio estas, ke sidecar ujoj povas, principe, kolekti ĉiujn ĉi-suprajn datumojn de siaj servoj. Alivorte, vi havas ununuran telemetrian kolektosistemon je via dispono, kaj la servomaŝo povas prilabori ĉiujn ĉi tiujn informojn diversmaniere. Ekzemple:

vostaj protokoloj de certa servo en la CLI;
monitori la volumon de petoj de la servo-maŝa panelo;
kolekti distribuitajn spurojn kaj plusendi ilin al sistemo kiel Jaeger.

Atentu, subjektiva juĝo: Ĝenerale, telemetrio estas areo en kiu forta interfero de la servomaŝo estas nedezirinda. Kolekti bazajn informojn kaj spuri sur la flugo kelkajn orajn metrikojn kiel peto-sukcesprocento kaj latenciado estas bone, sed ni esperu, ke ni ne vidos Frankenstein-stakojn aperi kiuj provas anstataŭigi specialigitajn sistemojn, iuj el kiuj jam pruvis sin kaj bone studis. .

15. Revizio

TL;DR: Tiuj, kiuj forgesas la lecionojn de la historio, estas kondamnitaj ripeti ilin.

Revizio estas la arto observi gravajn eventojn en sistemo. En la kazo de servomaŝo, ĉi tio povus signifi spuri kiu faris petojn al specifaj finpunktoj por specifaj servoj, aŭ kiom da fojoj iu sekureca evento okazis en la lasta monato.

Estas klare, ke revizio estas tre proksime rilata al telemetrio. La diferenco estas, ke telemetrio kutime rilatas al aferoj kiel produktiveco kaj teknika taŭgeco, dum revizio povas rilati al juraj kaj aliaj aferoj, kiuj iras preter la strikte teknika sfero (ekzemple, konformeco al GDPR - la Ĝenerala Regularo de EU pri datumprotekto).

16. Antaŭrigardo

TL;DR: Vivu React.js - neelĉerpebla fonto de elegantaj interfacoj.

Eble estas pli bona termino, sed mi ne konas ĝin. Mi simple celas grafikan reprezenton de servomaŝo aŭ iuj el ĝiaj komponantoj. Ĉi tiuj bildigoj povas inkluzivi indikilojn kiel averaĝaj latentecoj, informoj pri agordo de kromĉaroj, rezultoj de sankontrolo kaj atentigoj.

Labori en servo-orientita medio implikas multe pli altan kognan ŝarĝon kompare kun Lia Moŝto la Monolito. Tial, kogna premo devus esti reduktita ĉiakoste. Simpla grafika interfaco por servo maŝo kun la kapablo alklaki butonon kaj akiri la deziratan rezulton povus esti decida por la kresko de populareco de ĉi tiu teknologio.

Ne estis inkluditaj en la listo

Mi origine intencis enmeti kelkajn pliajn uzkazojn en la liston, sed poste decidis ne. Jen ili, kune kun la kialoj de mia decido:

Multi-datuma centro. Laŭ mi, ĉi tio ne estas tiom uzkazo, kiom mallarĝa kaj specifa areo de apliko de servaj retoj aŭ iu aro da funkcioj kiel servo-malkovro.
Eniro kaj eliro. Ĉi tio estas rilata areo, sed mi limigis min (eble artefarite) al la uzkazo "orientokcidenta trafiko". Eniro kaj eliro meritas apartan artikolon.

konkludo

Jen ĉio por nun! Denove, ĉi tiu listo estas tre arbitra kaj plej verŝajne nekompleta. Se vi pensas, ke mi maltrafis ion aŭ misfaris, bonvolu kontakti min en Twitter (@luckerkins). Bonvolu respekti la regulojn de deco.

PS de tradukisto

La titolilustraĵo por la artikolo baziĝas sur bildo de la artikolo "Kio estas Serva Reto (kaj kiam uzi tian)?"(de Gregory MacKinnon). Ĝi montras kiel iuj funkcioj de aplikoj (en verdo) moviĝis al servomaŝo kiu disponigas interkonektojn inter ili (en blua).

Legu ankaŭ en nia blogo:

fonto: www.habr.com