In this blog I’m going to explain how to monitor your IoT or other devices without having to open up ports, install agents or require access to your network. We will rely on Node-RED, Azure LogicApps and Azure Monitor Alerts.

Opening up ports you say?

If you like to tinker, like me, and have a Raspberri Pi somewhere in your network, you probably want to now if it is running properly, and what the temperature is. You could open up a port on your modem/router and check from the outside (with something like uptimerobot) if the device is up and running.

There are some problems with this approach. First of all, you will need a fixed IP, or some crappy DNS service that will fail once in a while (rendering your monitoring useless). The second problem is, a simple ping is not really helpful so you want to setup a probe of some sort, or allow SSH access.

Opening up ports also open up the possibility of people other than you logging onto your network with all kinds of mayhem as a result.

Example: Temperature monitoring on a Raspberry Pi

So how can we solve the problem? Let’s take a simple example. My Raspberry Pi is located near my fuse box. Yes, I’ve fitted it with heatsinks but still temperature is important to monitor, as a higher temperature will decrease the lifespan. How to monitor this without opening up ports?

In come Node-RED and Azure LogicApps!

Prepare your Pi

For sake of shortening this article, I’m not diving into the full setup. But if you run a factory default Raspberry Pi, Node-RED is by default installed. Otherwise find the installation instructions over here.

Setup a LogicApp

We will start with a really simple LogicApp, that receives a POST request from Node-RED, and parse the information. It will then determine if it needs to notify you, or not. We also will save the temperature into a table storage (bonus) to see the history over time.

Explanation or the LogicApp:

1. The first step is a HTTP trigger. We want to receive a POST from the Node-RED flow running on our Raspberri Py
2. As we are going to receive a temperature, we need to initialize a float variable to hold that value. While initializing we also decode the incoming message. Node-RED will send a base64 encoded string, so a simple function in LogicApps helps us to create a float: ‘@float(base64ToString(triggerBody()?[‘$content’]))‘
3. After this, we want to save the result in a storage table. Just so we can see the history of the values, and perhaps plot some graph in the future, food for another blog.
4. Finally we want to check if the temperature is reaching a treshold. In this example the treshold is 70 degrees Celsius. So if the temperature goes above that value, I’ve setup an email to myself in the ‘True’ block of the LogicApp.

To download the LogicApp code, see the gist over here.

Create your Node-RED flow

Now that we’ve setup the receiving end of our solution, we need to setup the Raspberry Pi flow. The following Node-RED flow will get the temperature, and call the Azure LogicApp every 15 minutes!

Explanation of the above flow:

1. The timestamp node runs every 15 minutes, simply for trigger usage
2. The second node gets the actual temperature from the Raspberry Pi OS
3. As this temperature has text in it, we need to extract the value only without any text
4. We call the LogicApp and it will post the value

This example is really simple, and you can download the code of the gist here.

And we are done! You now have a fully working example of checking your temperature, and getting notified when the temperature goes beyond your set treshold.

Heartbeat

No, not Don Johnsons song; You know how a doctor checks if you are alive right? Listening to your heartbeat is one of those ways.

The problem with the temperature monitoring is that when my Pi dies or hangs, I’m unaware of any issues. A heartbeat check will fix this problem.

If you setup the temperature monitoring, we basically already have a periodical call from the Pi towards Azure. And boom, that is basically a heartbeat!

In come Azure Monitor Alerts!

Alerts in Azure can trigger on fails, but also on successes. Simply put, if we do not receive a call, the device is offline. In my example scenario I’m calling the LogicApp every 15 minutes. So, if I have less than 3 calls in an hour, something is wrong!

Setting up Azure Alerts

Creating alerts is pretty simple. Just go to the alerting section of your LogicApp, in the portal:

Just click on ‘Alerts’ and create the rule!

To simplify things, I copy/pasted/cropped the alert screen below:

As you can see above, we trigger based on number of Runs Completed. Like previously mentioned, we run the trigger every 15 minutes. So, in the above case I trigger the alert when I have less than 2 completed LogicApp runs in one hour. You can also go up to 3 completed runs, but I don’t care if my Pi is down for a short while.

And there you have it; a working example of a heartbeat!

Concluding

In this blog I’ve explained how you can setup monitoring for your device (in this case a Raspberry Pi temperature) and how you can use those calls as a simple heartbeat.

