Joitain aikoja sitten rupesin autossani kuuntelemaan työmatkoilla musiikkia ensisijaisesti USB-tikulta tai radiosta. Aikaisemmin olen käyttänyt pääosin Spotifyä mutta laitoin sen tilauksen pois. Omistan kohtalaisen paljon CD-levyjä ja rippailen ostamani levyt aina myös verkkolevylleni josta sitten voin kotona kuunnnella niitä eri laitteilla sekä tarpeen mukaan myös kopioida ne USB-tikulle autossa kuuntelemista varten.
Kopioin musiikit aina häviättömässä FLAC-formaatissa. Autosoittimeni (lue täältä) osaa toistaa kyseiset tiedostot ongelmitta USB-tikulta, mutta levyt vievät kohtalaisen paljon tilaa. Autossa kuunteluolosuhteet eivät ole taustamelusta johtuen optimaaliset joten autokäyttöön riittää varsin mainiosti myös MP3-pakattu musiikki.
Jotta FLAC-tiedostot saa MP3-muotoon pitää ne pakata jollain mp3-enkooderilla. Käytännössä LAME on de facto ainakin open source -maailmassa ja on sitä ollut niin kauan kuin muistan joten sen avulla onnistuu mp3-pakkaaminen.
Koodailin omaan käyttööni sopivan FLACista MP3-muuntajan joka toki käyttää erillisiä apuohjelmia muunnoksen tekemiseen, mutta kuitenkin omassa käytössäni tuo lisäarvoa siinä että se osaa rekursiivisesti rullata hakemistot läpi joita olen sen konfiguroinut käyttämään. Lisäksi skriptini pitää myös haluamani metadatat tallessa joten autosoitin osaa myös näyttää raidan nimen, artistin, albumin ja muut vastaavat tiedot.
Jo jonkin aikaa on ollut ajatuksena laittaa kotonani verkkoasioita paremmalle jamalle ja aina vähän kerrallaan näin olen tehnytkin.
Olen aikaisemmin hankkinut jo gigabittisiä Zyxelin switchejä olohuoneen puolelle ja myöskin jo kauan aikaa sitten olen hankkinut kotiini Jensen Omni Mesh -järjestelmän (lue täältä) joka on itselläni yhä käytössä. Molemmat ovat siis olleet peruskäytössä varsin toimivia ja tehneet sen mitä niiltä olen odottanutkin.
Verkossa olevien laitteiden kasvun myötä tarpeeni verkkojen konfigurointiin on kuitenkin laajentunut ja monipuolistunut jonka vuoksi tarvetta on ollut saada verkkoani hieman fiksummaksi konfiguroitavaksi.
Oma verkko IoT-laitteille ja käytännön haasteet
Käytännön tasolla ajatuksena on ollut tarve saada eristettyä kotona IoT-laitteet (mm. Robotti-imuri, Hue-valot, Sonos-kaiuttimet ja monet muut) kokonaan omaan verkkoon siten että niiden käytettävyys kotona ei kuitenkaan kärsi.
Syynä tälle päämäärälleni on tietoturva. Monet IoT-laitteet eivät ole kovinkaan tunnettuja hyvästä tietoturvastaan (ainakaan halvimmat idän ihmeet) jonka vuoksi on hyvä mikäli nämä laitteet saa pois pyörimästä samasta verkosta jossa kotini muut laitteet ovat ja ainoastaan sallia pääsy ja näkyvyys eksplisiittisesti tietyiltä laitteilta tiettyihin laitteisiin, ei kerralla jokaiselta vekottimelta kaikkiin muihin laitteisiin.
Ongelmahan olisi tietenkin helposti kierrettävissä siten että luo vain kaksi erillistä WLAN-verkkoa ja tunkee älylaitteet sinne, mutta tässä vaiheessa käytettävyyden ja käytännöllisyyden voi samantien unohtaa. Esimerkiksi jos haluan katsoa kännykälläni verkkolevylläni olevia valokuvia tai videoita pitäisi kännykkä aina vaihtaa verkosta toiseen.
Ubiquity Unifi 8 porttinen 60W PoE-kytkin
Kännykän tapauksessa tämän ehkä vielä jaksaisi sietää, mutta vaikkapa Apple TV:n ja verkkolevyn ollessa eri verkoissa ei enää käytettävyydestä voi puhua saman päivän aikana ja kummankin laitteen hyödyt jäisivät käyttämättä.
Tietoturvasta mainintana vielä sen verran että jopa FBI suosittelee älylaitteiden laittamista omaan verkkoon (lue uutinen aiheesta täältä ja toinen uutinen täältä) joten siitä voi jokainen päätellä itse kuinka hyvä idea on pitää kaikki verkon laitteet kotona samassa verkossa keskenään 🙂
Tekninen ratkaisu lyhyesti kuvaten
Tapa millä tätä käytännön haastetta lähdin ratkaisemaan oli luoda kaksi erillistä VLANia (ei siis WLAN vaan VLAN). Toiseen VLANiin menee kodin normaalit tietokoneet tai muut sellaiset (PC, mäkit ja verkkolevy) ja toiseen sitten kaikki muut.
Valitettavasti omistamani laitteet eivät ymmärtäneet VLANeista sen enempää kuin sika satelliitista (tai ainakaan niitä en päässyt konfiguroimaan tarpeeksi monipuolisesti omiin tarpeisiini) joten lompakon nyörejä joutui raottamaan useamman laitteen osalta.
Viimeisen parin kuukauden aikana kaupasta on tullut kannettua useampia Ubiquityn vekottimia joilla tätä asiaa pääsin laittamaan kuntoon. Ubiquity Security Gateway, Ubiquity Unifi 8 porttinen 60W PoE -kytkin sekä Ubiquity Cloud Key. Viimeinen näistä listan laitteista ei toki ole välttämätön, mutta elämääni helpottaakseni hankin sen samaan syssyyn viimeisimmällä käynnilläni Verkkokaupalla.
Karkea ja yksinkertaistettu kuvaus nykyisestä verkosta fyysisellä tasolla
Ubiquityn hallintapaneelista loin perusverkon lisäksi IoT-nimisen VLANin. Unifin ohjelmoitavassa switchissä pystyi sen jälkeen määrittämään porttikohtaisesti mihin VLANiin vekottimet menevät.
Koska Jensenin mesh-verkko menee fyysisesti kiinni tuohon switchiin pystyin määrittämään suoraan tuolle portille IoT-alueen. Käytännössä siis jokainen laite mikä nyt yhdistyy langattomasti Mesh-verkkooni päätyy IoT-alueelle ja saa sieltä sen mukaisen IP-osoitteen DHCP:llä – robotti-imuri, Sonoksen kaiuttimet, Hue-valot, TV, tabletit, kännykkä yms.
Tämän lisäksi myös Apple TV ja Pioneerin vahvistin menee fyysisesti kiinni tuohon switchiin joissa olen vain näihin portteihin myös määrittänyt että ne menevät IoT-alueelle.
Kun laitteet oli jaettu karkeasti eri VLANeihin täytyi vielä Unifin palomuurista käydä konfiguroimassa inter-VLAN routing pois käytöstä. Laitoin kaikki IoT-verkosta tulevat yhteydet varsinaiseen pääverkkooni suoraan droppiin jonka jälkeen erikseen kävin aukaisemassa tietyiltä laitteilta pääsyn VLANista toiseen ja niissäkin ainoastaan niihin laitteisiin joihin erikseen haluan.
Tähän mennessä ratkaisu on toiminut. Muutamat laitteet vielä odottaa konfiguroimistaan, mutta tästä hän hyvä jatkaa 🙂
Viime viikon puolella innostuin perehtymään kuinka Chromelle voidaan luoda omia extensioneita. Lisäosa jonka värkkäilin hakee aina Chromella uutta tyhjää välilehteä avatessa selaimeen uuden taustakuvan Wallhaven.cc sivustolta.
Toiminnallisuudeltaan tämä on varsin simppeli, mutta mielenkiintoinen harjoitus yhtä kaikki selaimen lisäosien luontiin. Lisäosa ei löydy mistään virallisesta lisäosamarketista vaan ainoastaan koodina, joten aivan perusjantterin käyttöön tätä ei ole suunntattu.
Eilen Helsingissä järjestettiin ensimmäinen Serverless Days -tapahtuma jonne itsekin menin kuuntelemaan ja katselemaan minkälaisesta tapahtumasta on kyse.
Koska kyseessä oli omaan alaani (eli aateekoo ja intternet) liittyvä tapahtuma on mahdollista että termi Serverless ei soita monelle tämän blogin lukijalle kelloja mistä on kyse. Lyhyesti ilmaisten termillä siis viitataan verkkopalveluiden tuottamiseen siten että itse tai muut välikädet eivät joudu hoitamaan palvelinten ylläpitoa vaan varsinainen palvelimen olemassaolokin pyritään poistamaan kuvioista ja sovelluksia ajetaan suoraan pilvipalveluissa siten että tarpeen mukaan pilvipalvelun tuottaja (esim. AWS, Azure tai Google Cloud) hoitaa koodareille näkymättömästi tämänkaltaiset prosessit.
Edellinen kappale ei varmasti sytyttänyt idean lamppua päässä palamaan epäselvän ilmaisunsa vuoksi, mutta otetaan esimerkki josko se selventäisi yhtään sen enempää.
Kun normaalisti vaikkapa jonkin verkkokaupan käyttäjä tulee nettisivulle ja saa näkyviin myynnissä olevat tuotteet on tämä perinteisesti hoidettu siten, että taustalla on koko ajan käynnissä palvelin josta nettisivun “frontend” (eli se käyttäjälle näkyvä osa) pyytää listaa tuotteista. Tällöin frontend lähettää kyselyn taustalla pyörivälle ns. backendille joka pyörii jossain palvelimella (joka karkeasti yleistäen ja tiivistäen ihmisten ymmärrettävästi on vain jokin tietokone jossain) ja se sitten saatuaan pyynnön etsii tietokannasta että mitäs tuotteita tuohon kategoriaan käyttäjälle pitäisi näyttää. Sen jälkeen se lähettää frontendille vastauksena listan näytettävistä tuotteista jonka jälkeen sitten frontend osaa tehdä käyttäjälle näkyviin oikeanlaiset tuotteet.
Serverless-ajattelun ideana on saada poistettua tuo “backend” nykyisessä muodossaan kuvioista pois kokonaan että ei olisi olemassa enää perinteistä palvelinta jossain pyörimässä turhaan. Käytännön tasolla tämä tapahtuu ns. event driven -ajattelumallilla toteuttamalla. Eli äskeisessä esimerkissä se tarkoittaisi sitä, että vasta siinä vaiheessa kun frontend lähettää pyynnön backendille pitäisi joku saada sinne vastaamaankin jotain jotta pyynnön esittäjä saa haluamansa tulokset että tietää mitä sivulle pitää näyttää.
Isot pilvipalvelut – ainakin AWS sekä Azure – tarjoavat tähän ns. Lambda-funktioita joita triggeröidään vasta kun jotakin tapahtuu. Eli koko aikaa ei ole palvelin taustalla pyörimässä turhan päiten, vaan vasta siinä vaiheessa kun käyttäjältä tulee pyyntö saada lista noista verkkokaupan tuotteista herättää nämä pilvipalvelut koodareiden tekemät funktiot jotka tekevät halutut asiat.
Jos tämän miettisi reaalimaailman asiana vastaisi se samaa kuin talossa ei olisi lainkaan puhelinasiakaspalvelua, mutta heti kun puhelin soi olisi maagisesti oikeita ihmisiä heti vastaamassa puhelimeen ja kun puhelu on ohi katoaisi hän samantien eikä olisi koko aikaa paikan päällä päivystämässä josko sinne sattuisi puhelu tulemaan.
Tapahtuma
Varsinainen tapahtumapäivä oli mielenkiintoinen ja puhujia oli useita erilaisia. Ensimmäisenä puheena kuulimme Lego-kaupan uudelleen toteuttamisesta serverless-arkkitehtuuria hyödyntäen. Seuraavana puheena kuulimme chaos engineeringistä ja kuinka toteuttaa tällaisia serverless -arkkitehtuurilla tehdyissä sovelluksissa. Seuraava puhe käsitteli erilaisten palveluiden integraatioista ja kuinka tämänkaltaisia haasteita on taklattu serverless-sovelluksilla ja ennen lounasta kuulimme vielä puheen kuinka Google Cloud -palvelun koneoppimisen rajapintoja hyödyntäen voi tehdä erilaisia tutkimuksia esimerkiksi fake news -sivustoista verrattuna ns. vakavammin otettaviin uutissivuihin.
Lounaan jälkeen sitten oli puheita virheenkäsittelystä, suunnittelun patterneista ja anti-pattereista sekä todellisen elämän esimerkki kuinka chatbot oli toteutettu Azuren funktioilla.
Kahvitauon jälkeen puheina kuultiin SLA:sta ja kuinka sen mittaaminen serverless-aikakaudella on sinänsä hankalaa ja merkityksetöntä, seuraava puhe kertoi kuinka finanssiraporttejen käsittelyä oli toteutettu AWS:n lambdoissa ja viimeisenä puheena vielä kuulimme CI/CD aiheesta kuinka serverlessillä voi toteuttaa esimerkiksi erilaisia deploymettejä turvallisesti.
Lopussa vielä oli paneelikeskustelu jossa käsiteltiin mm. kannattaako serverless-maailmaan hypätä ja luoda sitä kautta vendor-lockia ja muita yleisiä kiintoisia aiheita.
Kokonaisuutena päivä oli varsin mielekiintoinen ja oli mukava päästä käymään. Toivon mukaan näitä tapahtumia tulisi useamminkin myös Helsinkiin ja toivottavasti myös serverlessiä pääseemme pian toteuttamaan laajamittaisemminkin. Uskon että suurimmat haasteet tällä hetkellä sen yleistymiselle on business-näkökulmat (totuttu vanhoihin toimiviin tapoihin) sekä tietenkin tekniset aspektit joka aiheuttaa oman mielentilan muutosta ohjelmoinnissa ja ilmenevien ongelmien ratkaisuissa.
Alkuviikko meni vaihteen vuoksi kouluttautumisen merkeissä kun olin maanantaista keskiviikkoon AWS-koulutuksessa. Mikäli AWS ei ole entuudestaan tuttu on kyseessä siis Amazonin pilvipalvelualusta jonka päällä moni internetissä pyörivistä suurista ja pienistäkin verkkopalveluista toimii.
Aiheina koulutuksessa oli mm. vikasietoisten ja tehokkaiden verkkoinfrastruktuurien rakentamista AWS:ään, Serverless arkkitehtuuri sekä tietoturva ja työkalut joita AWS tarjoaa tämänkaltaisten haasteiden ratkaisuun. Lisäksi myös oli puhetta kuinka infrastruktuuria rakennetaan koodilla ja sen eduista.
Koulutus oli mielenkiintoinen ja toki moni asia oli entuudestaan jo tuttua käytännön tasolta, mutta mielenkiintoista oli silti päästä käymään koulutuksessa ja saada kertausta sekä uuttakin tietoa. AWS:n ja muiden pilvipalvelualustoiden kehitys on todella nopeaa ja uusia palveluita niihin tulee kovalla tahdilla lisää joten jatkuva oman osaamisen kehittämisen tarve IT-alalla ei luultavasti tule jatkossakaan osoittamaan vähenemisen merkkejä.
