Azure SDK is over 500MB and growing on each release.

[sodul]

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 Azure SDK, in the SDK the network directory is taking almost half of the size and this is because there are 39 versions of the SDK.

I have never seen anyone doing such a strange approach to version their API clients. I fail to understand why anyone would even want to use the client from 2015 on a cloud product like Azure.

root@1bba10bd1500:~/.pyenv/versions/3.9.2/lib/python3.9/site-packages/azure/mgmt/network# du -shc * | grep M | sort -n 
1.2M	aio
2.4M	v2015_06_15
3.3M	v2016_09_01
3.5M	v2016_12_01
3.7M	v2017_03_01
4.4M	v2017_06_01
4.4M	v2017_08_01
4.9M	v2017_09_01
5.1M	v2017_10_01
5.1M	v2017_11_01
5.1M	v2018_01_01
5.7M	v2018_02_01
6.5M	v2018_04_01
6.6M	v2018_06_01
6.9M	v2018_07_01
8.3M	v2018_08_01
8.4M	v2018_10_01
8.6M	v2018_11_01
8.8M	v2018_12_01
9.0M	v2019_02_01
9.5M	v2019_04_01
10M	v2019_06_01
11M	v2019_07_01
11M	v2019_08_01
11M	v2019_09_01
11M	v2019_11_01
11M	v2019_12_01
12M	v2020_03_01
12M	v2020_04_01
13M	v2020_05_01
13M	v2020_06_01
13M	v2020_07_01
13M	v2020_08_01
259M	total

Can the default release only prove the latest version of the client libraries, or at least provide a 'lean' version of the SDK? This release model is certainly not sustainable and is causing useless grief to your users.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

Issue Details

---

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 Azure SDK, in the SDK the network directory is taking almost half of the size and this is because there are 39 versions of the SDK.

I have never seen anyone doing such a strange approach to version their API clients. I fail to understand why anyone would even want to use the client from 2015 on a cloud product like Azure.

root@1bba10bd1500:~/.pyenv/versions/3.9.2/lib/python3.9/site-packages/azure/mgmt/network# du -shc * | grep M | sort -n 
1.2M	aio
2.4M	v2015_06_15
3.3M	v2016_09_01
3.5M	v2016_12_01
3.7M	v2017_03_01
4.4M	v2017_06_01
4.4M	v2017_08_01
4.9M	v2017_09_01
5.1M	v2017_10_01
5.1M	v2017_11_01
5.1M	v2018_01_01
5.7M	v2018_02_01
6.5M	v2018_04_01
6.6M	v2018_06_01
6.9M	v2018_07_01
8.3M	v2018_08_01
8.4M	v2018_10_01
8.6M	v2018_11_01
8.8M	v2018_12_01
9.0M	v2019_02_01
9.5M	v2019_04_01
10M	v2019_06_01
11M	v2019_07_01
11M	v2019_08_01
11M	v2019_09_01
11M	v2019_11_01
11M	v2019_12_01
12M	v2020_03_01
12M	v2020_04_01
13M	v2020_05_01
13M	v2020_06_01
13M	v2020_07_01
13M	v2020_08_01
259M	total

Can the default release only prove the latest version of the client libraries, or at least provide a 'lean' version of the SDK? This release model is certainly not sustainable and is causing useless grief to your users.

Author:	sodul
Assignees:	-
Labels:	Mgmt, Network, Service Attention, customer-reported, question
Milestone:	-

[kristapratico]

Hi @sodul, thanks for the feedback, we'll investigate asap.

[jiasli]

Previously reported in #11149.

[sodul]

To clarify #11149 is only about azure-mgmt-network which is the largest directory but the problem is present across the entire Azure SDK.

I understand the reasoning for the approach to keep everything for backward compatibility but if you do have customers that point to the old versions then they should pin their requirement versions to the old pypi.org releases of the Azure SDK, not force everyone to keep a copy of everything around. How about providing two versions of the SDKs: one large with everything, one small with just the latest version.

[nolaexe]

Hey, is there any update?

[sodul]

I wrote a script that we run after pip install. It detects the unused versions and this got us an azure folder shrink from ~ 680MB to ~ 280MB. It cannot go any lower because for some reason some of the objects model definitions from multiple versions are merged together to make the final list that is then used. The script detects the versions that are used internally by the SDK and preserves them, making the script very safe to use.

