Yesterday we had the monthly Webtuesday meeting in Zürich, Switzerland. Chris and myself showed in quite some detail how we are building the Memonic platform from a technical point of view. We presented our usage of HTTP web services, presented some services as examples and showed what technologies and products we use to power the platform.
See the slides (PDF, 400k) for lots of details.
Additional background information is available from past talks:
Yesterday the Internet Briefing Developer Conference took place in Zurich, Switzerland. All the talks were about current technology trends and were of great quality. I did a talk about scalable applications with HTTP - basically I showed how we build our architecture at Memonic.
The background material is available in a separate Memonic Set for the HTTP Scalability presentation. That Set also includes the Slides.
At Memonic we use a lot of Amazon's cloud services. I talked about our experiences with those at yesterday's Cloud Suisse conference in Zürich, Switzerland. The presentation (PDF, 1MB) is in German, but most of the information is in the graphics anyway.
I also created a Memonic Set for this presentation with some background material and additional links.
Thanks to the Cloud Suisse committee for organizing the interesting conference!
Today I am attending the Google Travel Summit here at Google Zurich. An interesting mix of Google folks and startups like RouteRank, TouristWay, TripSay, Gekko, YourTour, HouseTrip, TripWolf, GetYouGuide and ourselves.
Funny question of the day: What do you do different than Google Notebook? Answer: Google Notebook is no longer. ;-)
Heute Abend spreche ich bei Reto Hartinger's Internet Briefing über neue Technologien für ein interessantes Web-Erlebnis. Am konkreten Beispiel zeige ich, welche Erfahrung wir mit Friend Feeding, Remix the Web, skalierbaren Infrastrukturen, etc. gemacht habe.
Die Slides sind hier hinterlegt (PDF, 205kb), ein Memonic Set mit den wesentlichen Links und Erkenntnissen ist hier zu finden.
I held a presentation today at the Internet Briefing. Find the slides (in German) and the code samples below:
“When our first parents were driven out of Paradise, Adam is believed to have re-marked to Eve: ‘My dear, we live in an age of transition’.” (Inge 1929)
We started out a couple of months ago with this series on scalable startups with a reflection on organizations as lump of butter in a sea of milk. Organizations are social arrangements. Hence our next focus was the core constituent of any organization: Its people. A well-crafted strategy is worthless without a committed crew. The focus on people is core to what we do. Nonetheless, an organization is no end in itself. The fuel that drives the engine forward is customer needs. We cherish users like nothing else: They come first.
We argued forcefully for smaller organizations. Instead of large anonymous corporate monsters we made a case for smaller and nimbler units. We also outlined how to maximize involvement and reduce the useless part of management: Let people decide. To put these decisions into action we rely on a project methodology – Scrum – that finely aligns overall goals, immediate tasks, people and resources.
A particular issue we dealt with is how to get work done. Instead of word wilderness and excel wasteland we draw on the advantages of Wikis for documentation and a powerful task tracking tool. Both tool sets are completely web-based and accessible from everywhere.
In terms of actual setup and operation of an online platform we learned a lesson or two from our previous engagement at local.ch. A must is a shared nothing architecture plus automated building of the software application. To ensure consistency and reliability we made testing a daily priority.
The virtualization options available today are essential for a startup. We can cut down very considerably on our asset investment in servers and other bulky infrastructure items.
The outlined setup of a scalable startup is very much the realization of what Peter Drucker sketched out in his essay on The coming of the new organization over twenty years ago:
“The typical large business 20 years hence will have fewer than half the levels of management of its counterpart today, and no more than a third the managers. In its structure, and in its management problems and concerns, it will bear little resemblance to the typical manufacturing company, circa 1950, which our textbooks still consider the norm. Instead it is far more likely to resemble organizations that neither the practicing manager nor the management scholar pays much attention to today: the hospital, the university, the symphony orchestra. For like them, the typical business will be knowledge-based, an organization composed largely of specialists. … For this reason, it will be what I call an information-based organization.”
A little over two decades later, the startling development of the Internet has driven much of the transformation from an industry-based economy to an information-based economy. Multilevel hierarchies have given way to clusters of business units coordinated by market mechanisms rather than by layers of middle management. The large enterprise structures designed for the business environment of the 1950s and 1960s – firms that typically sought economies of scale through central planning and control mechanisms – are quite likely not the most adroit forms at meeting the current competitive environment that demands both efficiency and effectiveness. Companies track opportunities and resources on a global scale. In an attempt to maximize return on assets, firms perform only those functions for which they possess or can develop expert skills. Activities that can be performed quicker, more effectively or at lower cost by others are outsourced. An intricate network of formal and informal relations ties the firm together. The momentum is paced by information technology.
Back in 1978 Hiltz and Turoff summarized this phenomenon as follows:
“We will become the Network Nation, exchanging vast amounts of both information and socio-emotional communications with colleagues, friends, and ‘strangers’ who share similar interests. ... we will become a ‘global village.’ ... An individual will, literally, be able to work, shop, or be educated by or with persons anywhere in the nation or in the world.”
True.
_______
Series Overview
_______
Drucker P.F., “The Coming of the New Organization”, Harvard Business Review, January - February 1988, pp. 45-53.
Hiltz S.R. and Turoff M., The Network Nation: Human Communication via Computer, London: Addison-Wesley, 1978.
Inge W.R., Dean of St.Paul’s London, Assessments and Anticipations, London, 1929.
To strive for perfection but fall two steps short, is all but human. I remember with mixed emotions the German classes back at school. Quite often we had to do essays on this or that topic. Quite often I got good marks for essay’s idea and its composition just to loose a couple of points for (surely involuntary) grammatical inadequacies.
Writing software is pretty similar: The most elegant lines of code will be undone by mundane errors.
Error recognized, error fixed, or so they say. Yet research shows that on average for every six errors fixed, one new error is introduced. Kind of never catch up game. Similar to the anecdote of Achilles, who is not able to catch up with the turtle.
A scalable website is a complex beast. Even in it’s simplest form it is a web of thousands of lines of code, several servers and services.
Humans perform mostly well in conditions of relative uncertainty. Computers not. Whereas we are able to adapt to situations, computers fail abysmally at tasks that are not clearly specified and where there is no error free code to execute. An unrecognized set of characters in a get request and the receiving web service goes havoc. A minor glitch in a sub-routine and the transaction fails.
Thus the importance of testing.
Testing comes in a number of flavors. Every developer agrees that code should be tested. However, testing on an individual code level is not enough. Especially hard it gets if you have to take over legacy code with little test coverage. My colleague Patrice suggests two simple rules:
Here at Nektoon our goal is to cover as much code with tests as possible and sensible. We don't reach 100% coverage but accept one or two percent less. Going all the way to 100% will drive you crazy, as there is a lot of code, which hasn't been written with testability in mind. Testing such code while possible would be a lot more work.
A certain level of error is an acceptable outcome for a system like ours. A simple solution is some redundancy to be built in.
We consider testing integral to our work. Before automatically building the application (also referred to as continuous integration – see previous post on automation) any piece of code must be thoroughly tested.
The equation is simple: What will the additional time investment in testing yield in terms of benefits? The answer: A lot! Simpler code, more reliability, less onerous bug fixes, and less disappointed users because our service was down.
We believe in testing. Over on his personal blog, Patrice commenced a series specifically dedicated to testing. Over the next few weeks he will write about selection and setup of a testing framework, unit and functional testing, Javascript testing, continuous integration, test-driven development, testability and measuring coverage.
Next in the series how to build a scalable startup: Conclusion.
Quite unnoticed by the casual Internet user a silent revolution took place in the server centers around the globe.
I fondly remember that cold Christmas 2000 when our company delta consulting (later namics), a Web consultancy, moved to a new location. We had to move the server room, too. No easy undertaking. We had dedicated servers for a number of clients, our internal development and staging servers, filers, mail servers etc.
But we had a noble goal: finally some space again! Our old and crammed server room couldn’t hold more servers. Our new room seemed large and spacious. We continued to grow and soon we were once again mired in finding additional space.
Recently I returned to visit my former workplace just to find three quarters of the room converted into a meeting room.
How come?
How does Virtualization work? Companies like Parallels, VM Ware, Citrix and others provide software allowing to emulate or “virtualize” the hardware resources of a machine. The ubiquitous x86 type computer infrastructure was designed to run a single operating system and a single application. This leaves most machines vastly underutilized. Virtualization lets you run multiple virtual machines on a single physical machine, sharing the resources of that single computer across multiple environments.
Sure you loose a bit of performance because the virtualization software mimics the actual physical hardware. With ever faster machines and ever more memory this is no roadblock to virtualization. There are however two big gains: Less space and less initial investment.
At Nektoon we have just a single server for the entire development platform. Roughly twenty or so virtual servers are running on top of it. Especially welcome for our startup: Instead of twenty servers we bought one. Albeit a bit more expensive, our initial investment was still a fraction of a normal setup. Nekton.com
Our live infrastructure is hosted on Amazon Web Services. This has one key advantage: We do not need to invest time and money in setting up a live infrastructure but instead pay-as-we-go at Amazon. With the automation in place (see previous post) we have contained the sheer volume of repetitive setup tasks. Plus we let others solve these tasks.
The distributed infrastructure also allows you to get closer to your customers. In case of physical servers we would have chosen close-by server centers for purely practical reasons (Physical reboot of a machine). Yet somebody from the US will have quite longer response times when accessing servers at some place in Switzerland instead of someplace in the US itself. The distributed infrastructure of Amazon provides a neat framework for this case: Distributed storage and processing power across the globe. So we will store the notes of our American customers in America and vice-versa with notes in Europe.
Next to the technical benefits the impact on the business plan is remarkable: We can run a startup on a shoestring for quite some time.
Next in the series how to build a scalable startup: Testing.
The previous post outlined our architectural approach to a scalable website. This post outlines our approach to building such website. Our solution in a single word: Automation.
Some hundred years ago industrial production of goods such as cars was still a craft-based production. Ford introduced the moving assembly line and heavy automation. By standardizing productivity increased tenfold. Prices for a model T were cut from $760 to $360*.
A little less known is the information that Ford based his standardization on the work of Taylor. Taylor's gospel also known as "Taylorism" or Scientific Management standardizes tools, employs precise task allocation, does time studies (e.g., screw on each bolt in 15.2 seconds), introduces performance pay, and automates by repetition**.
So do we.
Setting up a server manually is time consuming and error prone. To install Debian – our operating system of choice – we make use of Fully Automated Installation – FAI to, well, automate server setup. FAI uses a collection of Perl and shell scripts for the installation process.
Picture by Ford
On the next level we use Puppet for automating system administration tasks. Instead of manually running through all those application setup tasks Puppet introduces a declarative language. This language provides a framework to express the relationships between servers, the services they run and the objects that compose those services.
At first it takes some time to get familiar with this language and a couple of early Puppet scripts were a bit frustrating. Yet it is worth it: The time it takes to write the puppet module that potentially runs on dozens of machines is actually often less than executing the administration task on a single server. Once you master the initial obstacles you cut huge chunks of time and pain out of the process of administrating a distributed server and services landscape.
The last part is code deployment. There we use Hudson. In a nutshell, Hudson (like a number of other systems) provides an easy-to-use so-called continuous integration system. The system does two jobs: First, it allows software developers to easily integrate changes to the software and second, it provides for an automated and continuous building and testing of software projects. Once done, Hudson / Puppet push the code to our development and live systems without human intervention.
This automated setup of our core infrastructure increases the productivity of our team dramatically. Instead of investing time at unnecessary places – server setup – we can focus on what matters most: An application that wins the minds and hearts of our users.
Next in the series how to build a scalable startup: Virtualization.
_______
*) Interestingly enough not all of the cost advantages were due to introduction of the assembly line and the involved productivity gains. A lot was owed to a focus on reduced material costs (PDF Document). The equivalent today is greatly reduced hardware costs (More on this and virtualization in the next post).
**) Taylorism would quickly become the standard for businesses worldwide. Fordism and Taylorism would be hotly contested for unfairness towards workers. But that is another story.
| More memonic photos |
