(most) code is now a liability

When I started in this industry, it was difficult for companies to create code that other people cared about and would purchase access to. As open source philosophies proliferated and software construction tools improved over time, the trickle of code became a flood. The world is now swimming in code.

Access to code for any task in any context is now practically assumed. Most established organizations have some internal code; at one time this code was considered an asset. I believe a sea-change will soon sweep industry and code will begin to be seen as a liability.

Organizations have underestimated the tendency of code to rot, dragging down those who cling to aging, poorly written codebases. People come and go, requirements change, but the costs of pulling codebases forward is too great for many, and as a result otherwise viable organizations are strangled by their own means of production.

Some winning solutions are emerging as we finally figure out how to build business software. Many large organizations driving the change may profit from their ability to improve the means of production as much as from their final products. This can be seen historically in the examples of Henry Ford and Alfred P. Sloan, who not only profited from making cars, but achieved dominance for the way they made cars.

In my opinion hosted APIs like AWS, Azure and Google Compute Engine (GCE) are pointing the way forward. They represent the first opportunity to grow software-related businesses while reducing the growth of internal frameworks. We now know enough about how networked software will work (storage, compute, analysis, etc), that we can encapsulate useful methods in widely applicable APIs that can be distributed at scale. By utilizing these APIs, not only can internal frameworks be tamed, but operational commitments can be reduced and often eliminated. As bad as small/medium organizations are at software, they are even worse at ops. The potential for higher quality solutions (correctness, security, performance) is also a possibility since efforts can be focused on fewer services. That cloud vendors are forcing separation of concerns into design processes is a bonus all systems architects should be thankful for.

"Hybrid clouds" are simply not an alternative to this emerging model at all. Hybrid clouds merely deliver new encapsulation methods (Docker etc) to better contain our awful internal framework code. To be certain, a standard container approach is obviously welcome, but at this point it should be considered an implementation detail and not a solution on its own. Adopting many of the emerging hybrid cloud solutions merely adds thousands of lines of beta-quality container orchestration code to your internal framework. We don't want more code (and ops obligations), we want less.

To the leaders in the cloud space, this is all obvious, which is why none of the "big three" bother putting much effort into hybrid solutions. They already have something easy to use that provides global scale. They have moved beyond renting capacity; they are moving towards distributed operating systems. Others in the field who cannot afford to undertake the massive build-out to create similar systems will likely whither away. Within a decade, companies owning servers may become as rare as companies owning their own headquarters. What once was an asset is now a liability.

The first counterargument to hosted APIs is lock-in. But lock-in is always there. You are locked in to operating systems (even free), programming languages (even free), people, hardware, ops. Every design decision made with regards to software systems implies some degree of lock-in as there is a cost to undo these decisions. So far, competition in hosted APIs have kept prices reasonable and vendors respectful of choice.

Another common counterargument to hosted APIs is security. It is true that you do not get physical access to a cloud instance, and hosted APIs always live on shared resources. That said, you share access to your co-location facility as well, and you simply have no idea if someone is tampering with your hardware. You may have a key to a cage but so may someone else. Those who have legitimate high-security needs would simply never entertain either hosted APIs or shared co-location facilities.

One legitimate concern is performance. In applications that are LAN-bound, precise performance requirements can require full access to hardware. Some cloud vendors are providing this, but that is an edge case for the hybrid cloud, not hosted APIs. For those with specific performance requirements, hosted APIs may not yet be a reality. That said, for WAN applications that have global requirements, you will almost certainly be working with a third-party, either through a hosted API or a CDN.

last update 2015-07-14