The provider debate AzureRM vs AzAPI

Azure RM and aapi two excellent providers but which one is best there's only one way to find [Music] [Applause] out so in this video we're going to be comparing Azure RM version 4 and aapi version 2 and the idea is to help you understand which one you think might be the best fit for your requirements it's a very personal choice um what I hope to do in this video is explain my

experiences of using both providers uh in order to help you make the right choice for you we're going to start with an overview of both providers and then we're going to cover a few topics we're going to look at documentation arm compatibility the features and the developer experience and then I'll wrap up at the end I guess the first place I'd like to start is with this blog article by Steven Ma so Steven is terapon PG at Microsoft uh this Blog has also been repeated on the Hashi Corp site as as

well so it's basically a co-release by both Microsoft and hash cob I should point out that this video is just my personal View and is not affiliated with either organization so this is worth a read um essentially we're saying two powerful terraform providers yeah agree with that um this article offers guidance to which one you should use fantastic so at high level asrm provides a stable well tested layer on top of the Azure apis it handles the entire resource life cycle uh while managing breaking

changes ensuring smooth operations azm is ideal for users looking for stability and a simplified configuration management yeah I'd agree with that I think that's fair on the other hand aapi is a lightweight wrapper around the Azure apis direct and early access to latest Azure features yeah I absolutely uh quicker adoption of new services and workarounds for a limitations which we'll come into a bit later

ideal for users who need cutting EDG functionality uh and we'll Deep dive into them below right proven simplified approach for Azure RM abstract complexity by managing things like API versions on your behalf um better documentation uh and simplicity okay this is the real big one I think for azm Simplicity a API um when you need stuff that azm can't do ultimately um is the principal reason for using it but there's more than that and and this is what I want this is where I think this this

blog article perhaps misses a trick um because it does cover some of the new features in here so resource versioning user defin retrival errors header support URL control um all this kind of stuff I think is is probably not mentioned enough and and I'm going to make a bit more of a point of that um okay so when to use each provider again kind of repeating the messaging here RM if you want stability Simplicity automatic versioning aapi if you want Cutting Edge features um latest

stuff for measure okay so I'm now going to take this article this is the this is the line from Microsoft and Hashi cor but I'm going to take this article now and go through the providers on my own uh and I will give you my take on that so first of all let's cover the key differences between them in terms of the way that they've been designed ATM is uh handcrafted each resource is handcrafted each documentation uh page is also handcrafted did and tested so that's

where the Simplicity stuff comes from because you know a developer has had to go and look at the SDK in fact the asrm uses it doesn't use the Microsoft SDK uses its own SDK and then bring the features from that and create a terraform schema which is their opinion of how they think the resource should look in terraform it's actually got nothing to do with the arm uh rest API because there's that layer in between that transitions from the terraform schema to

the rest eventual rest call that's been made so because of that there is always going to be a delay between a thing being released in Azure and it being supported in Azure RM because somebody has got to go and make a thing or update a thing and this is the same with new features new API versions whatever and it's just that's how it's been designed and to be fair that's how most providers have have been designed for terraform historically aapi is a

resour is a provider that has been built on essentially autogen so it looks at it's got some generic resources in there and it looks at the rest API specs and it generates the schemas from there and they are all Dynamic so that has the advantage of ultimately being able to support absolutely anything in arm um but you just have to realize that aapi is it can't have the level of documentation because it's autogenerated however there are a few tricks that we can use to uh to make

life a little bit easier so let's start at the first ctory documentation azm has excellent documentation because it's been crafted by a a human being and it is very very very good absolutely hands down Azure is the winner in terms of documentation but there are some there are some features that I don't think people know enough about with a API so let's say I wanted to create an application Gateway and API

and in my search engine I put application Gateway and I won't put terraform in here because I'll get probably the provider docs for Azure RM but if I put bicep what it will do is it will link me to this page and if I zoom in a bit want that key there sorry if I zoom in a bit you can see we've got the application gateways resource I can look at the terraform so this is the aapi documentation it's it's just not in the

hash portal it's here so my top tip is to search for the resource type you want and then the word bicep actually uh and then you can have a look at this so you can it tells you it's deployed at a resource Group scope it's then got the entire resource format uh the one thing I will say is uh we're still working on getting rid of this Json and code bit you don't need that anymore is this is just an HL object so you can just get rid of this function around it and then the corresponding closing bracket at the end so this is a real complicated

resource and you might be thinking oh my goodness what does all this do uh but let's scroll so let's scroll down here and you will see so this is for example the backend HTTP settings these what all the properties are this is the description of it and this is the this is the value type right and you can see that authentication certificate is a sub resource and you can click on that and it'll take you to the definition of what that is so connection draining we can click on connection draining and it then tells you that that's an object with drain time out seconds and whether it's enabled or not and you can tell

one's an in and one's a ball so there is documentation for a API um it is not as good as as yourm it just isn't but it is there and that is a really really useful trick so let's move on now to arm compatibility so aszure RM it's okay it's for most stuff it's it's fine but there are a lot of times that you will be waiting for stuff to be added because it's doesn't exist now if you're not a

go developer and you can't make that poll request yourself you can be waiting months which is incredibly frustrating um it's just the way it is um I don't know there's not much you can do about it um the only thing the only thing I've seen people do is to use aapi for just the things that they want to have the extra features for which is cool um however if you've already deployed that thing you're then into a time where you need to migrate the St over from an asrm resource to an eapi

