San Francisco Chronicle rapporterar att Facebook köper Sharegrove. Förklaringen uppges huvudsakligen vara värdet hos medarbetare Adam Wolff:
"For Facebook, the deal was made primarily to bring in Sharegrove co-founder Adam Wolff, said Facebook spokesman Larry Yu. Sharegrove announced the deal on its own Web site, but said the company will wind down operations immediately and close Tuesday."
Från: Facebook acquires Sharegrove | San Francisco Chronicle
Ett uttalande som detta är alltid intressant därför att det sällan är kompetensen hos personen ensamt i sådana fall som oberoende av något till denna nära associerat som konkret avgjort. Associerad marknad, teknisk plattform (både möjligt här Facebooks egna eller "oberoende" plattformar) o.s.v. kan förvisso ligga direkt i företaget men i sådana fall är det inte naturligt att inte sätta likhetstecken mellan det och företaget d.v.s. inte specifikt kommentera.
Jag har egentligen aldrig följt Facebook rörande tekniska satsningar, uppköp m.m. utanför deras API:er (se Facebook-guiderna) men tittade här över Sharegrove och Adam Wolff ytligt på några minuter.
En teknisk plattform utanför Sharegrove som Adam Wolff åtminstone är "associerad" till visade sig vara openmsjs.org givet bl.a. en av hans minst två Twitter-profiler (en för sitt namn och denna):
Dessutom tycks den URL man hamnar på när man surfar in på Sharegrove antyda att Openmsjs.org används för tjänsten:
sharegrove.com/msjs/sg/welcome
Nu är openmsjs.org åtminstone just nu nere (vilket givetvis i sig är intressant om det fortsätter). Dessutom tycks den vara på väg ur Googles cache (men jag kan för lite om hur det fungerar för att dra någon slutsats från det) i den mening att enstaka undersidor fortfarande finns där medan t.ex. startsidan inte gör det.
Openmsjs.org har en blogg på Google Blogger och det sista inlägget från 25 april 2010 är både lärorikt och intressant när det gäller utmaningen att skapa prestanda-effektiv skalbarhet över tekniska plattformar när det gäller meddelandehanteringen.
I Adam Wolff sista inlägg framgår (utan att jag egentligen försökt sätta mig in i vad openmsjs mer exakt gör vilket för vilken seriös analys som helst är oseriöst på rent löjliga nivåer men duger för den allmänna diskussionen här) att det handlar om Javascript, API:er mot servrar som hanterar användares meddelanden och i situationer där målsättningen är en samlad "view" i prestanda kritiska tillämpningar enkel att skapa med.
Jämför med den klassiska problematiken vi har i gamla system där multipla bilder av meddelanden existerar. När jag t.ex. i ett uppdrag för många år sedan agerade kunskapsresurs rörande säkerhetsfrågor för en internetbank som byggdes hade vi följande situation för finansiella bankomat transaktioner i Sverige (och åtminstone delvis kan jag enkelt genom att följa hur pengar dras från mitt konto i olika situationer konstatera att den fortfarande gäller):
- Bankomat uttag hanteras via batchar som går diskret från det allmänna gemensamma systemet som därifrån synkroniserar mot bankerna.
- Enskilda banker kan ha direkt synkronisering mot egna bankomater och bankomater tillhörande banker man har närmare samarbete med även utanför mer gemensamma lösningar.
- Bankogiro, internetbanker, Swift m.m. som representerar access kan också (och gör det ofta) representera en egen tidsrymd.
I denna situation existerar aldrig en gemensam korrekt bild av lönekontot. I någon mening har möjligheter skapats genom åren där det i varje situation visat sig varit - trots att det verkligen förvånar - för mycket ansvar oavsett storlek på budget. Stannar tiden t.ex. om kontot blir "låst" därför att kontanter eller kredit tagit slut kommer den förvisso uppstå efter upp till säg kanske inte mer än en tre dagar (men möjligen att checkar m.m. kan tänkas påverka längre om det fortfarande används av privatpersoner).
Det enda sättet att hantera dessa svårigheter rörande aktörer som integrerar praktiskt för en aktör som Facebook är lyfta bort de områden som kan skapa problem och samtidigt göra det med ökad kvalitet. I princip ska vilken inkompetent person som kopierar in en bit kod från en webbsida klara att få saker att fungera utan att det skapar problem för Facebook och om det blir populärt korrekt med hög prestanda och tillförlitlighet hanteras hos Facebooks servrar. Detta behov uttrycktes bra på Nodejs.org (jag noterade att Adam Wolff åtminstone var intresserad av):
"This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. Node will show much better memory efficiency under high-loads than systems which allocate 2mb thread stacks for each connection. Furthermore, users of Node are free from worries of dead-locking the process—there are no locks. Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems."
Det handlar om programmering där saker bara fungerar utan att det går att göra fel så att det påverkar något annat, och dessutom där allt vanligt (och strategiskt för Facebook tilltalande) man vill göra är väldigt enkelt att realisera.
Det är ett kritiskt område för Facebook såväl som Google. De skapar tjänster med gemensamma tillstånd för användarna och öppnar upp det för oerhört många egna applikationer och externa webbsajter medan antalet faktiska använder stiger i snabb takt.
Att tekniskt klara det kan tyckas enkelt givet att det något liknande redan fungerar på Facebook.com men i praktiken kan jag tänka mig att det är en krävande utmaning. Några av dom områden som är viktiga lyfts bra fram av Facebook själva:
"We're going through an inversion of scale in computing which is making parallelism and concurrency much more important. Single computers are no longer fast enough to handle the amounts of data we want to process. Even within one computer the relative speeds of processors, memory, storage, and network have diverged so much that they often spend more time waiting for data than doing things with it. The processor (and by extension, any program we write) is no longer a Wizard of Oz kind of character, sole arbiter of truth, at the center of everything. It's only one of many tiny bugs crawling over mountains of data."
Från: A Dismal Guide to Concurrency | Facebook.com
Facebook har givetvis redan en gemensam transaktionshantering av meddelanden men de vill föra ut denna på internet där de blir ett gemensamt system som andra aktörer använder för att skapa möjlighet till diskussion, kommentarer m.m. Därigenom kan både ett värde skapas för användarna via välkända funktioner, webbsajter genom enkla möjligheter och facebook genom fler registrerade användare och på sikt mycket bättre möjligheter att skapa annonsnätverk utanför Facebook.com (vilket de idag så vitt jag vet helt saknar).
För att prestanda-, stabilitets- och kostnadseffektivt klara att nå fram till en stabil lösning med mycket bredare funktionalitet än Facebook idag erbjuder tror jag säkert att ett antal strategiska uppköp av kompetens och företag kommer att ske. Det kommer säkert också gälla Google trots att de redan har en bredare stabil plattform för den här typen av transaktioner helt enkelt därför att en liten ökad effektivitet p.g.a. storleken ger en mätbar besparing i CPU, förbrukad elektrisk energi eller ger snabbare upplevelse av användaren.
Vi kan också se hur applikationen Sharegrove skapat praktiskt rör sig i den exakta mitten av denna utmaningen. Den ligger emellertid varken direkt som en aktör som integrerar med facebook, som användare eller som något liknande Facebook utan är en typ av lösning som funnits, kan dyka upp i nya områden men som allmänt erbjuder vad aktörer som Facebook, Google m.fl. typiskt förr eller senare ger möjligt till i sina egna plattformar.
Uppköpet av Sharegrove och att Adam Wolff flyttar in i Facebook kanske är ett exempel på ett sådant uppköp. Eventuellt kanske spelade Openmsjs eller annan grundläggande teknisk plattformsliknande funktionalitet in och den kunskap om denna Adam Wolff har om denna man sökte i så fall eventuellt kombinerat med Sharegrove som ett case för Openmsjs som var viktigt. Alternativt kanske Facebook helt enkelt behöver fler utvecklare som är vana att arbeta mot deras egna system.
Relaterat
Även om openmsjs.org åtminstone just nu är nere (kanske kommer den snart upp) finns källkoden att ladda ner via Github.com (jag har inte tittat på den alls):
Tidigare inlägg, guider och nyheter om Facebook på Nyhetsbloggen:
Facebook Like knappen på din sajt steg för steg | Nyhetsbloggen
Facebook Like knappen till Google Blogger | Nyhetsbloggen
Facebook Like med URL till inlägg även på startsidan för Google Blogger
Tipsa om länkar i Facebook med bookmarklet direkt från sidan du besöker | Nyhetsbloggen
Meta taggar i Open Graph Protocol och Facebook
Facebook har RSS strömmar att prenumerera på | Nyhetsbloggen
