Globális hódításra kész a Fujitsu felhője (x)

Címkék

Az OpenStack-alapú K5 infrastruktúra- és platformszolgáltatásokat is kínál, nyilvános és privát felhőben egyaránt. A cég most kezdte el a globális bevezetést, Magyarországon várhatóan 2017-ben lesz elérhető.

Kezd kézzel foghatóan beérni az a stratégia, amit a Fujitsu évekkel ezelőtt vázolt fel a müncheni Fujitsu Forumon – a cég akkor jelentette be, hogy teljes erővel egy felhős ökoszisztéma létrehozásába fog. A K5 nyilvánosfelhőszolgáltatásról először tavaly év elején lehetett hallani, amikor a Fujitsu közölte, hogy a Fujitsu Groupon belül integy 640 rendszert és 13 ezer szervert költöztet át OpenStack-alapú felhőjébe (ezzel mintegy 300 millió dolláros megtakarítást elérve), a kereskedelmi változatot pedig 2015 őszén először a hazai piacán, Japánban indítja el.

A cég már akkor is az OpenStack ismert előnyeit domborította ki: a beszállítófüggőség (vendor lock-in) kockázatának jelentős csökkentését, a nyílt forrású alapokat, a széles körű interoperabilitást más publikus felhőkkel és egyéb széles körben használt vállalati IT (hálózat, tároló stb.) megoldásokkal, a kimerítő automatizációs lehetőségeket, az API-alapú menedzselhetőséget, a skálázhatóságot, a teljes bekerülési költség hosszabb távon jelentős csökkenését és a rugalmasság költözési lehetőséget a publikus és privát felhő között. A K5 fontos része a fél éve bevezetett MetaArc integrációs rétegnek, de utóbbi nem szükséges a K5 igénybe vételéhez.

A Fujitsu is az OpenStackre fogad

Egyáltalán nem meglepő, hogy a japán vállalat is az OpenStacket választotta felhőszolgáltatása alapjául. A cégnél kiemelt szempont volt, hogy a könnyű bővíthetőség, testreszabhatóság és integrációs lehetőségek miatt a K5 nyílt szabványokkal üzemeljen, így a Fujitsu már régóta jelentős hozzájárulója az OpenStack-projektnek. Az elmúlt másfél évben a hatodik helyre tornázta fel magát a hozzájárulók listáján, a következő egy-két évben pedig a harmadik hely a cél – így amellett, hogy a Fujitsu sokat is ad vissza a közösbe, aktív szerepvállalását is demonstrálja a platform fejlesztésében és jövőbiztossá tételében.

Ahogy említettük, a K5 teljes átjárást kínál az erre épülő (a Fujitsu adatközpontjaiban üzemeltetett) nyilvános és a privát (az ügyfél adatközpontjában telepített) felhő között. Így könnyen lehet létrehozni akár hibrid környezetet is, vagy például fejlesztési-tesztelési célokra használni a nyilvános felhőt, majd az éles üzemet (akár adatvédelmi, akár üzemeltetési szempontok miatt) a privát adatközpontba átemelni. A Fujitsu egyébként a PRIMEFLEX termékcsaládban kulcsrakész privát felhős appliance-et is kínál, melynek révén jelentősen lerövidíthető a beüzemelési idő, továbbá az is biztos, hogy a "vas" és a szoftver minden tekintetben passzol egymáshoz.

Ugyan a Fujitsu hivatalosan elindította a K5 globális piaci bevezetését, a folyamat – ahogy az ilyen típusú szolgáltatások esetében az lenni szokott – viszonylag hosszú idő alatt fog lezajlani. Japánon kívül idén három országban tervezi elindítani a cég a K5-öt (elsőként júliusban az Egyesült Királyságban, majd októberben Finnországban és novemberben Németországban). A további terjeszkedés 2017-re csúszik Spanyolországgal kezdődően, majd az Egyesült Államok, Ausztrália és Szingapúr is bekerül a körbe – a magyar élesítés szintén jövőre várható.

(A Fujitsu Technology Solutions Kft. megbízásából készített anyag.)

Hozzászólások

Nagyon nem vagyok kepben az ilyen felhos hostingokkal, de mar regota erdekel a tema, foleg Spring Boot vonatkozasban. Uzemeltetes teren nem sok tapasztalatom van, szoval fejlesztoi szemszogbol nem vilagos par dolog.

Van valami tomor osszefoglalo ezekrol a dolgokrol? Mi a minimum config, mi kell elosztott rendszerekhez, mi kell akkor, ha microservicekben gondolkodik az ember, stb. Gyakorlatilag egy System Architecture for Dummies, ahogy elnezem :)