If there is interest I can open source the script.

[sodul]

We have released our script on GitHub. It does delete a good chunk of the API folders but not all of it. With the script the Azure directory is now just under 300MB instead of over 700MB. It is compatible with most, but not all, third party packages, as long as they do not point to a version that is trimmed.

https://github.com/clumio-code/azure-sdk-trim

[KranthiPakala-MSFT]

@kristapratico Following up to see if there is any update on this issue? - Thank you

[lmazuel]

@KranthiPakala-MSFT we are working on this, and there is ongoing discussion on the issue to be sure we consider all possible impact of any decisions, and nobody would be broken by it.

[logachev]

@lmazuel I think one old proposal that won't break anything is to release separate azure-sdk-slim with only latest APIs (that are used by default) and possibly do something with comments (iirc, removing comments reduces the size by 30%)

[sodul]

Removing non latest APIs, will remove about 60% of the disk space needed. A further design issues is that some of the API definitions import prior APIs in order to have a complete set of objects. I have no idea why these API definitions where designed this way but it is definitely not very good. I did not think of the idea of stripping comments, which means that we could probably extend azure-sdk-trim to remove comments and other useless whitespace. There is probably a tool that 'compresses' python that we could run. Of course we would not want to remove docstrings, they do help.

[logachev]

@sodul Yeah, agreed. So far I saw only keyvault being broken by your tool (which should be fixed soon I guess #21623).

I think there are actually 2 scenarios we're talking about.. Development - I agree, comments & doc strings are useful.
However, building production image - docstrings are unnecessary.. The only trick there is - need to preserve number of empty lines as a replacement for a docstring comment to get same line numbers with exceptions.

[ghost]

Hi @sodul. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[sodul]

/unresolve

[Lawouach]

Thanks @iscai-msft for keeping it opened.

[sodul]

I've noticed a significant improvement with the more recent releases of the SDK. The space used has been pretty much halved from 1.2GB to 600MB and with azure-sdk-trim we went from 600MB to 300MB.

+ azure-sdk-trim
.pyenv/versions/3.12.3/lib/python3.12/site-packages/azure is using 606.9 MB.
Detected az cli with 39 SDKs to keep.
.pyenv/versions/3.12.3/lib/python3.12/site-packages/azure is now using 305.7 MB.
Saved 301.2 MB.

This was with azure-cli==2.60.0.

[iscai-msft]

Amazing, it's still an ongoing process but the sdk and the cli team have both been working on reducing the package size, glad that you're able to see the difference!

[github-actions]

Hi @sodul, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

[sodul]

The latest SDK releases are back to 1.2GB somehow.

Output from running https://github.com/clumio-code/azure-sdk-trim:

/Users/stephane/.pyenv/versions/3.12.6/lib/python3.12/site-packages/azure is using 1.2 GB.
Detected az cli with 39 SDKs to keep.
/Users/stephane/.pyenv/versions/3.12.6/lib/python3.12/site-packages/azure is now using 603.3 MB.
Saved 622.8 MB.

[iscai-msft]

@msyyc do you know why the size would bump x 2?

[msyyc]

@msyyc do you know why the size would bump x 2?

I think it is still related with some multiapi packages (e.g azure-mgmt-network/web/containerservice). These packages are updated frequently with more new api-version so the size increases more.

[sodul]

@msyyc @iscai-msft is there a hard limit on the size where it will be deemed unacceptable and be made a blocker for new releases? Is it 1.5GB, 2GB, 5GB, 10GB? Unless there is some drastic changes with the current SDK model these sizes will be reached.

I can't see this path to be sustainable, especially in the modern container based world.

[iscai-msft]

@sodul agreed, @msyyc are you able to reach out to your contacts on the management team and ask which multiapi packages they're releasing and why they aren't using the multiapi combiner script? We definitely don't want to move backwards here

[orgads]

Version 2.64.0 installed on debian takes 1.9G with all __pycache__ dirs. Removing them reduces the size by 2 to 980M.

[msyyc]

I will contact CLI team for more discussion about the size issue.

[kbrock]

There were similar issues with the ruby gem. It just kept growing and growing until support was dropped.

With rapidly iterating code, it is tricky to version APIs.
To me the current version is just a snapshot on a date and time.
Has there been thought into introducing semantic versioning? Guess this would follow along with a scheme like keepachangelog.com - you mark what new apis are added and removed at each version. Good advertising for the new features, and helpful for customers to fix bugs and migrate code to the newer apis.

• If functionality is added and none removed/changed, then just update the current api code.
• If functionality is added and changed (and old code still works from different endpoint), then you need to add a new endpoint.
• If functionality is added and changed (and old code does not work), then keeping the old endpoint is not very useful - not sure what you do here. Probably drop old endpoint code and use latest.

[sodul]

One problem is that the Azure SDK team insists on bundling every single past release of the SDKs as a whole. The reasoning is that some customers might be stuck on a specific version, which I personally find dubious since I find it difficult to believe that anyone would want to use the 9+y old version of the networking SDK for their work. Does it even actually work with the API in place in 2024?

If such customers insist on using such old versions they probably use very old, long deprecated, versions of Python and other libraries, likely full of known CVEs as well. This causes a massive inconvenience to the vast majority of the users of the SDK and az cli tool. Such customers, could simply pin their requirements to these older releases and everyone else would not have to suffer through the size issues. It would be easier to manage as well for the SDK development team.

The current workaround, to help reduce the size, is to have newer SDKs import and add/override methods on top of prior versions of the SDKs. While this helps with reducing the incremental size, it does not fix the problem that the new releases are carrying unnecessary files that are useless to the vast majority of the users of the SDK.

If prior versions of the SDKs are still required with the same model, at the very least introduce a deprecation model where v2015_06_15 is eventually dropped off completely. Even if it is 1-2 years, or keeping the prior 2-3 versions, but not dozens of versions until the end of times. Not removing older versions is probably a cumbersome maintenance burden when old versions have hard dependencies on older 3rd party libraries and the SDK maintainers have to fix all these versions to move forward. With the python project deprecating things more aggressively staying compatible with newer versions of Python will also become harder over time. We have seen that with the syntax deprecation on how strings are quoted in the SDK in recent months for example.

Sorry for this long post but a lot of the SDK and az cli users are facing very concrete issues caused by this unusual approach to the SDK maintenance and this need to be addressed as a higher priority by the SDK PMs.

[iscai-msft]

i agree, and I apologize again for all of the issues you guys have been dealing with. I'm going to reach out more to the folks working on this. Really sorry for this still being a continued issue.

[Lawouach]

I think your commitment to move the needle in the right direction is great.

[lmazuel]

Thanks for commenting on this thread, this is highly appreciated. We're 100% aware of this, and we tried different approach to solve this problem (you may have noticed that azure-mgmt-network is smaller than it used to be), but there are unfortunately a few tooling (ironically this includes the CLI), that are designed assuming they can install multi-api SDK and load API-version by module name. I hope we can reach a conclusion that solve this problem for all party involved soon, I'll keep you guys updated, this issue is bookmarked in my top bucket list.

[msyyc]

Status update:
SDK team has converted part of multiapi packages into singleapi packages. The size of those packages including network is reduced by 61%~94%: #38009

[lmazuel]

Additional update: we have all agreed, including CLI team members, that SDK should stop shipping multi-api SDK entirely. A SDK will target the last known API version as the expected contract. It will still be possible to pass an api_version parameter, but the SDK will not verify if the parameter set passed is conformed to that API version and will let server signal any troubles with a server exception. It's recommended for people that rely on a very specific API version, to pin the SDK package to the version where that API version was the last one (so you get proper typing help at least).

We're rolling this on all packages over the next couple of months.

Part of this effort, we will also split some packages into sub packages. For instance, disks from the azure-mgmt-compute package will have its own individual package. The rational is that disks never versioned its service with the same API versions than regular compute operations (like VM), making that package complex to version, as it actually contained a combination of API versions of various resource types. The bad side effect, is that it will be a breaking change when disks will disappear from azure-mgmt-compute, but the good side effect is even smaller SDK (less API versions and less resource types, both contributing) and a more consistent API version timeline (a unique one per package). The breaking change should be minimal (install new package, and create new client, everything else is still the same, no operation or model change).

We will do this split on a few packages, the exact list is TBD, but if you're aware of a SDK with a mix of various API versions, he's probably on the future list.