Basically I now have a warning system for my temperature and as a bonus, when my device goes down, I get a warning and everything without needing remote access!

So you have a Oculus Quest 2 lying around and want to develop with Unity? You’re at the right address. This blogpost will help you setup your environment.

Setup your machine

I’ve chosen to setup a virtual machine in the Microsoft Azure cloud. Why? Basically because my laptop has too much crap installed and I want to develop on a clean, nice, Windows 11 machine.

For this I use Azure DevTest labs, so I can setup a new machine really quick, and make use of auto start and shutdown features to save money!

I’m not diving into DevTest labs, but the specs of my machine are as follows:

Yes that is a 8 core machine. At this moment I advise you to convince your boss to give you a MSDN Enterprise subscription.

Sincerely, your creditcard

You also could run with a 4 core machine, but the 8 core is a lot snappier, obviously more cores is always better.

Install Tooling

When you started your VM, you will see the default screen of Windows 11. Due to the preinstalled tooling, Visual Studio 2019 Community and Unity Hub are already installed:

First things first. We need to install the ‘Media Feature Pack’ in Windows 11. If you do not install this, your build will fail in Unity later on, so go to Settings, select ‘Add an optional feature’ and search for Media Feature Pack:

This step will require you to reboot your machine. Thanks to the 8 core VM this will be really quick.

After the reboot, open the Unity Hub:

As you can see above, it will ask you to update. Please note that by default the ‘beta’ channel is selected. Clicking on the cogwheel in the top right will allow you to revert to the ‘normal’ feed. You can then update to the latest Hub (3.1.2) at time of this writing.

And… Yes! You’ve just installed Unity Hub!

Make sure you create a Unity account so you can create and select a license later on.

After opening Unity Hub, you can install the actual editor. You can run multiple side by side, but in this case I just grabbed the latest one, and clicked Install:

When the install is finished, we need to add some modules:

As the Oculus Quest 2 runs on Android, select the Android Build Support like below:

Congratulations! You’ve prepared your machine for creating Unity projects! The next part will explain creating your first Unity project.

My First Unity Project

To create your first project; fire up Unity Hub, and select ‘New Project’:

As you can see above, I’ve selected a empty 3D (URP) project, named it ‘My First Project’. Click on ‘Create project’ to get started.

After some time, your editor will be loaded. But by default it won’t target Android. For this go to ‘File’ -> ‘Build Settings…’:

Select ‘Android’ and click on ‘Switch Platform’ to make sure you target Android. After that, select ‘Player Settings…’:

As you can see above, I’ve set the company name, and the product name to something of my choosing. Also make sure you check the ‘Auto Graphics API’ checkbox or you will get reminded when you want to build.

Also important is to set your Package Name correctly. Scrolling down in the Player Settings, will allow you to set that name. If you choose an invalid name the program wil nag about it, so keep it simple:

Adding Packages and setting the Scene

To be able to run this project actually on the VR glasses, you will need to install some packages. This might seem tedious, but it is needed every time you create a new project.

Go to the Package Manager via the Windows menu:

And install the packages highlighted below:

Finally make sure your scene is a ‘XRRig’ one, like shown below:

Just play around with the ‘Plus’ button to see how everything works.

If you build it, they will come

Obviously (for me) you will need to build the actual application. As we are building an Android App, it will create an APK file:

The screenshot above shows what happens after clicking the Build button. You will get a popup and should be able to select a name and location for your file.

And you are done! You’ve successfully built your first APK file for the Oculus Quest 2.

Deploying to your Oculus Quest 2

There are several ways of deploying Android applications to a device. Doing it outside of a appstore is called sideloading, and can be done using a tool.

First of all you will need the USB drivers, and a USB cable. Follow this guide to install the drivers otherwise it won’t work.

Next, make sure your Oculus Quest 2 has ‘Developer mode’ enabled. This easy guide will help you do just that. It is basically setting a switch to ‘on’.

In my quest (pun intented) of finding the absolute most easy way of doing this, I stumbled upon SideQuest. Go to ‘Get SideQuest’ install it, and you’re good to go.

So, if your drivers are installed, and your glasses are linked to your PC, you can click on the icon shown below, and select your APK file:

That is it. You’ve just finished all the steps and installed your application on your Oculus Quest 2.

