The whole pipeline debacle is confusing. I recently did a demo at a Microsoft DevDays showing Microsoft hosted Ubuntu 16.04 agents in my build and then a self-hosted vsts-agent container (provided by Microsoft which still has the old name, why?) and part of the point was to show how slow not having caching is, even for a simple Python build pipeline. On top of that Microsoft has some odd pricing in that they limit your self hosted pipeline concurrency to 1 unless you pay them. That seems like a bad decision because most people would probably go through the effort of spinning some VMs natively in Azure which would increase overall OpEx. But instead, like the OP of the article, people will self-host on prem or in another/cheaper cloud. Microsoft gives no incentives to use native build agents (they are unreliable and slow) and almost force users to go self hosted but also charge for concurrency.

I've also had very odd issues where agent pools will have an idle worker but the pipeline will sit saying there are no agents, waiting. Eventually it goes, but... It's just a bad impression when you're showing it and it's not consistent.

Also, the UI. Tis horrible. Take a nod from AWS guys and get rid of the widgety attempt at entertaining some exec who doesn't use Azure. AWS interfaces load consistently for the most part and do a much better job in being not annoying, comparatively.

Another bad user experience is if you write a pipeline, by hand, without the GUI and try to run your pipeline - well, good luck. Authorization for certain components of your pipeline will fail, even if they follow the pipeline documentation to the T. Why? Because the pipeline web GUI workflow does linking of authorization between components on first run and if you only kick your build off using, say a code check-in, the pipeline will just fail. And it will give you a non-descript authorization error until you pull all your hair out and randomly do a commit from the Repository GUI of which it will pop up a message asking you to authorize the thing that had been failing for the last hour. Either document this better or give users a descript error of the actual problem. This, again, is oft where I find Azure lacking.