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.
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’.
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), while a sheep wearing neon sunglasses looks on …
Recently, I had a need to understand IP fragmentation better, so I built a lab to experiment with. I wanted it to be easy to setup, and built in a way that is repeatable by others, so I designed automation to stand it up with virtual machines in a hypervisor. The lab network topology is shown in Figure 1.
Figure 1 – Network Diagram for IP Fragmentation Lab
Network traffic flows (flows) are useful for building a coarse-grained understanding of traffic on a computer network. Flows provide a convenient unit for the measurement and/or treatment of traffic.
Following on from What is a Network Traffic Flow?, this second post delves into Internet layer flow considerations. Previously, we found that the definition of a flow is mainly arbitrary, primarily driven by the capabilities of hardware/software, and the use cases. We now delve further into the considerations around specific features and behaviours of IP.
Network traffic flows (flows) are useful for building a coarse-grained understanding of traffic on a computer network, providing a convenient unit for the measurement and/or treatment of traffic.
Flows can be measured to understand what hosts are talking on the network, with details of addresses, volumes and types of traffic. This view of the network can be useful for troubleshooting, detecting security incidents, planning and billing
But what exactly is a flow, and how is it defined?
This question sounds trivial to answer, however when we dig deeper we find nuances and corner cases that make flows interesting, and ultimately difficult to define. Continue reading →