1. Przyszłość webu?
Wiktor Schmidt
wiktor@netguru.pl

2. O czym?
nowe trendy w
• data-storage
• languages / frameworks
• development process

3. Data storage

4. Files

5. S3
CDN (CloudFront)

6. Application Data

8. Nowe wymagania
• szybkość i skalowalność
• mniejsze wymagania co do
persistence, integrity, etc.

9. Document store

10. Document store
• najbardziej zbliżony do SQLa, duże
możliwości filtrowania
• łatwy sharding i replikacja
• brak JOINów,

11. Better Key-Value
• Redis
• memcacheDB
• Riak

12. Better Key-Value
• prosty
• bardzo łatwy sharding
• brak JOINów, brak filtrowania

13. “MapReduce”
• Cassandra - Facebook, Digg, Twitter,
OpenX, Reddit
• HBase - Mahalo, yahoo, stumbleUpon,
ning

14. “MapReduce”
• Potencjalnie wysokie możliwości
filtrowania i agregacji danych
• przechowywanie dużych ilości danych
• auto-scaling, auto-sharding
• bardzo skomplikowane

15. Application layer

16. Application layer

17. Nowe wymagania
• real-time web
• logika po stronie klienta
• high concurency

18. Whatʼs hot?

19. pierwsza połowa
2010

21. rapid development
rapid prototyping

22. druga połowa 2010

25. Dlaczego “hot”?
• javascript
• V8 (chrome) engine
• evented, non-blocking I/O
• native HTTP support

26. Javascript
• dynamiczny
• powszechnie znany
• bezpieczny
• “dziwny”

28. Evented vs. Threaded

29. Evented vs. Threaded

30. Non-blocking I/O

31. Native HTTP server

32. Procesy

33. QA oraz Deployment

34. Ewolucja procesów
QA
• “u mnie działa” aka SOA#1
• “wrzucam na produkcje i klikam”
• staging server - testy ręczne
• unit, integration, functional tests
• ...

35. Ewolucja procesów
deploymentu
• “sie koduje i sie wrzuca na eFTePa”
• VCS (SVN), svn update na serwerze,
rsync, nfs
• scripted deployment - multiserver,
(semi-)automated
• ...

36. Continuous...
• integration
• deployment

37. Continuous
Integration
• automated tests after each commit
• always ready for deployment

38. Korzyści
• szybki feedback
• eliminacja “złego” kodu w repo
• “usystematyzowanie” jakości

39. Niebezpieczeństwa
• poprawnie działąjące testy !=
poprawnie działająca aplikacja
• nie można testować reguł
“biznesowych”

40. Continuous
Deployment
• automated tests after each commit
• automated deployment
after each commit

42. Procesy

43. Case
• IMVU
• commit -> test -> deploy
• 15k test cases
• 70 deploys/day
• 1 mln tests/day
• 30-40 test servers

44. Case
• IMVU
• commit -> test -> deploy
• 15k test cases
• 70 deploys/day
• 1 mln tests/day
• 30-40 test servers

45. Deploy
• initial deploy (small % of users)
• metrics sampling (load, cpu, etc.)
• (some time)
• sampling and compare
• deploy to 100% or rollback

46. Jak to wygląda
u nas?

47. Deployment
• “master” branch
• automated tests
• staging server
• manual testing
• beta server
• manual testing
• production server

48. Korzyści
• szybki i konkretny feedback
• dalsze “usystematyzowanie” jakości
• eliminacja “strachu” przed
deploymentem
• TTR - time to recovery

49. Dziękuje
pytania/uwagi?
Wiktor Schmidt / netguru / wiktor@netguru.pl