Bonus: Stream your Oculus Quest 2

The disadvantage of having only one pair of glasses is that other people in the room cannot see what your are seeing. To solve this you can stream your viewport to a laptop.

For this you need a USB cable, and a software too . The cool thing is that the same SideQuest app for deploying your package to the Oculus Quest 2 can be used to stream your viewport to your laptop!

The same tool for sideloading can be used:

Click on the TV icon, click on ‘Quest 2 Crop’ and ‘Start Stream’. In the following video I will show the application we just sideloaded to finalize the demo:

Costs and Licensing

Check your license! Personal use is free but for companies and enterprises you definitely need a license for both Unity and Visual Studio!

If your revenue or funds raised in connection with your use of Unity are more than $100K in the last 12 months, choose one of our subscription plans.

Unity licensing

An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.

In non-enterprise organizations, up to five users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.

Visual Studio Community licensing for organisations

Concluding

So, it is easy to develop for VR? No it is not.

Yes it is relatively easy to get started, but remember that this is only the beginning. Like with programming, a Hello World example is easy, but creating an application that holds value can be really complicated and needs a team of people working on it.

Feel free to leave your comment on this site or contact me through on of my social channels on: https://peterrombouts.nl/about-me/

With the rise of cloud, cloud-native and a lot of other buzzwords, we also see the rise of all kinds of Dev(fill here)Ops practices. While I’m an avid advocate of the DevOps mindset, all the buzz around pipelines sounds old-school to me.

What is GitOps?

GitOps evolved from DevOps. The specific state of deployment configuration is version-controlled (using Git for example). Changes to configuration can be managed using code review practices, and can be rolled back using version-controlling.

https://en.wikipedia.org/wiki/DevOps#GitOps

A quick look at Wikipedia brings you the above description. It is stuffed away somewhere in the DevOps article. Like with DevOps, there is a whole religion around what tool is the best to use, and people even claim to be ‘DevOps Engineers’ whatever that may be. In most cases they mean ‘cloud infrastructure’ because DevOps is a mindset, and not a function.

It doesn’t help that some tools like Azure DevOps are actually called this way, but hey, VSTS is also not really a snappy name IMHO.

To explain GitOps in my own words and in a single sentence: Instead of pushing your code and deploy, your system pulls the software from the version control system.

A nice one-liner by WeaveWorks is: GitOps is Continuous Delivery meets Cloud Native

https://www.weave.works/technologies/gitops/

GitOps versus DevOps Pipelines

So, it is the same as DevOps Pipelines right? No it is not. From a distance it can seem to be the same. In a way your code, if configured correctly, will be deployed automatically with CICD.

The fundamental difference is that your system (for example Kubernetes) and not your DevOps CICD pipeline, is in the lead. Remember, the settings of the k8s system itself also need a repository.

Let’s look at a typical CICD setup:

As you can see in the example above, the Azure DevOps pipelines are in the lead. The Build step pulls in the code, the Release step creates the artifact and pushes it towards a registry, and also installs it on AKS. But this does not include the state of your cluster.

Let’s say your DevOps pipeline trigger failed, or someone made changes manually to the AKS applications or configuration. AKS has no idea where the code is located so it cannot check if there are any changes. This is where GitOps can be a solution. Let’s look at the following example:

In the example above you can see that (in this case Flux) is used to pull the desired state towards your Kubernetes cluster. This pulling makes sure that you are always up-to-date. And it can also detect changes so if anything or anyone changes the configuration manually, this ‘drift’ will be resolved by the desired state pulling with Flux!

Yes, this complicates your setup, but you always know that your clusters are exactly how you described them in the desired state. Especially in situations with Kubernetes, deployment and configuration can be really complex, so these tools make sure you are in control of your systems.

Example of GitOps tools

So I need Kubernetes? No. In theory any system can use the GitOps setup, but for Kubernetes a lot of tools and so called operators are readily available.

In the previous paragraph, Flux is drawn in the picture. There are many more tools out there, but we see convergence on two major tools: Flux andArgo. The resources section at the end of the blog shows more tools and resources if you want to dive in the deep end of GitOps.

There is a nice writeup (sponsored by Red Hat) on deciding between Flux and Argo. Depending on your situation it can fall either way. GitOps on Kubernetes: Deciding Between Argo CD and Flux – The New Stack.

