The “Why” of Cloud-Native: Goals and Benefits
Kyle Brown and Kim Clark
Note: This is part 5 of five-part series. For the first article in the series, start here or jump to Part 2, Part 3, Part 4
In our past articles, we’ve established “what” cloud native refers to and even “how” cloud native works. However, there’s a bigger, more fundamental question we haven’t addressed. Why should anyone care? Given the background from the previous two articles, we can now explore the “why” and look at the benefits of cloud native, starting at a high level of what it means to the business, then dropping down to what it means on the ground.
Business perspective on goals and benefits
Let’s face it, IT fads come and go. Many business teams try to stay above those fads and let the IT folks go their own way — after all the choice of an application server or language runtime usually doesn’t have much bearing on the way the business operates. What makes cloud native any different? Why should the business support a move to cloud native? In order to understand that, we need to start from a point of view taking into account three key things nearly all businesses must focus on to be successful: growth, risk mitigation and cost reduction. We would argue that building applications with a cloud native approach has the potential to provide benefits in all of these categories.
Market growth
Market growth is all about capturing new customers and keeping their interest. In order to win new customers and retain the interest of customers that are marginal, you have to be able to bring good, new ideas to market faster than your competition. Factors such as the adoption of lean methods and the streamlining of the path to production through pipeline automation enable teams to bring business ideas to production more quickly. This enables a reduced time to market, helping IT to move at the speed of the business in bringing out new features. However, new features will not, by themselves, ensure market growth. You have to be able to winnow out those new features that have a negative effect on customer retention and customer acquisition and allow those to die, while keeping those new features that have a positive effect on those two measures. The real key is to ensure innovation readiness; letting the business boldly and rapidly bring disruptive ideas to life in order to capture new market niches ahead of the competition, while at the same time putting in place measurements that allow you to determine empirically which ideas were good, and which ideas were not good.
Risk mitigation
New features are not everything a business needs, however. If a business could just forge ahead by constantly delighting its customers with new, awesome features, then we would have an easier job. The reality is more complex and difficult, but no less important. Customers need to trust your business. This is, of course, most visible in highly regulated industries such as financial services or healthcare, but relevant to every business. The solutions you provide need to have an appropriate degree of resilience and security to ensure that customers can be sure you’ll be there when they need you, and they can trust you with their money, their data, or their lives.
As we covered in a previous article, well written cloud native solutions make use of abstraction to decouple themselves from the underlying physical infrastructure, offering implicit resilience. Furthermore, they also follow a zero trust model for their components, since they must assume portable deployment into any cloud environment. However, the more we are concerned with risk, the more likely we are to put up barriers to making changes, which works against our need for market growth. It is here that cloud native can help in risk mitigation by providing highly automated and consistent ways to put things into production, reducing the fear of change through deployment confidence.
However, a cloud native approach doesn’t magically reduce risk on its own. Techniques like feature flags and canary testing can enable the business to do things that they might previously have rejected as being too risky, but that requires close cooperation with the business in order for those techniques to become valuable to the business. We must work with the business to update how they measure and control risk so that it is compatible with the methods and processes being introduced.
Cost reduction
No business can ignore cost. It doesn’t matter how big your market share is, or how much your customers trust you, if you can’t control costs, you can’t count on reliable profits. Businesses are run by people (at least today!) and people cost money. We need to ensure we can get the best from the smallest number of them, and this is all the more true of those with the deepest skills. The platforms on which cloud native solutions are built should aim to standardize and, wherever possible, automate the day-to-day tasks of building, deploying and managing software. This makes for optimized high value staff who can focus on directly adding value to the business rather than getting bogged down with day-to-day operations. Of course, those platforms and their underlying infrastructure need to be paid for too. Fortunately, cloud native solutions are designed to use only the resources they need, so you should take advantage of elastic cost models provided by the platform to enable you to take advantage of that cost efficiency.
IT perspective on goals and benefits
To this point, our discussion has been a bit high-level in terms of how cloud native impacts the business. In order for the business to comprehend the benefits of cloud native, we have to translate the IT benefits we have discussed into corresponding business benefits. We’ll next show how each of the key business benefit areas above map to our earlier cloud native ingredients.
Agility and productivity (Market growth)
Every business wants more features from IT — they also want them faster, and they want them to more accurately reflect what they need. How does cloud native help with that?
Faster delivery of components
Delivery acceleration is of the most commonly stated goals for a cloud native approach and pulls together three core aspects: cloud platforms, agile methods and microservices. Cloud platforms, through aspects such as elastic provisioning and component orchestration, enable us to focus on building business functionality by automating and simplifying most of the day-to-day operations work. By reducing toil, they allow teams to focus on higher-value work. Agile methods should enable us to shorten the distance between requirements and implementation and improve alignment with business goals. That means that less rework is required, and bad ideas are discovered and corrected more quickly. Design approaches such as microservices enable us to deliver functionality incrementally, with fewer dependencies, and thereby more rapidly.
Autonomous teams with freedom to innovate
An intentional consequence of fine-grained and discrete components is that it offers more autonomy to the teams creating them. As long as the key rules of decoupling we earlier described are followed, the components can be treated largely as a “black box” by the receiving platform. While cross-team collaboration and common practices should be encouraged, teams are free to, for example, use whatever language runtimes and frameworks are most productive for their needs. This freedom to innovate allows teams to “think out of the box” and deliver solutions to the business not only more quickly, but also to deliver solutions that are more innovative in terms of the business. A key aspect of this autonomy is that the business must be part of each autonomous team. The notions of a Product Owner and Sponsor Users are critical to building not only productive, but innovative teams.
Responsive to changing business conditions
Earlier, we talked about how the ability to not only innovate, but to determine if an innovation is valuable through concrete and empirical measurements were important in order to make a team ready to move at the speed of the business. A critical aspect of this is the ability of the business and IT to work together through Hypothesis driven development. Simply put, Hypothesis Driven Development is phrasing business ideas as scientific hypotheses that can be either proven or dis-proven. Cloud native development only brings benefit to the business if the business is engaged throughout the development cycle.
A primary form of engagement is through A/B testing — if you put a measurement in place, such as the percentage of abandoned carts, or the percentage of customers that click “buy” after browsing, then you can compare different ideas empirically. You can direct some of your customers to a new approach featuring a new idea, and others to the existing approach, and then compare the difference in the measurement between the two over time. The key here is that this requires the business to think in terms of measurable differences. Much as a scientific hypothesis isn’t a hypothesis if it cannot be dis-proven, the same applies to a business hypotheses. The business has to be able to help determine a quantifiable measure by which two different ideas or approaches can be compared. That means that they have to be involved throughout the process in helping determine not only what ideas should be tested, but how they should be tested, and what the definition of success means. Cloud native is well suited to enabling this responsive behavior. It is an essential part of agile methodology, and furthermore the use of fine grained, well-decoupled components makes it safer to add new functionality without disturbing what’s already there. Furthermore, generic mechanisms such as a service mesh can be used to selectively route requests across the ideas being tested, as well as simplify the collection of data for hypothesis assessment.
Resilience and scalability (Risk mitigation)
Cloud platforms, and especially containers, inherit a number of abstractions from their underlying infrastructure. This enables common and lower risk approaches to non-functional requirements such as availability, robustness, performance and security. Some key examples are:
Fine-grained elastic scalability and resilience
A well written cloud native solution is built with fine-grained, lightweight components with minimized state. This enables the cloud platform to inherently provide robustness and scalability by rapid replication and disposal of components as required. Thanks to containerization, this can be provided in a standardized way, resulting in significant operational simplification. Furthermore, the ability for container orchestration platforms to distribute container instances across multiple physical servers, over multiple regions, further increases the level of resilience possible.
Consistent environments and reversible deployments
For the agility and productivity discussed in the earlier section to become a reality, we need to be able to confidently deliver new code into environments, safely re-route traffic, and indeed reverse those deployments with minimal pain if necessary. Ideally, cloud native code should be delivered in immutable images containing all dependencies, and including complete, declarative deployment instructions. This ensures the deployment process and artifacts are identical on all environments, which eliminates the risk of environment drift. Furthermore, features of the cloud platform such as routers and service meshes enable the code to be canary tested (passing a small amount of load through the new code) before full rollout. This also simplifies rolling back a release, as we can simply revert to the images and deployment instructions of the previous release. This simplicity is important to the business, as it gives them assurance that changes can be quickly and safely reversed if the outcome is not what was expected.
Continuous adoption of software runtimes
Agile methods dictate that the path to production must be as automated as possible in terms of build, test and deployment. Often termed continuous integration/continuous delivery (CI/CD) these pipelines are typically triggered as a result of changes to the source code. However, since a declarative deployment is also code, a change to the version of an underlying runtime can also trigger a new build/test cycle — an example of “GitOps”. Assuming sufficient confidence in our automated tests, this should enable us to keep underlying runtime versions much more current than most applications do today, ensuring not only that we can capitalize on the latest features but also that we are not at risk from known security vulnerabilities. Again, this should be valuable to the business in that it reduces the fiduciary risk of the loss of customer data or assets.
Optimization and efficiency (Cost reduction)
Cloud based computing enables us to pool resources: hardware, software, and indeed people too. By sharing these resources across applications, across domains in the organization, and even across organizations. we have the opportunity to reduce operational cost. Cloud native ensures applications are written to gain the most from those optimizations.
Consistent skills on the underlying platform
Underlying the obvious characteristics of containers — lightweight scalable components — there is a much greater gem. Perhaps their greatest benefit over the long term is in operational consistency. Using exactly the same skills to build, deploy, provide high availability, scale, monitor, diagnose, and secure regardless of the runtimes within a set of orchestrated containers is a huge leap forward. At a minimum, this means transferable, common skill sets across previously siloed parts of the IT landscape. At best, the opportunities for automation of operations should result in a reduction in the number of people required to run a given infrastructure, and an increase in its reliability. However, since these technologies are new, there is a steep learning curve that individuals, and companies must go through before these benefits become a reality.
Optimized infrastructure usage and licensing
Arguably the most fundamental definition of “cloud” is abstraction from the underlying physical infrastructure. Virtual machines gave us the first level of indirection, in that we were no longer tied to specific hardware within a physical machine. Containers, if coupled with cloud native ingredients such as minimal state, immutable deployment, etc. take us much further. Cloud native enables us to invisibly distribute components across many machines in multiple data centers, providing greater opportunities for economies of scale. Software licensing of course needs to rise to this challenge with new models and potentially more sophisticated and dynamic metering.
Rapid self-provisioning of resources and capabilities
Self-provisioning is one of the key promises of cloud, enabling rapid requisition of virtual compute, memory, storage, networking and more. Container platforms further abstract this by allowing declarative requests for resources at the point of deployment, and setting policies for how these change at runtime based on load. Whole new environments can be created with a single click, and segregated from other environments through software defined networking. To make the most of all this, applications need to be written differently. Applications need to be stateless, disposable, fine grained, and indeed, all of the things we have discussed in this series.
Conclusion
Cloud native, just like most significant changes in approach, requires a level of commitment in order to achieve your goals. As we have seen, that requires many separate ingredients to be in place. For many, perhaps most, organizations it may be impossible to get all of those ingredients in place from the start, so the key to success is prioritization.
By selecting the benefits that are most important to you, we hope our series can help you to prioritize which of the cloud native ingredients you should focus on maturing first.
