@Milfaus
Myslíš, že velkým hráčům stávající situace vyhovuje? Jasně, Google si rád platí za svoje servery a konektivitu, i když by data mohla téct napřímo.
Myslim, ze jim situace vyhovuje hlavne proto, ze se muzou tema datama prohrabavat. Jejich zisk z toho je mnohem vyssi nez je stoji provoz serveru, jinak by to nedelali....
Dělal jsem vývoj embedded SW u jedné zahraniční firmy. Měli jsme fungující produkt, ke kterýmu se marketing rozhodl přidat možnost ovládání z mobilu a dálkovýho upgrade software. Jinak řečeno, IP konektivitu a sdílení cca 2kB dat mezi krabičkou a mobilem. Dovol několik postřehů:
1) Při přípravě projektu se ukázalo, že s přímým spojením (IPv6) se nedá počítat a musíme jít do IPv4 s tunelováním NATu. Takže vlastní servery. Cenová kalkulace ukázala, že protunelování NATu při uvažované výrobě a životnosti výrobku vychází na jeho 30% ceny a alternativou je jenom měsíční výpalný, který by se zákazníkovi nelíbilo a šel by ke konkurenci. Pokud by konkurence fungovala napřímo na šestce, jde o třetinu dolů s prodejní cenou.
2) Ukázalo se, že otevřít NAT na různých SOHO krabičkách znamená ping do 10s, zvedlo to spotřebu zařízení o cca 45% proti stavu, kdy by jenom poslouchalo na portu. Dost blbě to vypadalo v dokumentaci, když u sebe byla online a offline verze. Muselo se to hodit aspoň tři stránky od sebe, aby to nebylo tak nápadný.
3) Nemůžeš přestat komunikovat ani ve chvíli, kdy je appka na mobilu vypnutá. Po zapnutí by se nemohla dostat k aktuálním datům.
4) Servery. Nadupaný dělo vydrželo prototypku a start výroby. Po půl roce dva load balancery, pět front end serverů a vlastní vlákno do racku z nixu. Jenom na to, aby papouškovaly co 10s zařízením, že uživatel na mobilu nic nezměnil.
5) V původním zařízení se ve 3:15 provedl self test a aktualizace. V reálu to bylo mezi 3:10 a 3:20. Po překročení kritickýho množství zařízení ve fieldu si DDOSly server a vyskákaly na nich hlášky o chybě, že mají uživatelé volat servis. Ono kritický množství bylo kolem 55k zařízení. Servisáci to naházeli na technockou podporu, technická podpora sbírala lejna do 200l sudů a pak to hodila na nás. Nic moc příjemný.
6) Marketing podepsal kontrakt na prodej 120k zařízení ročně po dobu pěti let. S tím, že ve smlouvě byla reakce na změnu nastavení na mobilu do 5s. (= ping na C&C po 2s). Manažer, co měl na starosti online background, týden mluvil jak J když chce sbalit Kate. Pak se trochu uklidnil, nechal se slyšet, že tohle si zaslouží řešit za trest chuji v Redmondu, nechal to migrovat do Ažůru a zdrhl...
A přitom by stačilo, kdyby s krabička s mobilem viděly napřímo. Něco se změní na zařízení, pošle to na mobil (třeba jenom 5x denně). Uživatel změní nastavení na mobilu, appka se přihláší na zařízení a updatuje to. Na serverech zůstane 1x týdně na žádost krabičky informovat o nové verzi SW a řešit pořadník stahování + párování telefonů a krabiček podle uživatele při instalaci. Ani ten noční peak by nebyl problém, prostě by tam nebylo úzký hrdlo na jedné lince, 90% trafficu by odpadlo (neběží appka v mobilu), 9% by bylo lokálně z obýváku do ložnice (a tam se 2kB po WiFi do mobilu ztratí), 1% by holt bylo na ISP a mobilech. Server 0%.
Tož asi tak... Příklad s IP kamerama a nezabezpečený služby pro přístup k nim snad ani není třeba komentovat.
192 Odpovědí
24857 Zhlédnutí