Cloud Native Transformation : Scale Evolution and Cultural Understanding

PS: It is based on what I have witnessed, heard, learnt, and considered.
The scenes represented are relatively 
limited and may not be applicable to most scenes.

Last weekend, when I was thinking about “how to design a maturity model for DevOps in large organizations”, I began to think, why is DevOps a transformation? Agile can also be a transformation? They are sufficiently complex to require a series of organizational culture changes, as well as changes in technical practices. So, I try to continue to explore the realm of transformation.

If a field requires a lot of sermons, a lot of learning, and architectural (technical, organizational, or business) changes to change people’s perceptions, then it can be called a transformation.

So, I rethought some of the core change factors in agile transformation, and DevOps transformation, such as:

1. The transformation of ideas, the introduction of new cultures.
2. Align your architecture to improve collaboration. The architecture here includes technology, organization, business, and team.
3. Build a competence center.
4. Maturity guidance continues to improve.

So, I tried to integrate it into the process of cloud-native transformation. It is said to be tentative, but in fact, I have refined it by combining the demands of some companies and the process of migrating to the cloud. Such as promoting their own microservice frameworks in medium and large organizations, cultivating their own internal technical coaches, etc., and refining the technical competence center.

1. Start with the platform and progressively shift to the cloud.

Cloud-native originates from CloudNative, which is similar to microservices. Microservices represent an architectural style, while cloud-native is a more abstract model, that is, a concept. Therefore, based on the application of cloud-native theory, it is designed for the cloud when designing the architecture.

Today, the first step towards cloud-native is to adopt or build a cloud-native platform.

0.1 Pattern Tooling: Cloud Platform

In the past few years, the mainstream mode of going cloud-native is to build a containerized platform, such as using Kubernetes as the cornerstone of the platform and building an internal PaaS platform. Therefore, the process of Chen’s sesame rotten millet is irrelevant.

The reason for mentioning this is that there are some organizations with cloud platforms (PaaS) that are going the wrong way. Before the popularity of Kubernetes, there were already a series of DevOps tools on the market that did something similar: infrastructure as code. The “infrastructure as code” model is the core of building a cloud platform.

Patterns are extracted from practice, tools are extracted from patterns, and platforms are built from toolsets. However, people who use the platform will always forget the original model. This is why some cloud platforms (PaaS) require a lot of manual configuration.

0.2 Legacy Infrastructure Modernization

Around the cloud platform, it is necessary to remove the traditional legacy infrastructure and migrate to the cloud platform (PaaS).

There’s nothing else to say about it. The application will then be re-architected.

0.3 Designing for a resilient architecture – you don’t necessarily need microservices

Microservice architecture is a very good architectural pattern under cloud-native, but this does not mean that microservices are the only answer. Too many wrong ways of dividing microservices have caused a large number of systems to lose the elastic architecture they should have. So, don’t target microservices as your migration path. The direction we want to design should be an elastic architecture.

Designing around how to achieve resilient architecture, and then related technologies such as containers, service meshes, microservices, immutable infrastructure, and declarative APIs, is the right way to solve the problem.

Does the story end here?

1. Change concepts and introduce a new culture

Simply migrate to the cloud platform, and the application undergoes a microservice transformation. For most teams, it did not bring much change, and the team continued to design and build the system with the original ideas. If it is simply going to the cloud, the team may not have the awareness to build the required core capabilities.

What has cloud-native changed?

Think about this again, why did you choose cloud-native? From a benefits perspective, from an organizational perspective, it can be:

• better customer experience
• Increased revenue and reduced operating costs
• Significant reduction in wait times for new products and services
• As far as the team is concerned, it can be divided into two parts:
• From the platform side, that is, from the infrastructure level, it is about the abstraction of infrastructure. It’s also about the immutability and disposability of infrastructure.
• From the development side, that is, from the level of using the platform, it is about how elastic the application is.

