Etikettarkiv: molnet

Så programmerar du för molnet

Bild CC http://www.flickr.com/photos/torley/2311784203/in/photostream/Kanske en klyschig rubrik men det finns många saker man bör tänka på när din avsikt är att placera din kodbas i molnet. Och när jag skriver molnet så menar jag exempelvis Amazon EC2 där du hyr en virtuell server. Dessa åsikter är helt subjektiva och kan variera beroende programmeringsspråk eller molntyp.

Grundfilosofin bör dock alltid vara att skriva portabel kod utan statisk information såsom sökvägar eller annat som kan komma att ändra sig om du ökar eller minskar din kapacitet eller flyttar koden. Det är dock inte alltid helt lätt att skriva flexibel och portabel kod då du alltid någonstans måste inneha ett beroende mot den nuvarande plattformen.

  1. Undvik statiska sökvägar eller URL:er
  2. Dokumentera beroenden såsom Redis, MySQL och eventuella PHP-moduler som används
  3. Undvik versionsspecifika funktioner
  4. Inte direkt specifikt för molntjänster men glöm för all del inte att ta backup (och använd GitHub).
Och glöm framför allt inte säkerheten, som ska vara minst lika viktig i molnet som på din egen server eller VPS. Tyvärr blev detta inlägg inte riktigt så långt och innehållsrikt som jag hade tänkt mig, detta pg.a. att programmering för molnet inte skiljer sig allt för mycket mot ”vanlig” programmering.

Microsoft dag 1

Nu är dag ett av besöket hos Microsoft över och det har varit en dag full med olika intryck, funderingar och intressanta diskussioner. Dagen började med att Miha Kralj från ”Office of the CTO” höll en intressant presentation om allt från uppkopplade kylskåp till nanometer på kretsar.

Tydligen så har Microsoft 35 anställda som hanterar 200 000 servrar i Chicago där anställda inte ens har åtkomst till de fysiska servrarna. Detta för att förhindra fel orsakade av den mänskliga faktorn (kortfattat).

Andra föreläsare under dagen var bl.a. Tim O´Brien som pratade om molntjänster som bl.a. ingår i Azure.

En imponerande syn är storleken på det område där Microsoft håller till utanför Seattle där verkligen allt finns. Exempelvis så finns det minst två fotbollsplaner.

Imorgon ryktas det om att ett SDK ska släppas till Kinect samt så kommer det finnas tillfälle att träffa svenskar som jobbar på Microsoft i Redmond samt så är ett besök till Boeing museet inbokat.

Diverse bilder från dagen:


10 saker att tänka på vid skapande av API

Så du går i tankarna på att tillhandahålla ett API? Då har du kommit rätt. Jag försöker här att redogöra över de tankar jag har när det gäller det mesta vid API utveckling.

Först och främst så bör du ställa dig frågan om ett API verkligen är rätt, och i de flesta fall så skulle jag säga att API är rätt väg. De fall då ett API kanske inte är lämpligt är då din tjänst enbart bygger på ett annat API och ej tillför något mervärde. Prioritering är också en viktig punkt, i flertalet fall så kan det tillåmed vara så att ett API skall finnas innan en webbsida finnes (framförallt i offentlig sektor).

Om du tillhandahåller en iPhone-app eller någon annan typ av extern tjänst så är detta också tillämpningsbart.

1. Placera ditt API under ett eget DNS-namn, exempelvis api.domän.se. Även om api.domän.se pekar till domän.se till en början.

2. Detta har med ovan punkt att göra: Exportera din data till en separat server som exempelvis ligger i molnet. Detta för att enkelt göra ditt API redundant och icke beroende av din ordinarie tjänst som kanske får problem om du får tusentals API-förfrågningar per sekund. Kan dock bli problem med realtidstjänster om API:et tillhandahåller sekundaktuell information.

3. Fundera om du bör tillhandahålla en krypterad version över HTTPS. Fundera även över om anrop bör vara signerade, för https i sitt standardutförande verifierar ej klient, bara server. Självklart kan du köpa SSL-certifikat via min sajt https.se.

