Azure SDK is over 500 MB and growing on each release

https://github.com/Azure/azure-sdk-for-python/issues/17801

as another view point, azure packages add about 354mb of size to our docker images (which also support 4 other cloud providers in a fraction of that size). the current rate of package size improvements (2 in 2 years), means there is timely no visible path to correction given the number of packages in the azure ecosystem. and as service teams rev versions, these problems are likely to reoccur in the 'corrected' packages.

wrt to packages we're (cncf cloud custodian) currently using

azure-mgmt-authorization
azure-mgmt-advisor
azure-mgmt-apimanagement
azure-mgmt-applicationinsights
azure-mgmt-batch
azure-mgmt-cognitiveservices
azure-mgmt-cosmosdb
azure-mgmt-costmanagement 
azure-mgmt-containerinstance
azure-mgmt-compute
azure-mgmt-cdn 
azure-mgmt-containerregistry
azure-mgmt-containerservice
azure-mgmt-databricks
azure-mgmt-datalake-store
azure-mgmt-datafactory
azure-mgmt-dns
azure-mgmt-eventgrid
azure-mgmt-eventhub
azure-mgmt-hdinsight
azure-mgmt-iothub
azure-mgmt-keyvault
azure-mgmt-managementgroups
azure-mgmt-network
azure-mgmt-redhatopenshift
azure-mgmt-resourcegraph
azure-mgmt-resource
azure-mgmt-rdbms
azure-mgmt-search
azure-mgmt-sql
azure-mgmt-storage
azure-mgmt-subscription
azure-mgmt-web
azure-mgmt-logic
azure-storage-blob
azure-storage-queue
azure-cosmosdb-table
applicationinsights
azure-functions
azure-graphrbac
adal
azure-storage-file
azure-mgmt-policyinsights
azure-mgmt-monitor
azure-cosmos
azure-mgmt-redis
azure-keyvault-secrets
azure-keyvault-keys
azure-keyvault-certificates
azure-identity
azure-keyvault
azure-storage-file-share
azure-mgmt-msi
azure-mgmt-servicefabric
azure-mgmt-trafficmanager
azure-mgmt-frontdoor
azure-mgmt-security
azure-mgmt-servicebus
azure-mgmt-appplatform
azure-mgmt-recoveryservices 

@johanste re dynamic gen, ide integration points can be had via other methods (typing files etc). re startup time, the runtime generation is typically cached, and lazy/amortized. most folks are aren't creating clients at import time versus runtime. the current static generation pattern also feels anti consumption, the more azure you use, the worse the problem is. and its not just package size, its an explosion on the dependency graph and supply chain validation due to the package count as well.

sadly I don't see a runtime style openapi client extant, so the lift on exploring this is larger then I'd like.

{
"by": "varun_chopra",
"descendants": 3,
"id": 40245553,
"kids": [
40245593,
40247401,
40245639
],
"score": 4,
"time": 1714726390,
"title": "Azure SDK is over 500 MB and growing on each release",
"type": "story",
"url": "https://github.com/Azure/azure-sdk-for-python/issues/17801"
}
{
"author": "Azure",
"date": "2021-04-05T12:00:00.000Z",
"description": "The azure SDK is ridiculously large for reasons that I have a hard time understanding. We pip install it for our CI pipelines and the vast majority of the size of our container is coming from the A…",
"image": "https://opengraph.githubassets.com/81ae5be0ddd45b83662bc92c250fc2e32f8cf4713bf04213e418474ce7d26557/Azure/azure-sdk-for-python/issues/17801",
"logo": "https://logo.clearbit.com/github.com",
"publisher": "GitHub",
"title": "Azure SDK is over 500MB and growing on each release. · Issue #17801 · Azure/azure-sdk-for-python",
"url": "https://github.com/Azure/azure-sdk-for-python/issues/17801"
}
{
"url": "https://github.com/Azure/azure-sdk-for-python/issues/17801",
"title": "Azure SDK is over 500MB and growing on each release. · Issue #17801 · Azure/azure-sdk-for-python",
"description": "The azure SDK is ridiculously large for reasons that I have a hard time understanding. We pip install it for our CI pipelines and the vast majority of the size of our container is coming from the A...",
"links": [
"https://github.com/Azure/azure-sdk-for-python/issues/17801"
],
"image": "https://opengraph.githubassets.com/81ae5be0ddd45b83662bc92c250fc2e32f8cf4713bf04213e418474ce7d26557/Azure/azure-sdk-for-python/issues/17801",
"content": "<div>\n <p>as another view point, azure packages add about 354mb of size to our docker images (which also support 4 other cloud providers in a fraction of that size). the current rate of package size improvements (2 in 2 years), means there is timely no visible path to correction given the number of packages in the azure ecosystem. and as service teams rev versions, these problems are likely to reoccur in the 'corrected' packages.</p>\n<p>wrt to packages we're (cncf cloud custodian) currently using</p>\n<div><pre><code>azure-mgmt-authorization\nazure-mgmt-advisor\nazure-mgmt-apimanagement\nazure-mgmt-applicationinsights\nazure-mgmt-batch\nazure-mgmt-cognitiveservices\nazure-mgmt-cosmosdb\nazure-mgmt-costmanagement \nazure-mgmt-containerinstance\nazure-mgmt-compute\nazure-mgmt-cdn \nazure-mgmt-containerregistry\nazure-mgmt-containerservice\nazure-mgmt-databricks\nazure-mgmt-datalake-store\nazure-mgmt-datafactory\nazure-mgmt-dns\nazure-mgmt-eventgrid\nazure-mgmt-eventhub\nazure-mgmt-hdinsight\nazure-mgmt-iothub\nazure-mgmt-keyvault\nazure-mgmt-managementgroups\nazure-mgmt-network\nazure-mgmt-redhatopenshift\nazure-mgmt-resourcegraph\nazure-mgmt-resource\nazure-mgmt-rdbms\nazure-mgmt-search\nazure-mgmt-sql\nazure-mgmt-storage\nazure-mgmt-subscription\nazure-mgmt-web\nazure-mgmt-logic\nazure-storage-blob\nazure-storage-queue\nazure-cosmosdb-table\napplicationinsights\nazure-functions\nazure-graphrbac\nadal\nazure-storage-file\nazure-mgmt-policyinsights\nazure-mgmt-monitor\nazure-cosmos\nazure-mgmt-redis\nazure-keyvault-secrets\nazure-keyvault-keys\nazure-keyvault-certificates\nazure-identity\nazure-keyvault\nazure-storage-file-share\nazure-mgmt-msi\nazure-mgmt-servicefabric\nazure-mgmt-trafficmanager\nazure-mgmt-frontdoor\nazure-mgmt-security\nazure-mgmt-servicebus\nazure-mgmt-appplatform\nazure-mgmt-recoveryservices \n</code></pre></div>\n<p><a target=\"_blank\" href=\"https://github.com/johanste\">@johanste</a> re dynamic gen, ide integration points can be had via other methods (typing files etc). re startup time, the runtime generation is typically cached, and lazy/amortized. most folks are aren't creating clients at import time versus runtime. the current static generation pattern also feels anti consumption, the more azure you use, the worse the problem is. and its not just package size, its an explosion on the dependency graph and supply chain validation due to the package count as well.</p>\n<p>sadly I don't see a runtime style openapi client extant, so the lift on exploring this is larger then I'd like.</p>\n </div>",
"author": "",
"favicon": "https://github.githubassets.com/favicons/favicon.svg",
"source": "github.com",
"published": "",
"ttr": 49,
"type": "object"
}