Hashicorp has done a terrific job making Terraform with the ability to template any API, and deploy and manage stacks in Azure, AWS and many, many more.
I’ve been following Pulumi for a while, and their approach is a bit different than the previous stated tools.
Originally posted on SogetiLabs: https://labs.sogeti.com/software-maintainability-in-the-cloud-era/
The shift to cloud, and with that, to PaaS services or low code alternatives like LogicApps push the actual code developers see and use to the background.
There is an ISO standard on software quality, and the maintenance best practices are well written and explained in the book Building Maintainable Software. Within low code systems, applying these guidelines can be less obvious and it can be a difficult task automating and testing the quality of your code with tools like SonarQube.
Should we even worry about the underlying code? Absolutely. The principles still adhere and creating a spaghetti of your low code systems can cause major issues on maintenance or adding new features.
Let’s focus on three points of the maintainability guidelines:
- Write code once
- Couple architecture components loosely
- Automate development pipeline and tests
In no way these are the most important items, but for this example an easy entry into the low code space.
1. Write code once
Just like any other audit of software, you still can avoid writing duplicate code. In a platform like LogicApps it can be easy to repeat a custom call to something like a custom HTTP API.
In traditional languages like C#, you have many options to reuse your code. You could create a library, or you can create a package and make it available via NuGet. Within low code systems, these same packaging mechanisms not always exist.
Taking the example of LogicApps, the solution could be to create Custom Connectors. These will wrap your custom API calls into a reusable component you can share within your organisation, or even outside.
2. Couple architecture components loosely
If your components are tightly coupled, it can be troublesome to replace or refactor your components. The impact will be on each and every other component that has a high coupling with your part.
Again taking the LogicApps for example, let’s state our LogicApp calls another component directly using HTTP. The Azure Portal gives you this out of the box, letting you call Azure Functions directly from your LogicApp.
This goes agains the principle of loosely coupling. The reason is that your call is directly bound to that function, so changing the interface or location of your function, impacts the LogicApp directly. In this case, it would simply break and stop working.
To solve this problem, a simple solution is to decouple the LogicApp and the Azure Function using a queueing mechanism. This way, the message to the Azure Function is put on a queue by the LogicApp, and the Azure Function listens on a queue. Now, if the developer of the Azure Function changes location or even use another platform, there is no need to change the LogicApp.
Obviously this would require you to make an agreement on the contents of the messages on the queue.
3. Automate development pipeline and test
Automating your CICD pipelines allows you to more easily build, test and deploy your code. In case of a language like C# or Java, you can easily run tests, build your code, and create packages or deployments. A tool like Azure DevOps can combine these steps and lets you create a wealth of quality gates, checks and processes to guide your team.
When using low code platforms, it can be cumbersome to get the code into your version control systems. Nevertheless, many of those platforms do give you the tooling. LogiApps for example has template creators, and systems like OutSystems have their own CICD ecosystem.
In the end the automation allows you to more easily add steps to your CICD process, and allow you to deploy more frequently without any hassle. The addition of automated testing will absolutely be beneficial to the overall quality of your product.
Treat your low code just like you would any other codebase. Almost all guidelines of mainainability can be mapped to your product. Some can may require a bit more investment, but in the end I truly believe it will help building a maintainable and high-quality (low) code base.
If you want to expand on the process part of high-quality software, please also take a look at the follow-up book of this series: Building Software Teams
As far as I’m concerned, a team can use any tool they want to track their work items and planning. But, my personal favourite is Azure DevOps. Currently I’m helping some teams moving their Jira projects to DevOps and this blog explains how you can do this, too!
While working on a side project, someone asked me how to scan for viruses in a cloud native and serverless landscape. That made me think about a project I did a couple of years back. During that project we used ClamAV that was installed on a VM. We scanned files that end-users uploaded within an ASP.NET application, and everything was hosted on datacenter VMs somewhere in the Netherlands.
ClamAV® is an open source antivirus engine for detecting trojans, viruses, malware & other malicious threats.
In this blogpost I will show a proof of concept using a Docker image and Azure Functions to create a simple automated virusscanner for Azure Blob storage.
In my current project I’ve stumbled upon a problem. We have many ARM templates and need to add tags to all resources. Doing this within templates can be cumbersome, so I’ve created a small VSTS extension that adds tags to all resources within a specific resource group.
The extension can be installed from https://marketplace.visualstudio.com/items?itemName=PeterRombouts.autotagging-extension
The working is pretty simple; enter the values for your subscription, and resourcegroup, and then add the tags.
The tag pairs should be entered, one pair per line, comma separated. The extension will add these tags to all resources in the given resource group, and will not do anything to the existing tags.
Remarks? Please do give feedback! The project is available on Github if you want to contribute!
In my work as Cloud Solution Architect I often find teams struggling with the exact same problem. In this blogpost I will highlight one of those problems; passing on ARM output variables within a VSTS pipeline.
Many developers have Powershell or other scripts in place, that fix this problem, but I want to highlight an extension, which is freely available and does this for you, for free!
This extension enables you to use the ARM Deployment outputs in your VSTS environment.
This step will use the last successful deployment within the selected resource group. If this deployment has outputs, all of them are copied to VSTS variables by the ARM Output key.
These outputs can then be used by default VSTS ways:
Usually this task is ran directly after the ‘Azure Resource Group Deployment’ task.
So my pro-tip; Stop using your own scripts and implement this handy extension!
PS: On a sidenote, Kees is also a great guy, give him a tweet after you install this in your project 😉
Link to Marketplace: https://marketplace.visualstudio.com/items?itemName=keesschollaart.arm-outputs
Kees on Twitter: https://twitter.com/keesschollaart
When trying to put your LogicApp code in a CICD pipeline, it is always problematic getting your code into a proper template.
Obviously switching to ‘LogicApp Code View’ is an option, but there is a better solution to this problem.
LogicAppTemplate is a PowerShell commandlet that makes is very easy to get the content (even automatically) of the app and save it to disk.
The usage is very simple, open up a PowerShell window and execute the next command:
Check out this gist
Big thanks to Jeff Hollan who authored this!
Recently my team and I were building and debugging LogicApps. At one point we seemed to have disappearing code within our code of these apps.
Obviously something is wrong when we were editing these apps.
Please note that we’ve got many LogicApps with custom code and mappings that we code using the code view, because not all properties can be set using the designer.
The problem arises when you are in ‘Logic App Code View’, and switch to ‘Logic App Designer’.
When switching back, the following popup arises:
In this case, we did not change anything, just switched to designer and back.
But, this is actually what triggers this problem.
Thanks to ‘Versions’ you can quickly see and use WinMerge (or any other tool) to compare the files:
In this sample, the ‘queueType’ magically disappeared, but in other cases other mappings of JSON object were deleted.
Always check, when the designer asks you to ‘Save changes’, if you actually made any changes.
I hope this helps someone out, it gave me and my team a real headache finding this out.