Cloud Native Transformation: Practical Patterns for Innovation

Pioneers are brilliant people. They are able to explore never before discovered concepts, the uncharted land. They show you wonder, but they fail a lot. Half the time the thing doesn’t work properly. You wouldn’t trust what they build. They create ‘crazy’ ideas. Their type of innovation is what we call core research. They make future success possib

example, it is common to see a platform DevOps team in charge of building the cloud native platform, while site reliability engineering (SRE) or first-level support teams respond to incidents (and spend the rest of their time working on automation to prevent them from happening in the first place).

the single most important metric for executives to focus on is time-to-value, which can be instrumented most easily as committing to deploy latency for each team. Many companies can’t innovate because they can’t get out of their own way, and short time-to-value (target less than a day) releases pent-up innovation from your teams. Third, there is fa

When experimentation becomes routine, the new is no longer to be feared. Innovation as a routine process is, after all, a core cloud native principle.

The culture-clash conundrum works backwards, too: you can’t have otherwise full-on cloud native culture but not have microservices. If it takes you six months to deliver, you can’t be truly distributed. There is nothing to be gained in simply re-creating a monolith on the cloud — yet companies try do it all the time.

First, most of the customers I meet think they have a technology adoption problem, when in reality they have an org-chart problem. The most successful orgs are made up of many small independent business teams communicating via clear APIs. If that’s your org chart, you will inevitably build a microservices architecture, a trick known as the Reverse

system. Planning fallacy is another extremely common hazard; most companies enter into a transformation thinking it will be relatively quick and simple. They budget time and resources for only a few weeks or months, only to find that a proper transformation can require a year or more to successfully complete.

If you change your actions, you change your culture.

teams are still not really in charge of what they are building; their authority is limited to how to build whatever they are assigned.