https://docs.microsoft.com/archive/blogs/felho-tanacsado/feed.xml Üzleti és technológiai lehetőségekről a felhőben. Wed, 17 Apr 2019 03:20:51 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/felho-tanacsado/kifejezetten-fejlesztoknek-szolo-azure-utmutato Fri, 03 Feb 2017 15:37:35 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=306

• Azoknak a fejlesztőknek, akik kíváncsiak arra, hogy miért az Azure az ideális fejlesztői felhőplatform, és hogyan kezdhetnek hozzá rövid idő alatt a kívánt alkalmazás elkészítéséhez.
• Azoknak a technikai vezetőknek, akik az Azure használatát tervezik új vagy meglévő alkalmazásfejlesztési projektek támogatásához.

Tartalom:

• Áttekintés
• Gyakori felhőalkalmazás-fejlesztési feladatok
• Az Azure platformszolgáltatásai
• Fejlesztés infrastruktúra-szolgáltatások (IaaS) használatával
• Szuperképességekkel ellátott alkalmazások

A letöltő oldal eléréséhez kattints ide.]]> https://docs.microsoft.com/archive/blogs/felho-tanacsado/david-chappell-hogyan-valtoztatja-meg-a-saas-modell-az-uzletunket-harmadik-resz Mon, 23 Jan 2017 08:41:05 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=295 Három poszttal ezelőtt a SaaS modellben rejlő lehetőségekről és kihívásokról írtam, amely David Chappell How SaaS Changes an ISV’s Business: A Guide for ISV Leaders című munkájából volt egy kivonat. (Emlékeztetőül: David Chappell, egy Egyesült Államokban élő, de a világ több országában tevékenykedő független konzulens. Munkássága arra fókuszál, hogy új technológiákat és azok hatásait megismertesse és megértesse az emberekkel, szervezetekkel.) A mostani posztom az előző kettő folytatásaként (első, második) kivonatot közöl az említett tanulmányból, amely folytatja annak a témának a boncolgatását, hogyan változtathatja meg egy szoftverfejlesztő cég üzletét a SaaS modell: 1. Az SaaS alkalmazásunk átlagos árának hatása az üzletünkre. SaaS alkalmazások havi díjai igen széles skálán mozognak: akár 5$-tól egészen 499$ dollárig, vagy még feljebb. Az ár, amennyiért el tudjuk adni a szolgáltatásunkat alapvetően határozza meg, hogyan tudjuk az ügyfeleket megszerezni, hogyan tartsuk a kapcsolatot az ügyfelekkel és így tovább: 2. Marketing: ha a SaaS termékünk ára a fenti táblázat felső sorában van, akkor a marketingünk nem fog sok mindenben különbözni az eddigiektől. (a legjelentősebb új terület a digitális marketing lesz - ha eddig még nem csináltuk). Ellenben, ha a termékünket alacsony áron tudjuk kínálni, akkor egy teljesen új megközelítés szerint kell felépítenünk a marketingünket. Ekkor a termék/cég weboldala lesz a kulcs: ez lesz a marketingesünk és az értékesítőnk is egyben. Az oldalt fel kell készíteni arra, hogy a potenciális ügyfeleink rátaláljanak, ki tudják próbálni az alkalmazást úgy, hogy a részünkről semmilyen interakció ne kelljen hozzá, illetve egyértelműen megértsék annak használatának az értékét. Digitális marketing eszköztárát kell alkalmaznunk. Továbbá mindent mérnünk kell! Hány látogató jött az oldalra, ebből hányan próbálták ki az alkalmazást, ebből hányan fizettek elő, stb... 3. Támogatás. Az ügyfelek támogatása az egyik olyan tényező, amelyen a legkönnyebben el lehet bukni a SaaS üzletben. Arra kell törekedni, hogy a support költségeket a lehető legalacsonyabban tartsuk. Néhány kulcs terület:

• teljesen önkiszolgáló fizetés, számlázás;
• magas rendelkezésre állás, könnyű kezelhetőség;
• transzparens, őszinte, nyílt kommunikáció hibák, leállások esetén;
• önkiszolgáló support: wiki vagy GYIK (FAQ) oldal;