Bár nem vagyok teljesen tisztában a Fujitsu megoldásának részleteivel, de abból kiindulva, hogy OpenStackből építkeznek, valószínűleg a fő hangsúly az IaaS-on van náluk. A te kérdésedből viszont az jön le (alkalmazási rétegbeli spring boot, microservice-ek, stb.), hogy te PaaS-megoldásokkal kapcsolatban érdeklődsz.

Ha az alapfogalmak tisztázása a cél, a Wikipedia Cloud Computing lapja jó kiindulás. Ha ezen belül a scalability természete érdekel, ez a könyv nagyon jól összefoglalja és szakkönyvhöz képest egész "olvasmányos". Minden e réteg fölötti dolog pedig már alkalmazás/framework/programnyelv specifikus.

Megrendelve, koszi :)

Amugy rajottem, hogy a puding probaja az eves, szoval regeltem egy AWS accountot, addigis tudok vele jatszani.

Szerk: amugy IaaS es PaaS is erdekel, nagy vonalakban ismerem is oket, csak jo lenne picit jobban belelatni. Foleg hogy mindenki Devops fele mozdul mostansag.

A hangsúly tőled teljesen független. Az utóbbi időben hála a klódnak meg a scalabilitynek, az üzemeltetéssel kapcsolatos feladatok egy része már programozói munkát igényel (devops). Ehhez az igényhez pedig nincs elegendő utánpótlás még, a piacon nem jelenik meg annyi munkaerő amennyi a két világ ellátásához szükséges. Ez nagyon jó, mert a fizetéseink az egekben vannak, de amit végül látunk az az, hogy mindkét oldalon az emberek 90%-a csak tákol valamit, ami pont átviszi a minimummal szemben állított követelményeket.

Jó korba születtünk, na.

Jajj, ne is mondd. Engem is probalnak belerancigalni ebbe az oruletbe, de annyira nem tetszik. En ugy gondolom, hogy egy fejlesztonek az environment tokeletesen transzparensnek kell lennie, egy paranccsal tudjon valtani koztuk. Vagy pedig legyen belevonva az uzemeltetesbe, de akkor legyen meg az ido/elszantsag a rendes toolingra. A takolas az nagyon nem jo semmilyen oldalrol se, es koszi a konyv ajanlot, megjott, es tenyleg jonak tunik. Engem pl. erdekel ez az aspektus is, nem mintha devopsot akarnam kozeliteni, de ha rendes fejlesztoi kornyezetet akarok magamnak, akkor azert neha bele kell maszni a melyebb dolgokba is :)

Az eredeti kérdésre a válasz, hogy mi kell egy felhős alkalmazáshoz, tömören itt érhető el: http://12factor.net/

A devops dologgal az a baj, ami minden más multifunkciós dologgal is: Aki/ami kicsit mindent tud, az inkább semmit sem tud igazán. Ha nem egy kisvállalaban dolgozik az ember, akkor hosszú távon jobb, ha van egy külön operátor (ops) és fejlesztő csapat (devs). A fejlesztők sok esetben úgy érzik, hogy maguk is képesek ellátni az üzemetetés feladatait, de fejlesztés helyett két-három napnyi guglizás, copy-paste és kézikönyv olvasgatás után általában, kiderül, hogy miért van erre külön ember.

A devopsnak az én olvasatomban nem az a lényege, hogy az ops és a dev csapatot egy emberben gyúrják össze. Sőt. Az inkább a buta megvalósítás.

A devopsnak az lenne a lényege, hogy az operátori feladatokat nem a józsi heggesztéseivel látjuk el, hanem fejlesztői szemlélettel és módszerekkel, reprodukálható módon, teszt/staging stratégiával, stb. Tehát a dev az én részemről nem a termék fejlesztőjére értendő, hanem a _módszerre_ amivel az ops megvalósul.

"fejlesztői szemlélettel és módszerekkel" - sok helyen a fejlesztői szemlélet az hogy ész nélkül adjál alá több resource-t, jó az SSLv3 még mert neki úgy működik (tegyél elé valamit), security meg minek úgy általában. A módszer meg az hogy fejlesztés helyett tákolnak, és a tákolt kód tesztelésére is sajnálják az időt. Jobb az ha külön kézben van Dev és Ops, dolgozzanak össze de a fejlesztés és az üzemeltetés két nagyon külön dolog.

Amikor évekig nem tudsz platformot váltani mert a fejlesztő lusta fél napot szánni arra hogy megszúrja a kódot ahol kell... "jóvanaz, működik nem?". Tisztelet a kivételnek, és no flame.

Mondjuk, az idő úgyis eldönti mi lesz a DevOps mozgalomból :-)

____________________
echo crash > /dev/kmem