robconery
azdify
Deleted the old scripts that handled deployment and replaced them with bicep files and azd commands.
Updated readme to indicate that it uses azd.
Updated Makefile to use azd, including a teardown command to delete infra/app.
Added a devcontainer to install the dependencies needed and setup a containerised dev environment
Thanks Aaron - much appreciated. I was hoping to offer multiple ways for people to deploy this, including the simplest path possible amounting to no work at all other than installing/logging in to the Azure CLI. I do understand AZD is fine option here - but for non MS people it's a magic black box. Would you mind adding an azd target in the Makefile and putting the scripts back?
The Makefile is still there, I just moved it out of the server folder to the root of the template, and it uses azd for the three core actions - setup Azure, deploy to Azure, remove from Azure.
But I disagree on having multiple approaches because I find that's one of the biggest issues we have with our docs, there's too many ways to do the same thing (ClickOps in the portal, Azure CLI, ARM/Bicep, Terraform, azd, bespoke tooling, CI/CD tasks, etc.).
This is why I like azd, it's the best of both worlds. There's the one-step deployment with azd up that will log you in, provision the infrastructure and deploy the app, but also more fine grain control through the commands of azd init to create a new environment (of which you can create multiple), azd provision to deploy infra, azd deploy to deploy the application, and even azd pipeline config to scaffold a CI/CD pipeline.
Sorry for the delay, got back to getting the az cli scripts added back in
One of the things I want to focus on with this project is simplicity. Minimal API is all about a small footprint and I'm trying to emphasize that by making things as small and obvious as I can. Azure isn't the goal here - just a nice side effect. An "oh yeah - if you want to deploy to Azure we made it easy for you".
I do appreciate your point, however, that too many ways to do things can be overwhelming. Also: CLI scripts can be pretty dense when it comes to figuring out how Azure works and what you're going to be charged. In looking over the Bicep stuff, I have the same concerns - a lot of things seem to be on by default, like log analytics, monitoring and insights, which come with a price tag. Same with the default S1 sku.
One of the nice things about CLI scripts is you can read them pretty easily - especially if they're commented. I just noticed that I have B1 sku as the default which is an oversight - it's supposed to be F1 free tier on Linux. Either way there's a note about that in the script so they can see the different SKUs along with a link to find out more about pricing.
I'm wondering if it's possible to 1) put everything AZD needs into the /deployment directory and not have it be so prominent in the project and 2) surface the choices made for deployment and how/where to change them. I'm not terribly familiar with how AZD works so I might have missed something on that.
RE the Makefile - the reason it's in /deployment is that it has nothing to do with building the project itself. Make nerds out there would want their own Makefile in the root, which would orchestrate build tasks and other things - not necessarily deployment. Small Makefiles, happy projects.
Popping one in /deployment allows Make nerds to orchestrate things specific to deployment.
One of the things I want to focus on with this project is simplicity. Minimal API is all about a small footprint and I'm trying to emphasize that by making things as small and obvious as I can. Azure isn't the goal here - just a nice side effect. An "oh yeah - if you want to deploy to Azure we made it easy for you".
The inclusion of anything Azure related could be seen as a barrier to entry, because if you're not using Azure as your host, do you perceive the template is not for you as there's a bunch of "stuff" that comes along for the ride?
We can address this with azd using the azd init command and having the IaC files kept elsewhere, so that someone can, with a single command, add everything you'd need for deploying to Azure, but only do that when they choose to.
Simplicity is also a double-edged sword, as simplicity often comes as the sacrifice of good practices. This is a balance I always try to find - how do you give people simple tools to deploy while giving them a workflow that will graduate to more complexity when the time comes? This is where I find a nice balance in azd - yes, we dump a heap of Bicep files in to make it work (and Bicep can feel very foreign) but there's really only one command you need to get started, azd up. But after your first deployment you can break things down with azd provision (to create infra) and azd deploy (to deploy the app). This helps instill the separation between infrastructure management and code deployments. Finally, you're guided to the path of setting up CI/CD with azd pipeline to graduate from build/deploy local.
In looking over the Bicep stuff, I have the same concerns - a lot of things seem to be on by default, like log analytics, monitoring and insights, which come with a price tag. Same with the default S1 sku.
Yes, we can drop stuff like azure monitor, but again it's finding that balance between doing things "right" the first time and simplicity (and in this case simplicity is represented by cost). Also, because the azd templates go the route of using Container Apps not App Service, there's the need for a Container Registry which, assuming ACR (as it does), there is always an incurred cost (I think it's $5 per month).
Aside: I went the container route because I noticed you had some starting work on using containers already in there so I assumed that was a direction you intended to go.
One of the nice things about CLI scripts is you can read them pretty easily - especially if they're commented.
The same can be said with Bicep. Admittedly, I didn't do that here, but adding comments to explain what the various parts are is something that can be done to help people learn. It's also likely that the Bicep can be slimmed down from what we have - I'm by no means a Bicep expert so I've pulling in the "kitchen sink"-esq files which are verbose because they show all options you can configure and plug in defaults where they make sense.
Also, adding documentation on how the .parameters.json files work/are used would likely support people in their understanding what they can/can't change and how to influence the defaults in place.
I'm wondering if it's possible to 1) put everything AZD needs into the /deployment directory and not have it be so prominent in the project and 2) surface the choices made for deployment and how/where to change them. I'm not terribly familiar with how AZD works so I might have missed something on that.
Possibly. I've only ever done azd as a repo root because a repo tends to be made up of more than a since "project", so having it within the src/server felt foreign to me. It's possible there are some hard-coded assumptions on repo/folder layout that need to be respected but I'd have to go looking to find out if they are there.
RE the Makefile - the reason it's in /deployment is that it has nothing to do with building the project itself. Make nerds out there would want their own Makefile in the root, which would orchestrate build tasks and other things - not necessarily deployment. Small Makefiles, happy projects.
Right, but this is where I felt it logical to lift the concept of deployment out of the src/server folder entirely. The implication upon initial inspection is that you are deploying the server only here, not the server and client (which is does) as a single web app. Given the JAMStack-inspired nature of the template, I look at this as a pseudo mono-repo with two components, frontend and backend, and there's no clear "deploying the frontend" aspect until you realise that the frontend is bundled into the server for deployment.
By lifting the concept or deployment to the root (and as such, the Makefile) I felt it was clearer in the intent.
Hey there - sorry I missed this! For some reason I didn't get notified that you replied... wasn't ignoring I promise :).
The inclusion of anything Azure related could be seen as a barrier to entry
That's just a starting point, honestly. I had a /docker directory in there with some compose stuff that @asw101 was putting together (as well as K8s) but we got a little sidetracked trying to figure out if it was overkill. I do appreciate your point RE barrier to entry, but I think that also applies to AZD's presence, yeah?
Regarding "doing things right" I also see what you mean - apps should be deployed with some type of monitoring/logs - but the thing I want to avoid is making that decision for the dev. They might be happy with PagerDuty or Honeybadger or whatever service they use - the last thing I want to do is give off the idea that I'm trying to shill for-pay services.
I would love to see if there's a way to have AZD be a bit less prominent and more of a deployment option. I do agree that it can read well if there are some comments and an explanation (a README maybe), but if we could confine it to /deployment/azd that would be very nice indeed.
I do appreciate your point RE barrier to entry, but I think that also applies to AZD's presence, yeah?
Everything is going to pose a barrier, it's more a question of where you find the trade-off. The way I'm seeing azd positioned is that it is to be the tool underpinning samples and demos being produced by teams going forward, resulting in a more consistent approach regardless of if you're doing .NET, Python, Java, etc. This consolidation helps lower the barrier as you're more likely to be familiar with the patterns as a result of them appearing in more locations.
They might be happy with PagerDuty or Honeybadger or whatever service they use
Sure, and it comes to a question of whether this should be opinionated or not. I will admit though, I'm somewhat at bemused by the JS community and the affinity to managing a dozen or so separate accounts rather than consolidation - which is ultimately the opinions expressed in the way I put these templates together.
I would love to see if there's a way to have AZD be a bit less prominent and more of a deployment option. I do agree that it can read well if there are some comments and an explanation (a README maybe), but if we could confine it to
/deployment/azdthat would be very nice indeed.
I think it should be possible to move it to a folder such as that, and maybe wrote some comments/README 😜