Reflecting on holidays

As the holiday rush is winding down, I sit here reflecting on all the companies that lost business/revenue over the past few days. Loss of business not because of technology failure, although this is always a manifestation of a problem, but because of process failure in order to remedy the failures of technology. I’ve offered some tips on preparing for the holiday traffic from the system architecture perspective, but perhaps I should’ve concentrated on preparing for the rush from the organizational perspective.

Read More…

PHP performance 101: so you need to use a database

The talk I gave at PHP World in Washington, DC. In this talk I presented the most common database-related performance bottlenecks that can happen in most PHP applications.

Read More…

Improving DevOps through monitoring

The talk I gave at Cloud Expo in Santa Clara, CA as part of DevOps Summit program. This talk was based on my real-world examples of common gaps in monitoring approach and explain why holistic instrumentation of business and functionality monitors should be a part of any project scope.

Read More…

[something] Devops

Yesterday, at the #watercooler, we were talking about the principals of devops (and how they were applied before the term was cool) and sharing war stories about organizations that preferred to intentionally wall off individual technology groups. Conversation turned to how running the code in production is the only measurable way to validate developers code, and instilling the culture that shares the responsibility for production readiness between operations and development teams is the way to go. As we were talking about it, I realized that despite the fact that majority of developers firmly believe that “It worked on my laptop” is a piss poor excuse for production failures, most don’t truly understand why it is virtually impossible to make your development environment representative of production.

Read More…

All the wrong reasons

Everything happens for a reason.
Sometimes that reason is you’re stupid and make bad choices.

A few months ago I attended Node Summit in San Francisco, dedicated to success stories around node.js implementations in large architectures. There were a couple of very educational war stories (particularly, the so-called, “boring” Walmart Black Friday case study, presented by Eran Hammer), but, this rant is not going to be about how awesome node.js is. This rant is going to be about bad decisions. Those that are still being made in the world of technology, driven by false premises, wrong reasons and buzzword bingo.

Read More…

How to make enemies

Every developer blames his or her predecessor. Whenever we get to work on, or maintain, a codebase that was developed by someone else, the first impression is always a negative one. Along with second, third, forth…up to nth. Someone else’s code is always worse than what we would’ve developed, given the opportunity. The design is wrong. The code is messy. There is insufficient documentation. The problem could’ve been solved in a more efficient way. Variable names too short. Variable names too long. Truth of the matter is – even when we look at our own code years later (and sometimes much sooner) we criticize it in exactly the same fashion. But after years of dealing with unrealistic deadlines, last minute changes in requirements, and “visionaries”, who cannot explain what they want, yet want it to work exactly the way they envision it, I’ve learned to make a distinction between “necessary evil” and complete incompetence.

Read More…

Time heals everything

Many years ago I was working with a very large customer, both from user-base and traffic perspective, with a pretty interesting business model at the time. Their MO was that, “time to market” is everything. And I mean everything. With the vast majority of their initiatives they were willing to launch the initiative today, knowing that there is a potential that it will fail for 20% of the users, rather than tomorrow, knowing that it those issues will be fixed by then. As a developer, that mentality drove me insane.

Read More…

Blame game

Every technologist has a technology preference. PHP vs Perl, MySQL vs PostgreSQL, Chef vs Puppet, Microsoft vs … well, pretty much everyone else. However, good technologists know the advantages and disadvantages of different tools to make the argument pro or against one of them. Others just blame technology for their own lack of knowledge.

Read More…

Let’s get personal

Last week, I was doing some research about my upcoming trip to Tanzania. I was browsing the web, looking for good deals on trip packages, reading feedback and comments from people who went on a similar trip, checking prerequisites (shots, visas)–basically general research anyone would do when going on a trip to a place where they’ve never been, or looking to buy a new product and trying to choose from the selections. Later that week I was checking my Gmail account, and, what do you know? The news ticker above the email showed me: NYT Travel – Next Stop: Off Tanzania, Serene Mafia Island. Obviously the article was targeted specifically to me, based upon my research over the few previous days, and it did provide me with some new information. But, is it a valuable service that companies provide, or an invasion of privacy–an abuse of the collected data that was never meant to be public?

Read More…

In search of unknown

I’ve talked at length about the importance of business process monitoring alongside of system monitoring, but in discussions I found that sometimes an overview and simple examples are not enough to convince people about the benefits of this approach. Business owners think they don’t need to know anything about the operational performance of their systems as long as they have their numbers, and engineers often don’t feel they need invest time into understanding the business they are supporting in detail, finding examples shown too “common sense.”

Read More…