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

nowe trendy w

• data-storage
• languages / frameworks
• development process
Data storage
Files
S3
CDN (CloudFront)
Application Data
Nowe wymagania


• szybkość i skalowalność
• mniejsze wymagania co do
  persistence, integrity, etc.
Document store
Document store

• najbardziej zbliżony do SQLa, duże
  możliwości filtrowania

• łatwy sharding i replikacja

• brak JOINów,
Better Key-Value


• Redis
• memcacheDB
• Riak
Better Key-Value

• prosty
• bardzo łatwy sharding

• brak JOINów, brak filtrowania
“MapReduce”

• Cassandra - Facebook, Digg, Twitter,
  OpenX, Reddit

• HBase - Mahalo, yahoo, stumbleUpon,
  ning
“MapReduce”
• Potencjalnie wysokie możliwości
  filtrowania i agregacji danych

• przechowywanie dużych ilości danych
• aut...
Application layer
Application layer
Nowe wymagania


• real-time web
• logika po stronie klienta
• high concurency
Whatʼs hot?
pierwsza połowa
     2010
rapid development
 rapid prototyping
druga połowa 2010
Dlaczego “hot”?

• javascript
• V8 (chrome) engine
• evented, non-blocking I/O
• native HTTP support
Javascript

• dynamiczny
• powszechnie znany
• bezpieczny
• “dziwny”
Evented vs. Threaded
Evented vs. Threaded
Non-blocking I/O
Native HTTP server
Procesy
QA oraz Deployment
Ewolucja procesów
       QA
• “u mnie działa” aka SOA#1
• “wrzucam na produkcje i klikam”
• staging server - testy ręczne
...
Ewolucja procesów
  deploymentu
• “sie koduje i sie wrzuca na eFTePa”
• VCS (SVN), svn update na serwerze,
  rsync, nfs

•...
Continuous...


• integration
• deployment
Continuous
       Integration

• automated tests after each commit
• always ready for deployment
Korzyści

• szybki feedback
• eliminacja “złego” kodu w repo
• “usystematyzowanie” jakości
Niebezpieczeństwa

• poprawnie działąjące testy !=
  poprawnie działająca aplikacja

• nie można testować reguł
  “bizneso...
Continuous
       Deployment

• automated tests after each commit
• automated deployment
  after each commit
Procesy
Case
• IMVU
• commit -> test -> deploy
• 15k test cases
• 70 deploys/day
• 1 mln tests/day
• 30-40 test servers
Case
• IMVU
• commit -> test -> deploy
• 15k test cases
• 70 deploys/day
• 1 mln tests/day
• 30-40 test servers
Deploy

• initial deploy (small % of users)
• metrics sampling (load, cpu, etc.)
• (some time)
• sampling and compare
• de...
Jak to wygląda
    u nas?
Deployment
• “master” branch
 • automated tests
• staging server
 • manual testing
• beta server
 • manual testing
• produ...
Korzyści

• szybki i konkretny feedback
• dalsze “usystematyzowanie” jakości
• eliminacja “strachu” przed
  deploymentem

...
Dziękuje
              pytania/uwagi?




Wiktor Schmidt / netguru / wiktor@netguru.pl
Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz...
Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz...
Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz...
Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz...
Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz...
Przyszłość technologii webowych i podejścia do realizacji projektów internetowych. Przyszłość, którą musisz znać już teraz...
Upcoming SlideShare
Loading in …5
×

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

1,405 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,405
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

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

×