I think the problem here is that they submitted a fabrication. If someone is prepared to do that, I don't think how they drafted the document is really the issue.
Reserved concurrency both guarantees a portion of your concurrency limit be allocated to a lambda as well as capping concurrency of that lambda to that portion. Reserved concurrency has no cost associated.
Provisioned concurrency keeps a certain number of execution environments warm for your use. Provisioned concurrency costs money.
I'd agree with them that the portal is terrible. Multiple times a day I get blank page errors, where the page is completely blank except for a single non-sensical error message in black text.
However their actual services are also pretty terrible. Pretty much everything takes significantly longer to deploy than the AWS couterpart. There are so many preview and deprecated features that it is often hard to judge exactly what feature set you are getting, this is often compounded by the fact that almost everything has multiple SKUs which also change available features. Azure AD RBAC is a bit of a mess, although its conceptually simpler than AWS IAM policies its just a pain to use in practice, and its often slow for changes in permissions to actually reflect. Azure VM disks are annoying to use too, you can't set the size of the OS drive at creation and extra data disks come unformatted. "Grossly incompetent" is probably an overstep though, Azure is very impressive, just not as impressive as its competitors right now.
Having said all that their are a couple places where Azure really shines in my opinion:
* Resource groups (GCP has a similar feature) allow you to more easily keep track of related resources across services.
* Price transparency. Many (not all) services tell you up front hourly/monthly costs as you are deploying them through the portal. You don't have to track down a pricing page or calculator yourself.
* Azure functions are amazing when using C#/.Net. A huge amount of the regular boilerplate is abstracted away into simple C# annotations so you can get a large % of business logic.
Hi, can you guys look at the portal security? In some corporate accounts most people have limited access to do stuff, but it is all enabled; you spend a few minutes to create a new resource just to get an access error after you submit, when it should be disabled (displayed, but disabled) if you cannot do it, do the access check before not after. There are so many options we never know which one is enabled and which one is not.
I'd much rather explicitly state when real resources are renamed than have terraform diffing my code and guessing whether I wanted to rename it or I am actually trying to recreate something. I can only imagine the headaches that would happen with a tool trying to track changes to infra as well as changes to code without explicitly tying infra state to version control somehow.
> I'd much rather explicitly state when real resources are renamed than have terraform diffing my code and guessing whether I wanted to rename it or I am actually trying to recreate something.
But you're not renaming real resources, you're just renaming the Terraform identifier that corresponds to them. There's no reason that changing this identifier should destroy and recreate the resource it corresponds to. If you explicitly want to destroy and recreate it, you can change an attribute that forces a recreation (typically a "name" field or whatever identifier the resource's provider cares about).
OK but how does Terraform know you are renaming a resource? It is not a daemon always running and watching everything you type. It only gets a snapshot of your code to work from when you run it, it doesn't know what your code was before, just the saved state from your last run and the real state in your cloud provider. The only way it can track the state is through the name which you have provided it, if you change that name it cannot know without inferring something. Maybe it matches up all the attributes in your code and state and infers that a rename has happened. What happens when only 95% of attributes match? What happens when multiple things match (An ec2 instance only requires 2 attributes so this is plausible)?
Example 1:
You have 2 essentially identical EC2 VMs with terraform names vm1 and vm2. You decide these are not good descriptive names so change them to webserver1 and webserver2, before running that change you also realise you only need 1 of the servers so delete webserver2 from your code. Terraform runs a plan and sees there is now only a single VM definition but 2 VMs in state. Neither of the terraform identifiers match the original resources. How does it know which one was renamed and which one to delete?
Example 2:
You use Terraform for IaC and something like Chef for configuration management so your Terraform code exclusively deals with the "hardware". A service is being migrated to a new implementation so you need to delete the old VM and bring up a new one. Both old and new implementation have the same exact hardware requirements. You make the change in your Terraform code, deleting the old resource and creating a new one with the same requirements but a different name, and run a plan. Terraform tells you there's nothing to change because its inferred that you wanted to rename.
See: https://en.wikipedia.org/wiki/List_of_grammar_schools_in_Eng...