ugrás a tartalomhoz

Jó-e és ha igen, akkor milyen mértékű legyen a kiszervezés?

Max Logan · 2010. Nov. 23. (K), 14.26

Az utóbbi években sok olyan szolgáltatás jelent meg, melynek használata webes megoldások esetén sok gondot levesz az ember válláról. De éppen ezen szolgáltatások használata az, ami alkalom adtán fejtörést okozhat.

Olyan dolgokra gondolok, mint például a képek Flickrön való tárolása, majd a saját webes megoldásunkban onnan való hivatkozása, ugyanez videók esetén a YouTube-nál megoldva stb. Sok ilyen példát lehetne hozni.

Ezen megoldások egyik hátrányát abban látom (a nyílvánvaló előny mellett), hogy minél több ilyen külső függésre tesz szert site-unk, annál kisebb a kontroll, annál jobban ki vagyunk téve a külső szolgáltatás szeszélyeinek (pl. lassú elérés), valamint az üzemeltető cégnek.

Ha a webhelyünk hobbi megoldás (pl. egy személyes blog), akkor nem olyan nagy gond, ha mondjuk nem elérhető vagy lassú a Flickr szerver. De ha éppen egy olyan profitorientált honlapot üzemeltetünk, mely erősen támaszkodik például a Google Mapsre (mert térkép alapú megoldásról beszélünk), akkor ott már nem kis fejfájást, okozhat egy kis üzemzavar, vagy éppen a Google részéről egy érdekes döntés az API-t illetően.

Persze lehet erre mondani az említett példánál maradva, hogy a Google az a Google, de ettől még lehet elérhetetlen, vagy éppen lassú a szolgáltatásuk. Mivel ingyenes megoldásról van szó, esélyünk sincsen az esetleges reklamációnknak jogalapot találni.

 
1

Szerintem minél idő- és

szappantarto · 2010. Nov. 23. (K), 15.10
Szerintem minél idő- és erőforrásigényesebb egy szolgáltatás önálló működtetése, annál inkább van értelme kiszervezni. Mert azért van különbség két üzleti honlap között is. Az igény a videók beszúrására és a térképekre már a kisebb vállalkozásoknál is fölmerül, de önállóan videót streamelni meg térképrendszert futtatni nem biztos hogy szeretnének ezért.
A másik elv meg nyilván az, hogy minél nagyobb mértékben támaszkodik a webes megoldásunk egy szolgáltatásra, annál kockázatosabb kiszervezni.
Aztán ott van még a biztonság kérdése is: minél szélesebb felhasználói körnek adjuk meg pl. a képfeltöltés lehetőségét /akár ideiglenesen is/, annál érdemesebb az ilyen képkezelést külső forrásra hárítani szerintem.

Egyébként egyre többször futok bele olyanba is, hogy teljesen feleslegesen alkalmazzák ezeket a szolgáltatásokat az üzleti honlapok. Külön bosszantó, amikor csak azért nő a betöltési idő a duplájára, mert arra várunk, hogy betöltsön az "itt van a cégünk!" feliratú google map, ami lehetne mondjuk egy kép is, ami alá behivatkozzuk a google térképet.
2

Videó, email

Poetro · 2010. Nov. 23. (K), 15.40
Szerintem nem érdemes Flickr vagy YouTube ilyen használata. Vannak ennél sokkal jobb szolgáltatók, akik megcsinálják neked a képek, videók átkonvertálását, tárolását. Csak megfelelő API-kat kell használni. Hasonló a helyzet például az email szolgáltatásokkal, amikkel a hírleveleket, feliratkozásokat, regisztrációkat érdemes kezelni. Jóval kényelmesebb, mint még egy komolyabb infrastruktúrát fenntartani a célra, és még az esetek nagy részében költséghatékonyabb is. És persze itt nem ingyenes szolgáltatásokra gondolok, mert azokkal általában csak a baj van, és nincs is semmilyen garancia arra nézve, hogy ha kiesik a szolgáltatás akkor hogyan kompenzálnak (leginkább sehogy). Egy fizetett szolgáltatás esetében ugyanakkor fogunk kapni valamilyen garanciát a szolgáltatásról.

Ez persze ezen igények mértékétől is függ, hogy mennyire éri meg kiszervezni valamelyik szolgáltatást. Ha csak kicsiben csináljuk, akkor nem igazán éri meg kiszervezni szerintem ezeket, mivel a saját dedikált szerverünk valószínűleg a töredékéért meg tudja oldani, habár ilyenkor a karbantartás feladata ránk hárul.
3

Presztizs kérdés

janoszen · 2010. Nov. 23. (K), 22.23
Én mindig azt a kérdést szoktam föltenni a kiszervezés fanboyoknak, hogy ha lehal, az mennyibe kerül? Mindenki azt mondja, hogy ó, azok nagyok, azok nem halnak le. A gyakorlat sajnos azt mutatja, hogy de. Tipikus problémák:

  • A szolgáltató valamiért ÁSZF sértőnek néz Téged, ezért bannolja az accountodat. A folyamat automatikus, apelláta pedig nincs. IJB, és a B az nem a Barátom.
  • A szolgáltatónak kiszolgálási problémái vannak. A redundancia nagyon, NAGYON sok pénzbe kerül. Ha egy ritkán látogatott képről van mondjuk szó, akkor az nem lesz szét replikálva a CDN-en, mert a terhelés nem indokolja. Ergó simán lehet, hogy az a része a szerverparknak megy karbantartásra, a kép meg nem lesz elérhető.
  • Nemzetközi sávszélesség! A szolgáltatók nagy része nincs fönt a BIX-en (európai szolgáltatók között azért akad, pl. a Holland LeaseWeb is itt van). Ez azt jelenti, hogy ha a látogató netszolgáltatójának a nemzetközi vonala szarakszik, akkor bizony nem fogja látni a képet.
  • Amerikai kiszolgálás. Egy csomó szolgáltató nem Európában hostol, ergó MINDEN lekérdezésre rájön az a laza 100-200 ms-es ping, amit az óceán alatti kábel okoz. Ez 10 képnél, akármilyen kicsik is, már nettó plusz egy-két másodperc.


