Streaming + Iceberg + KRaft: The Composable Data Platform Is Becoming the Default
Data platforms are consolidating around open table formats (Iceberg) and streaming ingestion, while workflow orchestration becomes more declarative and engine-agnostic.

Open table formats and streaming ingestion are moving from “nice to have” to baseline assumptions. Vendor roadmaps over the last 48 hours show the same direction: keep storage interoperable, keep ingestion continuous, and keep compute choices flexible. CTOs end up owning the tradeoffs, because the architecture determines cost structure, portability, and who carries operational risk.
Kafka modernization is part of the foundation work. AWS announced in-place ZooKeeper-to-KRaft upgrades for Amazon MSK, lowering the friction to move off ZooKeeper and aligning managed Kafka with the post-ZooKeeper future of the ecosystem (AWS Big Data Blog). AWS also published pragmatic guidance on MSK partition sizing, reinforcing that streaming performance is still gated by good capacity math and operational discipline, not by adding more tooling (AWS Big Data Blog). Streaming-first only works when the streaming layer is boring.
Storage is standardizing around Iceberg-style interoperability, even inside proprietary platforms. Snowflake’s guidance on streaming into Snowflake-managed Apache Iceberg tables via Snowpipe Streaming positions Iceberg as the table contract while Snowflake supplies managed services around it (Snowflake Blog). The practical implication is architectural: teams can increasingly separate “where the data lives” (open tables) from “which engine runs today” (warehouse, query engine, ML feature pipelines). That separation reduces lock-in, but it also increases the number of viable compute paths, which can create governance and cost-control problems if left unmanaged.
Orchestration is adapting to the multi-engine world by becoming more declarative. InfoQ’s coverage of AWS “specification-driven composition” describes separating intent from processing logic, using reusable capabilities and declarative specs to compose workflows (InfoQ). That pattern fits the open-table, many-engine reality: a workflow spec describes outcomes and constraints, while execution can target different runtimes (Spark, Flink, SQL engines, warehouse tasks) without rewriting the business logic each time. Platform teams should pay attention because declarative workflow layers become the control plane for cost, compliance, and reliability.
Compute is also getting more modular, including on the developer laptop. AWS’s agreement to acquire DuckLabs (DuckDB) signals that “local-first analytics” is no longer a side quest, it is becoming part of mainstream analytics stacks (AWS Big Data Blog). DuckDB-class engines let teams shift left on data validation, reproducibility, and debugging, and they pair naturally with open table formats. The governance twist is that more analysis happens outside the warehouse perimeter, so access controls, data classification, and lineage need to extend to local and ephemeral compute.
Actionable takeaways for CTOs:
- Treat streaming modernization as platform hygiene: plan the ZooKeeper-to-KRaft transition path (even if managed), and standardize partitioning and retention practices early.
- Use open table formats as the storage contract, then design a deliberate “engine portfolio” (warehouse, stream processor, local engine) with clear rules for when each is allowed.
- Invest in a declarative control plane for workflows and policy (spec-driven composition or equivalent), because orchestration becomes the enforcement point for cost and governance in a composable stack.
- Expand governance to cover local-first analytics and ephemeral compute, or expect trust problems to surface as adoption scales.
Sources
- https://aws.amazon.com/blogs/big-data/announcing-in-place-zookeeper-to-kraft-cluster-upgrades-for-amazon-msk/
- https://aws.amazon.com/blogs/big-data/amazon-msk-service-101-how-many-partitions-does-an-amazon-msk-topic-need/
- https://www.infoq.com/news/2026/08/aws-spec-driven-data-workflow/
- https://aws.amazon.com/blogs/big-data/aws-and-ducklabs-building-the-future-of-analytics-together/
- https://www.snowflake.com/en/blog/snowpipe-streaming-iceberg-tables/