4. Vilket format är lämpligast. JSON REST, XML SOAP eller annat? Jag rekommenderar REST JSON. Se Google eller FRAPI

5. Vill du hålla koll på vilka som anropar ditt API? Då bör du tillhandahålla en API-nyckel och bygga en registreringsprocess för detta. Enklast är att använda Google Forms. Det finns ofantligt många sätt att bygga detta förfarande.

6. Du bör införa kontroll av anrop samt begränsningar. Detta kan vara bra för att förhindra miljontals anrop i sekunden eller forcering av lösenord/användarnamn. Begränsa förfrågningar på så mycket som du bara kan, exempelvis IP-nummer.

7. Vilken licens kan användas? Här kan myndigheter få problem då CC-licenser kan gå emot lagstiftning. E-delegationen håller på med ett arbete om bl.a. detta och kommer att tillhandahålla mer information.

8. Upprätta en changelog, blogg eller E-postlista (Google Groups) för att berätta om eventuella förändringar. Här kan det även vara bra att prefixa alla API-anrop med versionsnummer för att bibehålla bakåtkompabilitet. Exempelvis: api.domän.se/v1/anropstyp

9. Glöm framförallt inte att erbjuda dokumentation och kod-exempel på hur API:et används. Berätta om innehållet, begränsningar, datatyper, relationer, statuskoder osv. Kanske ett forum för frågor? Wiki? Status-sida för att berätta om eventuella problem med ditt API eller fördröjningar. Se Pingdom eller Watchmouse.

10. Övriga punkter: Länka till de som använder ditt API för att uppmuntra användning. Ta betalt för ditt API? Berätta för Mashup.se att du har ett API. Hur länge bör du cacha? Pagination, page=1 vs.  cursor: start_id=1234. Loggning? If-Modified-Since header?

That’s it! Har säkert glömt många bra saker, skriv en kommentar och berätta vad du saknar.

Bloggsök flyttad till molnet

Sakta men säkert så flyttar jag mina bloggprojekt till molnet och Amazon EC2 + RDS. Det rör sig först och främst om bloggsökmotorn Bloggz.se där jag även kommer att öppna upp för ett bloggsök-API med JSON + XML. Fritt för privatpersoner att använda och en mindre summa för kommersiella projekt.

Bloggz var mitt första projekt som skapades år 2007 och har sedan dess indexerat den svenska bloggosfären. Tjänster som använder sig av bloggdata är exempelvis BloggVärde, BloggNytt och BloggBilder.

Jag håller även på att komma ikapp antalet bloggar som är indexerade:

Att utveckla för molnet

Att utveckla webbtjänster för molnet gör att utvecklingen blir bättre. Jag upplever att jag tvingas att tänka på portabilitet och möjlighet till skalnCC http://commons.wikimedia.org/wiki/File:Bedeckt.gifing på ett annat sätt än när jag vanligtvis skapar webbtjänster.  Detta gör mig troligtvis också till en bättre programmerare.

Låt mig ta några exempel:

1. Istället för att använda Pythons inbyggda köhantering (Queue) så använder jag Redis och får då automatiskt skalning. Dock inte till vilket pris som helst eftersom Redis äter minne. Men med Amazon EC2 och 15GB minne så kommer jag rätt långt. Har testat Amazon SQS för köhantering men prestandan är direkt usel och är inte avsedd för miljoner operationer per sekund.

2. Sökvägar tvingas att sättas dynamiskt eftersom jag använder Amazon EBS där sökvägarna sätts på den extramonteringen som EBS tillhandahåller. Dock är det lite trist att vara låst till en ”zon” hos Amazon.

3. Att inte tänka på begränsningar på samma sätt. Det går alltid att kasta fler servrar, ramminne och hårddisk på problemet så löser det sig utan att behöva införskaffa fysisk hårddvara. Detta är något som jag ser som mycket intressant, att som liten ensam entreprenör kunna bygga stora system med hundratalet servrar. Dock ska ju allt underhållas också..

Finns säkert en drös med andra saker som jag inte kommer på just nu, men lämna gärna en kommentar på vad du ser för fördelar med att använda molntjänster vid utveckling.