Azure
[FEATURE REQ] Workspaces Support
I must admit I don't know too much about them but I wonder what effect it will it have on this toolkit and whether there are changes needed within a roadmap to support them?
Currently workspaces are not supported by apiops as it's still in preview. Once Workspaces is out of preview it will be part of apiops. We can't promise any timeline but rest assured it will come down the line. In the meantime if you have ideas on how you feel the best implementation would look like we would love to hear your opinion as we are still going through the planning phase.
I actually don't see it as being too dissimilar, essentially we will of course want to extract and create workspaces within an instance and then for each workspace pretty much do what we do now i.e. extract products and api's but now will be scoped to a workspace rather than an instance
And would you rather see all the workspaces artifacts extracted to the same repository or would you rather use multiple repositories?
Excellent question - I didn't think of that but I guess keeping in spirit of supporting separate teams would mean having sperate repositories, one for the root and then additional ones for each workspace - that way it's much easier to isolate code and manage permissions on a granular level
Thanks for the feedback. And please keep using this thread if you have any other ideas as we are actively planning for this feature.
Seems to me like the work-space level resources (names values, backends, policy fragments) and workspace-scoped policies are the main value that workspaces could add to APIOps.
Apis as well. But remember there are global level artifacts and other that are unique to the workspace. Also workspaces will be optional so the tool has to adapt to that as well. Once we figure out all the details we will share back the details here and update the docs.
Hi! Do you have any news about plans to support APIM workspaces? We use APIOps extensively and very interested in this functionality. Thank you!
It's in the workings, but as an open source project, we cannot promise any timelines. I suggest that you subscribe to the release notifications on the GitHub repo to be notified when we release the support for workspaces.
Also, please note that we always accept contributions from the community in case you are interested in implementing missing features.
And would you rather see all the workspaces artifacts extracted to the same repository or would you rather use multiple repositories?
I'd prefer the option to do both. If workspaceNames could become a supported attribute in the CONFIGURATION_YAML_PATH file, that would solve all my needs.
Workspaces is GA now https://techcommunity.microsoft.com/t5/azure-integration-services-blog/announcing-general-availability-of-workspaces-in-azure-api/ba-p/4210796
It's important to note that workspaces support is available to the premium tier only :(
We are working on finalizing its implementation under apiops soon. Stay tuned.
Question, will each workspace have its own repo or everything will still reside in one repo?
Everything will be extracted into the same repo. But you can always modify the extractor pipeline to extract different artifacts to different repos. We just provide a starter pipeline which you are at liberty to customize.
@pfekrati @jayendranarumugam @magnus-longva-bouvet @shawnmurtagh we just pushed another alpha release which extracts more workpaces artifacts. Its not completed yet but we are getting there. Can you please give it a try and share your feedback so far v6.0.2-alpha.1.0.2
@waelkdouh w/ the premium pricing to go w/ the premium SKU, but the power of workspaces is perhaps compelling to socialize the costs, do you foresee organizations using fewer APIM instances and using workspaces whereas previously they may have used developer-tier APIM in non-prod environments? Since you're so embedded w/ this product and its value-proposition, we'd love to hear your thoughts.
@waelkdouh w/ the premium pricing to go w/ the premium SKU, but the power of workspaces is perhaps compelling to socialize the costs, do you foresee organizations using fewer APIM instances and using workspaces whereas previously they may have used developer-tier APIM in non-prod environments? Since you're so embedded w/ this product and its value-proposition, we'd love to hear your thoughts.
Yes, workspaces enable federated API management model within one service, as opposed to the siloed model with multiple API Management services. We talk about it in the announcement blog post. It makes sense to mirror production configuration in non-production environments, meaning that you would employ a single API Management service with workspaces rather than an API Management service per team (e.g., Developer tier) in non-prod environments.
@waelkdouh I couldn’t abel to access the docx is there any public doc available?
It's working fine in my end. Excellent work!
Thanks for confirming! Keep pushing the tool to the limit as your feedback is key.
You may have noticed that right now within the workspaces some folders have guids as their names which don't align with the top level artifacts. We are working on improving that as apim has this default behavior. Stay tuned.
@waelkdouh Does APIOps handle a design first approach where an OpenAPI spec is created ? Will APIOps import it into an APIM instance ?
Or, would one need to manually import the OpenAPI spec and then run the APIOps extractor to get it into a repo ?
@soonerfan as long as you get the following two files into the specific api you are trying to publish to your apim instance then apiops will publish through the publisher.
Make sure you look at the content of the two files of a sample api so you understand how you need to structure these files. For example:
Notice that you openapi spec would go into the specification.yaml file. The comibination of both is needed for a successful apim publishing. Take a look at some closed github issues that have discussed in the past how these two files coexist as sometimes the same information is stored in both and one can ovverride the other (which is an apim design requirement).