The is an attempt to bring some standardization to the space of shaping infrastructure platforms as products. Using the abstractions of components, application configurations, scopes and traits, developers can describe their applications in a platform-agnostic way, while platform implementers define their platform in terms of workload, trait and scope. Since we last talked about the OAM, we've followed one of its first implementations with interest, . KubeVela is close to release 1.0, and we're curious to see if implementations like this can substantiate the promise of the OAM idea.
We've talked a lot about the benefits of creating platform engineering product teams in support of your other product teams, but actually doing it is hard. It seems that the industry is still searching for the right abstraction in the world of infrastructure as code. Although tools such as Terraform and Helm are steps in the right direction, the focus is still on managing infrastructure as opposed to application development. There are also shifts toward the concept of infrastructure as software with new tools such as Pulumi and CDK being released. The is an attempt to bring some standardization to this space. Using the abstractions of components, application configurations, scopes and traits, developers can describe their applications in a platform-agnostic way, while platform implementers define their platform in terms of workload, trait and scope. Whether the OAM will be widely adopted remains to be seen, but we recommend keeping an eye on this interesting and needed idea.