It's the Stack That Matters
LAMP makes Linux. Although Linux is great, for many application developers it’s not Linux that matters. It’s not Apache that matters. It’s the stack that matters. The stack answers basic technical questions so you can move onto more pressing application related issues. Linux is the base operating system, Apache is the web server, MySQL is the database and PHP is the scripting language. Could you replace parts of that infrastructure? Sure. You could use HP/UX, Sun Web Server, Ingress and Perl. No one knows HSIP. People know LAMP. They write books on LAMP. They write software around LAMP and for LAMP and assume that MySQL will be the database, as they assume it will run on Linux with PHP under Apache.
Other famous stacks are MVS/COBOL/CICS on IBM mainframes. It’s a stack that people understand. They know going into that environment that they will issue commands in JCL to get things done. They know they will store data in a given way. Transactions will be handled by a given subsystem. They know COBOL will always be there to write new code. They know their way around TSO. Knowing COBOL is fine, but to have real value you need to know the whole stack. COBOL is almost useless in the minds of many without z/OS and CICS.
A stack has longevity. The more applications are written around a stack, the more people get to know and love (or hate) a stack, the more the network effects will take over. Will we see PHP 9.3 with Linux (kernel) 4.1 running MySQL 7.5 in 2015? Sure we will. People will invest in a stack and decide it’s better to fix or upgrade this one part of the stack then to throw out the whole stack. They will be loath to replace pieces of the stack. The other pieces of the stack will be influenced by how the rest of the stack evolves.
Loose pieces don’t matter. Take the HSIP example. It may make for an awesome web platform but the temptation will be to replace the pieces. Why Ingres? Why not MySQL – more people know it. There’s probably a good business, if not technical, reason for favoring MySQL if you can replace it without too much hassle. Why Perl? Why not add PHP? You might know a really good PHP person. And of course, when it’s time to upgrade the box, why not Linux? More people know Linux-isms than they know HP/UX commands. The stack has mass from all those network effects. It has a kind of gravity – pulling in users and developers.
Eventually loose pieces will go away. They will be either be replaced by the stack or they will be periodically re-invented. The company deploying HSIP today may replace bits and pieces over time, attempting to find a stable solution. Unless people start coalescing around that aggregation of pieces, it will become something else in 5 years. The stack is your friend. But only if you treat the stack as a whole, as an ecosystem, as your platform. Don’t think of what individual pieces can do for you, think of what the stack does for you.
Of course, no one wants to stay in the same stack for years and years. A stack shouldn’t be a black-hole, sucking in all those in its orbit, trapping them forever. Rather a stack, once established, is a saddle point at which problems find solutions. New stacks form as technology changes. The new stacks are forming around Ruby on Rails and other dynamic frameworks. It’s early, but the outlines of common patterns are solidifying and the ‘dynamic language stack’ is starting to take shape.
Once formed, however, these dynamic language stack will be stable. Developers promote their experience with the stack, vendors sell software for the stack, hosting companies provide instances of the stack. The virtuous circle builds and the ecosystem is born around the stack. Pragmatic Programmers has an array of Ruby and Rails books available. Companies like Heroku are finding ways to deliver the stack. And, of course, we’re some of the developers bringing experience and development expertise to companies looking to the stack to solve their problems.
Up Next: Developer as (Fashion) Designer by
Previously: Content Is King by