Apache NiFi (see Introduction to NiFi) is a free open-source tool for managing the flow of data between systems.
In this second post, we build a working NiFi demo, with a couple of simplified use cases, allowing us to see it in action and learn by experimenting. The demo runs in a Docker container and comes with batch and real time event DataFlows and basic test data.
Apache NiFi facilitates the movement of data between systems. This free open-source software can ingest, manipulate and send/store data for batch and real-time use cases.
When I had a need to visualise telemetry data from a home project, the ELK stack was my go-to solution. The ELK stack (Elasticsearch, Logstash, Kibana) is an open-source-ish[i] tool for ingesting, searching, and visualising data.
I like PlantUML and the whole diagrams-as-code ethos, where diagrams auto-generate from source code in the same repo.
Sure, the way PlantUML lays out objects and lines in free-form diagrams is arcane – try drawing anything beyond a few components, and you’ll end up in a pitched battle with the layout engine, resulting in a mediocre diagram in a state where you’re afraid to make changes, lest the lines and placement go all wonky (again).
Thankfully, things are better when using PlantUML to produce opinionated diagram types, where the layout rules are predetermined, such as sequence diagrams, mind maps etc.
I got to thinking – could I use PlantUML in the workplace, outside traditional architecture/code documentation, to help visualise other things? Only one thing for it – give it a go…
In the world of IT architecture, coupling is a much talked about concept. But what is coupling, why is it important and what techniques/patterns can we use to optimise it?
That’s a lot to unpack, so let’s start with an example outside IT. Consider this trendy all-in-one desk lamp:
It looks lovely, but what happens if the bulb fails, or you want to change the light colour? It is tightly coupled because the bulb component cannot be replaced separately, so the whole lamp must be replaced in these circumstances. Continue reading →
When you work in IT, security audits are par for the course. Like dental check-ups, they’re generally a good idea, but can still be painful (and expensive). They help uncover issues that need fixing, and raise senior exec visibility.
There is however a dark underbelly to security audits – they can drive counterproductive behaviours leading to unintended and undesirable outcomes.
Wouldn’t it be ironic if remediating a security audit item made your organisation less secure…? Continue reading →
Is a picture really worth a thousand words? What if that picture was a diagram?
A colleague recently introduced me to Diagrams as Code, using PlantUML, and in this post we explore the concept of diagrams-as-code, and how to use PlantUML.
Diagram Methods
Let’s start with some background. Diagrams should engage their audience, informing them and encouraging collaboration. Understanding the knowledge and needs of your audience is critical to creating a successful diagram.
We adjust the diagram to suit the audience, using different views of people / process / technology to inform and engage them. Often, we will draw multiple views of the same system to suit the needs of different audiences, as per Figure 1.
I recently attended the fantastic Kiwicon 2038 InfoSec conference (shout out to the crew and speakers – you guys rock!) in Wellington, New Zealand. An eclectic cast of speakers, including Bruce Schneier, Kelly Ann from Slack and many others, delivered thought-provoking talks accompanied by ‘flame effects’[1].
We’re all doomed…
Bruce Schneier, a celebrity in the world of InfoSec, painted a grim picture of the future of security, to the point that part way through the talk he had me convinced that we’re all doomed…
Only at Kiwicon: Bruce Schneier prophesising doom (and plugging his new book[2]), while a sheep wearing neon sunglasses looks on …