How Ops Teams Can Thrive in the Cloud‑Native Era: Strategies and Lessons

Operations in the Cloud‑Native Era

With the arrival of the cloud‑native era, operations face both opportunities and challenges that demand a strategic transformation.

Key Points

Traditional operations assemble industrial products into services, heavily dependent on business.

The cloud‑native shift—public cloud, micro‑service architecture, and DevOps—creates a domain crisis, outsourcing and replacing many traditional responsibilities.

Organizational structures evolve from universal collaboration to platform self‑service, turning operations into a service product and technical middle platform.

The domain model centers on maintaining operation objects through a service‑as‑a‑platform (OPaS) approach, providing sustainable high‑tech leverage.

Operations Stages

Internet operations have progressed through manual, standardized, platform, and intelligent stages. DevOps represents a technology‑driven organizational change rather than a professional one.

Traditional Operations

Traditional operations serve three layers: hardware infrastructure (IaaS), software infrastructure (OS, virtualization, middleware), and business applications. Their goal is to assemble industrial products into services, ensuring stability, cost‑effectiveness, security, and efficiency, often relying on business dependency for value.

Challenges in the Cloud Era

Public‑cloud adoption abstracts most IaaS/PaaS/SaaS services via APIs, reducing the need for manual setup.

Cloud‑native and DevOps shift many tasks from specialized ops to business development, moving responsibilities to the business side.

Tooling and open‑source ecosystems lower technical barriers, automating tasks that previously required significant manpower.

Organizational Structure

The new structure includes end‑users, business teams (product, commerce, marketing), business development (SaaS), platform development (PaaS), and cross‑functional groups such as FinOps, EP, and IT. Collaboration moves from universal coordination to platform self‑service, with operations focusing on service products and technical platforms.

Technical Architecture

Operations split into object management (vertical) and scenario management (horizontal). Object management covers IaaS resources, PaaS components (databases, caches, MQ, gateways), SaaS applications, and service frameworks, each with dedicated platforms. Scenario management addresses delivery, change, monitoring, multi‑cloud, and cost, providing self‑service capabilities via platforms like IDP.

Same‑Structure Maintenance

Maintaining the consistency of operation objects involves controlling increments, fixing existing stock, and preventing large‑scale divergence through service and management standards.

Ops Mid‑Platform

The original ops platform is divided: functional parts (e.g., IDP console, ICSP tools) remain with users, while common services (IAM, workflow engine, monitoring agents) form the ops mid‑platform managed by OpDev.

Transformation Practice

Role shift: operators become independent service providers rather than business‑dependent operators.

Four‑step transformation: identify objects → abstract commonalities → build platforms → achieve scalable ops.

Component ops follow the onion model: resource delivery, platform management, and deep component specialization.

Super‑Service Perspective

Operations can lead the “super‑service” view (now called scenario construction), filling gaps left by DevOps in business, department, and company‑wide perspectives, creating a win‑win situation.

Onion Model

The onion model guides ops migration across three stages: resource delivery, platform management with self‑service, and deep component specialization, proven in cloud services, middleware, and big‑data domains.

Lessons Learned

Balance transformation with conservatism; not all staff can migrate at once.

Address skill gaps by aligning development capabilities with business needs and enforcing rigorous design and testing.

Platforms are powerful but not the sole solution; organization, culture, and processes remain essential.

Clearly define responsibilities; the more common features an application has, the higher the operational leverage.

Organizational guarantees are critical; clear goals, responsibilities, and measurement loops support successful transformation.

Avoid pure project focus that yields short‑term value but no lasting service capability.

Prioritize prevention over emergency handling; extend MTBF and reduce MTTR.

Conclusion

Cloud‑native technologies lower the difficulty of maintaining operational consistency, shift cost curves, and enable ops teams to manage more objects at lower cost, significantly boosting productivity.