resource yeah you can do it I'm not saying you can't do it you can do it but it's a pain um so you need to research whether azm supports the stuff you want from the beginning and if it doesn't you need to make a different Choice aapi obviously perfect supports everything uh you can even do non uh put requests so you can do posts you can do basically anything you want to do with as your apis you can do with AC

API features so azm has got provider functions now which is really good so you can do things with resource IDs like pausing them and chopping off into bits other than that I don't think there's much to add with V4 in terms of features they've you know renamed a few things and changed a few things around um one thing I would like to point out is it's a it's a bit of a regression I think to mandate the subscription ID I'm sure they had good reasons for it but for a

developer a terraform developer it's a pain like if I'm deploying a resource at a management scope Management Group scope why do I need a subscription ID doesn't make sense um if I haven't got any subscriptions and I want to create one so I'm thinking a terraform Stacks style scenario here where I create a subscription and I put something in it in a separate uh component I I have to have a subscription to begin with it's just seems odd uh I don't know why they did it um so yeah I'm not a massive fan

of that a plus point for Azure RM though is data plane azure's got great data plane access uh it sometimes does it when it doesn't have to so um a weird issue that I I still don't understand fully is when Azure RM creates like a blob container or a key in a key Vault it actually has to talk to the data plane even though it's not necessary because bicep can do it bicep doesn't talk to the data plane and aapi can do it and that doesn't talk to the data so yeah that's not that's only a problem

if you use something like private endpoint so you configure your storage account you put a private endpoint on it then you try and create a blob container and asual R will fail because hasn't got access to the data plane why why why does it need to do that anyway in general though data plane support for asrm is is much much better than aapi so if that's really important to you that's that's the key decision point aapi so so so many features um things like doing aapi resource action

with the when equals apply or destroy so you can do something like do a post request or something when something's on a destroy plan like it's just just amazing uh so much flexibility in there you can do now do James path queries for the resource body output so if you just want to Output a specific thing from the resource body you can write a Jason query and just pull that exact thing out that you want you can now modify headers and query parameters so why would you want to do that well virtual Network peering

resync is actually a URI parameter so if you wanted to orchestrate that within an aapi module you can now conditionally add the uh uh resin the v-net peers onto your um peering object um yeah massive win you you could do it with aapi before but it was a bit of a hack but now they've made it a first class feature which is amazing um retries this is the biggest one for me and a slight humble brag because um it was sort of me and my

team's idea to to add this to the provider because we were having so many problems deploying stuff at Management Group Scopes the reconciliation time for when you deploy stuff at Management Group scope is quite long so if like if you put a policy definition at a management group and then you try to assign that policy definition at a child Management Group it would sometimes complain as you would complain say oh sorry you can't this this definition is not in scope and it was it just hadn't reconciled it hadn't become come consistent so with

this retry feature we can with a RM you you had to be using awful things like time sleeps and other really blunt tools to try and get around this problem but with aapi now you can say actually if you get this error I want you to retry because I know that this Trans in error how long will it retry it will retry up to the uh timeout value the resource creation timeout value or the resource update timeout value whatever it is so you can have complete control over what is a retriable error and what is actually this is now I want you to

stop absolutely fantastic it's gone from for the Azure Landing zones module it's gone from having you know taking a few goes to apply it every time to applying it every time first time in a single go it's absolutely incredible so for me on features aapi definitely wins let's talk about developer experience asrm is it's it's simple it's it's really easy to use and get started

it's idiomatic terraform it just the documentation is great the language server is great it's cool it's brilliant aapi well the price you pay for all that control is that it is more complex to develop for you need to be comfortable with the arm resource schema and you need to be comfortable with putting all the properties as an HCL Dynamic object the language server and docs are there that page over there I just showed you that has all the documentation for the resource is a really really great help

the challenge comes when you want to have optional features in your module so you know you have if variable Fu enabled then you know do this if not do something else the challenge is then you either going to be using locals to Define partial bits of that that resource or you're going to be uh using inline teries or something like that to just switch things on and off it's cool you can do it I'm going to do a separate video on module development for aapi CU I think it's an unexplored topic and there are a couple of tricks that are really really useful and a couple of P that I'm going to

show but yeah it is harder to develop for not going to lie the price you pay for all that extra all those extra cool features is that you need to be slightly better at creating the modules it's kind of a bit less forgiving like you need to and bicep authors will be familiar with this but to get an IDM potent configuration you need to know which bits of the the resource uh property to include and exclude depending on what features are enabled it's just it slightly elongates the developer cycle

if you're coming from bicep then AI is the obvious choice I think just because you completely used to it so um yeah to wrap up documentation asm's better arm compatibility clear win for a API features I think a clear wi for a API developer experience as your RM is is easier so I hope that kind of helps you understand where you might want to use which provider for me so my advice is use whichever one makes you

happy I'm it's it's a very personal choice for me I use aapi for most things now because typically in the modules that I write I'm going to be having to use aapi at some point anyway because there'll be something I want to do that I can't do with a RM as soon as you get to that point actually I'd rather have I'd rather just do it all in aapi because if you're managing modules over a wide uh module estate the the the fewer

dependencies you can have the better and if my module's dependent on that azm and aapi it just makes life more difficult when it comes to version upgrades and things like that so typically I will default down to aapi because of the reasons mentioned um yeah I hope that was useful um it's normally a quite uh people get quite into this and so I'll be interested to know what people think um but that's my personal take on which Prov to use they're both great choices

but I would if you if you made me choose I would pick a API anyway that's it for this one I'm going to do a follow up on some of the new aapi features and how to use them hope you found it useful uh see you next time