I’ve contributed to the development community in many ways, be it speaking at conferences, writing technical blog posts, getting involved in conferences as volunteer or part of the crew, or helping with Hackatons and Open Hacks. However, writing a book has been in my todo list for quite a while, and honestly, I’ve been afraid to start due to various reasons, mainly because I heard how much time and energy you need to put into it.
\nRegardless, I set it as a goal in 2021 and after a few months working on it, voila, it’s now listed on Amazon to be published early next year. I am so excited about it and thought to share my experience and how I reached this milestone.
\n\nWriting a book might seem like a far fetched goal, in fact there are many smart and talented people out there writing great technical books on various topics which become best sellers. So you might be asking yourself why would I even think about it.
\nHowever, before we go further let me tell you a few things:
\nSo let’s go back to why you should write a book. I would share my own reasons, but you might find them relatable too.
\nYou might be good in a subject and have worked with it for a long time. You might even not have worked with it but be very passionate about it and wanted to share what you learn with others to help them succeed. For this exact reason, I believe it’s important to think about writing a book if you have enough in your mind to make it work.
\nI have read books before and they have helped me reach where I am because I’ve always progressed as a self-thought individual rather than being academic or even as a trainee. So it was important for me to give it back somehow and finally it happened, think about it.
\nFrom a professional perspective, writing a book will add to your creditability and establish you as an expert in that field. Who knows, it might also help you land a great job, think about your interviewer when you tell them you have a book on the subject and how positively it can affect the process.
\nIf you have a todo list and have some goals for yourself, why not put writing a book in there too. Think about how accomplished you feel when you actually do it. You will tackle a new challenge and prove to yourself that nothing is impossible if you put your energy into it.
\nWriting a book can help you learn a lot in a specific subject. When you are writing a book, it becomes important that you validate your knowledge and back everything with facts and data. During this process you will learn new things in every step of the way and that to me is worth all the time and energy you put into it.
\nNot every goal is about money, but if you can make a few extra bucks publishing your book, why not. You have put your time on it and getting rewards in form of a currency (😎) can be very helpful to anybody.
\nNow that I mentioned my reasons, think about what else and let me know, I am keen to hear yours too. Enough about reasons, let’s talk about the process.
\nIt is no secret that writing a book requires discipline and good time management. But let me tell you it needs a little bit more than that, in my case anyway. You might have to put extra effort or be a bit more proficient than me, so take this with a grain of salt.
\nFirst thing you need to do is to find a topic, but you can’t find any topic. You need to find something that you’re good at it, and you really believe it’s important to share it with others. In my case Azure Bicep is a new tool, there are not many books written on it, and I am really passionate about how it can help people achieve more by doing less.
\n\n\nIf you want to publish your book, you also need to find a topic where there are not many books available by other writers on it.
\n
It’s important to have an outline to be able to tell a story. Yes, you heard me right, even a technical book needs a story if you want it to be effective. You need a beginning, middle and end which takes your readers on a journey. Start with simples, then move to advanced areas and then finish off by some best practices or something that compliments your points and helps them a few extra steps.
\nI can’t emphasis enough how important it is to read what you write first. If you feel you’re biased, get somebody else to read it and give you feedback. Sometimes we don’t realise how we fall into trap of making assumptions and the book turns out to be useless because of that.
\nIf you are a full time employee like me, you need to set a schedule for yourself and make it a habit. Lock it in your calendar and make sure it’s a time with minimal disruptions. I used one hour every night from 10pm to 11pm when my kids were in bed and I had already finished my dad duties. But I kept it like that for 4 months until I finished the book and boy that helps.
\nIf that doesn’t work for you, you can set a goal for how many words need to write each day, week, months, etc.
\nBooks are different that blog posts in a sense that they need to be credible. Having grammar errors or spelling mistakes will look really bad, so use a software which helps you proofread your writing.
\nAnd that’s all I did to be able to be here writing this post.
\nIt can become a really hard job even from start, so keep yourself motivated. If you face any setbacks or challenges, try to positively face them and work your way around solving those slowly and steadily.
\nReward yourself, give yourself a little treat at the end of every chapter, or section. This definitely helped me, so it will probably help you too.
\nI hope this has motivated you to at list think about the possibility of wiring a book. Anyway, I didn’t talk about the book itself, so read on.
\nInfrastructure as code with Azure Bicep is a book which takes you on a journey from what Azure Bicep is, to how it works and its syntax. Then you learn about all the bits and pieces to be able to write maintainable, reusable, modular templates to be able to deploy your resources into your Azure environment with confidence. It also covers the authoring experience and how amazing it is to work with it from Visual Studio Code and its extension.
\nThen it covers how to use it in your CI/CD pipelines both on Azure DevOps and GitHub actions. And at last we will cover some advanced topics to add that extra bit of tidbits which makes you stand out when writing infrastructure as code such as some best practices and patterns when deploying multiple environments.
\nSo keep an eye out and support me and my book if you can 😍🙏🏽.
","timeToRead":5,"frontmatter":{"title":"My first ever book on Azure Bicep","unformattedDate":"2021-12-02T00:00:00.000Z","date":"Dec 02, 2021","path":"/bicep-book/","author":"Yaser Adel Mehraban","tags":["azure","bicep","devops","infrastructureascode"],"thumbnail":null}}},{"node":{"id":"6d57c7aa-5f97-5164-a4fa-2ccacf70cdde","html":"If you have deployed a resource in Microsoft Azure as part of your CI/CD pipeline you have probably worked with ARM templates. These templates can be used to automate your resource deployment to Azure and help you to have consistent environments whether it’s for testing, development or production purposes. However, there are some shortcomings when it comes to complex environments especially when you have many resources and the dependency between them makes the templates to be either super busy, very complex, or unreadable.
\nFor that Microsoft has introduced Bicep which is designed to overcome these issues and help you with your infrastructure as code setup.
\n\nAlthough there are some great features which make working with ARM templates a good experience such as functions, variables, nested templates etc, there is some room for improvements regarding below which has been raised by the community:
\nBicep is a DSL (domain specific language) which can be used to write your Infrastructure as Code (IaC). Instead of writing ARM templates you write your code with Bicep and it will transpile it to ARM for you. It simplifies the authoring experience and addresses some of the issues we mentioned earlier. Compared to using JSON, Bicep can help you simplify the template definition a great deal.
\nLet’s see this using a simple example. Imagine you are trying to create a storage account in Azure, with ARM template this is the minimum you will need:
\n{\r\n \"$schema\": \"https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#\",\r\n \"contentVersion\": \"1.0.0.0\",\r\n \"parameters\": {\r\n \"storageAccountType\": {\r\n \"type\": \"secureString\"\r\n }\r\n },\r\n \"variables\": {\r\n \"diagStorageAccountName\": \"[concat('diags', uniqueString(resourceGroup().id))]\"\r\n },\r\n \"resources\": [\r\n {\r\n \"type\": \"Microsoft.Storage/storageAccounts\",\r\n \"apiVersion\": \"2019-06-01\",\r\n \"name\": \"[variables('diagStorageAccountName')]\",\r\n \"location\": \"[resourceGroup().location]\",\r\n \"sku\": {\r\n \"name\": \"[parameters('storageAccountType')]\"\r\n },\r\n \"kind\": \"Storage\"\r\n }\r\n ]\r\n}Using Bicep it will be simplified to:
\n@secure()\r\nparam storageAccountType string\r\nparam location string = resourceGroup().location\r\nvar diagStorageAccountName = concat('diags', uniqueString(resourceGroup().id))\r\nresource diagsAccount 'Microsoft.Storage/storageAccounts@2019-06-01' = {\r\n name: diagStorageAccountName\r\n location: location\r\n sku: {\r\n name: storageAccountType\r\n }\r\n kind: 'Storage'\r\n}You can see how much time and space you could be saving if you were to use Bicep.
\nWhen it comes to the benefits of using Bicep, there is a list published in our documentation:
\nEvery Bicep resource will have the below syntax:
\nresource <symbolic-name> '<resource-type>@<api-version>` = { \r\n //properties\r\n name: 'bicepstorage2063'\r\n location: 'northcentralus' \r\n properties: {\r\n //...sub properties\r\n }\r\n}Where:
\nresource: is a reserved keyword.symbolic name: is an identifier within the Bicep file which can be used to reference this resource elsewhere.resource-type: is the type of the resource you’re defining, e.g. Microsoft.Storage.api-version: each resource provider publishes its own API version which defines which version of the Azure Resource Manager REST API should be used to deploy this resource.properties: these are the resource specific properties. For example every resource has a name and location. In addition some have sub properties which you can pass on.When we talk about infrastructure as a code and reusability of our templates, we definitely end up using parameters to customise our resources. Be its name, sku, username or password, we will need to change these per environment or application.
\nIn a Bicep file you can define the parameters that need to be passed to it when deploying resources. You can put validation on the parameter value, provide default value, and limit it to allowed values. The format of a parameter will be such as below:
\nparam <parameter-name> <parameter-type> = <parameter-value>Where:
\nparam: is a reserved keyword.parameter-name is the name of the parameter.parameter-type: is the type of the parameter such as string, object, etc.parameter-value: is the value of the parameter you’re passing in.Let’s review two examples to get a better understanding of the structure.
\n@minLength(3)\r\n@maxLength(24)\r\nparam storageName stringIn this example you’re limiting the storageName parameter’s value length to be between 3 and 24 characters. Or:
@allowed([\r\n 'Standard_LRS'\r\n 'Standard_GRS'\r\n 'Standard_RAGRS'\r\n 'Standard_ZRS'\r\n 'Premium_LRS'\r\n 'Premium_ZRS'\r\n 'Standard_GZRS'\r\n 'Standard_RAGZRS'\r\n])\r\nparam storageRedundancy string = 'Standard_LRS'In this example you’re specifying the allowed values for the storageRedundancy parameter and also provide the default value if nothing is provided during the deployment.
With ARM templates you had to use a separate file to pass the parameters during the deployments usually with a name ending in .parameters.json. In Bicep you need to use the same JSON file to pass the parameters in:
{\r\n \"$schema\": \"https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#\",\r\n \"contentVersion\": \"1.0.0.0\",\r\n \"parameters\": {\r\n \"storageName\": {\r\n \"value\": \"myuniquestoragename\"\r\n },\r\n \"storageRedundancy\": {\r\n \"value\": \"Standard_GZRS\"\r\n }\r\n }\r\n}Similar to parameters, variables play an important part in our templates, especially when it comes to naming conventions. These can store complex expressions to keep our templates clean and their maintenance simple. In Bicep variables are defined using the var keyword:
var <variable-name> = <value>Where variable-name is the name of your variable. For example in our previous Bicep file we could have used a variable for our storage name:
var storageAccName = 'sa${uniqueString(resourceGroup().id)}'\r\n\r\nresource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {\r\n name: storageAccountName\r\n //...\r\n}Since we need a unique name for our storage account the uniqueString function is used (Don’t worry about that for now). The point is that we can create variables and use them in our template with ease.
There are multiple variable types you can use:
\nExpressions are used in our templates for variety of reasons, from getting the current location of the resource group to subscription id or the current datetime.
\nThe good thing is that ANY valid ARM template function is also a valid Bicep function.
\nparam currentTime string = utcNow()\r\n\r\nvar location = resourceGroup().location\r\n\r\nvar makeCapital = toUpper('all lowercase')To use conditions in your deployments you would use the if function in ARM templates, however, that’s not supported in Bicep. Instead, you can leverage the ternary operator:
param globalRedundancy bool = true\r\n\r\nresource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {\r\n name: storageAccountName\r\n location: location\r\n kind: 'Storage'\r\n sku: {\r\n name: globalRedundancy ? 'Standard_GRS' : 'Standard_LRS' // if true --> GRS, else --> LRS\r\n }\r\n}ARM templates have an output section where you could send information out of your pipeline to be accessed within other deployments or subsequent tasks. In Bicep you have the same concept via the output keyword.
resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {\r\n //...\r\n}\r\n\r\noutput storageId string = stg.idThis will return the storage id out to be used later.
\nIn ARM templates if you wanted to deploy a resource multiple times you could leverage the copy operator to add a resource n times based on the loop count. In Bicep you have the for operator at your disposal:
resource foo 'my.provider/type@2021-03-01' = [for <ITERATOR_NAME> in <ARRAY> = {...}]Where ITERATOR_NAME is a new symbol that’s only available inside your resource declaration.
param containerNames array = [\r\n 'images'\r\n 'videos'\r\n 'pdf'\r\n]\r\n\r\nresource blob 'Microsoft.Storage/storageAccounts/blobServices/containers@2019-06-01' = [for name in containerNames: {\r\n name: '${stg.name}/default/${name}'\r\n //...\r\n}]This snippet creates three containers within the storage account in a loop.
\nIf you want to deploy a resource which is depending on an existing resource you can leverage the existing keyword.
resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' existing = {\r\n name: storageAccountName\r\n}You won’t need the other properties since the resource already exists. You need enough information to be able to identify the resource. Now that you have this reference, you can use it in other parts of your deployment.
\nIn ARM templates you had the concept of linked templates when it came to reuse a template in other deployments. In Bicep you have modules. You can define a resource in a module and reuse that module in other Bicep files.
.\r\n├── main.bicep\r\n└── stg.bicepIn our stg file you will define the resource, its parameters, variables, outputs, etc:
//stg.bicep\r\nparam storageAccountName\r\nvar storageSku = 'Standard_LRS'\r\n\r\nresource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {\r\n name: storageAccountName\r\n location: resourceGroup().location\r\n kind: 'Storage'\r\n sku: {\r\n name: storageSku\r\n }\r\n}And in the main file you will reuse the storage account as a module using the module keyword:
//main.bicep\r\nmodule stg './storage.bicep' = {\r\n name: 'storageDeploy'\r\n params: {\r\n storageAccountName: '<YOURUNIQUESTORAGENAME>'\r\n }\r\n}\r\n\r\noutput storageName array = stg.outputs.containerPropsYou only need to pass the required properties which in case of our storage account is the name.
\nany keywordThere might be some cases where Bicep throws a false positive when it comes to errors or warnings. This might happen based on different situations such as the API not having the correct type definition. You can use the any keyword to get around these situations when defining resources which have incorrect types assigned. One of examples is the container instances CPU and Memory properties which expect an int, but in fact they are number since you can pass non-integer values such as 0.5.
resource wpAci 'microsoft.containerInstance/containerGroups@2019-12-01' = {\r\n name: 'wordpress-containerinstance'\r\n location: location\r\n properties: {\r\n containers: [\r\n {\r\n name: 'wordpress'\r\n properties: {\r\n ...\r\n resources: {\r\n requests: {\r\n cpu: any('0.5')\r\n memoryInGB: any('0.7')\r\n }\r\n }\r\n }\r\n }\r\n ]\r\n }\r\n}By using any and passing the value you can get around the possible errors which might be raised during the build or the validation stage.
In terms of tooling the support is the same if not better than the ARM templates.
\nVS Code comes with an official extension for Bicep. This extension gives you validation, intellisense, dot property access, snippets etc.
\nIf you’re using GitHub Actions for your CI/CD pipeline, there is already a Bicep action created by our developer advocate Justin Yoo which you can use to build you bicep file and deploy it to Azure.
\nBicep comes with a CLI that you can install locally on Windows, MacOS, and Linux. That gives you the ability to build and deploy your Bicep files with Azure CLI.
\nIn short, I highly recommend using Bicep and improving your IaC and deployments. Of course if your ARM templates are too many, or very complex you might benefit from converting them more, but if you already have a streamlined pipeline with maintainable templates, you could keep them and create any new template using Bicep instead.
","timeToRead":8,"frontmatter":{"title":"From ARM to Bicep 💪🏽","unformattedDate":"2021-05-10T00:00:00.000Z","date":"May 10, 2021","path":"/from-arm-to-bicep/","author":"Yaser Adel Mehraban","tags":["showdev","azure","arm","bicep"],"thumbnail":null}}}]}},"pageContext":{"tag":"bicep"}},"staticQueryHashes":[],"slicesMap":{}}