4. A SaaS üzlet cégünk napi működésére is hatással lehet:

• Számlázás;
• A SaaS appot futtató infrastruktúra költségei, amely két részre bomlik:
  • adatközpont/saját infrastruktúra költségei;
  • a folyamatos futtatás költségei (pl.: mindig legyen ügyeletben egy mérnök, aki egy esetleges nem várt leállás esetén minél hamarabb be tud avatkozni).

5. Szoftverfejlesztés: mivel a SaaS alkalmazásunk az általunk kezelt infrastruktúrán fut (ellentétben az ügyfeleink kliensei, vagy szerverein futó alkalmazással), ezért sokkal könnyebben és ami még fontosabb, gyakrabban tudjuk azt frissíteni. Az új funkciók, javítások így nagyon rövid idő (kétheti, havi rendszerességgel) alatt bekerülhetnek az éles alkalmazásba. Ennek nagyon fontos következménye, hogy a klasszikus vízesés módszertan nem igazán tudja támogatni ezt a gyakorlatot. Ezért, -ha még nem tettük meg,- akkor mindenképpen át kell állnunk agilis metodikára, és el kell kezdenünk használni az ezt támogató szolgáltatásokat, eszközöket is (pl.: VSTS). Továbbá meg kell ismerkednünk a gyors alkalmazás fejlesztést és közzététellelt támogató metodikákkal is: DevOps, Continuous Integration, Continuous Delivery, stb...    ]]> https://docs.microsoft.com/archive/blogs/felho-tanacsado/david-chappell-hogyan-valtoztatja-meg-a-saas-modell-az-uzletunket-masodik-resz Tue, 10 Jan 2017 13:23:06 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=265 kettővel ezelőtti posztom a SaaS modellben rejlő lehetőségekről és kihívásokról szólt, amely David Chappell How SaaS Changes an ISV’s Business: A Guide for ISV Leaders című munkájából volt egy kivonat. (Emlékeztetőül: David Chappell, egy Egyesült Államokban élő, de a világ több országában tevékenykedő független konzulens. Munkássága arra fókuszál, hogy új technológiákat és azok hatásait megismertesse és megértesse az emberekkel, szervezetekkel.) A mostani posztom az előző folytatásaként szintén kivonatot közöl az említett tanulmányból, amely folytatja annak a témának a boncolgatását, hogyan változtathatja meg egy szoftverfejlesztő cég üzletét a SaaS modell:

1. Célközönség: SaaS alkalmazás létrehozása alapvetően két új irányt vázolhat fel egy ISV előtt:
   • a meglévő piacunkon terjeszkedünk, csak sokkal hatékonyabban,
   • új piacra lépünk be. Alapvető kérdés, hogy az olcsóbb SaaS alkalmazásunk kannibalizálja-e a hagyományos alkalmazásunk piacát? Ezt a döntést meghozhatjuk tudatosan mi magunk is, ha a SaaS alkalmazásunk egy fájdalompontunkat old meg. (pl.: hagyományos app magas deployment és support költsége)
2. A SaaS alkalmazások árazása általában eltérő a hagyományos licenceléstől. Néhány általánosan használt modell:
   • előfizetés: az ügyfelünk felhasználó vagy eszköz után fizet havidíjat
   • egység alapú: a fizetés alapját valamilyen mérhető egység adja: pl: tranzakciószám, tárolt adatmennyiség, stb...
   • ingyenes: freemium modell: ebben az esetben a termékünk alapváltozata teljesen ingyenes. A felhasználók pedig prémium szolgáltatásokra tudnak előfizetni. Az app ingyenes, de hirdetéssel monetarizálunk. Az app ingyenes, a felhasználók az adataikkal fizetnek.
3. A bevételek: A SaaS üzlet időben eltéréseket mutat a hagyományos üzlettel szemben, ezek:
   • nagyobb kezdeti beruházás, amely abból fakadhat, hogy teljesen új területen kezdünk el tevékenykedni, illetve a SaaS alatti infrastruktúrát addig is kell üzemeltetnünk, amíg el nem érjük az elegendő felhasználó számot.
   • Mivel az ügyfeleink az alkalmazásunkért annak használatáért fizetnek, ezért időben lassabban épül fel a bevételünk.
   • Később érjük el a jövedelmezőségi szintet.
   • Viszont hosszú távon több, és stabilabb bevételre tehetünk szert.
