How much do developers really need to know about infrastructure? I read an article recently about developers becoming further removed from the infrastructure. Which on the surface sounds pretty good. Tools make you more productive, auto generating this and that. But how does that play out in the integration landscape? The more abstracted the developer becomes from the underlying infrastructure, the less likely the developer is going to be able to deliver reliable integrations. So what does that really mean?
Integration reliability depends on the developer understanding the infrastructure. What happens when the network is down? What happens when a database connect fails? What happens if two targets are updated but the third one fails? How does the integration respond to the various runtime errors that can occur when traversing multiple distributed systems? Most of this stuff takes place asynchronously making the matter even more difficult. I plan sharing some my experiences with designing for these types of events in the integration layer. Some of the hard lessons learned.
1 comment:
I'm a big fan of being a mile wide and, well, pretty deep, too.
Perhaps if the developer is "sheltered" by an effective IT organization that provides the appropriate layers of review to inspect-in coding to handle the things that can go wrong in the infrastructure layer, then the developer doesn't have to understand much about things outside of the development tool.
However, solid understanding of hardware, OS, network, security, database issues are absolutely essential to being a good architect or an effective consultant.
I can't count the number of times that I've taken on a new client only to find out that I'm the most knowledgeable about their own infrastructure within a matter of a few weeks (OK, sometimes a few days).
Developers and Infrastructure... don't kid yourself you gotta know it to be good.
-M
Post a Comment