Spring Framework may be one of the most widely adopted libraries in the Java world.
It came to be so widely adopted because of its open source license and consistent quality.
Its authors decided to monetize the wide adoption, and formed SpringSource to sell support.
Now they are pulling a bait and switch to maximize their short term profit, by selling licenses on top of support, because license business scales better than support business.
SpringSource are significantly altering the factors which led to Spring Framework's popularity, by making the previously simple process required to use Spring Framework so complicated, with marked unknowns, that the SMB/consultant sector, which comprises 90% of its user and technology decisionmaker base, has to in effect make a whole new purchase decision in a product landscape which has the technology giant Google offering Guice, and EJB 3.1 getting nearly on par on technological usability.
The question is: is Spring Framework worth it anymore to anyone, if its user base shrinks to 10%, and is unlikely to raise back to preceding levels?
Edit: apparently the new pricing starts from $20,000 for a small team.
2008-09-15
New cloud datacenter products: VMWare vCloud, Citrix Cloud Center and Sun xVM OpsCenter
VMWare released their vAporWare vCloud announcement at VMWorld08.
Citrix released Citrix Cloud Center.
Sun released xVM OpsCenter and the rest of the xVM product line.
Of the three, the Sun products seem the closest to becoming actual reality.
Here's to both competition and standards!
Citrix released Citrix Cloud Center.
Sun released xVM OpsCenter and the rest of the xVM product line.
Of the three, the Sun products seem the closest to becoming actual reality.
Here's to both competition and standards!
2008-09-14
Skaalautuva palveluarkkitehtuuri joka keittiöstä löytyvillä aineksilla
Hei, sinä joka rakennat juuri verkkopalvelua! Kyllä, juuri sinä.
Teetkö suunnitelmia siitä lähtökohdasta, että tulet onnistumaan työssäsi, vai oletatko epäonnistuvasi?
Jos verkkopalvelusi onnistuu, kuinka paljon sillä tulee olemaan käyttäjiä? Kuinka monta pyyntöä sekunnissa se saa palvella?
Juuri nyt, ennenkuin palvelullasi on vielä sitä ensimmäistäkään käyttäjää, on paras aika istua alas ja ajatella mitä onnistuminen tarkoittaa.
Jos rakennat verkkopalvelua, suunnittelet varmaankin käyttäväsi työkaluina PHP:ta, Pythonia, Javaa tai dotnettiä, ja tallettavasi palvelun tiedot MySQL:n, Postgresiin tai MSSQL:n.
Olet tottunut toimimaan niin, että ensin suunnittelet relaatiokannan, sitten rakennat sitä käyttävän saitin, ja iteroit asiakastarpeiden ja uusien ajatusten pohjalta. Jos sinulla on jo jonkin verran kokemusta, suunnittelet rakentavasi kolmitasoarkkitehtuurin ja käyttäväsi MVC-kehystä, sen sijaan että kaikki koodi on samoissa PHP-tiedostoissa.
Nämä suunnitelmat auttavat sinua onnistumaan. Se on hienoa!
Ne eivät auta sinua kohtaamaan onnistumisen aiheuttamia ongelmia. Se on huonoa!
Onnistuminen ja epäonnistuminen ovat luonteeltaan erilaisia. Jos onnistut, peli ei lopukaan, vaan sinulta odotetaan vielä lisää onnistumisia. On paljon katkerampaa väsyä toisessa mäessä, kun ensimmäinen on jo ylitetty.
Kehitys ei pysähdy koskaan, mutta verkkopalveluiden kohdalla voit ottaa suurten toimijoiden onnistumisista ja epäonnistumisista mallia, ja suunnitella järjestelmäarkkitehtuurisi sekä ensimmäistä että toista mäkeä varten. Kolmatta mäkeä ei sitten teknologialla valloitetakaan, vaan siitä huolehtivat humanistit.
Ensimmäinen mäki on palvelun saaminen markkinoille. Toinen on suurten käyttäjämäärien palveleminen palvelunlaadun kärsimättä. Kolmas on oman organisaation kasvukivut tämän seurauksena.
Toisessa mäessä moni verkkopalvelu uupuu siihen, että kehitystiimin sydänverelläkään ei pysytä käyttäjämäärän kasvun perässä, vaan palvelu alkaa hidastumaan ja saattaa hajota kokonaankin, josta viime aikojen kuuluisimpana esimerkkinä Twitter. Hidastelu ja hajoileminen on tuhonnut monta lupaavaa palvelua ajamalla niiden käyttäjät luotettavampien saittien huomaan. Mitä sosiaalisempi on palvelukonsepti, sitä herkemmin näin käy.
Näin ei tarvitse käydä sinulle. Toisen mäen hanskaamista kutsutaan palvelun skaalautumiseksi, ja se tarkoittaa sitä, että tuotat palvelun monella pienellä tavalla yhden suuren askeleen sijaan.
Yhdellä suurella askeleella tarkoitan järjestelmäarkkitehtuuria, jossa kaikki tieto on yhdessä tietokannassa. Kyllä, vaikka suunnittelisit antavasi kannalle lukuorjia.
Monella pienellä tavalla tarkoitan sitä, että teet jokaisesta palvelusi osa-alueesta oman taustapalvelunsa, ja jaat jokaisen taustapalvelun edelleen pienempiin paloihin.
Käyttäjätilien hallinta voi olla oma taustapalvelunsa. Kun koostat verkkosivun, jossa haluat sanoa käyttäjän koko nimen, sivua rakentava kontrolleri tekee HTTP-haun "http://tilipalvelu/users/gumi" ja saa XML/JSON-vastauksen.
Tilipalvelu puolestaan koostuu jatkuvasti kasvavasta määrästä yhden edustakoneen ja kahden HA-klusteroidun MySQL-palvelimen kokonaisuuksia, joissa jokaisessa on vain niin monen käyttäjän tiedot kuin mitä tälläinen toiminnallinen kokonaisuus voi palvella hyvällä palvelunlaadulla.
Ennen tilipalvelun toiminnallisia klustereita on hakemistopalvelu, jonka ainoa tehtävä on kertoa, mistä löytyvät käyttäjän "gumi" tiedot. Koko hakemisto pidetään palvelun muistissa, joten vastaukset missä-kyselyihin tulevat pahimmillaan mikrosekunneissa.
Voilà. Meillä on tilipalvelu, joka ei väsy toisessa mäessä.
Haastavampaa on suunnitella ryhmäpalvelu. Jos ryhmät ja käyttäjätunnukset ovat eri koneilla, tietokanta ei voi pitää huolta tiedon eheydestä sillä tavalla johon olet jo tottunut.
Se, että tiedon eheyttä ei voida 100% taata taustapalveluiden rajojen yli on se hinta joka joudutaan maksamaan toisen mäen ylittämisestä. Siitä ei pääse yli eikä ympäri. Tämä johtuu siitä, että etäisyydet tietokoneiden välillä verkossa ovat niin erilaisia kuin etäisyydet yhden tietokoneen prosessorin ja muistin välillä.
Sovellussuunnittelijoiden ja sivuja koostavien kontrollereiden pitää varautua siihen, että yhden ryhmän jäsenen tietoja ei enää löydykään, ja jättää nimi tulostamatta. Suunnittelijoiden pitää priorisoida sivun tavoitteet, ja päättää mistä voidaan tarvittaessa tilapäisesti luopua.
Olet ohjelmistoja rakentaessasi oppinut saman läksyn kuin minäkin: muutoskustannukset kasvavat logaritmisesti ajan myötä.
Sinun tehtäväsi on suunnitella onnistuvasi. Kyllä, juuri sinun!
Keskustele tiimisi kanssa ensimmäisestä ja toisesta mäestä, hahmottele palvelusi taustapalveluina ja toiminnallisina klustereina, ja tee prototyyppi hakemistopalvelusta jo tänään!
Ja ole ylpeä itsestäsi!
Teetkö suunnitelmia siitä lähtökohdasta, että tulet onnistumaan työssäsi, vai oletatko epäonnistuvasi?
Jos verkkopalvelusi onnistuu, kuinka paljon sillä tulee olemaan käyttäjiä? Kuinka monta pyyntöä sekunnissa se saa palvella?
Juuri nyt, ennenkuin palvelullasi on vielä sitä ensimmäistäkään käyttäjää, on paras aika istua alas ja ajatella mitä onnistuminen tarkoittaa.
Jos rakennat verkkopalvelua, suunnittelet varmaankin käyttäväsi työkaluina PHP:ta, Pythonia, Javaa tai dotnettiä, ja tallettavasi palvelun tiedot MySQL:n, Postgresiin tai MSSQL:n.
Olet tottunut toimimaan niin, että ensin suunnittelet relaatiokannan, sitten rakennat sitä käyttävän saitin, ja iteroit asiakastarpeiden ja uusien ajatusten pohjalta. Jos sinulla on jo jonkin verran kokemusta, suunnittelet rakentavasi kolmitasoarkkitehtuurin ja käyttäväsi MVC-kehystä, sen sijaan että kaikki koodi on samoissa PHP-tiedostoissa.
Nämä suunnitelmat auttavat sinua onnistumaan. Se on hienoa!
Ne eivät auta sinua kohtaamaan onnistumisen aiheuttamia ongelmia. Se on huonoa!
Onnistuminen ja epäonnistuminen ovat luonteeltaan erilaisia. Jos onnistut, peli ei lopukaan, vaan sinulta odotetaan vielä lisää onnistumisia. On paljon katkerampaa väsyä toisessa mäessä, kun ensimmäinen on jo ylitetty.
Kehitys ei pysähdy koskaan, mutta verkkopalveluiden kohdalla voit ottaa suurten toimijoiden onnistumisista ja epäonnistumisista mallia, ja suunnitella järjestelmäarkkitehtuurisi sekä ensimmäistä että toista mäkeä varten. Kolmatta mäkeä ei sitten teknologialla valloitetakaan, vaan siitä huolehtivat humanistit.
Ensimmäinen mäki on palvelun saaminen markkinoille. Toinen on suurten käyttäjämäärien palveleminen palvelunlaadun kärsimättä. Kolmas on oman organisaation kasvukivut tämän seurauksena.
Toisessa mäessä moni verkkopalvelu uupuu siihen, että kehitystiimin sydänverelläkään ei pysytä käyttäjämäärän kasvun perässä, vaan palvelu alkaa hidastumaan ja saattaa hajota kokonaankin, josta viime aikojen kuuluisimpana esimerkkinä Twitter. Hidastelu ja hajoileminen on tuhonnut monta lupaavaa palvelua ajamalla niiden käyttäjät luotettavampien saittien huomaan. Mitä sosiaalisempi on palvelukonsepti, sitä herkemmin näin käy.
Näin ei tarvitse käydä sinulle. Toisen mäen hanskaamista kutsutaan palvelun skaalautumiseksi, ja se tarkoittaa sitä, että tuotat palvelun monella pienellä tavalla yhden suuren askeleen sijaan.
Yhdellä suurella askeleella tarkoitan järjestelmäarkkitehtuuria, jossa kaikki tieto on yhdessä tietokannassa. Kyllä, vaikka suunnittelisit antavasi kannalle lukuorjia.
Monella pienellä tavalla tarkoitan sitä, että teet jokaisesta palvelusi osa-alueesta oman taustapalvelunsa, ja jaat jokaisen taustapalvelun edelleen pienempiin paloihin.
Käyttäjätilien hallinta voi olla oma taustapalvelunsa. Kun koostat verkkosivun, jossa haluat sanoa käyttäjän koko nimen, sivua rakentava kontrolleri tekee HTTP-haun "http://tilipalvelu/users/gumi" ja saa XML/JSON-vastauksen.
Tilipalvelu puolestaan koostuu jatkuvasti kasvavasta määrästä yhden edustakoneen ja kahden HA-klusteroidun MySQL-palvelimen kokonaisuuksia, joissa jokaisessa on vain niin monen käyttäjän tiedot kuin mitä tälläinen toiminnallinen kokonaisuus voi palvella hyvällä palvelunlaadulla.
Ennen tilipalvelun toiminnallisia klustereita on hakemistopalvelu, jonka ainoa tehtävä on kertoa, mistä löytyvät käyttäjän "gumi" tiedot. Koko hakemisto pidetään palvelun muistissa, joten vastaukset missä-kyselyihin tulevat pahimmillaan mikrosekunneissa.
Voilà. Meillä on tilipalvelu, joka ei väsy toisessa mäessä.
Haastavampaa on suunnitella ryhmäpalvelu. Jos ryhmät ja käyttäjätunnukset ovat eri koneilla, tietokanta ei voi pitää huolta tiedon eheydestä sillä tavalla johon olet jo tottunut.
Se, että tiedon eheyttä ei voida 100% taata taustapalveluiden rajojen yli on se hinta joka joudutaan maksamaan toisen mäen ylittämisestä. Siitä ei pääse yli eikä ympäri. Tämä johtuu siitä, että etäisyydet tietokoneiden välillä verkossa ovat niin erilaisia kuin etäisyydet yhden tietokoneen prosessorin ja muistin välillä.
Sovellussuunnittelijoiden ja sivuja koostavien kontrollereiden pitää varautua siihen, että yhden ryhmän jäsenen tietoja ei enää löydykään, ja jättää nimi tulostamatta. Suunnittelijoiden pitää priorisoida sivun tavoitteet, ja päättää mistä voidaan tarvittaessa tilapäisesti luopua.
Olet ohjelmistoja rakentaessasi oppinut saman läksyn kuin minäkin: muutoskustannukset kasvavat logaritmisesti ajan myötä.
Sinun tehtäväsi on suunnitella onnistuvasi. Kyllä, juuri sinun!
Keskustele tiimisi kanssa ensimmäisestä ja toisesta mäestä, hahmottele palvelusi taustapalveluina ja toiminnallisina klustereina, ja tee prototyyppi hakemistopalvelusta jo tänään!
Ja ole ylpeä itsestäsi!
Subscribe to:
Posts (Atom)