2. Foreword........................................................................................................................6
Introduction..................................................................................................................9
Culture..........................................................................................................................11
The Obsession with Performance Measurement......................13
Build vs Buy.....................................................................................................19
Enhancing User Experience...................................................................27
Code crafters.................................................................................................33
Open Source Contribution....................................................................41
Sharing Economy platforms..................................................................47
Organization.............................................................................................................57
Pizza Teams.....................................................................................................59
Feature Teams...............................................................................................65
DevOps.............................................................................................................71
Practices.......................................................................................................................85
Lean Startup...................................................................................................87
Minimum Viable Product.........................................................................95
Continuous Deployment.......................................................................105
Feature Flipping.........................................................................................113
Test A/B...........................................................................................................123
Design Thinking.........................................................................................129
Device Agnostic.........................................................................................143
Perpetual beta.............................................................................................151
Architecture............................................................................................................157
Cloud First.....................................................................................................159
Commodity Hardware............................................................................167
Sharding..........................................................................................................179
TP vs. BI: the new NoSQL approach..............................................193
Big Data Architecture..............................................................................201
Data Science................................................................................................211
Design for Failure......................................................................................221
The Reactive Revolution........................................................................227
Open API ......................................................................................................235
About OCTO Technology..............................................................................243
Authors......................................................................................................................245
Table of Contents
3. 3
THE WEB GIANTS
It has become such a cliché to start a book, a talk or a preface by stating that the rate
of change is accelerating. However, it is true: the world is changing faster both because
of the exponential rate of technology evolution and the central role of the user in today’s
economy. It is also a change characterized by Marc Andreessen in his famous blog post
as “software is eating the world“. Not only is software at the core of the digital economy,
but producing software is changing dramatically too. This is not a topic for Web
companies, this is a revolution that touches all companies. To cope with their
environment’s change, they need to reinvent themselves into software companies, with
new ways of working, organizing themselves and producing digital experiences for their
customers.
This is why I am so pleased to write the preface to “The Web’s Giants“. I have been
using this book intensely since the first French edition was on the market. I have given
copies to colleagues both at Bouygues Telecom and at AXA, I have made it a permanent
reference in my own blogs, talks and writing. Why? It is the simplest, most pragmatic
and convincing set of answers to the previous questions: what to do in this software-
infused, technology-enabled, customer-centric fast changing 21st century?
This is not a conceptual book, a book about why you should do this or that. This is a
beautifully written story about how software and service development is organized in
some of the best-run companies of the world. First, this is a book about practices. The
best way to grow change in a complex world is to adopt practices. It is the only way to
learn, by doing. These practices are sorted into three categories: culture, organization
and architecture; but there is a common logic and a systemic reinforcement. Practices
are easier to pick and they are less intimidating than methodologies or concepts.
However, strong will and perseverance are required. I will not spoil your reading by
summarizing what OCTO found when they look at the most common practices of the
most successful software companies of the world. I will rather try to convince you that
reading this book is an urgent task for almost everyone, based on four ideas.
The first and foremost idea is that software systems must be built to change constantly.
This is equally true for information systems, support systems, embedded, web or mobile
software. What we could define as customer engagement platforms are no longer
complex systems that one designs and builds, but continuously evolving systems that are
grown. This new generation of software systems is the core of the Web Giants. Constant
evolution is mandatory to cope with exponential technology changes, as well as the only
way to co-construct engagement platforms through customer feedbacks. The
unpredictability of usage, especially social usage, means that digital experiences software
processes that can only be crafted through measure and continuous improvement. This
Foreword
4. 4
THE WEB GIANTS FOREWORD
critical change, from software being designed to software being grown, means that all
companies that provide digital experiences to their customers must become software
companies. A stable software support system could be outsourced, delegated or bought,
but a constantly evolving self-adaptive system becomes a core capability. This capability
is deeply mixed with business and its delivery processes and agents are to be valued and
respected.
The second key idea is that there exists a new way of building such software systems.
We are facing two tremendous challenges: to churn out innovations at the rate that is
expected by the market, and to constantly integrate new features while factoring out
olderones,toavoidthesuffocationbyconstantgrowththatplaguedpreviousgenerations
of software systems. The solution is a combination of open innovation - there are clearly
more smart developers outside any company than inside – together with source-level
“white box“ integration and minimalist “platform“ design principles. When all your
code needs to be constantly updated to follow the environment change, the less you own
the better. It is also time to bring source code back from the dark depths of “black box
integration“. Open source culture is both about leveraging the treasure trove of what
may be found in larger development communities and about mashing up composite
applications by weaving source code that one may be proud of. Follow the footsteps of
the Web Giants: code that changes constantly is worth being well-written, structured,
documented and test-viewed by as many eyeballs as possible.
The third idea is another way of saying that “software is eating the world“, this book
is not about software, it is about a new way of thinking about your company, whichever
businessyouarein.Notsurprisingly,many“known“practicessuchasagiledevelopment,
lean startup, measure obsession or obsession about saving customer’s time - the most
precious commodity of the digital age -, have found their way into Octo’s list. By
reading the practical testimonies from the Web Giants, a new kind of customer-focused
organization will emerge. Thus, this is a book for everyone, not for geeks only. This is
of the utmost importance since many of the change levers lay in other stakeholders’
hands than software developers themselves. For instance, a key requirement for agility
is to switch from solution requirement to problem requirement, allowing the solution to
be co-developed by cross-functional teams as well as users.
The last idea I would propose is that there is a price to pay for this transformation.
There are technologies, tools and practices that you must acquire and learn. Devops
practices, such as continuous delivery or managing infrastructure as code, require to
master a set of tools and to build skills, there is no “free lunch“. A key set of benefits
from the Web Giants way of working comes from massive automation. This book also
5. 5
shows some of the top recent technology patterns in the architecture section. Since this
list is evolving by nature, the most important lesson is to create an environment where
“doers“ may continuously experience the tools of the future, such as massively parallel
cloud programming, big data or artificial intelligence. A key consequence is that there is
a true efficiency and competitiveness difference between those who do and those who
don’t master the said set of tools and skills. In the world of technology, we often use the
world “Barbarians“ to talk about newcomers who leverage their software/technology
skills to displace incumbents in older industries. This is not a question of mindset (trying
to take legacy companies head-front is an age-old strategy for newcomers) but a matter
of capabilities!
As stated earlier, there would be other, more conceptual, ways to introduce the key ideas
and practices that are pictured in this book. One could tell about the best sources on
motivation and collaborative work, such as Daniel Pink for instance. These Web Giants
practices reflect the state of the art of managing intrinsic motivation. The same could be
said about the best books on lean management and self-organization. The reference to
Lean Startup is one from many subtle references to the influence of the Toyota Way in
the modern 21st century forms of organization. Similarly, it would be tempting to
convoke complex system theory - see Jurgen Apello and his “Management 3.0“ book for
instance - to explain why the practices observed and selected by Octo are the natural
answer to the challenges of the increasingly changing and complex world that we live
in. From a technology perspective, it is striking to see the similarity with the culture &
organizational traits described by Salim Ismael, Michael Malone and Yuri van Geest in
their book “Exponential organizations“. The beauty of this pragmatic approach is that
you have almost all what you need to know in a much shorter package, which is fun
and engaging to read.
To conclude this preface, I would advise you to read this book carefully, to share it with
your colleagues, your friends and your children - when it’s time to think about what it
means to do something that matters in this new world. It tells a story about the new way
of working that you cannot afford to miss. Some of the messages: measuring everything,
learning by doing, loving your code and respecting those who build things, may make
the most seasoned manager smile, but times are changing. This is no longer a set of
suggested, “nice-to-have“ practices, as it might have been ten years ago. It is the
standard of web-age software development, and de facto the only way for any company
to succeed in the digital world.
Yves Caseau - National Academy of Technologies of France,
President of the ICT commission.
Head of Digital of AXA Group
THE WEB GIANTS
6. 6
THE WEB GIANTS INTRODUCTION
Introduction
Something extraordinary is happening at this very moment; a sort of revolution is
underway. Across the Atlantic, as well as in other parts of the world such as France,
people are reinventing how to work with information technology.
They are Amazon, Facebook, Google, Netflix and LinkedIn, to name but the most
famous. This new generation of players has managed to shed old dogmas to examine
afresh the issues at hand by coming up with new, radical and efficient solutions for
long-standing IT problems.
Computer scientists are well aware of the fact that when IT tools are introduced to a
trade, the benefits of computerization can only be reaped if business processes are
re-thought in light of the new potential offered by technology.
One trade, however, has mostly managed thus far to avoid upheavals in their processes:
Information Technology itself. Many continued – and still do – to build information
systems the way one would build highways or bridges.
There is a tendency to forget that the matter being handled on a daily basis is extremely
volatile. By dint of hearing tell of Moore’s law,[1]
its true meaning is forgotten: what
couldn’t be done last year is possible today; what cannot be done today will be
possible tomorrow.
The beliefs and habits of the ecosystem we live in must be challenged at regular intervals.
This thought is both terrifying and wonderful.
Now that the pioneers have paved the way, it is important to re-visit business
processes. The new approaches laid out here offer significant increases in through
efficiency, proactivity, and the capacity for innovation, to be harnessed before the
competition pulls the rug out from under your feet.
The good news is that the Web Giants are not only paving the way; they espouse the
vision of an IT community.
They are committed to the Open Source principle, openly communicating their practices
to appeal to potential recruits, and work in close collaboration with the research
community. Their work methods are public knowledge and very accessible to those who
care to delve.
The aim of this book is to provide a synthesis of practices, technological solutions and
the most salient traits of IT culture. Our hope is that it will inspire readers to make
contributions to an information age capable of reshaping our world.
This book is designed for both linear and thematic reading. Those who opt for the
former may find some repetition.
[1] empirical law which states that computing power roughly doubles in capacity at a fixed
price every 18 months.
8. 8
The obsession with performance measurement................................. 13
Build vs Buy..................................................................................... 19
Enhancing the user experience......................................................... 27
Code crafters................................................................................... 33
Developing Open Source................................................................. 41
THE WEB GIANTS
11. 11
THE WEB GIANTSCULTURE / THE OBSESSION WITH PERFORMANCE MEASUREMENT
Description
In IT, we are all familiar with quotes reminding us of the importance of
performance measurement:
That which cannot be measured cannot be improved;
without measurement, it is all opinion.
Web Giants have taken this idea to the extreme, and most have
developed a strong culture of performance measurement. The
structure of their activities leads them in this direction.
These activities often share three characteristics:
For these companies, IT is their means of production. Their costs
are therefore directly correlated to the optimal use of equipment and
software. Improvements in the number of concurrent users or CPU
usage result in rapid ROI.
Revenues are directly correlated to the efficiency of the service
provided. As a result, improvements in conversion rates lead to rapid
ROI.
They are surrounded by computers! And computers are excellent
measurement instruments, so they may as well get the most out of
them!
Most Web Giants have made a habit of measuring everything, response
times, most visited web pages or the articles (content or sales pages) that
work best, the time spent on individual pages...
In short, nothing unusual – at first glance.
But that’s not all! – They also measure the heat generated by a given CPU,
or the energy consumption of a transformer, as well as the average time
between two hard disk failures (MTBF, Mean Time Between Failure).[1]
This
motivates them to build infrastructure that maximizes the energy efficiency
of their installations, as these players closely monitor PUE, or Power Usage
Effectiveness.
Most importantly, they have learned to base their action plans on this
wealth of metrics.
[1] http://storagemojo.com/2007/02/19/googles-disk-failure-experience
12. 12
THE WEB GIANTS
Part of this trend is A/B testing (see “A/B Testing“ on p. 123 for further
information), which consists of testing different versions of an application
on different client groups. Does A work better than B? The best way
to find out remains objective measurement: it results in concrete data
that defy common sense and reveal the limits of armchair expertise, as
demonstrated by the www.abtests.com website, which references A/B
testing results.
In an interview, Yassine Hinnach – then Senior Engineer Manager at LinkedIn –
spoke of how LinkedIn teams were encouraged to quickly put any technology
designed to boost site performance to the test. Thus decisions to adopt a
given technology are made on the basis of observed metrics.
HighScalability.com has published an article presenting Amazon’s recipes
for success, based on interviews with its CTO. Among the more interesting
quotes, the following caught our attention:
Everyone must be able to experiment, learn, and iterate.
Position, obedience, and tradition should hold no power.
For innovation to flourish, measurement must rule.[2]
As another example of this approach, here is what Timothy B. Lee, a
journalist for Wired and the New York Times, had to say about Google’s
culture of performance measurement:
Rather than having intimate knowledge of what their
subordinates are doing, Google executives rely on
quantitative measurements to evaluate the company’s
performance. The company keeps statistics on everything—
page load times, downtime rates, click-through rates,
etc—and works obsessively to improve these figures. The
obsession with data-driven management extends even to
the famous free snacks, which are chosen based on careful
analysis of usage patterns and survey results.“[3]
[2] http://highscalability.com/amazon-architecture
[3] http://arstechnica.com/apple/news/2011/06/fourth-times-a-charm-why-icloud-faces-long-
odds.ars
13. 13
THE WEB GIANTSCULTURE / THE OBSESSION WITH PERFORMANCE MEASUREMENT
The consequences of this modus operandi run deep. A number of pure
players display in their offices the motto “In God we trust. Everything else,
we test“. This is more than just a nod to Deming;[4]
it is a profoundly pragmatic
approach to the issues at hand.
An extreme example of this trend, verging on caricature, is Google’s ‘Project
Oxygen’: a team of internal statisticians combed through HR data collected
from within – annual performance reviews, feedback surveys, nominations
for top-manager awards. They distilled the essence of what makes a good
manager down to 8 rules. Reading through them, any manager worthy
of the name would be struck by how jaw-droppingly obvious it all seems.
However, they backed their claims with hard, cold data,[5]
and that made all
the difference!
What about me?
The French are fond of modeling, and are often less pragmatic than their
English-speaking counterparts.
Indeed, we believe that this constant and quick feedback loop “hypothesis
measurement decision“ should be an almost systematic reflex in the ISD
world, and can be put into effect at a moment’s notice.
The author of these lines still has painful memories of two four-hour
meetings with ten people organized to find out if shifting requests to the
service layer to http would have a “significant“ impact on performance.
Ten working days would have largely sufficed for a developer to figure that
out, at a much lower cost.
OCTO consultants have also had the experience, several times over, of
discovering that applications performed better when the cache that
was used to improve performance was removed! The cure was therefore
worse than the disease and its alleged efficacy never actually measured.
Management runs the risk of falling into the trap of believing that analysis
by “hard data“ is a done deal. It may be a good idea to regularly check
that this is indeed the case, and especially that the information gathered
is put to use in decision-making.
[4] “In God we trust; all others must bring data“, W. Edward Deming.
[5] Adam BRYANT, Google’s Quest to Build a Better Boss, The New York Times Company,
March 12, 2011 : http://www.nytimes.com/2011/03/13/business/13hire.html
13
14. 14
THE WEB GIANTS
Nevertheless, it cannot be emphasized enough that an ecosystem
fostering the application of said information makes up part of the recipe
for success of Web Giants.
Two other practices support the culture of performance metrics:
Automated tests: it’s either red or green, no one can argue with
that. As a result, this ensures that it is always the same thing being
measured.
Short cycles. To measure – and especially interpret – the data, one
must be able to compare options, “all other things being equal“.
This is crucial. We recently diagnosed the steps undertaken to
improve the performance of an application. But about a dozen
other optimizations were made to the next release. How then can
efficient optimizations be distinguished from those that are counter-
productive?
17. 17
THE WEB GIANTS CULTURE / BUILD VS BUY
Description
One striking difference in the strategy of Web Giants as compared
to more usual IT departments lies in their arbitrations around Build
vs. Buy.
The issue is as old as computers themselves: is it better to invest
in designing software to best fit your needs or to use a software
package complete with the capitalization and R&D of a publisher
(or community) having had all necessary leisure to master the
technology and business points?
Most major firms have gone for the second option and have enshrined
maximal software packaging among their guiding principles, based on
the view that IT is not one of their pillar businesses so is better left to
professionals.
The major Web companies have tended to do the exact reverse. This
makes sense given that IT is precisely their core business, and as such is
too sensitive to be left in the hands of outsiders.
The resulting divergences are thus coherent.
Nonetheless, it is useful to push the analysis one step further because Web
Giants have other motives too: first, being in control of the development
process to ensure it is perfectly adjusted to meet their needs, and second,
the cost of scaling up! These are concerns found in other IT departments,
meaning that it can be a good idea to look very closely into your software
package decisions.
Finding balanced solutions
On the first point, one of the built-in flaws of software packages is that they
are designed for and by the needs which most arise for the publisher’s
clients.[1]
Your needs are thus only a small subset of what the software
package is built to do. Adopting a software package by definition
entails overkill, i.e. an overly complex solution not optimized for your
[1] We will not insist here on the fact that you should not stray too far from the standard
out-of-the-box software package as this can be (very) expensive in the long term,
especially when there are new releases.
18. 18
THE WEB GIANTS
needs; and which has a price both in terms of execution and complexity,
offsetting any savings made by not investing in the design and development
of a complete application.
This is particularly striking in the software package data model. Much of the
model’s complexity stems from the fact that the package is optimized for
interoperability (a highly standardized Conceptual Data Model, extension
tables, low model expressiveness as it is a meta-model...). However the
abstractions and the “hyper-genericity“ that this leads to in software
design has an impact on processing performance.[2]
Moreover, Web Giants have constraints in terms of volumes, transaction
speed and the number of simultaneous users which push the envelopes
of traditional architecture and which, in consequence, require fine-tuned
optimizations determined by observed access-patterns. Such read-
intensive transactions must not be optimized in the same way as others,
where the stakes will be determined by I/O writing metrics.
In short, to attain such results, you have to pop the hood and poke around
in the engine, which is not something you will be able to do with a software
package (all guarantees are revoked from the moment you fiddle with the
innards).
Because performance is an obsession for Web Giants, the overhead costs
and low possibilities for adjustments to the software package make the
latter quite simply unacceptable.
Costs
The second particularly critical point is of course the cost when scaling up.
When the number of processors and servers increases, the costs rise very
quickly, but not always in linear fashion, making some items more visible.
And this is true of both business software packages and hardware.
That is precisely one of the arguments which led LinkedIn to gradually
replace their Oracle database by an in-house solution, Voldemort.[3]
.
In a similar vein, in 2010 we carried out a study on the main e-commerce
[2] When it is not a case of a cumbersome interface.
[3] Yassine Hinnach, Évolution de l’architecture de LinkedIn, enjeux techniques et
Organizationnels, USI 2011:
http://www.usievents.com/fr/conferences/8-paris-usi-2011/sessions/1007
19. 19
THE WEB GIANTS CULTURE / BUILD VS BUY
sites in France: at the time, eight of the ten largest sites (in terms of annual
turnover) ran on platforms developed in-house and 2 used e-commerce
software packages.
Web Giants thus prefer Build to Buy. But not only. They also massively
have recourse to Open source solutions (cf. “Developing open source“,
p. 41). Linux and MySQL reign supreme in many firms. Development
languages and technologies are almost all open source: very little .NET
for example, but instead Java, Ruby, PHP, C(++), Python, Scala... And they
do not hesitate to fork off from other projects: Google for example uses
a largely modified Linux kernel.[4]
This is also the case for one of the main
worldwide Global Distribution Systems.
Most technologies making a stir today in the world of high
performance architecture are the result of developments carried
out by Web Giants and then opened to the community. Cassandra,
developed by Facebook, Hadoop and HBase inspired by Google and
developed by Yahoo!, Voldemort by LinkedIn...
A way, in fact, of combining the advantages of software perfectly tailored
to your needs but nonetheless enhanced by improvements contributed by
the development community, with, as an added bonus, a market trained
to use the technologies you use.
Coming back to the example of LinkedIn, many of their technologies are
grounded in open source solutions:
Zoie, a real time indexing and search system based on Lucene.
Bobo, a faceted search library based on Lucene.
Azkaban, a batch workflow job scheduler to manage Hadoop job
dependencies.
GLU, a deployment framework.
[4] http://lwn.net/Articles/357658
20. 20
THE WEB GIANTS
How can I make it work for me?
Does this mean I have to do away with software packages in my IT choices?
Of course not, not for everything. Software packages can be the best
solution, no one today would dream of reengineering a payroll system.
However, ad hoc developments should be considered in certain cases:
when the IT tool is key to the success of your business. Figure 1 lays out
orientations in terms of strategy.
The other context where specific developments can be the right choice is
that of high performance: with companies turning to “full web solutions“,
very few business software packages have the architecture to support
the traffic intensity of some websites.
As for infrastructure solutions, open source has become the norm: OSs and
application servers foremost. Often also databases and message buses.
Open source are ideally adapted to run the solutions of Web Giants. There
is no doubt as to their capacity for performance and stability.
One hurdle remains: reluctance on the part of CIOs to forgo the support
found in software packages. And yet, when you look at what actually
happens, when there are problems with the commercial technical platform,
it is rarely support from the publisher, handsomely paid for, which
provides the solution, but rather networks of specialists and help fora
Unique,
differentiating.
Perceived as
a commercial asset.
Innovations and
strategic assets
Faster
SPECIFIC
SOFTWARE
PACKAGE
BPO[5]
Resources
Cheaper
Common to all
industry organizations.
Perceived as a production asset.
Common to all organizations.
Perceived as a ressource.
[5] Business Process Outsourcing.
21. 21
THE WEB GIANTS CULTURE / BUILD VS BUY
on the Internet. For application platforms of the database or message
bus type, the answer is less clearcut because some commercial solutions
include functionalities that you do not find in open source alternatives.
However if you are sending an Oracle into regions where MySQL will not
be able to follow, that means that you have very sophisticated needs...
which is not the case for 80% of the contexts we encounter !
24. 24
THE WEB GIANTS CULTURE / ENHANCING THE USER EXPERIENCE
Description
Performance: a must
One conviction shared by Web Giants is that users’ judgment of
performance is crucial. Performance is directly linked to visitor
retention and loyalty. How users feel about a particular service is
linked to the speed with which the graphic interface is displayed.
Most people have no interest in software architecture, server power,
or network latency due to web based services. All that matters is the
impression of seamlessness.
User-friendliness is no longer negotiable
Web Giants have fully grasped this and speak of metrics in terms of
“the bat of an eyelash“. In other words, it is a matter of fractions of seconds.
Their measurements, carried out namely through A/B testing (cf. “A/B
Testing“, p. 123), are very clear:
Amazon :
a 100ms. increase in latency means a 1% loss in sales.
Google :
a page taking more than 500ms to load loses 20% of traffic (pages
visited).
Yahoo! :
more than 400ms to load means + 5 to 9 % abandons.
Bing :
over 1 second to load means a loss of 2.8% in advertising income.
How are these performances attained?
In keeping with the Device Agnostic pattern (cf. “Device Agnostic“,
p. 143), Web Giants develop native interfaces, or Web interfaces,
to always offer the best possible user experience. In both cases,
performance as perceived by the user must be maximized.
25. 25
THE WEB GIANTS
Native applications
With the iPhone, Apple reintroduced applications developed for a specific
device (stopping short of the assembler however) to maximize perceived
performance. Thus Java and Flash technologies are banished from the
iPhone. The platform also uses visual artifacts: when an app is launched,
it displays the view as seen when it was last charged by the system to
strengthen the impression that it is instantaneous, with the actual app
being loaded in the background. On Android, Java applications are
executed on a virtual machine optimized for the platform. They can also
be written in C to maximize performance.
Generally speaking, there is a consensus around native development,
especially on mobile platform: it must be as tightly linked as possible
to the device. Multi-platform technologies such as Java ME, Flash and
Silverlight do not directly enhance the user experience and are therefore
put aside.
Web applications
Fully loading a Web page usually takes between 4 and 10 seconds
(including graphics, JavaScript, Flash, etc.).
It would seem that perceived slowness in display is generally linked
for 5% to server processing, and for 95% to browser processing. Web
Giants have therefore taken considerable care to optimize the display of
Web pages.
As illustration, here is a list of the main good practices which most agree
optimize user perception:
It is crucial to cache all static resources (graphics, CSS style sheets,
JavaScript scripts, Flash animations, etc.) whenever possible. There
are various HTTP cache technologies for this. It is important to
become skillful at optimizing the life-cycle of the resources in the
cache.
It is also advisable to use a cache network, or Content Delivery
Network (CDN) to bring the resources as close as possible to the
end user to reduce network latency. We highly recommend that you
have cache servers in the countries where the majority of your users
live.
26. 26
CULTURE / ENHANCING THE USER EXPERIENCE
Downloading in background is a way of masking sluggishness in
the display of various elements on the page.
One thing many do is to use sprites: the principle is to aggregate
images in a single file to limit the amount of data to be loaded;
they can then be selected on the fly by the navigator (see the Gmail
example below).
Having recourse to multiple domain names is a way to maximize
parallelization in simultaneous resource loading by the navigator.
One must bear in mind that navigators are subjected to a maximum
number of simultaneous queries for a same domain. Yahoo.fr for
example loads their images from l.yimg.com.
Placing JavaScript resources at the very end of the page to ensure
that graphics appear as quickly as possible.
Using tools to minimize, i.e. removing from the code (JavaScript,
HTML, etc.) all characters (enter, comments, etc.) serving to read
the code but not to execute it, and to shorten as much as possible
function names.
Compacting the various source code files such as JavaScript in a
single file whenever possible.
Who makes it work for them?
There are many examples of such practices among Web Giants, e.g.
Google, Gmail, Viadeo, Github, Amazon, Yahoo!...
References among Web Giants
Google has the most extensive distributed cache network of all Web
Giants: the search giant is said to have machines in all major cities, and
even a private global network, although corroboration is difficult to come
by.
Google Search pushes the real-time user experience to the limits with its
“Instant Search“ which loads search results as you type your query. This
function stems from formidable technical skill and has aroused the interest
of much of the architect community.
27. 27
THE WEB GIANTS
Gmail images are reduced to a strict minimum (two sprite images shown
on Figure 1), and the site makes intensive cache use and loads JavaScript
in the background
Figure 1: Gmail sprite images.
France
Sites using or having used the content delivery network Akamai:
cite-sciences.fr
lemonde.fr
allocine.com
urbandive.com
How can I make it work for me?
The consequences of display latency are the same with in-house
applications within any IT department: users who get fed up with the
application and stop using it. This to say that this is a pattern which
perfectly applies to your own business
Sources
• Eric Daspet, “Performance des applications Web, quoi faire et
pourquoi ?“ USI 2011 (French only):
> http://www.usievents.com/fr/conferences/10-casablanca-usi-2011/
sessions/997-performance-des-applications-web-quoi-faire-et-pourquoi
• Articles on Google Instant Search:
> http://highscalability.com/blog/2010/9/9/how-did-google-instant-
become-faster-with-5-7x-more-results.html
> http://googleblog.blogspot.com/2010/09/google-instant-behind-
scenes.html
Editor’s note: By definition,
sprites are designed for
screen display, we are
unable to provide any
better definition for the
printing of this example.
Thank you for your
understanding.
29. 29
THE WEB GIANTS CULTURE / CODE CRAFTERS
Description
Today Web Giants are there to remind us that a career as a developer
can be just as prestigious as manager or consultant. Indeed, some of
the most striking successes of Silicon Valley have originated with one
or several visionary geeks who are passionate about quality code.
When these companies’ products gain in visibility, satisfying an increasing
number of users means hugging the virtuous cycle in development quality,
without which success can vanish as quickly as it came.
Which is why a software development culture is so important to Web
Giants, based on a few key principles:
attracting and recruiting the best programmers,
investing in developer training and allowing them more
independence,
gaining their loyalty through workplace attractiveness and payscale,
being intransigent as to the quality of software development -
because quality is non-negotiable.
Implementation
The first challenge the Giants face is thus recruiting the best
programmers. They have become masters at the art, which is trickier than
it might at first appear.
One test which is often used by the majors is to have the candidates write
code. A test Facebook uses is the FizzBuzz. This exercise, inspired by a
drinking game which some of you might recognize, consists in displaying
the first 1000 prime numbers, except for multiples of 3 or 5, where “Fizz“
or “Buzz“ respectively must be displayed, and except for multiples of
3 and 5, where “FizzBuzz“ must be displayed. This little programming
exercise weeds out 99.5% of the candidates. Similarly, to be hired by
Google, between four and nine technical interviews are necessary.
30. 30
THE WEB GIANTS
Salary is obviously to be taken into account. To have very good developers,
you have to be ready to pay the price. At Facebook, Senior Software
Engineers are among the best paid employees.
Once programmers have joined your firm, the second challenge is to
favor their development, fulfillment, and to enrich their skills. In such
companies, programmers are not considered code laborers to be
watched over by a manager but instead as key players. The Google
model, which encourages developers to devote 20% of their time to
R&D projects, is often cited as an example. This practice can give rise
to contributions to open-source projects, which provide many benefits
to the company (cf. “Open Source Contribution“, p. 41). On the Netflix
blog for example, they mention their numerous open source initiatives,
namely on Zookeeper and Cassandra. The benefit to Netflix is twofold: its
developers gain in notoriety outside the company, while at the same time
developing the Netflix platform.
Another key element in developer loyalty is the working conditions. The
internet provides ample descriptions of the extent to which Web Giants
are willing to go to provide a pleasant workplace. The conditions are
strikingly different from what one finds in most Tech companies. But that
is not all! Netflix, again, has built a culture which strongly focuses on its
employees’ autonomy and responsibility. More recently, Valve, a video
game publisher, sparked a buzz among developers when they published
their Handbook, which describes a work culture which is highly demanding
but also propitious to personal fulfillment. 37 signals, lastly, with their
book Getting Real, lays out their very open practices, often the opposite
of what one generally finds in such organizations.
In addition to efforts deployed in recruiting and holding on to
programmers, there is also a strong culture of code and software quality.
It is this culture that creates the foundations for moving and adapting
quickly, all while managing mammoth technological platforms where
performance and robustness are crucial. Web Giants are very close to
the Software Craftsmanship[1]
movement, which promotes a set of
values and practices aiming to guarantee top-quality software and to
provide as much value as possible to end-users. Within this movement,
Google and GitHub have not hesitated to share their coding guidelines[2]
.
[1] http://manifesto.softwarecraftsmanship.org
[2] http://code.google.com/p/google-styleguide/ and https://github.com/styleguide
31. 31
THE WEB GIANTS
How can I make it work for me?
Recruiting It is important to implement very solid recruitment processes
when hiring your programmers. After a first interview to get a sense of
the person you wish to recruit, it is essential to have the person code. You
can propose a few technical exercises to assess the candidate’s expertise,
but it is even more interesting to have them code as a pair with one of
your developers, to see whether there is good feeling around the project.
You can also ask programmers to show their own code, especially what
they are most proud of - or most ashamed of. More than the code itself,
discussions around coding will bring in a wealth of information on the
candidate. Also, did they put their code on GitHub? Do they take part in
open source projects? If so, you will have representative samples of the
code they can produce.
Quality: Offer your developers the context which will allow them to
continue producing top-quality software (since that is non-negotiable).
Leave them time to write unit tests, to set up the development build you
will need for Continuous Deployment (cf. “Continuous Deployment“,
p. 105), to work in pairs, to hold design workshops in their business
domain, to prototype. The practice which is known to have the most
impact on quality is peer code reviewing. This happens all too rarely in
our sector.
R&D: Giving your developers the chance to participate in R&D projects in
addition to their work is a practice which can be highly profitable. It can
generate innovation, contribute to project improvement and, in the case
of Open Source, increase your company’s attractiveness for developers. It
is also simply a source of motivation for this often neglected group. More
and more firms are adopting the principles of Hackathons, popularized
by Facebook, where the principle consists in coding, in one or two days,
working software.
CULTURE / CODE CRAFTERS
32. 32
THE WEB GIANTS
Training: Training can be externalized but you can also profit from
knowledge sharing among in-house developers by e.g. organizing group
programming workshops, commonly called “Dojo“.[3]
Developers can
gather for half a day, around a video projector, to share knowledge and
together learn about specific technical issues. It is also a way to share
developer practices and, within a team, to align with programming
standards. Lastly, working on open source projects is also a way of learning
about new technologies.
Workplace: Where and how you work are important! Allowing
independence, promoting openness and transparency, hailing mistakes
and keeping a manageable rhythm are all paying practices in the long
term.
Associated patterns
Pattern “Pizza Teams“, p. 59.
Pattern “DevOps“, p. 65.
Pattern “Continuous Deployment“, p. 105.
Sources
• Company culture at Netflix:
> http://www.slideshare.net/reed2001/culture-1798664
• What every good programmer should know:
> http://www.slideshare.net/petegoodliffe/becoming-a-better-
programmer
• List of all the programmer positions currently open at Facebook:
http://www.facebook.com/careers/teams/engineering
• The highest salary at Facebook? Senior Software Engineer:
http://www.businessinsider.com/the-highest-paying-jobs-at-facebook-
ranked-2012-5?op=1
[3] http://codingdojo.org/cgi-bin/wiki.pl?WhatIsCodingDojo
33. 33
THE WEB GIANTS CULTURE / CODE CRAFTERS
• GitHub programming guidelines:
https://github.com/styleguide
• How GitHub grows:
http://zachholman.com/talk/scaling-github
• Open source contributions from Netflix:
http://techblog.netflix.com/2012/07/open-source-at-netflix-by-ruslan.
html
• The FizzBuzz test:
http://c2.com/cgi/wiki?FizzBuzzTest
• Getting Real:
http://gettingreal.37signals.com/GR_fra.php
• The Software Craftsmanship manifesto:
http://manifesto.softwarecraftsmanship.org
• The Google blog on tests:
http://googletesting.blogspot.fr
• The Happy Manifesto:
http://www.happy.co.uk/wp-content/uploads/Happy-Manifesto1.pdf
35. 35
THE WEB GIANTS
Description
Why is it Web Giants such as Facebook, Google and Twitter do so
much to develop Open Source?
A technological edge is a key to conquering the Web. Whether it be to
stand out from the competition by launching new services (remember
when Gmail came out with all its storage space at a time when Hotmail
was lording it?) or more practically to overcome inherent constraints such
as the growth challenge linked to the expansion of their user base. On
numerous occasions, Web Giants have pulled through by inventing new
technologies.
If so, one would think that their technological mastery, and the asset
which is the code, would be carefully shielded from prying eyes, whereas
in fact the widely shared pattern one finds is that Web Giants are not
only major consumers of open source technology, they are also the
main contributors.
The pattern “developing open source“ consists of making public a software
tool (library, framework...) developed and used in-house. The code is
made available on a public server such as GitHub, with a free license of
the Apache type for example, authorizing its use and adaptation by other
companies. In this way, the code is potentially open to development by
the entire world. Moreover, open source applications are traditionally
accompanied by much publicity on the web and during programming
conferences.
Who makes it work for them?
There are many examples. Among the most representative is Facebook
and its Cassandra database, built to manage massive quantities of data
distributed over several servers. It is interesting to note that among current
users of Cassandra, one finds other Web Giants, e.g. Twitter and Digg,
whereas Facebook has abandoned Cassandra in favor of another open
source storage solution - HBase - launched by the company Powerset.
With the NoSQL movement, the new foundations of the Web are today
massively based on the technologies of the Giants.
36. 36
THE WEB GIANTS
Facebook has furthermore opened several frameworks up to the
community, such as its HipHop engine which compiles PHP in C++, Thrift,
a multilanguage development service, and Open Compute, an Open
hardware initiative which aims to optimize how datacenters function. But
Facebook is not alone.
Google has done the same with its user interface framework GWT, used
namely in Adword. Another example is the Tesseract Optical Character
Recognition (OCR) tool initially developed by HP and then by Google,
which opened it up to the community a few years later. Lastly, one cannot
name Google without citing Android, its open source operating system
for mobile devices, not to mention their numerous scientific publications
on storing and processing massive quantities of data. We are referring
more particularly to their papers on Big Table and Map Reduce which
inspired the Hadoop project.
The list could go on and on, so we will end with first Twitter and its CSS
framework and very trendy responsive design, called Bootstrap, and the
excellent Ruby On Rails extracted from the Basecamp project management
software opened up to the community by 37signals.
Why does it work?
Putting aside ideological considerations, we propose to explore various
advantages to be drawn from developing open software.
Open and free does not necessarily equate with price and profit wars.
In fact, from one angle, opening up software is a way of cutting competition
off in the bud for specific technologies. Contributing to Open Source is
a way of redefining a given technology sector while ensuring sway
over the best available solution. For a long time, Google was the main
sponsor of the Mozilla Foundation and its flagship project Firefox, to the
tune of 80%. A way to diversify to counter Microsoft. Let us come back to
our analysis of the three advantages.
[1] Interface Homme Machine.
CULTURE / OPEN SOURCE CONTRIBUTION
37. 37
THE WEB GIANTS
Promoting the brand
By opening cutting-edge technology up to the community, Web Giants
position themselves as leaders, pioneers. It implicitly communicates a
spiritofinnovationreigningintheirhalls,aconstantquestforimprovements.
They show themselves as being able to solve big problems, masters of
technological prowess. Delivering a successful Open Source framework
says that you solved a common problem faster or better than anyone else.
And that, in a way, the problem is now behind you. Done and gone, you’re
already moving onto the next. One step ahead of the game.
To share a framework is to make a strong statement, to reinforce the
brand. It is a way to communicate an implicit and primal message: “We
are the best, don’t you worry“
And then, to avoid being seen as the new Big Brother, one can’t but help
feeling that the message also implied is:
“We’re open, we’re good guys, fear not“.[2]
Attracting - and keeping - the best
This is an essential aspect which can be fostered by an open source
approach. Because “displaying your code“ means showing part of your
DNA, your way of thinking, of solving problems - show me your code
and I will tell you who you are. It is the natural way of publicizing what
exactly goes on in your company: the expertise of your programmers,
your quality standards, what your teams work on day by day... A good
means to attract “compatible“ coders who would have already been
following the projects led by your company.
Developing Open Source thus helps you to spot the most dedicated,
competent and motivated programmers, and when you hire them you
are already sure they will easily integrate your ecosystem. In a manner of
speaking, Open Source is like a huge trial period, open to all.
[2] Google’s motto: “Don’t be evil“
38. 38
THE WEB GIANTS
Attracting the best geeks is one thing, hanging on to them is another. On
this point, Open Source can be a great way to offer your company’s best
programmers a showcase demonstration open to the whole world.
That way they can show their brilliance, within their company and beyond.
Promoting Open Source bolsters your programmers’ resumes. It takes
into account the Personal Branding needs of your staff, while keeping
them happy at work. All programmers want to work in a place where
programming is important, within an environment which offers a career
path for software engineers. Spoken as a programmer.
Improving quality
Simply “thinking open source“ is already a leap forward in quality:
opening up code - a framework - to the community first entails defining its
contours, naming it, describing the framework and its aim. That alone is a
significant step towards improving the quality of your software because it
inevitably leads to breaking it up into modules, giving it structure. It also
makes it easier to reuse the code in-house. It defines accountability within
the code and even within teams.
It goes without saying that programmers who are aware that their code
will be checked (not to mention read by programmers the world over) will
think twice before committing an untested method or a hastily assembled
piece of code. Beyond making programmers more responsible, feedback
from peers outside the company is always useful.
How can I make it work for me?
When properly used, Open Source can be an intelligent way not only to
structure your RD but also to assess programmer performance.
The goal of this paper was to explore the various advantages offered by
opening up certain technologies. If you are not quite up to making the
jump culturally speaking, or if your IS is not ready yet, it can nonetheless
be useful to play with the idea taking a few simple-to-implement actions.
Depending on the size of your company, launching your very first Open
Source project can unfortunately be met with general indifference. We do
not all have the powers of communication of Facebook. Beginning by
CULTURE / OPEN SOURCE CONTRIBUTION
39. 39
THE WEB GIANTS
contributing to Open Source projects already underway can be a good
initial step for testing the culture within your teams.
Like Google and GitHub, another action which works towards the three
advantages laid out here can be to materialize and publish on the web
your programming guidelines. Another possibility is to encourage your
programmers to open a development blog where they could discuss
the main issues they have come up against. The Instagram Engineering
Tumblr moderated by Instagram can be a very good source of inspiration.
Sources
• The Facebook developer portal, Open Source projects:
http://developers.facebook.com/opensource
• Open-Source Projects Released By Google:
http://code.google.com/opensource/projects.html
• The Twitter developer portal, Open Source projects:
http://dev.twitter.com/opensource/projects
• Instagram Engineering Blog:
http://instagram-engineering.tumblr.com
• The rules for writing GitHub code:
http://github.com/styleguide
• A question on Quora: Open Source: “Why would a big company do
open-source projects?“:
http://www.quora.com/Open-Source/Why-would-a-big-company-do-
open-source-projects
42. 42
THE WEB GIANTS CULTURE / SHARING ECONOMY PLATFORMS
Description
The principles at work in the platforms of the sharing economy
(exponential business platforms) are one of the keys to the successes
of the web giants and other startups valuated at $1 billion (“unicorns“)
such as BlablaCar, Cloudera, Social finance, or over $10 billion
(“decacorns“) such as Uber, AirBnB, Snapchat, Flipkart (List and
valuation of the Uni/Deca-corns).
The latter are disrupting existing ecosystems, inventing new ones,
wiping out others. And yet “Businesses never die, only business
models evolve“ (To learn more, see: Philippe Siberzahan, “Relevez le
défi de l’innovation de rupture“).
Concerns over the risks of disintermediation are legitimate given that
digital technology has led to the development of numerous highly
successful “exponential business platforms“ (see the article by Maurice
Levy, “Se faire ubériser“).
The article below begins with a recap of what is common to these
platforms and then explores the main fundamentals necessary for
building or becoming an exponential business platform.
The wonderful world
of the “Sharing economy“
Thereisacontinuousstreamofnewcomersknockingatthedoor,progressively
transforming many sectors of the economy, driving them towards a so-
called “collaborative“ economy. Among other goals, this approach strives
to develop a new type of relation: Consumer-to-Consumer (C2C). This is
true e.g. in the world of consumer loans, where the company LendingHome
(Presentation of LendingHome) is based on peer-2-peer lending. Another
area of interest is blockchain technology such as decentralisation and the
“peer-2-peer'isation“ of money through the Bitcoin!
What is most striking is that this type of relation can have an impact in
unexpected places such as personalised urban car services (e.g. Luxe and
Drop Don't Park), and movers (Lugg as an “Uber/Lyft for moving“).
Business platforms such as these favor peer-2-peer relations. They have
achieved exponential growth by leveraging the multitudes (For further
information, see: Nicolas Colin Henri Verdier, L'âge de la multitude:
Entreprendre et gouverner après la révolution numérique). Such models
make it possible for very small structures to grow very quickly by generating
revenues per employee which can be from 100 to 1000 times higher than
43. 43
THE WEB GIANTS
in businesses working in the same sector but which are much larger. The
fundamental question is then to know what has enabled some of them to
become hits and to grow their popularity, in terms of both community and
revenues. What are the ingredients in the mix, and how does one become so
rapidly successful?
At this stage, the contextual elements and common ground we discern are:
An often highly regulated market where these platforms appear
and then develop by providing new solutions which break away
from regulations (for example the obligation for hotels to make at
least 10% of their rooms disability friendly, which does not apply
to individuals using the AirBnB system).
An as yet unmet need in supply and demand can make it possible
to earn a living or to generate additional revenue for a better
quality of life (Cf. AirBnB's 2015 communication campaign on the
subject) or at the least to share costs (Blablacar). This point in
particular raises crucial questions as to the very notion of work, its
regulation and the taxation of platforms.
There is strong friction around the experience, of clients and
citizens, where the market has as yet to provide a response (such
as valet car services in large cities around the world where parking
is completely saturated)
A deliberate strategy to not invest in material assets but rather to
efficiently embrace the business of creating links between people.
Given this understanding of the context, the 5 main principles we propose
to become an exponential business platform are:
Develop your “network lock-in effect“.
Pair up algorithms with the user experience.
Develop trust.
Think user and be rigorous in execution.
Carefully choose your target when you launch platform
experiments.
44. 44
THE WEB GIANTS
“Network lock-in effect“
The more supply and demand grow and come together, the more
indispensable your platform becomes. Indispensable because in the end
that is where the best offers are to be found, the best deals, where your
friends are.
There is an inflection point where the network of suppliers and users
becomes the main asset, the central pillar. Attracting new users is no
longer the principal preoccupation. This asset makes it possible to
become the reference platform for your segment. This growth can provide
a monopoly over its use case, especially if there are exclusive deals that
can be obtained through offers valid on your platform only.
It can then extend to offers which follow upon the first (for example Uber's
position as an urban mobility platform has led them to diversify into a
meal delivery service for restaurants). This is one of the elements which
were very quickly theorised in the Lean Startup approach: the virality
coefficient.
The perfect match:
User eXperience Algorithms
What is crucial in the platform is setting up the perfect relation between
supply and demand, celerity in implementing relations in time and/
or space, lower prices as compared to traditional systems, and even
providing services that weren't possible before. For some, algorithms
for establishing relations are the core of their operations to deliver on
their daily promise of offering suggestions and possibilities for relevant
connections within a few micro-seconds.
The perfect match is a fine-tuned mix between stellar research into the
user experience (all the way to swipe!), often using a mobile-first approach
to explore and offer services, based on advanced algorithms to expose
relevant associations. A telling example is the use of “Swipe“ in terms
of uniquely tailored user experiences for fast browsing as in the personal
relationship tool “Tinder“.
CULTURE / SHARING ECONOMY PLATFORMS
45. 45
THE WEB GIANTS
Trust security
To get beyond the early adapters to reach the market majority, two
elements are critical to the client experience: trust in the platform, trust
towards the other platform users (both consumers and providers).
Who has not experienced stress when reserving one's first AirBnB? Who
has not wondered whether Uber would actually be there?
This level of trust conveyed by the platform and platform users is so
important that it has been one of the leveraging effects, like for the shared
Blablacar platform which thrived once the transactions were operated by
the platform.
What happens to the confidential data provided to the platform?
You may remember a recent hacking event of personal data on the “Ashley
Madison“ sites affecting the 37 million platform users who wanted total
discretion (Revelations around the hacking of the Ashley Madison sites).
Security is thus key to protecting platform transactions, guaranteeing
private data and reassuring users.
Think user excel in execution
Above all it is about realising that what the market and what the clients
want is not to be found in marketing plans, sales forecasts and key
functionalities. The main questions to ask revolve around the triplets Client
/ Problem / Solution: Do I really have a problem that is worth solving? Is
my solution the right one for my client? Will my client buy it? For how
much? Use whatever you can to check your hypotheses: interviews, market
studies, prototypes...
To succeed, these platforms aim to reach production very quickly, iterating
and improving while their competition is still exploring their business plan.
It is then a ferocious race between pioneers and copycats, because in
this type of race “winner takes all“ (For further reading, see The Second
Machine Age, Erik Brynjolfsson Andrew Mcafee).
46. 46
THE WEB GIANTS
Then excellence in execution becomes the other pillar. This operational
excellence covers:
the platform itself and the users it “hosts“: active users, quality of
the goods offered... quality in rating with numerous well assessed
offers...
offers which are mediated by the platform (comments, satisfaction
surveys...)
One may note in particular the example of AirBnB on the theme of
excellence in execution, beyond software, where the quality in the
description of the lodgings as well as beautiful photos were a strong
differential as compared to the competition of the time (Craig's List) (A
few words on the quality of the photos at AirBnB).
Critical market size
Critical market size is one of the elements which make it possible to rapidly
reach a sufficiently strong network effect (speed in reaching a critical size is
fundamental to not being overrun by copycats).
Critical market size is made up of two aspects:
Selecting the primary territories for deployment, most often in
cities or mega-cities,
Ensuring deployment in other cities in the area, when possible in
standardized regulatory contexts.
You must therefore choose cities particularly concerned by your value
propositions for your platform, where a sufficient number of early adapters
is high enough to quickly garner takeaways. Mega-cities in the Americas,
Europe and Asia are therefore choice targets for experimental deployments.
Lastly, during the generalisation phase, it is no surprise to see stakeholders
deploying massively in the USA (a market which represents 350 million
inhabitants, with standardised tax and regulatory environments, despite
state and federal differences) or in China (where the Web giants are among
the most impressive players, such as: Alibaba, Tencent and Weibo) as well
as Russia.
CULTURE / SHARING ECONOMY PLATFORMS
47. 47
THE WEB GIANTS
In Europe, cities such as Paris, Barcelona, London, Berlin, etc. are often
prime choices for businesses.
What makes it work for them?
As examined above, there are many ingredients for exponentially
scalable Organizations and business models on the platform model:
strong possibilities for employees to self-organise, the User eXperience,
continuous experimentation... algorithms (namely intelligent networking),
and leveraging one's community.
What about me?
For IT and marketing departments, you can begin your thinking by
exploring digital innovations (looking for new uses) that fit in with your
business culture (based e.g. on Design thinking).
In certain domains, this approach can give you access to new markets or to
disruption before the competition. A recent example is that of Accor which
has entered the market of independent hotels through its acquisition of
Fastbooking (Accor gets its hands on Fastbooking).
Still in the area of self-disruption, two main strategies are coming to the
fore. The first consists, based on partnerships or capital investments
through incubators, in coming back into the game without shouldering
all of the risk. The other strategy, more ambitious and therefore riskier, is
to take inspiration from these new approaches to transform from within.
It is then important to examine whether some of these processes can be
opened up to transform them into an open platform, thereby leveraging the
multitudes.
In the distribution sector for example, the question of positioning and
opening up various strategic processes is raised: is it a good idea to turn
your supply chain into a peer-2-peer platform so that SMEs can become
consumers and not only providers in the supply chain? Are pharmacies the
next on the list of programmed uberisations through stakeholders such
as 1001pharmacie.com? In the medical domain, Doctolib.com has just
leveraged €18 million to ensure its development (Doctolib raises funds)...
48. 48
THE WEB GIANTS
Associated patterns
Enhancing the user experience
A/B Testing
Feature Flipping
Lean Startup
Sources
• List of unicorns:
https://www.cbinsights.com/research-unicorn-companies
• Philippe Siberzahan, “Relevez le défi de l’innovation de rupture“,
édition Pearson
• Article by Maurice Levy on “Tout le monde a peur de se faire ubériser“
http://www.latribune.fr/technos-medias/20141217tribd1e82ceae/tout-
le-monde-a-peur-de-se-faire-uberiser-maurice-levy.html
• Lending Home present through “C’est pas mon idée“:
http://cestpasmonidee.blogspot.fr/2015/09/lendinghome-part-
lassaut-du-credit.html
• Nicolas Colin Henri Verdier, “l’âge de la multitude, 2nde
édition“
• Ashley Madison hacking:
http://www.slate.fr/story/104559/ashley-madison-site-rencontres-
extraconjugales-hack-adultere
• Second âge de la machine, Erik Brynjolfsson
• Quality of AirBnB photos:
https://growthhackers.com/growth-studies/airbnb
• Accor met la main sur Fastbooking:
http://www.lesechos.fr/17/04/2015/lesechos.fr/02115417027_accor-
met-la-main-sur-fastbooking.htm
• Doctolib raises 18M€:
http://www.zdnet.fr/actualites/doctolib-nouvelle-levee-de-fonds-a-18-
millions-d-euros-39826390.htm
CULTURE / SHARING ECONOMY PLATFORMS
53. 53
THE WEB GIANTS ORGANIZATION / PIZZA TEAMS
Description
What is the right size for a team to develop great software?
Organizational studies have been investigating the issue of team size
for several years now. Although answers differ and seem to depend on
various criteria such as the nature of tasks to be carried out, the average
level, and team diversity, there is consensus on a size of between 5 and
15 members.[1][5]
Any fewer than 5 and the team is vulnerable to outside
events and lacks creativity. Any more than 12 and communication is less
efficient, coherency is lost, there is an increase in free-riding and in power
struggles, and the team’s performance drops rapidly the more members
there are.
This is obviously also true in IT. The firm Quantitative Software
Management, specialized in the preservation and analysis of metrics from
IT projects, has published some interesting statistics. If you like numbers,
I highly recommend their Web site, it is chock full of information! Based
on a sample of 491 projects, QSM measured a loss of productivity
and heightened variability with an increase in team size, with a quite
clear break once one reaches 7 people. In correlation, average project
duration increases and development efforts skyrocket once one goes
beyond 15.[6]
In a nutshell: if you want speed and quality, cut your team size!
Why are we mentioning such matters in this work devoted to Web Giants?
Very simply because they are particularly aware of the importance of team
size for project success, and daily deploy techniques to keep size down.
[1] http://knowledge.wharton.upenn.edu/article.cfm?articleid=1501
[2] http://www.projectsatwork.com/article.cfm?ID=227526
[3] http://www.teambuildingportal.com/articles/systems/teamperformance-teamsize
[4] http://math.arizona.edu/~lega/485-585/Group_Dynamics_RV.pdf
[5] http://www.articlesnatch.com/Article/What-Project-Team-Size-Is-Best-/589717
[6] http://www.qsm.com/process_improvement_01.html
54. 54
THE WEB GIANTS
In fact the title of this chapter is inspired by the name Amazon gave to
this practice:[7]
if your team can’t be fed on two pizzas, then cut people.
Albeit these are American size pizzas, but nonetheless about 8 people.
Werner Vogels (Amazon VP and CTO) drove the point home with the
following quote which could almost be by Nietzsche:
Small teams are holy.
But Amazon is not alone, far from it.
To illustrate the importance that team dynamics have for Web Giants:
Google hired Evan Wittenberg to be manager of Global Leadership
Development; the former academic was known, in part, for his work on
team size.
The same discipline is applied at Yahoo! which limits its product teams in
the first year to between 5 and 10 people.
As for Vidaeo, they have adopted the French pizza size approach with
teams of 5-6 people.
In the field of startups, Instagram, Dropbox, Evernote.... are known for
having kept their development teams as small as possible for as long as
possible.
How can I make it work for me?
A small, agile team will always be more efficient than a big lazy team; such
is the conclusion which could be drawn from the accumulated literature
on team size.
In the end, you only need to remember it to apply it... and to steer away
from linear logic such as: “to go twice as fast, all you need is double the
people!“ Nothing could be more wrong!
According to these studies, a team exceeding 15 people should set
alarm bells ringing.[8][10]
[7] http://www.fastcompany.com/magazine/85/bezos_4.html
[8] https://speakerdeck.com/u/searls/p/the-mythical-team-month
[9] http://www.3circlepartners.com/news/team-size-matters
[10] http://37signals.com/svn/posts/995-if-youre-working-in-a-big-group-youre-fighting-
human-nature
55. 55
THE WEB GIANTS ORGANIZATION / PIZZA TEAMS
You then have two options:
Fight tooth and nail to prevent the team from growing, and, if that
fails, to adopt the second solution;
split the team up into smaller teams. But think very carefully before
you do so and bear in mind that a team is a group of people
motivated around a common goal. Which is the subject of the
following chapter, “Feature Teams“.
57. 57
THE WEB GIANTS ORGANIZATION / FEATURE TEAMS
Description
In the preceding chapter, we saw that Web Giants pay careful
attention to the size of their teams. That is not all they pay attention
to concerning teams however: they also often organize their teams
around functionalities, known as “feature teams“.
A small and versatile team is a key to moving swiftly, and most Web
Giants resist multiplying the number of teams devoted to a single
product as much as possible.
However, when a product is a hit, a dozen people no longer suffice for
the scale up. Even in such a case, team size must remain small to ensure
coherence, therefore it is the number of teams which must be increased.
This raises the question of how to delimit the perimeters of each.
There are two main options:[1]
Segmenting into “technological“ layers.
Segmenting according to “functionality thread“.
By “functionality thread“ we mean being in a position to deliver
independent functionalities from beginning to end, to provide a service
to the end user.
In contrast, one can also divide teams along technological layers, with one
team per type of technology: typically, the presentation layer, business
layer, horizontal foundations, database...
This is generally the organization structure adopted in Information
Departments, each group working within its own specialty.
However, whenever Time To Market becomes crucial, organization into
technological layers, also known as Component Teams, begins to show
its limitations. This is because Time To Market crunches often necessitate
Agile or Lean approaches. This means specification, development, and
production with the shortest possible cycles, if not on the fly.
[1] There are in truth other possible groupings, e.g. by release, geographic area, user segment
or product family. But that would be beyond the scope of the work here; some of the options
are dead ends, others can be assimilated to functionality thread divisions.
58. 58
THE WEB GIANTS
Functionality 1
Functionality 2
Functionality 4
Functionality 5
Team 1
- Front
Team 1
- Back
Team 1
- Exchange
Team 1
- Base
The trouble with Component Teams is you often find yourself with
bottlenecks.
Let us take the example laid out in Figure 1.
Figure 1
Theredarrowsindicatethefirstproblem.Themostimportantfunctionalities
(functionality 1) are swamping the Front team. The other teams are left
producing marginal elements for these functionalities. But nothing can be
released until Team 1 has finished. There is not much the other teams can
do to help (not sharing the same specialty as Team 1), so are left twiddling
their thumbs or stocking less important functionalities (and don’t forget
that in Lean, stocks are bad...).
There’s worse. Functionality 4 needs all four teams to work together.
The trouble is that, in Agile mode, each team individually carries out the
detailed analysis. Whereas here, what is needed is the detailed impact
analysis on the 4 teams. This means that the detailed analysis has to take
place upstream, which is precisely what Agile strives to avoid. Similarly,
downstream, the work of the 4 teams has to be synchronized for testing,
which means waiting for laggers. To limit the impact, task priorities have to
be defined for each team in a centralized manner. And little by little, you
find yourselves with a scheduling department striving to best synchronize
all the work but leaving no room for team autonomy.
59. 59
THE WEB GIANTS ORGANIZATION / FEATURE TEAMS
In short, you have a waterfall effect upstream in analysis and planning and
a waterfall effect downstream in testing and deploying to production. This
type of dynamics is very well described in the work of Craig Larman and
Bas Vodde, Scaling Lean and Agile.
Feature teams can correct these errors: with each team working on a
coherent functional subset - and doing so without having to think about
the technology - they are capable of delivering value to the end client
at any moment, with little need to call on other teams. This entails
having all necessary skills for producing functionalities in each team,
which can mean (among others) an architect, an interface specialist, a
Web developer, a Java developer, a database expert, and, yes, even
someone to run it... because when taken to the extreme, you end up
with the DevOps “you build it, you run it“, as described in the next
chapter (cf. “DevOps“, p. 71).
But then how do you ensure the technological coherence of the product,
if each Java expert in each feature team takes the decisions within their
perimeter? This issue is addressed by the principle of community of
practice. Peers from each type of specialty get together at regular intervals
to exchange on their practices and to agree on technological strategies
for the product being produced.
Feature Teams have the added advantage that teams quickly progress
in the business, this in turn fosters implication of the developers in the
quality of the final product.
Practicing the method is of course sloppier than what we’ve laid out here:
defining perimeters is no easy task, team dynamics can be complicated,
communities of practice must be fostered... Despite the challenges, this
organization method brings true benefits as compared to hierarchical
structures, and is much more effective and agile.
To come back to our Web Giants, this is the type of organization they tend
to favor. Facebook in particular, which communicates a lot around the
culture, focuses on teams which bring together all the necessary talents to
create a functionality.[2]
[2] http://www.time.com/time/specials/packages
article/0,28804,2036683_2037109_2037111,00.html
60. 60
THE WEB GIANTS
It is also the type of structure that Viadeo, Yahoo! and Microsoft[3]
have
chosen to develop their products.
How can I make it work for me?
Web Giants are not alone in applying the principles of Feature Teams. It is
an approach also often adopted by software publishers.
Moreover, Agile is spreading throughout our Information Departments and
is starting to be applied to bigger and bigger projects. Once your project
reaches a certain size (3-4 teams), Feature Teams are the most effective
answer, to the point where some Information Departments naturally turn
to that type of pattern.[4]
[3] Michael A. Cusumano and Richard W. Selby. 1997. How Microsoft builds software.
Commun. ACM 40, 6 (June 1997), 53-61 :http://doi.acm.org/10.1145/255656.255698
[4] http://blog.octo.com/compte-rendu-du-petit-dejeuner-organise-par-octo-et-strator-
retour-dexperience-lagilite-a-grande-echelle (French only).
63. 63
THE WEB GIANTS ORGANIZATION / DEVOPS
Description
The “DevOps“ method is a call to rethink the divisions common in
our organizations, separating development on one hand, i.e. those
who write application codes (“Devs“) and operations on the other,
i.e. those who deploy and implement the applications (“Ops“).
Such thoughts are certainly as old as CIOs but find renewed life thanks
notably to two groups. First there are the agilists who have minimized
constraints on the development side and are now capable of providing
highly valued software to their clients on a much more frequent basis.
Then there are the experts or “Prod“ managers, known as the Web Giants
(Amazon, Facebook, LinkedIn...) who have shared their experiences in
how they have managed the Dev vs. Ops divide.
Beyond the intellectual beauty of the exercise, DevOps is mainly (if not
entirely) gearing to reduce the Time To Market (TTM). Obviously, there are
other positive effects, but the main priority, all being mentioned, is this
TTM (hardly surprising in the Web industry).
Dev Ops: differing local concerns but a common goal
Organizational divides notwithstanding, the preoccupations of
Development and Operations are indeed distinct and equally laudable:
Figure 1
Seeking to innovate Seeking to rationalize
Local targets
DevOps
“wall of confusion“
Different
cultures
Deliver new functionalities
(of quality)
Guarantee application runs
(stability)
Product Culture (software)
Service Culture (archiving,
supervision, etc.)
64. 64
THE WEB GIANTS
Software development seeks heightened responsiveness (under
pressure notably from their industry and the market): they have to move
fast, add new functionalities, reorient work, refactor, upgrade frameworks,
test deployment across all environments... The very nature of software is
to be flexible and adaptable.
In contrast, Operations need stability and standardization.
Stability, because it is often difficult to anticipate what the impacts of
a given modification to the code, architecture or infrastructure will be.
Converting a local disk into a server can impact response times, a change
in code can heavily impact CPU activity leading to difficulties in capacity
planning.
Standardization, because Operations seek to ensure that certain rules
(equipment configuration, software versions, network security, log file
configuration...) are uniformly followed to ensure the quality of service of
the infrastructure.
And yet both groups, Devs and Ops, have a shared objective: to make
the system work for the client.
DevOps: capitalizing on Agility
Agility became a buzzword somewhat over ten years ago, its main
objective being to reduce constraints in development processes.
The Agile method introduced the notions of “short cycle“, “user
feedback“, “Product owner“, i.e. a person in charge of managing the
roadmap, setting priorities, etc.
Agility also shook up traditional management structures by including
cross-silo teams (developers and operators) and played havoc with
administrative departments.
Today, when those barriers are removed, software development is most
often carried out with one to two-week frequencies. Business sees the
software evolve during the construction phase.
It is now time to bring people from operations into the following phases:
65. 65
THE WEB GIANTS
Provisioning / spinning up environments: in most firms, deploying
to an environment can take between one to four months (even
though environments are now virtualized). This is surprisingly long,
especially when the challengers are Amazon or Google.
Deployment: this is without doubt the phase when problems come
to a crunch as it creates the most instability; agile teams sometimes
limit themselves to one deployment per quarter to limit the impacts
on production. In order to guarantee system stability, these
deployments are often carried out manually, are therefore lengthy,
and can introduce errors. In short, they are risky.
Incident resolution and meeting non-functional needs: Production
is the other software user. Diagnosis must be fast, the problems and
resilience stakes must be explained, and robustness must be taken
into account.
DevOps is organized around 3 pillars: infrastructure as code
(IaC), continuous delivery, and a culture of cooperation
1. “Infrastructure as Code“ or how to reduce provisioning and environment
deployment delays
One of the most visible friction points is in the lack of collaboration
between Dev and Ops in deployment phases. Furthermore this is the
activity which consumes the most resources: half of production time is
thus taken up by deployment and incident management.
Figure 2.
Source: Study by Deepak Patil (Microsoft Global Foundation Services) in 2006, via a
presentation modified by James Hamilton (Amazon Web Services), http://mvdirona.com/
jrh/TalksAndPapers/JamesHamilton_POA20090226.pdf
ORGANIZATION / DEVOPS
66. 66
THE WEB GIANTS
CMDB
Mustreflecttargetconfiguration
real-worldsystemconfiguration
configuration
OpenStack
VMWare vCloud
OpenNebula
VM instanciation / OS Installation
- Installation of Operating System
Bootstrapping
Capistrano
Custom script
(shell, python…)
Commandand
control
Application Service Orchestration
- Deploy application code to services
(war, php source, ruby, ...)
- RDBMS deployment (figure...)
Chef
Puppet
CFEngine
System Configuration
- Deploy and install services required for
application execution (JVM, application servers...)
- Configuration of these services
(logs, ports, rights, etc.)
And although it is difficult to establish general rules, it is highly likely that
part of this cost (the 31% segment) could be reduced by automating
deployment.
There are many reliable tools available today to generate provisioning
and deployment to new environments, ranging from setting up Virtual
Machines to software deployment and system configuration.
Figure 3. Classification of the main tools (october 2012)
These tools (each in its own language) can be used to code infrastructure:
to install and deploy an HTTP service for server applications, to create
repositories for the log files... The range of services and associated gains
are many:
Guaranteeing replicable and reliable processes (no user interaction,
thus removing a source of errors) namely through their capacity to
manage versions and rollback operations.
Productivity. One-click deployment rather than a set of manual
tasks, thus saving time.
Traceability to quickly understand and explain any failures.
67. 67
THE WEB GIANTS ORGANIZATION / DEVOPS
Reducing Time To Recovery: In a worst case scenario, the
infrastructure can be recreated from scratch. In terms of recovery
this is highly useful. In keeping with ideas stemming from Recovery
Oriented Architecture, resilience can be addressed either by
attempting to prevent systems from failing by working on the MTBF
- Mean Time Between Failures, or by accelerating repairs by working
on the MTTR - Mean Time To Recovery. The second approach,
although not always possible to implement, is the least costly. It is
also useful in organizations where many environments are necessary.
In such organizations, the numerous environments are essentially
kept available and little used because configuration takes too long.
Automation is furthermore a way of initializing a change in collaboration
culture between Dev and Ops. This is because automation increases the
possibilities for self-service for Dev teams, at the very least over the ante-
production environments.
2. Continuous Delivery
Traditionally, in our organizations, the split between Dev and Ops comes
to a head during deployment phases, when development delivers or
shuffles off their code, which then continues on its long way through the
production process.
The following quote from Mary and Tom Poppendieck[1]
puts the problem
in a nutshell:
How long would it take your organization to deploy a
change that involves just one single line of code?
The answer is of course not obvious, but in the end it is here that
differences in objectives diverge the most. Development seeks control
over part of the infrastructure, for rapid deployment, on demand, to all
environments. In contrast, production must see to making environments
available, rationalizing costs, allocating resources (bandwidth, CPU...)
[1] Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept
to Cash, Addison-Wesley, 2006.
68. 68
THE WEB GIANTS
Also ironical is the fact that the less one deploys, the more the TTR (Time To
Repair) increases, therefore reducing the quality of service to the end client.
Figure 4.
Source: http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-
change-4608108
In other words, the more changes there are between releases (i.e. the
higher the number of changes to the code), the lower the capacity to
rapidly fix bugs following deployment, thus increasing TTR - this is the
instability ever-dreaded by Ops.
Here again, addressing such waste can reduce the time taken up by
Incident Management as shown in Figure 2.
Figure 5.
Source: http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-
change-4608108
Deploys
Size of Deploy Vs Incident TTR
5 180
UnitsofChangedCode
TTR(minutes)
160
140
120
100
80
60
40
20
0
4
3
2
1
0
Sev 1 TTR Sev 2 TTR Lines Per Deploys Changed
CHANGE
SIZE
Huge changesets
deployed rarely
(high TTR)
(low TTR)
Tiny changesets
deployed often
CHANGE FREQUENCY
69. 69
THE WEB GIANTS ORGANIZATION / DEVOPS
To finish, Figure 5, taken from a Flickr study, shows the correlation between
TTR (and therefore the seriousness of the incidents) depending on the
amount of code deployed (and therefore the number of change to the
code).
However, continuous deployment is not easy and requires:
Automation of the deployment and provisioning processes: Infras-
tructure as Code
Automation of the software construction and deployment processes.
Build automation becomes the construction chain which carries the
source management software to the various environments where
the software will be deployed. Thus a new build system is neces-
sary, including environment management, workflow management
for more quickly compiling source code into binary code, creating
documentation and release notes to swiftly understand and fix any
failures, the capacity to distribute testing across agents to reduce
delays, and always guaranteeing short cycle times.
Taking these factors into account at the architecture level and above
all respecting the following principle: decouple functionality deploy-
ment and code deployment using patterns such as: Feature flipping
(cf. Feature flipping p. 113), dark launch… This of course entails a
new level of complexity but offers the necessary flexibility for this
type of continuous deployment.
A culture of measurement with user-oriented metrics. This is not only
about measuring CPU consumption, it is also about correlating busi-
ness and application metrics to understand and anticipate system
behavior.
3. A culture of collaboration if not an organizational model
These two practices, Infrastructure as Code and Continuous Delivery, can
be implemented in traditional organizations (with Infrastructure as Code
at Ops and Continuous Delivery at Dev). However, once development and
production reach their local optimum and a good level of maturity, the
latter will always be hampered by the organizational division.
70. 70
THE WEB GIANTS
This is where the third pillar comes into its own; a culture of collaboration,
nay cooperation, with all teams becoming more independent rather than
throwing problems at each other in the production process. This can mean
for example giving Dev access to machine logs, providing them with
production data the day before so that they can roll out the integration
environments themselves, opening up the metrics and monitoring tools
(or even displaying the metrics in open spaces)... Bringing that much more
flexibility to Dev, sharing responsibility and information on “what happens
in Prod“, which are actually just so many tasks with little added value that
Ops would no longer have to shoulder.
The main cultural elements around DevOps could be summarized as
follows:
Sharing both technical metrics (response times, number of
backups...) as well as business metrics (changes in generated
profits...)
Ops is also the software client. This can mean making changes
to the software architecture and developments to more easily
integrate monitoring tools, to have relevant and useful log files,
to help diagnosis (and reduce the TTD, Time To Diagnose). To go
further, certain Ops needs should be expressed as user stories in the
backlog.
A lean approach [http://blog.octo.com/tag/lean/] and post-mortems
which focus on the deep causes (the 5 whys) and implementing
countermeasures (French only).
It remains however that in this model, the zones of responsibility (especially
development, software monitoring, datacenter use and support) which
exist are somewhat modified.
Traditional firms give the project team priority. In this model, deployment
processes, software monitoring and datacenter management are spread
out across several organizations.
71. 71
THE WEB GIANTS ORGANIZATION / DEVOPS
Figure 6: Project teams
Inversely, some stakeholders (especially Amazon) have taken this model
very far by proposing multidisciplinary teams in charge of ensuring the
service functions - from the client’s perspective (cf. Feature Teams, p. 65).
You build it, you run it. In other words, each team is responsible for the
business, from Dev to Ops.
Figure 7: Product team – You build it, you run it.
BUSINESS
SOFTWARE PRODUCTION FLOW
MONITORING
(BUILD)
PRODUCTION
(RUN)
(Source: Cutter IT Journal, Vol. 24. N°8. August 21), modified)
Project Teams
Application
Management
Technical
Management
Service
Desk
Users
SOFTWARE PRODUCTION FLOW
PRODUCTS/SERVICES
(BUILD RUN)
PRODUCTION
Service Desk
Infrastructure
Users
(Source: Cutter IT Journal, Vol. 24. N°8. August 21), modified)
72. 72
THE WEB GIANTS
Moreover it is within this type of organization that the notion of self-
service takes on a different and fundamental meaning. One then sees
one team managing the software and its use and another team in
charge of datacenters. The dividing line is farther “upstream“ than is
usual, which allows scaling up and ensuring a balance between agility and
cost rationalization (e.g. linked to the datacenter architecture). The AWS
Cloud is probably the result of this... It is something else altogether, but
imagine an organization with product teams and production teams who
would jointly offer services (in the sense of ITIL) such as AWS or Google
App Engine...
Conclusion
DevOps is thus nothing more than a set of practices to leverage
improvements around:
Tools to industrialize the infrastructure and reassure production
as to how the infrastructure is used by development. Self service
is a concept hardwired into the Cloud. Public Cloud offers are
mature on the subject but some offers (for example VMWare) aim
to reproduce the same methods internally. Without necessarily
reaching such levels of maturity however, one can imagine using
tools like Puppet, Chef or CFEngine...
Architecture which makes it possible to decouple deployment
cycles, to deploy code without deploying all functionalities… (cf.
Feature flipping, p. 113 and Continuous Deployment, p.105).
Organizational methods, leading to implementation of Amazon’s
“Pizza teams“ patterns (cf. Pizza Teams, p. 59) and You build it, you
run it.
Processes and methodologies to render all these exchanges more
fluid. How to deploy more often? How to limit risks when deploying
progressively? How to apply the “flow“ lessons from Kanban to
production? How to rethink the communication and coordination
mechanisms at work along the development/operations divide?
73. 73
THE WEB GIANTS ORGANIZATION / DEVOPS
In sum, these four strands make it possible to reach the DevOps
goals: improve collaboration, trust and objective alignment between
development and operations, giving priority to addressing the stickiest
issues, summarized in Figure 8.
Figure 8
Faster
provisioning
Improved
quality
of service
Continuous
improvement
Operational
efficiency
Infrastructure
as Code
Continuous
Delivery
Increased
deployment
reliability
Faster incident
resolution (MTTR)
Improved TTM
Culture of
collaboration
74. 74
Sources
• White paper on the DevOps Revolution:
http://www.cutter.com/offers/devopsrevolution.html
• Wikipedia article:
http://en.wikipedia.org/wiki/DevOps
• Flickr Presentation at the Velocity 2009 conference:
http://velocityconference.blip.tv/file/2284377/
• Definition of DevOps by Damon Edwards:
http://dev2ops.org/blog/2010/2/22/what-is-devops.html
• Article by John Allspaw on DevOps:
http://www.kitchensoap.com/2009/12/12/devops-cooperation-doesnt-
just-happen-with-deployment/
• Article on the share of deployment activities in Operations:
http://dev2ops.org/blog/2010/4/7/why-so-many-devopsconversations-
focus-on-deployment.html
• USI 2009 (French only):
http://www.usievents.com/fr/conferences/4-usi-2009/sessions/797-
quelques-idees-issues-des-grands-du-web-pour-remettre-en-cause-vos-
reflexes-d-architectes#webcast_autoplay
THE WEB GIANTS
78. 78
THE WEB GIANTS PRACTICES / LEAN STARTUP
Description
Creating a product is a very perilous undertaking. Figures show that 95%
of all products and startups perish from want of clients. Lean Startup is an
approach to product creation designed to reduce risks and the impact of
failures by, in parallel, tackling organizational, business and technical aspects,
and through aggressive iterations. It was formalized by Eric Ries, and was
strongly inspired by Steve Blank’s Customer Development
Build – Mesure – Learn
All products and functionalities start with a hypothesis. The hypothesis can
stem from data collection on the ground or a simple intuition. Whatever
the underlying reason, the Lean Startup approach aims to:
Consider all ideas as hypotheses, it doesn’t matter whether they
concern marketing or functionalities,
validate all hypotheses as quickly as possible on the ground.
This last point is at the core of the Lean Startup approach. Each hypothesis,
from business, systems admin or development - must be validated,
for quality as well as metrics. Such an approach makes it possible to
implement a learning loop for both the product and the client. Lean Startup
refuses the approach which consists of developing a product for over a
year only to discover that the choices made (in marketing, functionalities,
sales) threaten the entire organization. Testing is of the essence.
Figure 1
IDEAS
PRODUCTLEARN
BUILD
DATA MEASURE