Ennek fényében tessék mindenkinek eldönteni, hogy megéri-e. További ellenérvek:

  • Ha úgy döntenek, hogy változtatnak, így jártál. Esélyed sincs azt mondani, hogy Te másképp akarod.
  • Ha nem fizetsz érte, nem reklamálhatsz.
  • Ha fizetsz érte sem biztos, hogy reklamálhatsz.
  • A külső szolgáltató hozzá fog férni a (látogatottsági) adataidhoz. Az információ pénz és hatalom. (Olvasd el alaposan a szerződési feltételeket.)


Mellette szól viszont:

  • Ha one-man-show businesst csinálsz, akkor valszeg esélytelen vagy megközelítőleg is hasonlót építeni.
  • Ha nem tudsz hasonló minőséget nyújtani, akkor a Tied gagyinak fog tűnni.


Ergó tanácsként azt mondanám: Ha nincsenek érzékeny adataid, indíts külső szolgáltatóval, legyen backupod a cuccokról és másik szolgáltató, akire át tudsz állni, ha para van. Ha lehet, akkor fizess elő, még akkor is, ha nem használod ki. Amikor eléred azt a szinted, hogy az igényeid, információid megérnek annyi pénzt, fizess meg egy vagy több szakembert (nem Webszerver Üzemeltető Weboldakészítő Egyszemélyes István Bt-t), aki megépíti Neked a rendszeredet. Ez nem lesz olcsó és nem lesz gyors.
4

Kis szőrszálhasogatás

inf · 2010. Nov. 24. (Sze), 00.33
Kis szőrszálhasogatás :-)
laza 100-200 ms-es ping, amit az óceán alatti kábel okoz.

Általában 200 vagy afeletti a ping usa-ba, ritkán 170-180, de nekem még nem sikerült 100 körüli szervert találnom, legalábbis abban a játékban, amivel régen toltam.


Maga a téma szerintem érdekes, meg az ellenérvek is. Nem gondoltam, hogy ilyen sok van belőlük...
5

Szőrszálak

janoszen · 2010. Nov. 24. (Sze), 01.32
OK, legközelebb nem a cégtől mérek. :) Egyébként igazad van, pocsék az óceán alatti vonal.
6

Jaja, USA-Európa válogatott

inf · 2010. Nov. 24. (Sze), 01.43
Jaja, USA-Európa válogatott mérkőzést is valami köztes szerveren csinálták, ahol mindkét félnek 100-as pingje volt. Usa még nem durva, ha profi vagy, akkor közepes szintű játékosok ellen játszható, Japán az igazán durva, arra 400as pingek vannak...
Tök érdekes, hogy a tizedmásodpercek mennyire számítanak ezekben a játékokban, és normálisan mennyire nem...
Yepp, ezek a távolsági vonalak minőségre sem a legjobbak, sok a lag meg a packetloss, bár ez weblapoknál annyira talán nem zavaró...
7

Zavaró

janoszen · 2010. Nov. 24. (Sze), 08.32
Japán... Szingapurban láttam árajánlatot sávszélre, valami háromszorosa volt az európainak.

Egyébként weboldalnál akkor zavaró, ha sok a statikus elem vagy mondjuk videót szolgálsz ki.
8

nem (csak) a kabel miatt van,

Tyrael · 2010. Nov. 24. (Sze), 11.58
nem (csak) az interkontinentalis kabel miatt van, sot igazabol valoszinunek tartom, hogy ott a leggyorsabb, mivel ott egyreszt tenyleg "legvonalban" halad, masreszt ott a leheto legkevesebb koztes eszkoz, elagazas, etc. van beepitve, a legnagyobb problema, hogy egyszeruen a feny ilyen lassu:
http://en.wikipedia.org/wiki/Latency_(engineering)#Packet-switched_networks
Latency is largely a function of the speed of light, which is defined to be 299,792,458 meters/second in a vacuum. This would equate to a latency of 3.33 microseconds for every kilometer of path length. Because the index of refraction of most fiber optic cables is about 1.5, light travels about 1.5 times as fast in a vacuum as it does in the cable. This works out to about 4.9 microseconds of latency for every kilometer. In shorter metro networks, the latency performance rises a bit more due to building risers and cross-connects and can bring the latency as high as 5 microseconds per kilometer. It follows that to calculate latency of a connection, one has to know the distance traveled by the fiber, which is rarely a straight line, since it has to traverse geographic contours and obstacles, such as roads and railway tracks, as well as other rights-of-way. Due to imperfections in the fiber, light degrades as it is transmitted through it. For distances of greater than 100 kilometers, either amplifiers or regenerators need to be deployed.

http://www.akamai.com/html/technology/dataviz2.html

europabol keleti part (Becs - Boston) idealis routeolassal 105ms, a "normal" utvonalat kovetve 156ms.
ugyanez Los Angeles fele (nyugati part 158ms vs 185ms)

btw. nem a counter strike a legjobb eszkoz a halozati latency meresere. :)

Tyrael
9

btw. nem a counter strike a

inf · 2010. Nov. 24. (Sze), 20.46
btw. nem a counter strike a legjobb eszkoz a halozati latency meresere. :)

:D :D :D