There is a general truth about better competitors. This truth applies at any scale. It applies to cultures, nations, companies, teams, and individuals. That truth is that better competitors are faster and more agile.
In this context, being faster means being able to execute the collective actions required to achieve an intended objective at a higher rate than the competition. That objective may be relatively simple, such as winning a 100-meter sprint. Or, that objective may be complex, such as winning a war or conquering a particular market. The simple tenet is that he who is faster at executing tends to win.
Being more agile means being able to readjust one’s methods of execution in response to external conditions faster than the competition. In sports, the more agile team can regroup and alter tactics if a key player is injured – thereby compensating for the loss – faster than the opposing team. In military conflicts, the more dominant army is able to alter the war plan and successfully execute it faster than the enemy. In other words, being agile means having the capability to learn fast and put that learning into practice quickly.
Because of Moore’s law, lean manufacturing techniques, and standardization, general-purpose computing hardware costs have been decreasing steadily and rapidly for the past few decades. This has been true for CPUs, storage, and networking when measured against GHz, GB, or Gbps per dollar. With this backdrop, and as Marc Andreessen famously said, software has been “eating the world.”
In large part thanks to lower hardware costs, software development costs also have plummeted over the years. However, Linux and the open source movement inspired other important players in this trend. With ever more capable development frameworks, well-proven software stacks, and an increasingly more powerful and ubiquitous operating system that is essentially free, relatively small development teams have the capability of creating complex and excellent and software in progressively shorter durations.
Finally, because of cloud computing and the intense competition between a few major providers, infrastructure capital investments required to produce and productize code have gone towards zero (or more accurately, they have been swapped for operational costs on a pay-for-what-you-eat model).
Lower hardware, software, and development and deployment infrastructure costs are general goodness. They apply equally to all parties demanding them and are akin to the atmospheric oxygen that everyone breaths. They are great democratizers and, precisely because of this, while they deliver general economic benefits to all, they do not favor any single company and make it more competitive. Competitive companies, those who are faster and more agile, have other secrets that keep them ahead of the pack.
Consuming software used to mean buying a shrink-wrapped package, installing it on a particular machine, and upgrading it periodically to fix bugs or get access to new features. Delivering and installing patches on-line was a breakthrough: instead of getting a CD or downloading an ISO image, more innovative software packages had the ability of contacting a server on the internet, checking for updates, and automatically downloading (and even deploying) it. This practice led to the insight that software itself could be a service, in that features, whether executed locally on a PC or remotely on a server, could also be delivered on demand, thereby circumventing much of the download and installation cycle. But, as long as software development itself was bound to the waterfall model where monoliths were delivered periodically – whether as a new product or an upgraded service – there were limits to the speed and agility that could be garnered from these new patch and feature delivery methods.
As such, the secret of staying ahead of the pack was breaking with the waterfall development model. Agile development processes were developed to allow software teams to focus on smaller features for a shorter period of time and repeating the process as necessary in the quest for hitting release milestones. Monolithic software architectures were giving way to SOA – service oriented architectures – where instead of a big functional blob, a group of smaller functional blobs, called services, coordinated actions to form more complex software packages.
After agile development became a standard practice with the vanguard of the software industry, microservices started to permeate software, essentially taking SOA architectures to their natural conclusions. “In contrast to SOA, microservices gives an answer to the question of how big a service should be and how they should communicate with each other. In a microservices architecture, services should be small and the protocols should be lightweight. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it much easier to change and add functions and qualities to the system anytime. It also allows the architecture of an individual service to emerge through continuous refactoring, hence reduces the need for a big upfront design and allows for releasing the software early and continuously.” [source]
By disaggregating larger blobs into smaller, manageable microservices, it became possible to release software “early and continuously.” By shifting away from waterfall development models and towards DevOps, where development scheduling is modeled after Just-In-Time manufacturing, it became possible to massively increase software engineering efficiency and improve the quality feedback loop throughout the process. A few farsighted development shops grasped the significance of DevOps and microservices early and implemented them in practice. As a consequence, they were able to gain an “unfair advantage” in their respective markets by having the ability to be faster and more agile than the competition: Not only could they release software with new capabilities faster, their development practices allowed their organizations to learn and adjust more quickly to external inputs.
“Unfair advantage” should be quantified so that its context is clear. It is undisputed that Amazon, Facebook, and Google are the 800 pound gorillas of online retail, social networking, and search respectively. “Amazon is on record as making changes to production every 11.6 seconds on average in May of 2011. Facebook releases to production twice a day. Many Google services see releases multiple times a week, and almost everything in Google is developed on mainline.” [source] In their respective markets, these armies have won the war. They were simply faster and more agile than their rivals who, in the words of Peter Thiel, are failing to escape competition.
DevOps and microservices are starting to permeate software engineering teams more broadly. There are companies who are – effectively – pure software shops but happen to run a business, such Uber and Airbnb. This category of businesses, whether they are established, larger companies or recently-formed startups, have adopted these practices universally. There are also companies that rely heavily on software to run more traditional business, such as financial firms or high-end manufacturers. In this category of companies, if an individual firm continuously produces strong financial results or has the capability to innovate rapidly, it is nearly certain that part of that company’s sustained strong performance relies on having the right software development methods that allow them to run faster and be more agile.
Microservices and DevOps have created speed and agility benefits, but they have also created problems; specifically, they have created software security issues. Imagine, for instance, riding a bicycle for many years. After several spills and bad cases of road rash, you learn how to protect yourself with a helmet and some protective clothing. So, despite taking an occasional fall, you get up, dust yourself off, and continue without getting injured seriously. Now imagine putting a motor on the same bicycle. Your speed multiplies and your gear that kept you safe becomes obsolete. This is the state of the software industry today: we have learned to pick up speed, but we are lagging in skills and tools to protect ourselves.