What TV4.se have learned since we started using cloud services (and some background).

1. ”Ten things the cloud has taught us”
Per Åström, TV4
Disruptive Media 2010

2. 20 years ago

3. Our History
4 Countries
31 channels
25 local TV stations
One channel Multichannel strategy Many websites
1990 .se
1990 2003 2010
TV4 Vision AB Mobilab
TV4 Sverige AB

4. TV4.se - anno 1997

5. Some of our sites
tv4.se  >150 blogs
tv4play.se Community (Hemmakanalen.se)
recept.nu soko.se
resor.nu blip.se
fotbollskanalen.se canalplus.se/no/dk/fi
nyhetskanalen.se
vaderkanalen.se
hockeykanalen.se
hemmakanalen.se
5

6. What is the cloud?
The definition of cloud computing according to Wikipedia is:
Cloud computing is Internet-based computing, whereby
shared resources, software, and information are provided
to computers and other devices on demand, like the
electricity grid.
6

7. What is the cloud?
Continued...:
Cloud computing is a paradigm shift following the shift
from mainframe to client–server in the early 1980s.
Details are abstracted from the users, who no longer have
need for expertise in, or control over, the technology
infrastructure "in the cloud" that supports them.
Cloud computing describes a new supplement,
consumption, and delivery model for IT services based on
the Internet, and it typically involves over-the-Internet
provision of dynamically scalable and often virtualized
resources.
7

8. Traffic
Peak
Average? People asleep
#1
8

9. Evolution of publishing platforms
Generation #1 - Static Files
 Static html - Editors needed to know html
 No database
 No reuse of content
 No channel publishing
 Typical Feature: Server Side Include
 Cause Of Death: Too static and too limited publishing
9

10. Evolution of publishing platforms
Generation #2 - Home grown with db
 Database!
 DIY - typically home made/home grown
 Depended on a few developers
 In the long run: expensive and complicated to develop
 Typical Feature: Taylor made for the own needs
 Cause Of Death: To complicated to continue develop (EOL)
10

11. Evolution of publishing platforms
Generation #3 - A CMS Product
 A CMS - one product
 Multi channel publishing
 Typically offsprings of internal products
 Closed source
 Expensive (?)
 Typical Feature: A swiss army knife: customize for own needs
 Cause Of Death: Slow development pace, limited upgrade path
11

12. Evolution of publishing platforms
Generation #4 - Open Platforms
 Many different products and tools
 Open API:s
 Built to integrate or to be integrated
 Ready for cloud computing
 ”Small pieces connected”
 Open source?
 Typical Feature: Open for integration and iterative development
 Cause Of Death: ?
#2
12

13. #3
From: http://www.darkgreyindustries.com/index.php/site/zone_mapping_chart/
13

14. Focus - What do we want to
focus our resources on?
hardware OS patches
network infrastructure scaling failover
redundancy antivirus upgrades capacity
backup installation planning firewall
specification design coding
operations gui SLA maintenance
#4
new features
14

15. #5 Learn - and improve
our products
15

16. How do we use the cloud today?
www.tv4.se IN CNAME www.tv4.se.edgesuite.net
Cache-Control: public, max-age=60
16

17. Origin vs. Delivery
Users
Delivery Muscles
Origin Brain
17

18. Origin vs. Delivery
Offload: average 90%, images 97%
Delivery
Origin
18

19. Idol Auditions 2010
Delivery
Origin
19

20. Comments
20

21. Comments - User Management
21

22. Addthis
22

23. Addthis - Analytics
23

24. Polldaddy - thumbs up and voting
24

25. Heroku - Ruby Cloud Platform as a Service
25

26. Väderkanalen.se - runs on Heroku
26

27. Väderkanalen.se - runs on Heroku
Heroku
API4
TV4 SMHI
27

28. Soko.se - runs on Heroku
28

29. 29

30. What’s our platform?
Before Now Then
Polopoly Polopoly ?
Xcap Disqus
Wordpress
Basefarm Addthis
svn Polldaddy
Google API
Cover it Live
Basefarm
Akamai
Heroku
Amazon AWS
Github m.fl.
30

31. What’s our platform?
Before Now
31

32. Example: Introducing Wordpress
 php - not Java
 Wordpress MU
 Subdomain with Wordpress MU Multi Domain Mapping plugin (with minor change)
 > 150 blogs + Resor.nu
 Five themes
 Home made and released plugin ”External Markup”
 Other plugins: All in One SEO Pack, DISQUS Comment System, Maintenance