OpenGitOps

The emergence of GitOps led to the OpenGitOps project.

OpenGitOps is a set of open-source standards, best practices, and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps.

https://opengitops.dev/

The principles of GitOps are four-fold:

1. Declarative
   A system managed by GitOps must have its desired state expressed declaratively.
2. Versioned and Immutable
   Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
3. Pulled Automatically
   Software agents automatically pull the desired state declarations from the source.
4. Continuously Reconciled
   Software agents continuously observe actual system state and attempt to apply the desired state.

“The GitOps Working Group is a WG under the CNCF App Delivery SIG.

The focus of the GitOps WG is to clearly define a vendor-neutral, principle-led meaning of GitOps. This will establish a foundation for interoperability between tools, conformance, and certification. Lasting programs, documents, and code are planned to live within the OpenGitOps project.”

The main goal of the OpenGitOps CNCF Sandbox project is to define a vendor-neutral, principle-led meaning of GitOps. This will establish a foundation for interoperability between tools, conformance, and certification through lasting programs, documents, and code.

Concluding

GitOps has been around for several years, and continues to evolve. CNCF has OpenGitOps as Sandbox project and embraced Flux and Argo as Incubating projects. The shift in mindset can be difficult, as some people still try to embrace DevOps as a principle.

Watch this space for more information and an upcoming eBook on our take and practices surrounding GitOps!

Resources and further reading

In this blogpost I will show a basic primer of using KICS together with Azure DevOps, to scan Terraform Infrastructure-as-Code.

Kics an open source solution for static code analysis of Infrastructure as Code.

https://kics.io/

What is KICS, and why should I care?

KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in the following Infrastructure as Code solutions: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, and OpenAPI 3.0 specifications

The open source tool is brought to you by Checkmarx but is a true open source community project.

I’ve blogged before about the importance of testing your IaC, and this tool makes it pretty easy to incorporate exactly this into your pipelines.

At this moment in time I’m experimenting with the usage and because some of the examples do not really work out-of-the-box, I’ve decided to put them in this blog.

Running KICS locally

You can run KICS locally, and the documentation of KICS shows a very easy example running it with a Docker container. This is a easy way of testing and playing around with the tool:

docker pull checkmarx/kics:latest
docker run -v {​​​​path_to_host_folder_to_scan}​​​​:/path /
    checkmarx/kics:latest scan -p "/path" -o "/path/results.json"

Setting up KICS in Azure DevOps

A more likely scenario is that you want to run KICS as part of your CICD strategy, automated and triggered by, for example, a pull request. But how to start?

First of all, you should have a repository in DevOps. In my example, I’ve created two folders with some Terraform code, and one Yaml pipeline:

In these ‘terraform-example1’ and ‘terraform-example2’ I’ve added some representative examples for Azure. Resources ranging from storage accounts, Windows Virtual Desktop resources to IAM and Virtual Machines.

As I have two example folders setup, I’ve created two pipelines. The Yaml file is the same, but using variables I can let KICS scan different folders. Basically it looks like this:

Opening up KicsExample1 and viewing the variables shows the following:

Important to note here, is that I’ve added the complete path to the working directory. My directory is ‘terraform-example1’ but as you can find in the documentation, the path on the build agent will be /home/vsts/work/1/s/terraform-example1/. For the second pipeline example, I obviously set/home/vsts/work/1/s/terraform-example2/ as variable.

Running the KICS Azure DevOps pipeline

So, for the actual magic to happen, let us run the pipeline and look at the outcome:

As we can see; due to some trickery with VSO logs, I’m able to put the feedback from KICS into the actual summary! In this case, I’ve taken the example from KICS and wrote the output errors to Azure DevOps. You can look at the example code how I did this.

Analyzing and debuging the results

In the previous paragraph we ran the KICS pipeline, and it came back with some errors. Now, we want to see what the actual problem is. For this we can drill down to the run:

One of the issues found in my first example, is the following error:

Storage Account Not Using Latest TLS Encryption Version, Severity: MEDIUM, Results: 1 
Description: Ensure Storage Account is using the latest version of TLS encryption 
Platform: Terraform

This issue is quite self-explanatory. KICS runs many queries, and you are able to tweak and adjust them.

The second issue found is on the keyvault in my example:

Vault Auditing Disabled, Severity: HIGH, Results: 1 
Description: Ensure that logging for Azure KeyVault is 'Enabled' 
Platform: Terraform

This also is based on a best practice, and it warns you about the disabled auditing. The great thing about this tool is that is also gives descriptions on how to fix your errors!

Concluding

There are many ways on securing your infrastructure as code and testing statically. In my previous blog about Open Policy Agent I also wrote about this. The great thing about KICS is that it is really easy to setup, and for my example in Terraform they have many well-documented queries and how to resolve the issues found.

Implementing KICS as your first line of defence is really easy and gives direct feedback in your DevOps process.

Give me the code!

The example pipeline has been put in to this public gist. Do not forget to pass in the variable PWD with the location of your project!

Any questions or remarks? Feel free to reach out via any of my public profiles or the contact page on this site.

Is the end coming for cloud? Are we changing our view on centralized big-tech cloud computing in favour of decentralized, edge or bare metal?

Yes and No

Read this post to find out the five signs I think ‘the cloud’ is not the de facto target state for future workloads.

1. Slow Adoption

For many big enterprises, cloud adoption is a tricky beast. Governance and risk assessments, opening up to the ‘big bad internet’. Issues that maybe solvable in a technical way can be really tricky to solve in an organizational way. Think of processes that allow specific traffic in- or out of your network. Locking a platform like Microsoft Azure fully down, basically slows down the adoption of services and makes devops teams not fully utilize the cloud native capabilities of the platform, slowing adoption also, amongs the technical stack.

2. Vendor Lock-in

Well, we heard that before. But in fact there is a truth to locking in to a specific cloud vendor. For example when choosing a serverless technique, you are binding yourself to a specific vendor. I do not think it is bad per sé, but you should do the calculation of the costs of exit. Please do understand that any technique basically is a lock in on one level or the other. Choosing for Linux based containers for example, or for Kubernetes based on OpenShift is also potentially locking in to a vendor/technique. Think about what happened to CentOS just for a sec.

3. GDPR

The now (in)famous Schrems II case makes legal departments run overtime to figure out how to deal with this case.

Customers of US cloud service providers must now themselves verify the data protection laws of the recipient country, document its risk assessment and confer with its customers.

https://www.gdprsummary.com/schrems-ii/

Can we even use the public cloud for data of our customers? I’m following the outcomes of those discussions closely…

4. Edge Computing

The cloud (Google) basically brought us Kubernetes, but it also means you can run anywhere so also on the edge, on bare metal or in your companies private cloud. That means your ROI on existing hardware should be recalculated; you drive up density, run ‘new’ types of workloads and open up possibilities for your devops teams. I’m not saying running Kubernetes is easy but it does run virtually anywhere, the cloud is not the only place.

5. Risk, Governance and Compliancy

One of the most important blockers on using cloud seems to be this; how to manage risk, control governance and ensure you are compliant. Being and proving you are ‘In Control’. And yes, most cloud providers have well-defined policy frameworks and control toolsets, but in practice this is a pretty big subject that requires time to setup properly in an entire enterprise. Think about banks, investment companies and insurers; they cannot just ‘do what they want’ because the legal implications of doing it wrong are enormous. The slow down caused by this issue can be a burden for devops teams simply giving up and ‘eating their dogfood’ i.e. in the form of a private cloud or DC.

Is it all doom and gloom?

I’m a avid fan and proponent of cloud computing. I truly think Microsoft Azure, Amazon AWS and other cloud vendors can help you gain speed, be more agile and even save costs doing it well.

Every now and then a post like this surfaces, so I’m guessing in 5 years time, we will still have ‘the cloud’ thankfully. But it is always interesting to reflect on choices and watching for changes in the landscape of computing technologies. Also; try to think about cloud in other ways than only the technical possibilities. Think about the ramifications for compliancy and risk.

Any ideas or feedback? I’m open for a (virtual) cup of coffee anytime!

In my previous blog I stated my learning goal for 2020: Learning (or getting a better understanding) of the Go language. Currently I’m studying various courses, and have to give huge credits to Todd McLeod for his excellent work on courses on this subject.

Working with what you were given