4. A sikeresség mérésére van egy széles körben használt mutató: a MRR, monthly recurring revenue, vagyis a havi ismétlődő bevétel. Ez azt mutatja meg, hogy egy adott időszakban (többnyire egy hónapban) mennyi volt az olyan típusú bevételünk, amely ismétlődő bevétel. Tehát a jövőben is nagy valószínűséggel számíthatunk rá, nem egyszeri tétel. (pl.: egy egyedi bevezetési díjból érkező bevétel nem tartozik ide). Ha jól csináljuk a dolgunkat, akkor az MRR időszakról-időszakra nő.
5. Az ügyfelek döntése a vásárlásról: habár a hagyományos szoftverek értékesítésének folyamatában az ügyfél (vagy az ügyfél döntéshozója) vásárlás előtt akár találkozhat is szoftverünkkel (próbaverzió, demó, stb...), de a vásárlási döntést percepciók és várakozások alapján kell meghoznia viszonylag nagy pénzügyi kockázatot vállalva. A SaaS alkalmazás esetében viszont (,ha van kipróbálási lehetőség, vagy freemium, stb..) az ügyfelünknek saját, közvetlen használaton alapuló tapasztalt birtokában hozza meg a döntését - ráadásul alacsonyabb pénzügyi kockázatot vállalva.
6. Értékesítők jutalmazása / partner visszatérítések: mivel a SaaS alkalmazásunkért az ügyfeleink általában használat alapon, rendszeres időközönként fizetnek, ami kisebb összeg mint egy kezdeti licencértékesítés, ezért az értékesítők/partnerek sikeres eladás utáni javadalmazását is át kell alakítani. Három tipikus példa:
   • az eladás pillanatában az üzletből remélt teljes első évi bevétel után kap visszatérítést.
   • Havi visszatérítés a korábban már eladott, de még MRR formájában továbbra is jövő bevétel után (esetleg évente csökkenő mértékben).
   • Ha előre fizet (pl: egy éves havi díjat az elején kifizeti) az ügyfelünk, akkor alkalmazható a hagyományos visszatérítés.

A következő részben az ár hatásával, a marketinggel, a cég működésével és a fejlesztést érintő kérdésekkel folytatjuk...]]> https://docs.microsoft.com/archive/blogs/felho-tanacsado/david-chappell-hogyan-valtoztatja-meg-a-saas-modell-az-uzletunket Thu, 15 Dec 2016 11:14:27 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=255 David Chappell How SaaS Changes an ISV’s Business: A Guide for ISV Leaders című munkájából volt egy kivonat. (Emlékeztetőül: David Chappell, egy Egyesült Államokban élő, de a világ több országában tevékenykedő független konzulens. Munkássága arra fókuszál, hogy új technológiákat és azok hatásait megismertesse és megértesse az emberekkel, szervezetekkel.) A mostani posztom az előző folytatásaként szintén kivonatot közöl az említett tanulmányból, amely arról szól, hogyan változtatja meg egy szoftverfejlesztő cég üzletét a SaaS modell: "

1. Célközönség: SaaS alkalmazásunkkal esély van arra, hogy másmilyen célközönséget szólítsunk meg, mint eddig:
   • a jelenlegi piacunkon több vásárlót érünk el, (pl: nagyvállalati ügyfelek mellett most már szolgáltathatunk KKV-knak is)
   • új piacra tudunk belépni meglévő termékkel, vagy teljesen új termékkel. (pl: helyi megoldás regionális, EU, világpiacra kisebb kockázattal tud belépni)
2. Árazás: feltehetőleg új árazási modelleket kell választanunk. Napjaink népszerű megoldásai:
   • Előfizetés alapú (felhasználó/hó, eszköz/év, stb...)
   • Egység alapú (pl.: tranzakciók száma, tárolt adat mennyisége, stb...)
   • Ingyenes (Freemium, a felhasználók az adataikkal fizetnek, stb...)
