El es un intento para crear algunos est¨¢ndares alrededor del modelamiento de plataformas de infraestructura como productos. Usando abstracciones para los componentes, las configuraciones de aplicaciones, sus ¨¢mbitos (scopes) y atributos (traits), los equipos de desarrollo pueden describir sus aplicaciones de forma agn¨®stica a la plataforma; mientras que el equipo que la implemente, lo puede hacer en t¨¦rminos de carga de trabajo, atributos y ¨¢mbitos. Desde la ¨²ltima vez que hablamos sobre OAM, hemos seguido con inter¨¦s una de sus primeras implementaciones: . KubeVela est¨¢ cerca de publicar su versi¨®n 1.0 y tenemos curiosidad de ver si este tipo de implementaciones pueden sustentar la promesa de la idea de OAM.
Hemos hablado mucho sobre los beneficios de crear equipos de producto de ingenier¨ªa de plataformas para dar soporte a los dem¨¢s equipos de producto, pero en realidad es dif¨ªcil hacerlo. Parece que la industria a¨²n est¨¢ buscando la abstracci¨®n correcta en el mundo de la infraestructura como c¨®digo. Aunque herramientas como Terraform y Helm son pasos en la direcci¨®n correcta, el enfoque sigue estando en la gesti¨®n de la infraestructura en lugar del desarrollo de aplicaciones. Tambi¨¦n hay cambios hacia el concepto de infraestructura como software con la aparici¨®n de nuevas herramientas como Pulumi y CDK. El es un intento de traer alguna estandarizaci¨®n a este espacio. Utilizando las abstracciones de componentes, configuraciones de aplicaciones, ¨¢mbitos o contextos (scopes) y aspectos o atributos (traits), las personas desarrolladoras pueden describir sus aplicaciones independientemente de la plataforma, mientras que las personas implementadoras de plataforma definen su plataforma en t¨¦rminos de cargas de trabajo, aspectos o atributos (traits) y ¨¢mbitos o contextos (scopes). Queda por ver si el OAM ser¨¢ ampliamente adoptado, pero recomendamos estar atento a esta idea interesante y necesaria.
