I read about “Pro Website Development and Operations” at Tom Limoncelli’s site, so I immediately marked it on my list of books to buy. A few days later Apress held a $10 ebook sale on every title they had, so I bought it. The good news first: The epub version of the book renders nicely on my BeBook Mini.
I have not written a book yet, but I know one when I read one. And this is not a book. It is a series of good long blog posts expanded to fill the size of a book (124 pages). It was not very well proof read so that it has many grammatical and syntactic errors and some others like “you might have several hundred servers in the subnet 10.10.20.0/24,”. You can have a couple hundred servers on a /24 but not three hundred so it is not some, sorry. A trivial mistake, but indicating of things that can annoy you in the book.
The word engineering and its derivatives is overused. There’s a reason that the intended audience of the book are DevOps and not engineers, or software engineers (even though there exist people who can carry all three hats). And that is that they are not. There is a great difference between engineering a solution and calling everyone on board an engineer. That is unless what you build has a direct impact on human lives (or loss of them) or is something that when failing can cause a national economy to go under or a disaster of a similar magnitude.
An interesting thing about the book is that it talks a lot about the significance of measurements in order to understand a site’s usage patterns. However there is not a single formula or methodology mentioned which the read can use in order to measure things! It is more along the lines of “you need to measure stuff because it is important” but nothing about how to measure or how to lay out a plan for a measurement infrastructure. Because forecasting performance is a must in website development and operations, I was expecting something like “Forecasting Oracle Performance“. I was also expecting hints on how to size a new server. Of course I will size a new server carefully, but I bought your book not to read generalizations, but how you actually do it. Again no formula (if you want to see some interesting mathematics on the subject, see “Mathematical Server Sizing“). We need to model stuff, so where is how I build and test a model?
Another thing I take issue with is the special projects team that the author advocates. The author is right in advising rotating roles between members of the special projects team in order to diffuse knowledge among them, but I believe that he has managed to be a member of special project teams only. Otherwise he would have described the impact on the morale of the operators who are not members of the special team that builds exciting new projects. Projects that it that get the budget, get to use new technologies and hardware to experiment on, while the rest must work on (a restricted) budget to maintain a (legacy) system that already brings money on the table. So in fact you not only have to rotate people among roles in the special projects team, you have to rotate them in and out of the team too. This also brings the advantage of avoiding the build up of IT silos or other small dominions with a single point (the operator) of failure.
Is there anything good in this book? Taking good care of your people and their health is one. Making it sure that they get proper sleep, even before launching is important. Not only for the health of the workers, but for the health of the company (and its culture) too.
In its effort to be technology agnostic so as to stand the test of time, the book suffers from generalizations and is disconnected from practice. Wait for the second edition.