3. Bevétel alakulása: mivel a SaaS alkalmazások esetén az ügyfelek használat alapon, folyamatosan fizetnek (pl: felhasználó/hó) ezért a bevételünk lassabban épül fel. Cserébe nagyobb hosszútávú bevételre tehetünk szert.
4. A sikeresség mérése. Van egy általánosan használt mérőszám, amely a SaaS üzletünk sikerességét mutatja: ez az adott hónapban befolyt ismétlődő bevétel, azaz a Monthly Recurring Revenue (MRR). Ebbe csak az ismétlődő bevételeket szabad beleszámítani, az ad-hoc bevételeket nem (pl.: egyszeri bevezetési díj).
5. Az ügyfelünk döntése a vásárlásról. Egy SaaS alkalmazás előnye, hogy a leendő ügyfelünk ki tudja azt próbálni úgy, hogy a mi oldalunkról ehhez semmilyen interakció sem szükséges. Így könnyebben tudunk döntéshozókat közvetlenül elérni. A leendő ügyfelek a próba időszak alatt közvetlen tapasztalatot szereznek az alkalmazásunkkal kapcsolatban, stb... Mindez viszont veszély is egyben, mert a SaaS aplikációnk így közvetlenül összehasonlíthatóvá válik a közvetlen és közvetett versenytársainkkal is.
6. Értékesítői bónusz. A bevétel lassabban épül fel, nincs azonnali, nagyobb mennyiségű bevétel, amely alapján az értékesítő kollegát jutalmazni lehet.  (egy 10 dolláros havi előfizetés értékesítése utáni 10%-os bónusz 1 dollár, amivel értékesítő nem motiválható). Néhány lehetőség ennek kezelésére:
   • Az éves teljes MRR után kapja a bónuszt.
   • Havi MRR után, havonta kap bónuszt.
   • Az eladott előfizetések tényleges használata után kap visszatérítést.
7. Partnerek. Ha partnerek is részt vesznek az értékteremtési láncunkban, a SaaS modell rájuk is hatással lesz:
   • Kisebb előfizetési díjból, kisebb részt is lehet megosztani a partnereinkkel, ami által nem lesznek motiváltak az új modell értékesítésére.
   • Ha a partnerünk üzletének fontos része a szoftverek bevezetése és az azokhoz tartozó támogató szolgáltatások, akkor többnyire nem lesz számára értékes a SaaS alkalmazásunk.
   • Rendszerintegrátorok sem mindig fogják szeretni, ha nem tudnak az integrációért pénzt kérni."

Következő részben az alábbi témákkal folytatjuk: az átlagos ár hatása, marketing, támogatás, szoftverfejlesztés...]]> https://docs.microsoft.com/archive/blogs/felho-tanacsado/lehetosegek-es-kihivasok-a-felhoben Fri, 09 Dec 2016 10:43:49 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=245 How SaaS Changes an ISV’s Business: A Guide for ISV Leaders, pont azt a témát járja körbe, ami ennek a blognak az egyik fő témája: ha egy szoftverfejlesztő cég (röviden csak ISV) belép a szoftver-mint-szolgáltatás (röviden csak SaaS) piacra, az hogyan változtatja meg az üzletét. Ebben a postban egy rövid kivonatot közlök a tanulmányból, amely a SaaS modell lehetőségeiről és kihívásairól szól. Az eredeti tanulmányért kattints a fenti linkre. "Egy tradicionális szoftverfejlesztő cégnek két fő motivációs tényezője lehet, ha be akar lépni a SaaS piacra:

• szeretné növelni a bevételeit,
• szeretné megvédeni a már kiépült üzletét SaaS versenytársaktól.

A cég vezetőinek, ha még nincs ilyen irányú tapasztalatuk, érdemes először megérteni, hogy mi is a a SaaS üzlet alapjai.

1. Előnyök az ügyfél oldaláról:
   • Mivel nincs helyi hardver igény, és a szoftvert sem kell telepíteni, ezért gyorsabban tudja használatba venni az alkalmazást.
   • A használat-alapú árazása miatt, az ügyfél csak azért fizet, amennyire ténylegesen szüksége van.
   • Kisebb induló költésége miatt alacsonyabb pénzügyi kockázattal tudja elkezdeni használni a SaaS megoldást.
   • Csökken, vagy teljesen megszűnnek a kezdeti költségek: nincs hardverberuházás, helyi IT bevezetési feladatai csökkennek, stb...
   • SaaS alkalmazást nem kell helyben frissíteni.
