Your SlideShare is downloading. ×
Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz. - Wiktor Schmidt -TechStandard
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz. - Wiktor Schmidt -TechStandard

1,189
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,189
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 7. Nowe wymagania • szybkość i skalowalność • mniejsze wymagania co do persistence, integrity, etc.
  • 8. Document store
  • 9. Document store • najbardziej zbliżony do SQLa, duże możliwości filtrowania • łatwy sharding i replikacja • brak JOINów,
  • 10. Better Key-Value • Redis • memcacheDB • Riak
  • 11. Better Key-Value • prosty • bardzo łatwy sharding • brak JOINów, brak filtrowania
  • 12. “MapReduce” • Cassandra - Facebook, Digg, Twitter, OpenX, Reddit • HBase - Mahalo, yahoo, stumbleUpon, ning
  • 13. “MapReduce” • Potencjalnie wysokie możliwości filtrowania i agregacji danych • przechowywanie dużych ilości danych • auto-scaling, auto-sharding • bardzo skomplikowane
  • 14. Application layer
  • 15. Application layer
  • 16. Nowe wymagania • real-time web • logika po stronie klienta • high concurency
  • 17. Whatʼs hot?
  • 18. pierwsza połowa 2010
  • 19. rapid development rapid prototyping
  • 20. druga połowa 2010
  • 21. Dlaczego “hot”? • javascript • V8 (chrome) engine • evented, non-blocking I/O • native HTTP support
  • 22. Javascript • dynamiczny • powszechnie znany • bezpieczny • “dziwny”
  • 23. Evented vs. Threaded
  • 24. Evented vs. Threaded
  • 25. Non-blocking I/O
  • 26. Native HTTP server
  • 27. Procesy
  • 28. QA oraz Deployment
  • 29. 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 • ...
  • 30. Ewolucja procesów deploymentu • “sie koduje i sie wrzuca na eFTePa” • VCS (SVN), svn update na serwerze, rsync, nfs • scripted deployment - multiserver, (semi-)automated • ...
  • 31. Continuous... • integration • deployment
  • 32. Continuous Integration • automated tests after each commit • always ready for deployment
  • 33. Korzyści • szybki feedback • eliminacja “złego” kodu w repo • “usystematyzowanie” jakości
  • 34. Niebezpieczeństwa • poprawnie działąjące testy != poprawnie działająca aplikacja • nie można testować reguł “biznesowych”
  • 35. Continuous Deployment • automated tests after each commit • automated deployment after each commit
  • 36. Procesy
  • 37. Case • IMVU • commit -> test -> deploy • 15k test cases • 70 deploys/day • 1 mln tests/day • 30-40 test servers
  • 38. Case • IMVU • commit -> test -> deploy • 15k test cases • 70 deploys/day • 1 mln tests/day • 30-40 test servers
  • 39. Deploy • initial deploy (small % of users) • metrics sampling (load, cpu, etc.) • (some time) • sampling and compare • deploy to 100% or rollback
  • 40. Jak to wygląda u nas?
  • 41. Deployment • “master” branch • automated tests • staging server • manual testing • beta server • manual testing • production server
  • 42. Korzyści • szybki i konkretny feedback • dalsze “usystematyzowanie” jakości • eliminacja “strachu” przed deploymentem • TTR - time to recovery
  • 43. Dziękuje pytania/uwagi? Wiktor Schmidt / netguru / wiktor@netguru.pl

×