Mode, My Custom Widgets, PollDaddy Polls, Report Comments, WP-PageNavi,
WP-SpamFree, Domain mapping, Vipers Video Quicktags, WP Super Cache,
WPMU Blog Defaults, PubSubHubbub
 Delivered through a CDN
32

33. Same WP-installation, same theme
33

35. Example: Introducing Wordpress
 php - not Java
 Wordpress MU
 Subdomain with Wordpress MU Multi Domain Mapping plugin (with minor change)
 > 150 blogs + Resor.nu
 Five themes
 Home made and released plugin ”External Markup”
 Other plugins: All in One SEO Pack, DISQUS Comment System, Maintenance
Mode, My Custom Widgets, PollDaddy Polls, Report Comments, WP-PageNavi,
WP-SpamFree, Domain mapping, Vipers Video Quicktags, WP Super Cache,
WPMU Blog Defaults, PubSubHubbub
 Delivered through a CDN
35

36. Resor.nu
 ..is made in cooperation with Momondo.com
 ..is a Wordpress MU blog
 ..was launched with ”a big bang”: TV-commercial, Ads in Expressen, Ads, links
and Editorial Content on Express.se and TV4-sites.
36

37. #1: The Team - the doers and decisionmakers
v e
l l ea
nt
a u by
oe r re dR
/D Pa a n
M % va
TO M /P 80 Ja
C S Teletext
Teletext
/ js e r
css ag
y
l/ an
ub
tm M
dR
h t
je c
an
o
Pr
va
Ja
37

38. 38

39. #2: The Vision - Where do you want to go?
 Examples of our vision:
 Scaling should not be an issue
 Products should improve continously
 Instant and frequent deploys
 Don´t reinvent the wheel (”Stand on the shoulder of giants”)
 Lower baseline costs
 Less operations
 Create a platform that is open (create API:s)
39

40. #3: Be Agile - Execute!
 Decide the next steps but dont plan too long ahead
 With smaller applications its easier to make changes
 Use a method
Sprint Daily
Ticket planning Retrospective
40

41. Old way with hardware
41

42. 42

43. 43

44. $ sudo gem install heroku
F
44

45. $ heroku create tv4weather-stage
Created http://tv4weather-stage.heroku.com
git@heroku.com:tv4weather-stage.git
F
45

46. $ git push heroku master
-----> Heroku recieving push
-----> Rails app detected
-----> Launching..... done
F http://tv4weather-stage.heroku.com deployed
46

47. 47

48. 48

49. 49

50. 50

51. 51

52. 52

53. 53

54. $ heroku addons:add custom:domains_basic
Adding custom_domains to myapp...done.
F
54

55. $ heroku domains:add stage.vaderkanalen.se
Added stage.vaderkanalen.se as a custom domain name to
tv4weather-stage.heroku.com
F
55

56. $ heroku addons:memcache add:5mb
Adding memcache to myapp...done.
F
56

57. $ heroku addons:add exceptional:basic
Adding exceptional to myapp...done.
F
57

58. $ git push heroku master
-----> Heroku recieving push
-----> Rails app detected
-----> Launching..... done
F http://stage.vaderkanalen.se deployed
58

59. 59

60. 60

61. 61

62. What is a Dyno?
 A dyno is roughly equivalent to an individual Mongrel, Thin, or FastCGI backend in
traditional Ruby deployment environments.
 4 dynos are equivalent to the compute power of one CPU-core on other systems.
 Elasticity: The number of dynos allocated for your app can be increased or
decreased at any time – without server provisioning of any kind.
 Intelligent routing: The routing mesh tracks the availability of each dyno and
balances load accordingly. Requests are routed to a dyno only once it becomes
available. If a dyno is tied up due to a long-running request, the request is routed
to another dyno instead of piling up on the unavailable dyno’s backlog.
 Process management: Each dyno process is monitored for responsiveness.
Misbehaving dynos are taken down and new dynos are launched in their place.
 Distribution and redundancy: Dynos are distributed across a large cluster of
machines called the “dyno grid”. An app configured with two dynos is running two
processes, as you'd expect, but each process is running on a separate machine. If
a machine goes down, your site stays up – even with only two dynos.
62

63. 63

64. 64

65. $ heroku dynos 1
vaderkanalen-stage now running on 1 dyno
F
65

66. $ heroku dynos 24
vaderkanalen-stage now running on 24 dynos
F
66

