After a very busy and difficult couple of months, the system I’d been working on is about to go live to ~27,000 users, and I’m feeling slightly pleased with myself. What should have been a simple integration morphed into a complex Mulesoft project. What a learning curve that was!
The following is my experience with Mulesoft so far.
I think the one advantage Mulesoft has over other platforms - and maybe its selling point - is that the Anypoint portal provides us with a single place from which numerous integrations, API specifications and deployment environments can be managed.
Getting software to work with OAuth is usually one of the easiest things a developer could be tasked with, if s/hehas done it a few times: Create an HTTP client method that sends four values to an OAuth provider, then pass the response to the next HTTP client method as a variable to be used in the Authorization header.
Doing that in Anypoint Studio, for a Mulesoft application, was an uphill struggle of resolving one error message after another.
After resolving the previous issue with the Content-Type defect in the Azure Logic App’s storage connector, I ran into a second problem: The Web pages being generated were populated with the correct content type, but the incorrect content. I quickly discovered that was partly caused by a race condition and with how memory is managed by Azure.
By default, a Logic App will run up to twenty instances of a ‘For Each’ loop in parallel, but this is multi-threading instead of true parallel processing.
One of our Logic Apps, which we developed as a static site generator, began writing the Web pages to the storage account as octet stream files, and I narrowed down the problem to a defect in the storage account connector.
I believe (but I’m not 100% certain yet) Microsoft’s developers hadn’t implemented the ‘"headers": {"Content-Type": "text/html"}’ code for the storage account connectors, and the file type, therefore, always defaults to octet stream.
One of the central claims made by Moxie Marlinspike, during his discussion at the Black Hat conference appears nonsensical, because he referred to two entirely different meanings of ‘abstraction’, and was thus comparing two entirely different things:
‘We spent the past 20 years onboarding people into software by putting them into black box abstraction layers, and then putting them into organizations composed of black box abstraction layers, […] Marlinspike posited that security researchers, who routinely probe beneath surface-level abstractions, are better positioned to drive innovation in software development.
Something unexpected happened this week: I was offered my first senior engineer position. I’ll be focussed mainly on the project management and planning side of things, and I’m being encouraged to delegate the software development work. I’m still prepared to get my hands dirty with the coding and systems administration, if anyone gets stuck on a tricky problem, and I’ll likely be working on a couple of .NET applications as personal projects.
One of my Logic Apps originally had just three steps:
HTTP trigger Deserialise HTTP request JSON payload Send objects from the request payload to a Service Bus queue Another Logic App would read the objects from the Service Bus queue, use them to query another source for data, then send a email to whatever address was in the initial request. I used this approach because there could be more requests than a Logic App can handle concurrently, and it made sense, therefore, to queue the requests.
One way to help understand how Active Directory, App Registrations, managed identities and Key Vaults work in Microsoft Azure is to look at a typical Logic App that authenticates itself with an API that provides data only to services registered with the organisation’s Active Directory.
The basic sequence for the authentication part of the Logic App here is this:
Get a password from an Azure Key Vault. Get an OAuth token for the Logic App from Active Directory.
Azure Key Vault is designed to store (and protect) secrets such as API keys, passwords, cryptographic keys, connection strings, etc. It can store the following categories of data:
Keys Certificates Secrets The Secrets storage can store arbitrary plaintext values, so Key Vault could potentially be used as a means of centrally managing a collection of usernames and passwords that could be copied and pasted straight from the Azure Portal. Is this a safe method of password management, though?
My brief encounter with Power BI began after one of the project managers had the idea of using Power BI Report Builder as a means for generating archived versions of what’s displayed on a site I developed not long ago, because he wanted a PDF export feature for that. ‘Why not just copy a couple of the API methods and add a PDF converter to them?’, I wondered, with the feeling I’d end up needing to do that anyway.