Developer as a Service

And the story is not that simple. If the platform team is only positioned to develop the platform, then they will encounter a series of practical shocks, such as I mentioned in ” Developer as a Service: Developers are used on-demand “.

The problems teams face are very similar to the dilemmas of open source projects, such as providing better service, a more comfortable experience, and wanting to avoid being overwhelmed with supporting various teams.

The platform team needs to change the way of solving problems, such as adopting internal open source, developer operation, etc.

Scaled elastic architecture design

Within an organization, the level of different teams varies, which may be limited by the level of competence and the ease of business scenarios. Therefore, once faced with these architectural adjustments, it will become extremely confusing.

In the cloud-native scenario, it is equivalent to establishing a technical baseline, and all teams should reach this baseline. In reality, most business teams do not have such capabilities and energy. Energy and time are major issues compared to ability.

Therefore, from the perspective of the organization, it is necessary to find ways to support large-scale technical capability improvements, such as the adoption of agile coaches during agile transformation, or the introduction of DevOps coaches/engineers during DevOps transformation.

2. Improve organizational collaboration

From a model point of view, the transformation of cloud-native also means changing the way organizations collaborate. Dimensionally, it’s more of a development-to-development collaboration. Rather than having wider organizational implications like a DevOps transformation.

DevOps >> Dev + Ops

The original goal of the DevOps movement was to tear down boundaries between development and operations and increase collaboration between the two. and encourage collaboration between development and operations. With the emergence of various domestic standards and maturity levels, we have defined it as BizDevOps, that is, the collaboration of business + development + operation and maintenance.

Becoming a DevOps movement can make organizations more fluid — at least standardized and instrumented in collaboration.

Therefore, the success of cloud-native is also based on DevOps. Dev + Ops together builds the PaaS platform and is used to support Business + Dev activities.

Internal Developer Experience: PaaS Dev + Biz Dev

And once the PaaS platform appears, then this platform is the collaboration of platform development (PaaS Dev) and business development (Biz Dev).

Improving the way they collaborate requires a focus on designing the developer experience, which is another collaborative change. Optimizing collaboration based on developer experience metrics is another change to make.

3. Build a technical competence center

Most organizations, I think make a mistake: not building an internal technical community. By building a technical community, the technical assets of the organization can be precipitated. One reason may be competition between departments. In the cloud-native era, this question has become very urgent. How to share cloud-native knowledge?

Precipitation knowledge system

Wikis are a way for development teams to accumulate knowledge. For an organization, the same knowledge may be spread across different teams.

In traditional mode, this is not a problem. In the cloud-native era, this problem is even more prominent. Therefore, the PaaS platform team should take the initiative to initiate the establishment of the knowledge base. In addition to helping others solve problems, you can also reduce your own response time.

Internal technical community

An internal technical community is one of the ways Tw builds technical capabilities. It may have enough capacity to support it when business opportunities in a particular field come. This is also a fairly effective approach for most organizations.

On top of this, organizations, also consider:

• Community support and operation system
• KPI reward mechanism

That being said, I’ve been wondering if department walls will limit the internal tech community?

Technical Competence Center

In a cloud-native context, it’s about enabling related PaaS platforms and developers to collaborate on patterns, blueprints, techniques, and code samples. Compared with the above two methods, it is a more challenging thing to become a team that focuses on improving technical capabilities.

Interestingly, this model has been adopted by a large number of companies with a technical atmosphere, which have recruited a series of in-house technical coaches to help each team develop their skills.

4. Maturity guides continuous improvement

The maturity model is another more interesting standardized model.
 It is used to direct how an organization works efficiently, in other words, 
how an organization becomes part of the huge wheel of society.

Maturity is still what we use to guide how we scale. In this regard, we have done a series of design presentations in our previous article, ” The DevOps Maturity Model for Medium and Large Organizations .” For large organizations, it is still based on the common model in the industry to further improve their own model.