2. Kihívások az ügyfél oldaláról:
   • Meg kell bízni egy külső, SaaS szolgáltatóban.
   • Jogi, szabályozási kihívások. Bizonyos esetekben az ügyfél adatainak kezelése erős jogi szabályozás alá esik: nemzeti adatvagyon, egészségügyi adatok, ....
   • Limitált testre szabás. Legtöbb SaaS alkalmazás multi-tennant architektúrájú, vagyis egy alkalmazás szolgálja ki az összes ügyfelet. Ebben az esetben általában nem lehetséges az ügyfél egyéni kéréseit kiszolgálni.
   • Integráció meglévő alkalmazásokkal.
3. Előnyök az ISV oldaláról:
   • SaaS alkalmazással sokkal könnyebben érhetünk el új ügyfeleket: meglévő piacon több ügyfélhez juthatunk el, új piacra léphetünk be.
   • Közvetlenül tudunk üzleti döntéshozókhoz eljutni.
   • Sokkal precízebben előre jelezhető (havi ismétlődő) bevételre teszünk szert.
   • Csökkenhetnek a támogatás biztosítására szánt erőforrások, költségek.
   • Több információt kapunk a SaaS szoftver használatáról: melyik ügyfelünknél hányan, milyen rendszeresen, mely funkciókat használnak.
4. Kihívások az ISV oldaláról:
   • SaaS alapjaiban változtathatja meg az üzletünket. (erről fog szólni a következő post)
   • Leendő ügyfelek tipikusan még vásárlás előtt kipróbálják a termékünket, ezért a SaaS alkalmazást úgy kell felépíteni, hogy a próba időszak alatt az ügyfél egyértelműen megértse annak értékességét. (könnyen kezelhető; egyértelmű és hasznos funkciók; gyors működés; stb...)
   • Az árbevétel lassabban épül fel, összehasonlítva a hagyományos licenceléssel.
   • Sokkal kevesebb testre szabási lehetőség.
   • Új értékesítési kihívások: általában weboldalon keresztüli közvetlen értékesítés, konverzió, SEO, Adwords, Facebook, Linkedin, stb..."

A következő részben azt nézzük meg, hogy az üzletünket hogyan változtatja meg a SaaS modell.]]> https://docs.microsoft.com/archive/blogs/felho-tanacsado/8-ok-amiert-egy-szoftverfejleszto-cegnek-felhovel-is-kell-foglalkoznia Mon, 28 Nov 2016 11:10:45 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=235 Első szkenárió: Ha a szoftverfejlesztő cég saját alkalmazást fejleszt, vagyis érdemes azt megfontolnia, hogy belépjen a szoftver-mint-szolgáltatás (SaaS) piacra:

• meglévő termékének átírásával ("felhősítésével"),
• meglévő termék képességeinek kiterjesztésével a felhőbe,
• vagy egy új termékkel.

Mit jelent mindez a gyakorlatban? Az első és a harmadik esetben termékünket szoftver-mint-szolgáltatásként (SaaS) kínáljuk: ez lehet például egy weben keresztül elérhető, publikus felhőben futó alkalmazás, amiért a felhasználóink használat alapon fizetnek. A második esetben pedig a kliens alkalmazásunkat egészítjük ki felhő béli szolgáltatásokkal: pl.: Backup, PowerBi Embedded. Ezáltal több értéket tudunk teremteni ügyfeleinknél. Miért érdemes ezzel foglalkozni?

1. Mert szeretnénk növelni az üzletünket: a felhő piac egyre nagyobb és nagyon gyorsan nő:
   • az IDC előrejelzése szerint 2020-re el fogja érni az 500 milliárd dollárt. (forrás)
   • az IDC adatai alapján körülbelül 19,4%-ot nő évente. (forrás)
   • az IDC szerint a teljes felhő piacból a szoftver-mint-szolgáltatás (SaaS) piac 64,8%-ot hasít ki. (forrás)