In many cases I have to work what is given. If I am helping a client running Java with Docker, I cannot simply move them to another language or framework, just because that seems a better technical solution. I have to keep in mind that people and companies have invested in a language or framework, and sometimes it seems almost a religious feud (Windows vs Linux) instead of an objective view on the subject. So in a way, a language does not matter in my work as a consultant or architect. I have my preferences, but cannot force them onto a group just for sake of my own reasons.

Let’s Go! (pun intended)

Go is a very elegant and fast language. Testing is built right into the language, as is documentation. It pretty much runs on any OS, and does that really fast.

The authors (Robert Griesemer, Rob Pike, and Ken Thompson) wanted to address criticism of other languages in use at Google, but keep their useful characteristics (Wikipedia):

• static typing and run-time efficiency (like C++)
• readability and usability (like Python or JavaScript)
• high-performance networking and multiprocessing

In Go everything revolves around ease of programming and frankly, it is just plain fun coding in Go! I’m amazed with the speed of coding and simplicity of concurrency. Numerous IDE’s are available, making it easy to start with the language.

What language do you choose?

If you are in a greenfield environment, or want to create services that have the need for speed; think beyond your comfort zone. Experiment with languagues and frameworks. See what fits for your purpose.

In any case, take a look at Go with your team, and let me know what you think of it!

This blog was originally posted on SogetiLabs: https://labs.sogeti.com/2020-keep-on-learning/

As the new year starts, many of us have New Year’s resolutions, and many of those will eventually perish within a month or two.

New Year, New Technology

I don’t have any resolutions. The only thing I try to do each year is to learn a new technique or language. Please note that new means new to me and not necessarily a brand new technique.

Why? In my day-job I focus on designing cloud native systems and architecture, and most of my ‘programming’ is done in Visio and PowerPoint. As my roots are in Software Engineering, I keep myself up-to-date by learning new languages and techniques.

For the upcoming year I’ve already made my choice. I started out with the following short-list.

1. Scala
2. Rust
3. Go

Creating the short-list

The reason I chose these techniques is not random. In my work as an external examiner for the University of Applied Sciences Avans and Fontys in the Netherlands, I see the work of many students each year. They inspire me to look at specific techniques that normally do not cross my path. In my day-to-day work, the most used languages are C#, TypeScript, Java, and JavaScript languages and frameworks like Angular.

1. Scala

Scala is a general-purpose programming language providing support for functional programming and a strong static type system. Designed to be concise, many of Scala’s design decisions aimed to address criticisms of Java.

Wikipedia

Functional programming is something that I do not see often in my day-to-day job, so I was intrigued by the capabilities of this language. Also, some very fast and popular software is written in Scala. Examples are: Apache Kafka, Apache Spark and Akka.

2. Rust

Rust is a multi-paradigm system programming language focused on safety, especially safe concurrency. Rust is syntactically similar to C++, but is designed to provide better memory safety while maintaining high performance.

Wikipedia

Originally invented by Mozilla and used within Firefox and Dropbox. Rust has been the “most loved programming language” in the Stack Overflow Developer Survey every year since 2016, so that drew my attention.

3. Go

Go, also known as Golang, is a statically typed, compiled programming language designed at Google by Robert Griesemer, Rob Pike, and Ken Thompson. Go is syntactically similar to C, but with memory safety, garbage collection, structural typing, and CSP-style concurrency.

Wikipedia

Go has been around for quite some time, and has an impressive list of applications that were built with the language. Kubernetes, OpenShift, Docker and the list goes on.

Choosing my 2020 technique

For an internal project, we were looking for a tool to provides us programmability against a multitude of APIs. Instead of grabbing an off-the-shelve product, I investigated tools and frameworks that could help us build an MVP, fast and reliably. This eventually made me look into Terraform Custom Providers.

In Terraform, a Provider is the logical abstraction of an upstream API. This guide details how to build a custom provider for Terraform.

https://www.terraform.io/docs/extend/writing-custom-providers.html

Terraform will let you wrap any API, so it will enable us to wrap our ITSM tooling, Monitoring tooling and what have you not.

As Terraform and the custom providers are written in Go, that was my main reason to dive into this language. I’ve created a Github repo with an example custom provider, find it here on Github.

Keep on learning

I’m curious if any of you are also keen on ‘staying relevant’ and want to keep up with new techniques and languages. And, what techniques and languages do you try out and investigate? Please feel free to let me know, and contact me on LinkedIn or Twitter!