Cloud Native Transformations have been on the rise over the past decade but many of them get off to a rocky start or fail. We have consulted with scores of organizations who have taken on the Cloud Native journey. This article outlines some consistent themes that most of these organizations faced.
There are usually two forms of drivers for the transformation effort, a top down and a bottom up driver. Top down is where an executive, vice president, or board of directors mandates a plan to go cloud native. Bottom up is where individual engineers, a team of engineers, or teams of engineers decided to go Cloud Native without executive buy in.
Common motivations for the top down
- Cost save (Example: only pay for what you use in the cloud instead of buying more datacenter than what you need )
- Avoiding vendor lock in
- Reduced time to market
- Improved market responsiveness
Common motivations behind bottom up
- Flexibility
- Passion
- Learning
- Improved working environment
- More frequent feelings of accomplishment
Common reasons why Cloud Native is rejected top down
- There is too much technical debt to transform
- Transforming will delay current goals
- Misconception of not being able to use existing datacenter or existing hardware
- Lack of knowledge on how to manage Cloud Native company or what metrics to look at
- Fear of the current talent’s inability to adopt Cloud Native Practices
- Fear of increased employee costs once they have “Cloud Native” on their resume
Common reasons why Cloud Native is rejected bottom up
- Resistance to learning new technologies
- Lack of desire for change or “I just want to do my job and go home”
- We will need less people if we go Cloud Native
- I am overworked already, doing this will be unbearable
- Our current solutions work just fine
But wait? What is Cloud Native? Oddly enough every person I have asked has a different definition of what Cloud Native is. So let us unpack that before we continue
Cloud Native is a practice, an ecosystem, and a set of standards. The reason why the definition of Cloud Native varies from person to person is simple, because it can. The best way to think about it is going Cloud Native means your organization is adopting as much of the Cloud Native best practices as makes reasonable business sense.
I’ll give a hypothetical example a financial institution who considers themselves to be “Cloud Native” has more than 40% of their business logic applications on mainframe or legacy frameworks. Why does this organization consider themselves cloud native? Well, because 90% of their front end customer facing applications adhere to most of the Cloud Native best practices. For this organization that is the mix that makes the most reasonable business sense.
This is a common practice with Cloud Native transformations. The front end customer facing or revenue generating applications go Cloud Native first in order to take advantage of improved time to market, market responsiveness, enhanced security, and uptime.
So back to why the corporate mandate fails
- The misunderstanding of what Cloud Native means to their organization
- In some cases where the engineering team is resistant to change, it may be better for the executives to avoid saying “Cloud Native Transformation. Executives instead can look at what aspects of Cloud Native are going to be the most advantageous for their organization and align company goals and milestones to gradually bring them to these goals. It is better to gain one or two sustainable advantages of Cloud Native.
- What to avoid? Instead of statements like “Everything on Azure by Q4” ask instead what applications are well suited to move to the cloud then “These applications on azure by Q4”
- Neglecting the culture change
- A company cannot go cloud native unless they make some changes to culture. This often has to do with the way things are approved, deployed, tracked, and how work is shared. Most Cloud Native companies adhere to agile and scrum practices but what they do not tell you is that these practices need to be modified to fit the business needs and evolve over time. It is good to start out by practicing textbook agile practices in the beginning, but after the concepts and practices are understood they must be adapted in a way that the organization can sustain them.
- Lack of employee endorsement
- People who feel excluded from the decision process and who feel they are being forced to change will often resist. The more employees inside of an organization that feel this way the easier it will be for them to procrastinate the transformation effort. Allowing employees to express their ideas, beliefs, and concerns before goals are set
- The cost
- What it takes in time, resources, and money is often underestimated. The more people involved and the more processes that exist currently the more costly it will be to perform a transformation.
- Cloud Native Transformation is limited to technical teams
- Other parties including finance, accounting, human resources, and operations will have changes in their processes due to a Cloud Native Transformation.
- One Common pitfall on the financial side is budgets. There is a general lack of knowledge on the real impact Cloud Native will have on budgets. An example being consumption of IaaS vs fixed cost amortization of physical hardware.
Cloud native is not an intangible set of standards to be strictly followed but a choose your own adventure story that lets you find the standards that best serve your business needs. But just as any company wide effort there needs to be agreement from bottom up to top down. A great place to start is with small attainable milestones that will enable sustainable Cloud Native practices. These small milestones once achieved will help gather top down and bottom up for bigger future moves.
Spread the word
