Continuous Innovation

Everything in business and technology is changing at a rapid pace, and companies can no longer seek and rely on sustainable competitive advantage. Companies instead need to innovate continuously to stay competitive, or even just to remain in business. Organizations must remain agile and able to respond to fast-changing market conditions very quickly, and software has to be able to quickly adapt to these changing business needs.

It’s not uncommon for organizations to refrain from pushing updates during their most busy seasons, unless they absolutely have to. For example, ecommerce sites have generally stopped deploying noncritical updates to systems during the busy holiday season. The thinking is, “Don’t touch anything unless we absolutely need to because we dare not break something right now.” Downtime during these critical periods can be extremely costly to the business—even a few minutes could mean significant losses in sales.

Through independent deployments and rigorous DevOps practices, a microservices architecture can make it possible for organizations to release updates during these critical times without adversely impacting the business. The software and services can continue to evolve, and valuable feedback can be gathered, enabling a business to innovate at a very rapid rate.

For example, during the holiday season a new recommendation service can be deployed without affecting the rest of the application. A/B testing can be performed during these times of heavy usage, and knowledge gained in this way can be used to improve conversions, or the user experience in the application. Fixes and new features can be deployed using release management strategies, like blue-green deployments and canary releases. If there is a problem with the changes, they can be quickly rolled back. Even if the updates temporarily break recommendations or performance is a problem, the components handling the purchase of goods remain untouched. Even if we break something, a good deployment strategy would impact a small number of customers, the problem would be detected early, and we would roll back. Deployments in these situations cease to become an event, and are simply daily routine. See Chapter 6, “DevOps and Continuous Delivery,” in this book for more information on microservices release management strategies.

The capability for a business to continuously innovate in today’s competitive markets is often reason enough to consider a microservices architecture approach.