2. Szeretnénk megvédeni az üzletünket:
   • számos piacra törnek be SaaS versenytársak. A publikus felhő szolgáltatóknak a világ szinte minden régiójában vannak adatközpontjai, amelyek lehetővé teszik, hogy egy helyi szoftverfejlesztő cég egy SaaS termékkel a világ minden pontján azonos minőségben tudja kiszolgálni az ügyfeleit.
   • az IDC szerint a cégeknél használt új szoftverek mindössze 10%-a lesz dobozos szoftver 2020-ban. (forrás)
3. A világ digitálisan transzformálódik és a felhasználói szokások pedig megváltoztak:
   • A felhasználók inkább szolgáltatásokat vásárolnak, nem alkalmazásokat.
   • Cégeken belül az IT projektek 81%-át üzleti döntéshozók befolyásolják, nem az IT.
   • 75%-a az ügyfeleknek közösségi médiából tájékozódik mielőtt vásárolna.
   • 57%-a a vásárlásoknak már azelőtt eldől, hogy értékesítővel találkoznának.

Második szkenárió: egyedi szoftverfejlesztési projekteken dolgozunk, amellyel egy cég üzleti igényeit elégítjük ki. Ebben az esetben érdemes elsőre olyan ajánlatot adni, ahol az elkészült alkalmazás publikus felhőben fut. Ebből David Chappell szerint az alábbi előnyeink származhatnak:

1. "Gyorsabb projekt leszállítást tesz lehetővé, amivel elégedettebb ügyfeleink lesznek."
2. "Nagyobb részt lehet kihasítani az ügyfél projektre szánt keretéből. Mivel nincs sem szoftver, sem hardver igénye az alkalmazásnak, ezért magasabb haszonkulccsal dolgozhatunk, az ott felszabaduló keret egy részéből."
3. "A Céges és felhasználó szokások változása miatt (előző rész 2.-3. pontja) több üzletet tudunk elhozni a hagyományos projekt ajánlattal operáló versenytársaink elől."
4. "Elősegíthetjük az ügyfeleinknél az innovációt. Mivel az ilyen típusú projekteknek sokkal kisebb induló költsége van, ezért kisebb kockázattal tudnak az ügyfeleink belevágni egy-egy újításba."

+ 1. A publikus felhőszolgáltató cégek partnerprogramjai általában különböző mértékű visszatérítésekkel díjazzák az ilyen projektek utáni felhő használatot.    ]]> https://docs.microsoft.com/archive/blogs/felho-tanacsado/bevezetes-a-szamitasi-felhobe Fri, 18 Nov 2016 11:49:56 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=225

használnak valamilyen felhő szolgáltatást, de fogalmuk sem volt róla, hogy az felhő,

a Dropbox és a Google Drive a felhő, (ezek felhő szolgáltatások, de nem a számítási felhő)

"Mi már használjuk a felhőt" = egy lokális szolgáltatónál bérlünk egy virtuális gépet. (a felhő sokkal több, mint virtuális gép bérlés)

Ahhoz, hogy egy szoftverfejlesztő cég teljes mértékben megértse, hogy számára milyen potenciál van a cloud technológiák használatában, szükséges, hogy megértse a számítási felhő alapjait is. A számítási felhőre (felhő, Cloud) vonatkozólag az Amerikai Szabványügyi Hivatalnak egzakt definíciója is létezik: "vagyis a felhő az a modell, amikor a számítástechnikai erőforrásokat (pl. számítógépeket, tárterületet, alkalmazást, szolgáltatást) az interneten keresztül vesszük igénybe. Ezeket olyan konfigurálható, osztott erőforrás-készletből tudjuk felhasználni, amelyek gyorsan provizionálhatóak minimális menedzsment erőforrás felhasználásával. A felhő modell emellett öt lényeges karakterisztikával is rendelkezik: [A post további része kivonat a kollégáim által írt Azure lépésről lépésre című könyv első fejezetéből, ezért külön nem tüntetek fel forrás megjelölést]