67. $ heroku dynos 100
vaderkanalen-stage now running on 100 dynos
F
67

68. Does it scale?
”For dynos - there is no real limit. You can already set your app to 100
dynos through the command line "heroku dynos 100". If you need more,
we can up that limit to just about any number you need. Let us know
a week in advance at least, and we'll get your limit increased. If you're
going to need a few thousand, it's best if we can work with you to
understand your demand.”
68

69. Heroku - there’s an app for that
69

70. Heroku - there’s an app for that
70

71. #4: Forget about perfect -
there is no such thing as PERFECT
 Remember - things break
 Things change, always
 You never finish, the target is moving
 Developing products is hard work
 Find the product you think will do best in the future
71

72. #5: It’s getting better all the time -
it’s not perfect, but it improves
 Watch your products improve
 Behind every product there are specialists
 Easy installation, easy configuration, no maintenance, no operations and it keeps
improving
72

73. Disqus improvements since we began using it
 Mobile version of Disqus
 iPhone-app
 More Community functions
 Like, Dislike and ”who does what”
 Security improvements with Trusted Domains
 Remake of the Commenting experience
 Updated Wordpress plugins
 Early Adopter Features and Settings
 Rewritten implementation for faster download and rendering
 Better Spam reporting and close commenting features
 Inline Moderating
 Yahoo and Facebook login
73

74. 22 kr
-app:
hone
iP
74

75. Heroku and Polldaddy improvements
since we began using it
Heroku Polldaddy
 Rails 3 available  Media Library
 MongoDB and CouchDB as an Addon  Location Filtering
 Redis to go  iPhone/iPad application
 Swedish translation
 SSL Support
 Multi user accounts
and so on.......
75

76. #6: Quality and standards - Add to Cart
 Use standard setups
 ”Thinner” products are easier to implement
 Every line of code needs to be maintained
 Done!
 Open source
 Speed of light matters
 If you can automate it - automate it (builds, deploy, testing and so on)
 Even advanced services can be delivered as products/platforms
76

77. #7: Build and use API’s -
Standing on the shoulders of giants
77

78. 78

79. 79

80. 80

81. Search with and without Solr
Old Setup New Setup
Scale
e
e
e
e
e
e
s hor
lav
lav
lav
lav
lav
lav
izont
lr S
lr S
lr S
lr S
lr S
lr S
a lly
So
So
So
So
So
So
Solr Master
Index Server Index Server
Polopoly Polopoly
81

82. 82

83. 83

84. Väderkanalen.se
84

85. Väderkanalen.se - mobile version
85

86. Variations built upon the API
86

87. Variations built upon the API
87

88. Old TV4Play and new TV4Play
Old TV4Play New TV4Play
OTT Android Plex
TV4Play.se iPhone
iPhone Plex
TV4Play.se
API
Backend
Backend
88

89. TV4Play.se’s API
API
Search Editorial Content
89

90. gKX8dF3mQs2NDbUN&Vw,p]RqFsBAX)CX>D4c/LEp
90

91. #8: Security, operations and status
 gKX8dF3mQs2NDbUN&Vw,p]RqFsBAX)CX>D4c/LEp
91

92. Mistakes can be fatal
92

93. Export your content
93

94. Väderkanalen.se
94

95. Väderkanalen.se
95

96. status.*.com
96

100. #9: The Echosystem of the Cloud -
use it and be a part of it
100

101. 101

102. 102

103. IaaS - PaaS - SaaS > You
You! TV4.se
SaaS Lightspun
=
PaaS Heroku
IaaS Amazon AWS
103

104. #10: It’s business! - Talk business, not clouds
 Use terms that your management understands: money, quality, ROI,
QoS, TTM etc.
 Find the price model that fits you
 Use the right numbers when you calculate costs (easy to forget what
you don’t see)
 More arguments:
 ”We can increase the time to market”
 ”We can scale (cheaper?)”
 ”We get "this" (ex. functionality developed)”
 ”We dont have to spend time doing xxx”
 Increased Transparency
104

105. #10: It’s business! - Talk business, not clouds
105

106. Transparency
106

107. 107

108. Thanks for listening!
per.astrom@tv4.se
http://github.com/TV4
http://twitter.com/perkovich/tv4-http
108

109. #Extra: Opportunities!
 Local clouds
 More products and services based on ”thin” needs
 Operations (backup, performance, tuning, support and more)
109