The Goals of Cloud-Native and What the Term Means
While the exact path to becoming cloud-native is unique to each organization, the goal is the same. Namely, organizations delivering valuable features to users in the form of custom-written software thatʼs continually improved through rapid iteration. ITʼs challenge is putting cloud-native processes and technologies in place that enable those frequent deployments. and thus, freeing resources to focus on a user-centric approach to software design. These tools are largely drawn from the bucket of technology known as cloud, hence the term cloud-native.
In the commercial world, the goals fueling change are usually creating new businesses and expanding existing products and services to grow revenue and profit. In the public sector, the goals are usually to improve customer service and workforce productivity, along with, above all else, to "do more with less." In both cases, ITʼs goal is to ensure a steady, reliable stream of innovation that improves how the organization performs and fulfills its goals in relation to customers, staff, citizens, or whomever is considered the softwareʼs user.
Small Batch Thinking
Thinking in terms of small batches is one of the key mind shifts required to become a cloud-native organization. By “small batches,” I mean identifying the problem to solve, formulating a theory about how to solve it, thinking of a hypothesis that would prove or disprove the theory, doing the smallest amount of application development and deployment needed to test your hypothesis, deploying the new code to production, observing how users interact with your software, and then using those observations to improve your software. The cycle, of course, repeats itself:
This whole process should take at most a week—preferably just a day. All of these small batches, of course, add up over time to large pieces of software, but in contrast to a “large batch” approach, each small batch of code that survives the loop has been rigorously validated with actual users. Schools of thought such as Lean Startup reduce this practice to helpfully simple sayings like “think, make, check.”
In contrast, a large batch approach follows a different path: teams document a pile of requirements up front, developers code away at implementing those features, perhaps creating “golden builds” each week or two (but not deploying those builds to production!), and once all of the requirements are implemented and QAed, code is finally deployed to production. With the large batch approach, this pile of unvalidated code creates a huge amount of risk. This is the realm of multi-year projects that either underwhelm or are consistently late. As one manager at a large organization put it, “We did an analysis of hundreds of projects over a multi-year period. The ones that delivered in less than a quarter succeeded about 80% of the time while the ones that lasted more than a year failed at about the same rate.
The Shape of a Cloud-Native Organization
In recent years, cloud-native organizations have been shaping into something like the structure in the following diagram:
As depicted crudely in the size of each layer, the number of staff in each layer dramatically reduces as you go down the stack. Exact numbers across each team and each layer will vary, but look for your approach to have the most people working in the business capability layer. This makes sense, if your goal is perfecting user interaction and innovating new software. You want to put most of your resources as close to the user as possible.
Picking a Platform
The amount of automation, standardization, and controls required to deploy on a weekly, let alone daily, basis requires a degree of automation thatʼs unknown to most IT organizations. Youʼll need a cloud platform to meet those needs. To prove this out, chart out all of the activities, approvals, and time it takes to deploy just one line of code to production. This is the simplest value stream map a software-driven organization could make.
The ability to deploy code on a small batch loop requires a platform that takes care of most all of the infrastructure needs—across servers, storage, networking, middleware, and security—removing the time drag associated with provisioning and caring for infrastructure.
Any good cloud platform will have deep capabilities in these five domains:
- Runtime, middleware, and data
Building your own platform is, of course, technically feasible and an option as such, but not very practical. Many Pivotal customers started off building their own platform, sometimes because when they started, there were no other options. Other times, itʼs a result of the fallacy of free software (if we can download open source software, itʼs free!), misjudging the total effort (as just described), or giving into the inescapable urge young developers have to build frameworks and platforms.
Instead of building and maintaining their own platforms, many organizations are using cloud platforms such as Pivotal Platform. Pivotal Platform comes fully integrated and full of services and middleware that allows product teams to start in minutes once the platform is up and running. Because thereʼs a full companyʼs R&D force and the larger open source community around Cloud Foundry, updates and patches are frequent and new features are added regularly.
Your initial project, or projects, should be material to the business, but low risk. They should be small enough that you can quickly show success in the order of months and also technically feasible for cloud technologies. Your initial projects should also enable you to test out the entire software life cycle—all the way from conception to coding to deployment to running in production. Learning is a key goal of these initial projects and youʼll only do that by going through the full cycle.
A cloud-native organizationʼs goal is to provide its business with an effective, sustainable means of innovating. This is accomplished by using cloud technologies and practices to fully automate the infrastructure layers of the application stack. With a huge chunk of resources and responsibility freed up, product teams can finally attain the focus and release speed needed to apply a small batch approach to development that results in continually improving software. A cloud-native IT approach in place enables organizations to meet the innovation needs of the business.