1. Igény szerinti, önkiszolgáló használat A fogyasztó egyoldalúan igénybe vehet számítási kapacitást, például gépidőt és hálózati tárterületet. Ez a folyamat a szolgáltató munkatársainak beavatkozása nélkül, automatikusan végrehajtható.
2. Online elérhetőség A számítási kapacitás hálózaton keresztül érhető el, szabványos hozzáférési mechanizmusok használatával, tetszőleges vékony és vastag kliensről (pl. mobiltelefon, táblagép, notebook, munkaállomás).
3. Nagy mennyiségű felhalmozott erőforrás A szolgáltató felhalmozott erőforrásai több ügyfelet szolgálnak ki több-bérlős modellben, a fizikai és virtuális erőforrások igény szerinti, dinamikus hozzárendelésével. A szolgáltatás helyfüggetlen abban az értelemben, hogy az ügyfél nem határozhatja meg, esetleg nem is ismeri a használt erőforrások pontos helyét, megszabhatja ugyanakkor magasabb szintű elhelyezkedésüket (például az országot, államot vagy adatközpontot). Példák a felhalmozott erőforrásokra: tárterület, feldolgozási képesség, memória, hálózati sávszélesség.
4. Gyors és rugalmas skálázhatóság A számítási kapacitás rugalmasan lefoglalható és felszabadítható, esetenként automatikusan is, hogy az igényeknek megfelelően gyorsan skálázódjon kifelé és befelé. Az ügyfelek számára az elérhető kapacitás gyakran végtelennek tűnik, és bármikor, bármekkora mennyiségben igénybe vehető.
5. Tervezhető és követhető költségek A felhő automatikusan ellenőrzi és optimalizálja az erőforrások felhasználását. Az egyes szolgáltatásoknak megfelelő jellemzők (pl. tárterület mérete, feldolgozási képesség, sávszélesség, aktív felhasználók száma) segítségével méri azok igénybevételét. Az erőforrások felhasználása követhető, vezérelhető és kimutatható mind a szolgáltató, mind pedig a szolgáltatás fogyasztója számára

A felhőben alapvetően három szolgáltatás modellt különböztetünk meg. (Ezek közti különbségek a későbbiekben fontosak lesznek számunkra)

1. Infrastruktúra-szolgáltatás (IaaS) A felhő legalsó szintje az ún. infrastruktúra-szolgáltatás (Infrastructure-as-a-Service, IaaS). Amikor infrastruktúra-szolgáltatást bérelsz, a felhőszolgáltató rendelkezésedre bocsátja informatikai infrastruktúrájának (hálózat, adattárolási lehetőség, virtuális gépek) egy részét, amin saját rendszereket, alkalmazásokat építhetsz ki és hosztolhatsz. Az infrastruktúra-szolgáltatás elsősorban a következő feladatok megoldását segíti:
   • Adatközpont kapacitásának bővítése. Ha akár ideiglenes, akár tartós jelleggel nagyobb informatikai kapacitásra van szükséged, mint amekkorát saját adatközpontod biztosítani tud, eszközbeszerzés helyett bérelhetsz virtuális gépeket, tárterületet és más szolgáltatásokat a felhőből, így kisebb és olcsóbb helyi környezetre lesz szükséged.
   • Üzleti alkalmazások kihelyezése. Ha egy üzleti alkalmazás esetében nem jelent stratégiai előnyt, hogy saját adatközpontodban futtatod, átviheted az alkalmazást és a hozzá szükséges egyéb szoftvereket futtató virtuális gépeket a felhőbe, így megtakaríthatod a helyi környezet költségeit.
   • Adattárolás. Ha tárterületre van szükséged archiválás, biztonsági mentések vagy más, akár ideiglenes adattárolási feladatok megoldásához, feltöltheted az adatokat a felhőbe, ezzel magasabb rendelkezésre állást érsz el, és csökkentheted a helyi környezet költségeit.
