The term “cloud native” gets tossed around a lot these days – particularly inside organizations that are just getting started on their cloud journeys. Stakeholders, after all, want to embrace the cloud for all it has to offer. The idea that cloud could be embedded – natively – in the organization’s DNA, and extend out in the form of processes and strategies, is a popular concept.
What we are finding, however, is that “cloud native” is a hard term to pin down. What does it really mean? And does it mean different things to different organizations? Is there a general cloud-native approach? And how does a cloud-native approach translate into a cloud-native experience for a specific organization?
These are all good questions. But they are really just a start. As we debated the subject back-and-forth – what cloud native is, and what it means – we came up with more and more questions about how organizations can and should use the cloud to accomplish their individual missions.
What each organization needs is its own Cloud Native Manifesto that guides it into and through a cloud computing journey. The manifesto will not necessarily define every last step of the journey, but it will answer the key questions organizations need to ask to ensure they are setting themselves up for success.
How Others Define Cloud Native
Before we dive into those questions, it is worth pondering how others define the cloud native term. Pivotal, the enterprise software platform company, defines it as “an approach to building and running applications that exploits the advantages of the cloud computing delivery model.” Others, including the Cloud Native Computing Foundation (CNCF), define it more narrowly – as being built around an open source software stack deploying applications as microservices, living in and being deployed from container-based environments.
For our purposes, we see cloud native computing as a concept focused broadly on speed and agility – two of the bedrock principles of the cloud itself which we defined earlier in this edition of The Doppler Quarterly. Digging deeper, all cloud-native environments tend to be structured as follows. They can:
- Provision app flexibly
- Pay for services on a per use basis
- Have a refresh-proof platform
- Work on an API-driven model
- Automate builds
- Be managed by a separate party
- Scale up and down in an elastic format
Cloud itself has many of these traits, but not all. However, we would argue that cloud-native delivers on all these facets.
To develop your own Cloud Native Manifesto, you need to fully understand where your organization positions itself in four specific areas, and how the use of cloud resources can drive change in them. The first, and most important, list of questions focuses on your business itself. Your organization should be trying to create a cloud-native environment to improve your business. That is the why component that sets up questions about how your company should transform its business by altering your strategies in three other areas – economics, technology and people.
Other experts may argue that a Cloud Native Manifesto should create a detailed, baked-in plan that any organization can follow, step-by-step, to get to a finish line. This model works for a chef who wants to make a perfect sauce, but IT projects are not recipes to follow. Tomorrow’s ingredients and conditions will be different from today’s. Answering questions about how your business goals, economics, technology and people impact each other will give you a playbook to respond to changes over time. Understanding how your organization is aligned enables you to create an innovation engine that will help your organization better compete in the marketplace.
Looking at Cloud Native from Every Angle
Different kinds of businesses are going to naturally use cloud in different ways, depending on many factors. B2B and B2C businesses have radically different selling models, so any cloud implementation will need to be sensitive to this. Ask who are the “customers” of the applications you want to build in the cloud – whether that be end customers, or internal groups? While internal groups will start with a certain amount of confidence in the success of the overall cloud delivery strategy, end users might require more education.
Who are the users of the application, and what are they using it for? If you are delivering a consumer app, you will need to hire skilled designers and commit to a trove of cloud-friendly tools. Then there are other factors to consider. What is the projected life span of the application? What is your release strategy? And how are your sales monetized – through a software-as-a-Service (SaaS) model or through legacy, up-front payments?
This is where you get down to dollars-and-cents issues: essentially, how to pay for the business benefits you are projecting from a move to the cloud. What is your budget? What is your time frame for entering the marketplace? How much do you expect to save through efficiencies, and/or generate in terms of revenue? You can make some projections based on assumptions aligned with your own particular industry. For example, an oil and gas company might project out a cloud-driven business scenario based on the price of oil staying at $50 a barrel. If the price drops below that, the whole project will have to be rescoped.
Based on the answers in the business section of the Manifesto, you can better determine how to configure your cloud-native environment. But before all the services can be ordered, you must also incorporate input from both the “technology” and “people” perspectives.
Cloud implementations do not exist on their own, separate from the rest of your organization’s technology capabilities. They closely dovetail with existing tools, processes and resources. So, it is critical to ask detailed questions about what is optimal and what is possible from a technology perspective. For example, what tech stack is your organization using? Are you currently deploying on-premises, in the cloud or in a hybrid IT environment? What dependencies does your application have? Is your development process agile or waterfall? And how automated is it? If you are in an industry with stiff regulations, for example, where the FDA requires you to validate all changes before anything is released, you should think twice before making heavy investments in technology tools and processes. You can streamline the development of apps, but it might be hard to speed up the release schedule.
The people function deals with more than just the number of people hired and the skills they will need to succeed in a cloud environment. You have to develop plans based on where you are getting your people, whether you are hiring new resources or retraining experienced staff, and how self-sufficient you will want the teams to be. What is your strategy to educate existing workers about the impacts of a radically altered release schedule? Are certain groups more likely to resist than others? Are you trying to reduce vendor lock-in, or are you willing to go deep with a cloud vendor? That will influence whether you need specialists on more than one platform, and how teams working on different technology sets will interact with each other.
Cloud native computing is a big step for organizations to take. The ones who are serious about implementing change are “all in” on the concept, but they may underestimate the impact it will impose on the organization. To succeed, you will not only need to prepare; you will first need to dig deep and figure out how to prepare. You will have to ask your teams the right questions – and get help from a partner who has been through this process many times before.