Miért érdemes mikroszolgáltatás-megközelítést használni az alkalmazások létrehozásához?
A szoftverfejlesztők számára nem újdonság, ha az alkalmazásokat összetevő részekre alakítja. Általában rétegzett megközelítést használnak, háttértárral, középszintű üzleti logikával és kezelőfelülettel (UI). Az elmúlt néhány évben megváltozott, hogy a fejlesztők elosztott alkalmazásokat fejlesztenek a felhőhöz.
Íme néhány változó üzleti igény:
- Olyan szolgáltatás, amely nagy léptékben készült és működik, hogy új földrajzi régiókban elérhesse az ügyfeleket.
- A szolgáltatások és képességek gyorsabb rendelkezésre állása, hogy rugalmasan reagáljon az ügyfelek igényeire.
- Továbbfejlesztett erőforrás-használat a költségek csökkentése érdekében.
Ezek az üzleti igények befolyásolják az alkalmazások készítésének módját .
További információ a mikroszolgáltatások Azure-beli megközelítéséről : Mikroszolgáltatások: A felhő által működtetett alkalmazásforradalom.
Monolitikus és mikroszolgáltatások tervezési megközelítése
Az alkalmazások idővel fejlődnek. A sikeres alkalmazások úgy fejlődnek, hogy hasznosak az emberek számára. A sikertelen alkalmazások nem fejlődnek, és idővel elavultak lesznek. Íme a kérdés: mennyit tud a mai követelményekről, és hogy milyenek lesznek a jövőben? Tegyük fel például, hogy egy jelentéskészítő alkalmazást hoz létre a vállalat egy részlege számára. Biztos benne, hogy az alkalmazás csak a vállalat hatókörén belül érvényes, és hogy a jelentések nem lesznek hosszúak. Az Ön megközelítése eltér majd például egy olyan szolgáltatás felépítésétől, amely több tízmillió ügyfélnek nyújt videótartalmat.
Néha az, hogy valamit kihozunk az ajtón, mint a koncepció bizonyítékát, az a fő tényező. Tudja, hogy az alkalmazás később újratervezhető. Kevés értelme van a túltervezésnek, amit soha nem használnak fel. Másrészt, amikor a vállalatok a felhőre építenek, a növekedés és a használat várható. A növekedés és a méret kiszámíthatatlan. Szeretnénk gyorsan prototípust készíteni, miközben tudjuk, hogy olyan úton járunk, amely képes kezelni a jövőbeli sikereket. Ez a lean indítási megközelítés: buildelés, mérés, tanulás és iteráció.
Az ügyfél/kiszolgáló korszakában arra összpontosítottunk, hogy rétegzett alkalmazásokat építsünk ki az egyes szinteken használt technológiák használatával. A monolitikus alkalmazás kifejezés megjelent ezeknek a megközelítéseknek a leírására. Az interfészek a szintek között készültek, és az egyes szinteken belüli összetevők között szorosabban összekapcsolt kialakítást alkalmaztak. A fejlesztők olyan osztályokat terveztek és faktoráltak, amelyeket kódtárakba állítottak össze, és néhány végrehajtható fájlhoz és DLL-hez csatoltak.
A monolitikus tervezési megközelítésnek vannak előnyei. A monolitikus alkalmazások tervezése gyakran egyszerűbb, az összetevők közötti hívások pedig gyorsabbak, mivel ezek a hívások gyakran folyamatközi kommunikáción (IPC- n) keresztül vannak. Emellett mindenki egyetlen terméket tesztel, amely általában az emberi erőforrások hatékonyabb felhasználását teszi lehetővé. A hátránya az, hogy szoros kapcsolat van a rétegzett rétegek között, és nem lehet skálázni az egyes összetevőket. Ha javításokat vagy frissítéseket kell végeznie, meg kell várnia, amíg mások befejezik a tesztelést. Nehezebb agilisnak lenni.
A mikroszolgáltatások kezelik ezeket a hátrányokat, és jobban összhangban vannak az előző üzleti követelményekkel. Ugyanakkor előnyöket és kötelezettségeket is élveznek. A mikroszolgáltatások előnye, hogy általában mindegyik magában foglalja az egyszerűbb üzleti funkciókat, amelyeket egymástól függetlenül lehet vertikálisan felskálázni, tesztelni, üzembe helyezni és kezelni. A mikroszolgáltatás-megközelítés egyik fontos előnye, hogy a csapatokat jobban üzleti forgatókönyvek vezérlik, mint a technológia. Egy mikroszolgáltatást kisebb csapatok fejlesztenek az ügyfél igényei szerint, tetszőleges technológiával.
Más szóval a vállalatnak nem kell szabványosítania a technológiát a mikroszolgáltatási alkalmazások karbantartásához. A saját szolgáltatásokkal rendelkező csapatok a csapat szakértelme vagy a probléma megoldásához legmegfelelőbb megoldás alapján tehetik meg a számukra megfelelőt. A gyakorlatban az ajánlott technológiák, például egy adott NoSQL-tároló vagy webalkalmazás-keretrendszer használata előnyösebb.
A mikroszolgáltatások hátránya, hogy több különálló entitást kell kezelnie, és összetettebb üzembe helyezésekkel és verziószámozással kell foglalkoznia. A mikroszolgáltatások közötti hálózati forgalom nő, ahogy a megfelelő hálózati késések is. A sok beszédes, részletes szolgáltatás teljesítménybeli rémálmot okozhat. A függőségek megtekintését segítő eszközök nélkül nehéz az egész rendszert látni.
A szabványok a mikroszolgáltatások megközelítését úgy teszik lehetővé, hogy a merev szerződések helyett csak a szolgáltatásból szükséges dolgokat kommunikálják és tolerálják. Fontos, hogy ezeket a szerződéseket előre definiálja a tervben, mert a szolgáltatások egymástól függetlenül frissülnek. A mikroszolgáltatás-megközelítéssel való tervezéshez egy másik leírás a "finomított szolgáltatásorientált architektúra (SOA).
A mikroszolgáltatások tervezési megközelítése legegyszerűbben a szolgáltatások független összevonásáról szól, az egyes és elfogadott kommunikációs szabványok független módosításával.
Ahogy egyre több felhőalkalmazás készül, a felhasználók felfedezték, hogy a teljes alkalmazás független, forgatókönyv-központú szolgáltatásokká való felbontása jobb hosszú távú megközelítés.
Alkalmazásfejlesztési megközelítések összehasonlítása
A monolitikus alkalmazások tartományspecifikus funkciókat tartalmaznak, és általában olyan funkcionális rétegekre vannak felosztva, mint a web, az üzleti és az adatok.
A monolitikus alkalmazásokat több kiszolgálón/virtuális gépen/tárolón klónozva skálázhatja.
A mikroszolgáltatási alkalmazások a funkciókat különálló, kisebb szolgáltatásokra bontják.
A mikroszolgáltatások megközelítése az egyes szolgáltatások egymástól függetlenül történő üzembe helyezésével skálázható fel, és a szolgáltatások példányait kiszolgálókon/virtuális gépeken/tárolókon hozza létre.
A mikroszolgáltatás-alapú tervezés nem minden projekthez megfelelő, de jobban igazodik a korábban ismertetett üzleti célkitűzésekhez. A monolitikus megközelítéstől kezdve akkor lehet értelme, ha tudja, hogy később átdolgozhatja a kódot egy mikroszolgáltatás-kialakításban. Általában monolitikus alkalmazásokkal kezdődik, és lassan bontja fel szakaszokban, kezdve azokkal a funkcionális területekkel, amelyeknek méretezhetőbbnek vagy rugalmasabbnak kell lenniük.
Ha mikroszolgáltatás-megközelítést használ, számos kis szolgáltatás alkalmazását fogja összeállítani. Ezek a szolgáltatások olyan tárolókban futnak, amelyek egy gépfürtön vannak üzembe helyezve. A kisebb csapatok olyan szolgáltatást fejlesztenek, amely egy forgatókönyvre összpontosít, és egymástól függetlenül teszteli, verziózza, üzembe helyezi és skálázza az egyes szolgáltatásokat, hogy a teljes alkalmazás fejlődjön.
Mik azok a mikroszolgáltatások?
A mikroszolgáltatásoknak különböző definíciói vannak. A mikroszolgáltatások ezen jellemzőinek többsége azonban széles körben elfogadott:
- Foglaljon össze egy ügyfél- vagy üzleti forgatókönyvet. Milyen problémát old meg?
- Egy kis mérnöki csapat fejlesztette ki.
- Bármilyen programozási nyelven, bármilyen keretrendszerrel megírva.
- Kódból és opcionálisan állapotból áll, amelyek mindegyike egymástól függetlenül verziószámozott, üzembe helyezve és skálázva van.
- Más mikroszolgáltatások kezelése jól meghatározott felületeken és protokollokon keresztül.
- Egyedi névvel (URL-címekkel) rendelkezik, amelyek a helyük feloldására szolgálnak.
- Továbbra is konzisztens és elérhető hibák esetén.
Összegezve:
A mikroszolgáltatás-alapú alkalmazások kis méretű, egymásétól független verziójú és skálázható, ügyfélközpontú szolgáltatásokból állnak, amelyek szabványos protokollokkal, jól definiált interfészeken keresztül kommunikálnak egymással.
Bármilyen programozási nyelven, bármilyen keretrendszer használatával megírva
Fejlesztőkként szabadon szeretnénk nyelvet vagy keretrendszert választani a képességeinktől és a létrehozott szolgáltatás igényeitől függően. Egyes szolgáltatások esetében a C++ teljesítménybeli előnyeit minden másnál magasabbra értékelheti. Mások számára a C#-ból vagy a Java-ból kapott egyszerű felügyelt fejlesztés fontosabb lehet. Bizonyos esetekben szükség lehet egy adott partnerkódtárra, adattárolási technológiára vagy módszerre a szolgáltatás ügyfelek számára történő felfedéséhez.
A technológia kiválasztása után figyelembe kell vennie a szolgáltatás működési vagy életciklus-felügyeletét és skálázását.
Lehetővé teszi a kód és az állapot független verziószámzását, üzembe helyezését és skálázását
Függetlenül attól, hogy hogyan írja meg a mikroszolgáltatásokat, a kódnak és opcionálisan az állapotnak egymástól függetlenül kell üzembe helyeznie, frissítenie és méreteznie. Ezt a problémát nehéz megoldani, mert az Ön által választott technológiákon múlik. A skálázáshoz a kód és az állapot particionálásának (vagy particionálásának) megértése kihívást jelent. Ha a kód és az állapot különböző technológiákat használ, ami ma gyakori, a mikroszolgáltatás üzembehelyezési szkriptjeinek mindkettőt skálázniuk kell. Ez az elkülönítés az agilitásról és a rugalmasságról is szól, így a mikroszolgáltatások némelyikét anélkül frissítheti, hogy egyszerre kellene mindegyiket frissítenie.
Térjünk vissza a monolitikus és mikroszolgáltatás-megközelítések összehasonlításához egy pillanatra. Ez az ábra az állapottárolási megközelítések különbségeit mutatja be:
Állapottárolás a két megközelítéshez
A monolitikus megközelítés a bal oldalon egyetlen adatbázissal és bizonyos technológiák rétegével rendelkezik.
A mikroszolgáltatások megközelítése a jobb oldalon egy összekapcsolt mikroszolgáltatások grafikonján található, ahol az állapot általában a mikroszolgáltatásra terjed ki, és különböző technológiákat használnak.
Monolitikus megközelítés esetén az alkalmazás általában egyetlen adatbázist használ. Az egyetlen adatbázis használatának előnye, hogy egyetlen helyen található, ami megkönnyíti az üzembe helyezést. Minden összetevőnek egyetlen táblája lehet az állapotának tárolására. A csapatoknak szigorúan el kell különíteni az állapotot, ami kihívást jelent. Elkerülhetetlen, hogy valaki csábítani fog egy oszlopot egy meglévő ügyféltáblához, összekapcsolni a táblákat, és függőségeket létrehozni a tárolási rétegben. Ezt követően nem méretezheti az egyes összetevőket.
A mikroszolgáltatások megközelítésében minden szolgáltatás kezeli és tárolja a saját állapotát. Minden szolgáltatás felelős azért, hogy a kódot és az állapotot együtt skálázhassa a szolgáltatás igényeinek megfelelően. Hátránya, hogy ha nézeteket vagy lekérdezéseket kell létrehoznia az alkalmazás adataiból, több állapottárolóban kell lekérdezést elvégeznie. Ezt a problémát általában egy külön mikroszolgáltatás oldja meg, amely több mikroszolgáltatás-gyűjteményre kiterjedő nézetet hoz létre. Ha több rögtönzött lekérdezést kell futtatnia az adatokon, érdemes lehet az egyes mikroszolgáltatások adatait egy adattárház-szolgáltatásba írni offline elemzés céljából.
A mikroszolgáltatások verziószámozottak. Előfordulhat, hogy egy mikroszolgáltatás különböző verziói egymás mellett futnak. Egy mikroszolgáltatás újabb verziója meghiúsulhat a frissítés során, és vissza kell állítani egy korábbi verzióra. A verziószámozás az A/B-teszteléshez is hasznos, ahol a különböző felhasználók a szolgáltatás különböző verzióit tapasztalják. Gyakori például egy adott ügyfélcsoport mikroszolgáltatásának frissítése az új funkciók szélesebb körű bevezetése előtt történő teszteléséhez.
Más mikroszolgáltatásokkal kommunikál jól meghatározott felületeken és protokollokon keresztül
Az elmúlt 10 évben széles körű információkat tettek közzé a szolgáltatásorientált architektúrák kommunikációs mintáiról. A szolgáltatáskommunikáció általában REST-megközelítést használ HTTP- és TCP-protokollokkal, szerializálási formátumként pedig XML vagy JSON protokollt. A felület szempontjából a webtervezési megközelítésről van szó. De semmi sem akadályozhatja meg a bináris protokollok vagy a saját adatformátumok használatát. Ne feledje, hogy a felhasználók nehezebben használhatják a mikroszolgáltatásokat, ha ezek a protokollok és formátumok nem érhetők el nyíltan.
Egyedi névvel (URL-címmel) rendelkezik a hely feloldásához
A mikroszolgáltatásnak címezhetőnek kell lennie, bárhol is fut. Ha gépekre gondol, és melyik futtat egy adott mikroszolgáltatást, a dolgok gyorsan elromolhatnak.
Ugyanúgy, ahogyan a DNS felold egy adott URL-címet egy adott gépre, a mikroszolgáltatásnak egyedi névre van szüksége, hogy az aktuális helye felderíthető legyen. A mikroszolgáltatásoknak olyan címezhető nevekre van szükségük, amelyek függetlenek az általuk futtatott infrastruktúrától. Ez azt jelenti, hogy interakció van a szolgáltatás üzembe helyezése és a felderítése között, mivel szükség van egy szolgáltatásregisztrációs adatbázisra. Ha egy gép meghibásodik, a beállításjegyzék-szolgáltatásnak meg kell adnia, hogy hová helyezték át a szolgáltatást.
Továbbra is konzisztens és elérhető hibák esetén
A váratlan hibák kezelése az egyik legnehezebb megoldási probléma, különösen az elosztott rendszerekben. A fejlesztőkként írt kódok nagy része a kivételek kezelésére szolgál. A tesztelés során a legtöbb időt a kivételkezeléssel is töltjük. A folyamat nagyobb szerepet játszik, mint a hibák kezelésére vonatkozó kód megírása. Mi történik, ha a mikroszolgáltatást futtató gép meghibásodik? Észlelnie kell a hibát, ami önmagában nehéz probléma. De újra kell indítania a mikroszolgáltatást is.
A rendelkezésre álláshoz a mikroszolgáltatásoknak ellenállónak kell lenniük a hibáknak, és újra kell tudniuk indítani egy másik gépen. A rugalmassági követelmények mellett az adatok nem vesznek el, és az adatoknak konzisztensnek kell maradniuk.
A rugalmasság nehezen érhető el, ha hibák történnek egy alkalmazásfrissítés során. A mikroszolgáltatásnak, amely az üzembe helyezési rendszerrel dolgozik, nem kell helyreállítani. Meg kell határoznia, hogy továbbléphet-e az újabb verzióra, vagy visszaállhat-e egy korábbi verzióra a konzisztens állapot fenntartása érdekében. Figyelembe kell vennie néhány kérdést, például azt, hogy elegendő gép áll-e rendelkezésre a továbblépéshez és a mikroszolgáltatás korábbi verzióinak helyreállításához. Ezeknek a döntéseknek a meghozatalához a mikroszolgáltatásra van szükség az állapotinformációk kibocsátásához.
Állapotjelentések és diagnosztikák
Nyilvánvalónak tűnhet, és gyakran figyelmen kívül hagyják, de egy mikroszolgáltatásnak jelentenie kell az állapotát és a diagnosztikát. Ellenkező esetben a működési szemszögből kevés betekintést nyerhet az állapotába. A diagnosztikai események független szolgáltatások halmazában való korrelálása, valamint a gépóra eltéréseinek kezelése az eseménysorrend értelmezéséhez kihívást jelent. Ugyanúgy, ahogyan egy mikroszolgáltatást a jóváhagyott protokollokkal és adatformátumokkal kezel, szabványosítania kell, hogyan naplózhatja az állapot- és diagnosztikai eseményeket, amelyek végül egy eseménytárba kerülnek lekérdezéshez és megtekintéshez. Mikroszolgáltatás-megközelítéssel a különböző csapatoknak egyetlen naplózási formátumot kell elfogadniuk. Konzisztens megközelítésre van szükség a diagnosztikai események az alkalmazás egészében való megtekintéséhez.
Az állapot eltér a diagnosztikától. Az állapot a mikroszolgáltatás aktuális állapotát jelenti a megfelelő műveletek elvégzéséhez. Jó példa erre a rendelkezésre állás fenntartására szolgáló frissítési és üzembehelyezési mechanizmusok használata. Bár a szolgáltatás jelenleg nem megfelelő állapotú lehet egy folyamat összeomlása vagy a gép újraindítása miatt, a szolgáltatás továbbra is működőképes lehet. Az utolsó dolog, amire szüksége van, hogy a helyzet még rosszabb legyen egy frissítés elindításával. A legjobb módszer az, ha először megvizsgálja a mikroszolgáltatást, vagy időt hagy a helyreállításra. A mikroszolgáltatásokból származó egészségügyi események segítenek a tájékozott döntések meghozatalában, és gyakorlatilag segítenek önjavító szolgáltatások létrehozásában.
Útmutató az Azure-beli mikroszolgáltatások tervezéséhez
Az Azure-beli mikroszolgáltatások tervezésével és létrehozásával kapcsolatos útmutatásért látogasson el az Azure architektúraközpontjába.
Service Fabric mint mikroszolgáltatási platform
Az Azure Service Fabric akkor jelent meg, amikor a Microsoft a dobozos termékekről a szolgáltatások nyújtására váltott, amelyek jellemzően monolitikusak voltak. A nagy méretű szolgáltatások, például a Azure SQL Database és az Azure Cosmos DB felépítésének és működtetésének élménye, formázott Service Fabric. A platform idővel fejlődött, ahogy egyre több szolgáltatás fogadta el. A Service Fabricnek nem csak az Azure-ban, hanem önálló Windows Server-környezetekben is futnia kellett.
A Service Fabric célja a szolgáltatások létrehozásának és futtatásának nehéz problémáinak megoldása, valamint az infrastruktúra-erőforrások hatékony használata, hogy a csapatok mikroszolgáltatás-megközelítéssel oldhassák meg az üzleti problémákat.
A Service Fabric segítségével mikroszolgáltatás-megközelítést használó alkalmazásokat hozhat létre a következők biztosításával:
- Egy platform, amely rendszerszolgáltatásokat biztosít a sikertelen szolgáltatások üzembe helyezéséhez, frissítéséhez, észleléséhez és újraindításához, a szolgáltatások felderítéséhez, az üzenetek átirányításához, az állapot kezeléséhez és az állapot figyeléséhez.
- Tárolókban vagy folyamatokként futó alkalmazások üzembe helyezésének lehetősége. A Service Fabric egy tároló- és folyamatvezénylő.
- Produktív programozási API-k, amelyekkel mikroszolgáltatásként hozhat létre alkalmazásokat: ASP.NET Core, Reliable Actors és Reliable Services. Lekérheti például az állapot- és diagnosztikai adatokat, vagy kihasználhatja a beépített magas rendelkezésre állást.
A Service Fabric agnosztikus a szolgáltatás felépítésével kapcsolatban, és bármilyen technológiát használhat. De olyan beépített programozási API-kat biztosít, amelyek megkönnyítik a mikroszolgáltatások kiépítését.
Meglévő alkalmazások migrálása a Service Fabricbe
A Service Fabric lehetővé teszi a meglévő kód újrafelhasználását és modernizálását új mikroszolgáltatásokkal. Az alkalmazás modernizálásának öt fázisa van, és bármelyik szakaszban elindíthatja és leállíthatja. A szakaszok a következők:
- Kezdje egy hagyományos monolitikus alkalmazással.
- Áttelepítése. Tárolók vagy vendég végrehajtható fájlok használatával üzemeltetheti a meglévő kódot a Service Fabricben.
- Modernizálják. Adjon hozzá új mikroszolgáltatásokat a meglévő tárolóalapú kóddal együtt.
- Innovációra. A monolitikus alkalmazást szükség szerint mikroszolgáltatásokra bonthatja.
- Alkalmazások átalakítása mikroszolgáltatásokká. Meglévő monolitikus alkalmazások átalakítása vagy új zöldmezős alkalmazások létrehozása.
Ne feledje, hogy bármelyik szakaszban elkezdheti és leállíthatja. Nem kell továbblépnie a következő szakaszra.
Tekintsünk meg példákat ezekre a szakaszokra.
Migrate
Két okból sok vállalat migrálja a meglévő monolitikus alkalmazásokat tárolókba:
- Költségcsökkentés a meglévő hardverek összevonása és eltávolítása, vagy a nagyobb sűrűségű alkalmazások futtatása miatt.
- Konzisztens üzembehelyezési szerződés a fejlesztés és a műveletek között.
A költségcsökkentések egyszerűek. A Microsoftnál számos meglévő alkalmazást tárolóba rendeznek, ami több millió dollár megtakarítást eredményez. A konzisztens üzembe helyezést nehezebb kiértékelni, de ugyanilyen fontos. Ez azt jelenti, hogy a fejlesztők kiválaszthatják a nekik megfelelő technológiákat, de a műveletek csak egyetlen módszert fogadnak el az alkalmazások üzembe helyezéséhez és kezeléséhez. Enyhíti a műveleteket attól, hogy kezelniük kell a különböző technológiák támogatásának összetettségét anélkül, hogy a fejlesztőket csak bizonyos technológiák kiválasztására kényszerítenék. Lényegében minden alkalmazás önálló üzembehelyezési rendszerképekbe van tárolóba helyezve.
Sok szervezet áll meg itt. Már rendelkeznek a tárolók előnyeikkel, és a Service Fabric biztosítja a teljes felügyeleti élményt, beleértve az üzembe helyezést, a frissítéseket, a verziószámozást, a visszaállításokat és az állapotfigyelést.
Modernizálják
A modernizálás új szolgáltatások hozzáadása a meglévő tárolóalapú kóddal együtt. Ha új kódot szeretne írni, a legjobb, ha kis lépéseket tesz a mikroszolgáltatások útvonalán. Ez azt jelentheti, hogy új REST API-végpontot vagy új üzleti logikát ad hozzá. Ily módon elindítja az új mikroszolgáltatások létrehozásának folyamatát, és gyakorolja azok fejlesztését és üzembe helyezését.
Újítás
A mikroszolgáltatás-megközelítés alkalmazkodik a változó üzleti igényekhez. Ebben a szakaszban el kell döntenie, hogy megkezdi-e a monolitikus alkalmazás szolgáltatásokra való felosztását vagy az innovációt. Egy klasszikus példa erre, amikor egy munkafolyamat-üzenetsorként használt adatbázis feldolgozási szűk keresztmetszetté válik. A munkafolyamat-kérelmek számának növekedésével a munkát skálázás céljából el kell osztani. Vegye ki az alkalmazásnak azt a részét, amely nem skálázható, vagy amelyet gyakrabban kell frissíteni, és ossza fel mikroszolgáltatásként és innovációként.
Alkalmazások átalakítása mikroszolgáltatásokká
Ebben a szakaszban az alkalmazás teljes mértékben mikroszolgáltatásokból áll (vagy fel van osztva). Ehhez a ponthoz a mikroszolgáltatás-utazást hajtotta végre. Itt kezdheti, de ehhez mikroszolgáltatási platform nélkül, hogy jelentős befektetést igényeljen.
Megfelelőek-e a mikroszolgáltatások az alkalmazásomhoz?
Esetleg. A Microsoftnál, mivel üzleti okokból egyre több csapat kezdett el felhőre építeni, sokan felismerték a mikroszolgáltatás-szerű megközelítés előnyeit. A Bing például évek óta használ mikroszolgáltatásokat. Más csapatok esetében a mikroszolgáltatás-megközelítés új volt. A csapatok úgy találták, hogy az alapvető erőterületeken kívül nehéz problémákat kell megoldaniuk. A Service Fabric ezért nyerte el a vontatást az épületgépészet technológiájaként.
A Service Fabric célja, hogy csökkentse a mikroszolgáltatási alkalmazások létrehozásának összetettségét, hogy ne kelljen annyi költséges átalakításon átesnie. Kezdjen kicsivel, igény szerint skálázható, elavulttá teszi a szolgáltatásokat, adjon hozzá újakat, és fejlődjön az ügyfélhasználattal. Azt is tudjuk, hogy sok más problémát még meg kell oldani, hogy a mikroszolgáltatások könnyebben kezelhetők legyenek a legtöbb fejlesztő számára. A tárolók és az aktor programozási modellje néhány példa az ebbe az irányba tett kis lépésekre. Biztosak vagyunk benne, hogy a mikroszolgáltatás-megközelítés megkönnyítése érdekében további újítások jelennek meg.