2. Platformszolgáltatás (PaaS) A felhő következő szintje az ún. platformszolgáltatás (Platform-as-a-Service, PaaS). Amikor platformszolgáltatást bérelsz, a felhőszolgáltató rendelkezésedre bocsát egy, a saját infrastruktúrája fölött működő platformot, amin alkalmazásokat telepíthetsz és üzemeltethetsz, illetve adatokat tárolhatsz és kezelhetsz. A platformszolgáltatás elsősorban a következő feladatok megoldását segíti:
   • Új felhőszolgáltatások kifejlesztése. A felhőplatform az online alkalmazások felhasználókhoz történő eljuttatásának új módja. Ha üzleti, társasági vagy egyéb, akár magáncélú alkalmazást fejlesztesz, aminek hosztolásához nem akarsz saját hardvert és szoftvert vásárolni, ugyanakkor biztosítani szeretnéd a széles körű elérhetőséget és a rugalmas skálázhatóságát, alkalmazásodat közzéteheted a felhőben.
   • Meglévő alkalmazások kiegészítése felhőben futó összetevővel. Ha egy, a vállalati adatközpontban futó alkalmazást egy front-end összetevővel, például webhellyel vagy webszolgáltatással szeretnél kiegészíteni, közzéteheted a front-endet a felhőben, és összekapcsolhatod a vállalati adatközponttal egy biztonságos szolgáltatásbusz vagy virtuális magánhálózat segítségével.
   • Adatbázisok a felhőben. Ha relációs adatbázisokat szeretnél online tárolni és elérhetővé tenni, használd a felhőplatform adatbázis-kezelő szolgáltatását! A felhőben közzétett adatbázis tartalmát szinkronizálhatod más felhő-adatbázisokkal, a vállalati kiszolgálókon lévő adatbázisokkal, és elérheted különböző mobileszközökről és személyi számítógépekről.
3. A felhő legfelső szintje az ún. szoftver-mint-szolgáltatás (Software-as-a-Service, SaaS). Ilyen a legtöbb fogyasztói online szolgáltatás: internetes keresők (Bing, Google Search, Yahoo), levelező és kommunikációs alkalmazások (Gmail, Outlook.com, Skype), médiamegosztó alkalmazások (Vimeo, YouTube) és közösségi hálózatok (Facebook, Twitter), illetve sok vállalati online szolgáltatás (Office 365, SalesForce.com). Saját, a platformszolgáltatás fölött létrehozott alkalmazásaidat általában szoftverszolgáltatásként teszed elérhetővé ügyfeleid, partnereid számára. A szoftverszolgáltatás esetében semmilyen üzemeltetési felelősséged nincs, az alkalmazásokat igény szerint beállítod, majd használod.

A felhő harmadik szempontú felosztása a bevezetési modellek szerinti csoportosítás:

1. Privát felhő A privát felhő egyetlen vállalat kizárólagos használatára létrehozott, felhő alapon működő informatikai környezet, amelyet több „fogyasztó” (tipikusan a vállalat szervezeti egységei, üzletágai) használ. A hangsúly a „kizárólagos használatára” kifejezésen van, a privát felhő tulajdonosa és kezelője lehet a vállalat, egy partner vagy ezek kombinációja. A privát felhő adatközpontja állhat a vállalat telephelyén, de bárhol máshol is. A vállalati adatközpontok a virtualizáció, a megfelelő módszertanra épülő, automatizált szolgáltatásfelügyelet, egy önkiszolgáló portál, valamint az erőforrás-használat mérése révén privát felhővé válhatnak.
2. Nyilvános felhő A nyilvános felhő a nyilvánosság (üzleti és magánfelhasználók) közös használatára létrehozott, felhő alapon működő informatikai környezet. Tulajdonosa és üzemeltetője (a felhőszolgáltató) lehet gazdasági vállalkozás, egyetem, kormányzati szerv vagy ezek kombinációja. A nyilvános felhő adatközpontjai a felhőszolgáltató telephelyein állnak.
3. Hibrid felhő A hibrid felhő a privát és nyilvános felhő együttes használatának eredménye. A két összetevő egymástól független marad, de a köztük lévő kapcsolat révén képesek az adatok és alkalmazások mozgatására, kiterjesztésére.

Az alábbi ábra jól szemlélteti a Microsoft, mint felhő szolgáltató és az ügyfelei (You) közti felelősség megosztást az egyes szolgáltatási modellek esetében (On Premises = saját szervere(i)den) :   ]]> https://docs.microsoft.com/archive/blogs/felho-tanacsado/prologus Thu, 17 Nov 2016 22:02:53 GMT https://blogs.msdn.microsoft.com/felho-tanacsado/?p=215 A digitális transzformációt érthetően leíró cikket itt találsz.]]>