A Lone Maintainer

If you CBA watching the video (seriously though, you really should, just put it on 1.5x!), here’s the short version. A lone developer called Lasse Collin maintained a compression library called “XZ Utils”, quietly and unpaid, for roughly twenty years. You’ve almost certainly never heard of it, which is basically the point. It sits underneath an enormous amount of critical infrastructure, including (most importantly) SSH, that millions of servers rely on every single day. Nobody thinks about it, nobody talks about it, and for most of its life exactly one person was keeping the lights on…

Lasse, who was already burned out and struggling with his mental health, was being hounded by “accounts” to make more progress on the project, some messages encouraging him to accept help and hand over responsibility to other devs. Then someone calling themselves “Jia Tan” showed up, which we now know was almost certainly a nation state operation, and spent two and a half years patiently social engineering their way into becoming a trusted maintainer of the project. They were helpful, responsive, wrote good code, etc. All seemed peachy! Enter Rich Jones, who works at RedHat, packaging Fedora. He began to trust Jia because… well, because Jia behaved exactly like the kind of person open source desperately needs. That’s what makes social engineering so effective; the good behaviour is the attack.

A Backdoor to the Internet

The backdoor they slipped in was technically brilliant and horrifying in equal measure, a hidden compromise buried in the compression library that would have given someone a backdoor to a significant chunk of the world’s servers if it had made it into stable releases across major Linux distros. The whole thing eventually unravelled because a single Microsoft developer called Andres Freund noticed that his SSH logins were taking half a second longer than they should and decided to dig into why. Five hundred milliseconds stood between us and a catastrophic supply chain compromise, and one curious engineer is the reason we caught it.

Open Source Matters

I’m pro open source, always have been. I’ve been using Linux since the 90s, which probably gives you an idea of what colour my beard is. The concept of “Software should be free and we’ll prove it works” is unarguably one of the greatest ever human endeavours. When geopolitical tensions seem to ratchet up weekly, where we’re supposedly retreating into blocs and borders, the fact that open source still works is genuinely remarkable and something to make you proud of bring an ape descendant! It’s proof that like-minded humans can can continue to collaborate on a global scale.

But here’s where we have a challenge… Linus’s Law says that given enough eyeballs, all bugs are shallow. That’s true for projects that actually have enough eyeballs, but popularity does not equal scrutiny. XZ Utils had millions (perhaps billions) of installs, but for most of its life basically one person was reading the code, and then there were two, and the second one was the attacker. (Yes, I know, hyperbole, but you get the point!). Downloads are not eyeballs, installs are not audits, and I think we’ve been confusing usage with oversight for a long time. The XZ story is a great example of where it went both brilliantly right and very wrong.

The real vulnerability here wasn’t technical; it was a system that let a single unpaid maintainer carry critical infrastructure on his back for two decades without meaningful support. We collectively built our digital world on top of someone’s volunteer labour and then acted surprised when that became an attack surface!

Will AI Make This Better or Worse?

Which brings me to the point of this article.

Can AI help with this?

[… and yes, it’s AI again! You now have permission to roll your eyes about having read YAAIA, aka yet another AI article]

In theory, AI-powered code review could potentially spot the kind of obfuscated changes that slipped through here. Automated analysis tooling that never gets tired, never gets burned out, never feels social pressure to approve a commit because the submitter has been so helpful lately. That sounds very promising, but there’s another side to it. As more code gets written by AI and reviewed by AI, do we end up with even fewer human eyeballs on critical paths? Do we create a new kind of “enough eyeballs” fallacy where the eyeballs are all artificial and share the same blind spots?

I genuinely don’t know the answer, and I suspect the truth is that AI will simultaneously make some attacks harder and others easier [really helpful insight, I know!].

Interesting Times

What I do know is that the XZ story deserves to be told widely, especially within our industry. Absolutely not as a cautionary tale about open source, because closed source has its own risks and horror stories that just happen behind closed doors.

To me, it’s a reminder that the humans behind the code matter as much as the code itself. Fund the hard working maintainers, buy them a ko-fi, support the people doing unglamorous work, and maybe, occasionally, investigate when something takes half a second longer than it should.

As my favourite author of all time, Sir Terry Pratchett reminded us, “may you live in interesting times”. As the world tries to keep up with supply chain security, I can confirm interesting times are in the current sprint…

PS – Amusingly as I was writing this, another article on a similar topic hit the headlines, about FOSS repos. Worth a few minutes of your time too I reckon.

The post Half a Second Saved the Internet appeared first on Tekhead.it.

“We need an AI strategy.”

It sounds urgent, and of course it is urgent in a way, but I’ve come to realise it almost always means two completely different things depending on who’s saying it and why. Getting your head around that gap is probably the most useful thing you can do when it lands on your desk.

When a board or CEO says “we need an AI strategy,” they’re almost never asking for a technical roadmap. What they’re really after is reassurance; that the organisation isn’t falling behind, that investors won’t ask an awkward question at the next AGM and get a blank stare in return, that somebody somewhere in the building has thought about this. They want something credible and coherent, ideally fitting on a slide that nobody has to squint at.

When an IT leader hears it, though, they hear something quite different. They hear “investment in data infrastructure.”, and they’re absolutely right to, because without a solid data foundation, you’re building your AI solution on quicksand.

I’ve made a silly analogy of this a few times over the years, something along the lines of how you can’t build anything massive on sand, apart from maybe the pyramids. Then I was in Egypt with my family last year and discovered something I never knew before… even the pyramid builders knew you can’t just stack stones on sand! The pyramids actually have foundations of bedrock and mahoosive limestones buried up to 6-8 metres deep! I’d been proving my own point for ages and I hadn’t even realised…

Two documents are better than one…

If you’re the IT leader with this request, my suggestion is that you probably need two documents rather than one, because the audience for each is completely different and trying to serve both at once almost never works.

The first is a exec board narrative. Short, strategic, and confident, focused on [most importantly] business outcomes, then perhaps competitive positioning, and risk. This is the information the CEO walks into an investor meeting with, and it needs to tell a story about where the organisation is heading without getting into how the plumbing works. Nobody on the board wants to hear about the optimised data lake architecture, and frankly they shouldn’t have to.

The second is the working strategy. This is the real one, with the investments, the data programme, the build-vs-buy decisions, the governance model, and probably a spreadsheet or twelve attached. It’s the document your teams will actually deliver against, and it has to be brutally honest about what state your data is in right now and what needs to happen before any of the exciting AI stuff becomes real.

Mashing these two together won’t work. Either it ends up so vague, it can’t actually drive decisions, or the working strategy gets presented to the board and you watch the room quietly die somewhere around slide seventy-eight [we’ve all been there!]. The CEO needs to calm investors, the IT team needs to know what they’re actually building, and one strategy document genuinely can’t do both.

Start With the Bedrock

Before writing any document, the most valuable thing you can do is take an honest look at your data. Not a new procurement exercise, not an AI pilot, just a straightforward answer to whether you could actually build something real on top of what you’ve got today.

In most organisations, the answer is “it’s complicated,” and that’s absolutely fine as a starting point, indeed nobody expects perfection [or indeed the Spanish inquisition!]. The outcome you really want to avoid is cracking on with the strategy without asking the question, then discovering six months later that the foundations aren’t there and having to retrofit them while everything else is already going up around you.

The ancient Egyptians figured that bit out about four and a half thousand years ago. There’s probably a lesson in there somewhere…

The post We Need an AI Strategy appeared first on Tekhead.it.

I’ve been running OpenClaw as a personal AI agent for several weeks now (in very strict isolation). It handles a standalone calendar, sends me reminders, processes emails I forward to it, manages my task lists, writes code and makes commits to specific projects I’ve shared from mine, to its GitHub account. Think Jarvis, but with more cron jobs and less Robert Downey Jr. Along the way I’ve learned a few things the hard way. I already posted about some of those last week, and here are five more.

1. Your AI Will Forget Unless You Make It Remember

This one caught me off guard. Every time your agent starts a new session, it wakes up with absolutely no memory of what you did yesterday. None. It’s like your intelligent, funny, witty teenage child, who wakes up every morning with no memory of you reminding them to clean their room tomorrow…

The fix is decidedly low tech, namely markdown files! The agent reads a MEMORY.md file at the start of every session for long term context, plus daily “summarising” note files for recent history. Without these, every conversation starts from zero. You find yourself re-explaining the same decisions, the same preferences, the same project context. It can be quite frustrating to say the least!

In short, if you want your AI to know something tomorrow (or even immediately following a /reset), write it down today. In a file. On disk. Like it’s 1995 (only not floppy)…

2. Silent Fallbacks Will Eat Your Budget

Here’s a fun one. I set up a simple reminder cron job. Simple task, should cost fractions of a penny. I configured it to use Google Gemini 2.5 Flash Lite, a super-fast, super cheap model. Perfectly adequate for “tell Alex to [insert reminder here].” (side note: mine has permission to do so “with attitude” if need be!).

What I didn’t click was that by default when Google rate-limited Gemini (I was using the free version to start), the system silently fell back to Opus, Anthropic’s most expensive model. My bedtime reminder, a task that could run on a calculator, was burning through premium AI tokens! I only found out when I was looking at some failed, rate-limited tasks. The bot didn’t think this would be something worthy of proactively letting me know. No warning, no alert. Just a quiet, expensive upgrade.

Check your fallback chains, then check them again. Then check them after each time you do an upgrade (which has on one occasion so badly broken the contexts and channels for the gateway, it forgot who it was and I had to restore from a backup!).

Finally, setup a monitoring page on your “Mission Control”. You should definitely build one of these – a bot-built small webapp for managing and monitoring your bot, e.g. here’s mine at the moment:

3. The Hidden Cost of “Good Enough” Model Defaults

Related to the above, but subtler. Not every task your agent performs needs the flagship model. Heartbeat checks, health pings, simple notifications: these can run on the cheapest model available. I’ve got simple jobs running on Gemini Flash Lite, which costs almost nothing. Meanwhile, many of my cron jobs were defaulting to models ten times the price for work that was just as simple.

Match the model to the task. Your “send me the weather” job doesn’t need the same brain as your “analyse this quarterly report” job. It sounds obvious, but so do many things!

4. Your AI Anchors on Context, Not Facts

This is the one that properly messed with my head. I spent a long evening debugging cron job issues. Hours of back and forth, pasting logs, tweaking configs. All the conversation context was about problems from Tuesday. By the time we finished, my agent was convinced it was still Tuesday.

It was Wednesday.

The model doesn’t always know what day it is from an internal clock (you know – those things that have been in computers for decades…). It appears to infer “reality” from the conversation window. If your context is full of Tuesday’s problems, Tuesday is reality. This has real consequences when you’re scheduling things, setting reminders, or asking “what’s happening tomorrow”. I’ve seen this happen many times in different scenarios, including pre-scheduled morning briefs based on the wrong day and scheduling cron jobs for the wrong day and time.

Your AI’s sense of the world is only as good as the context you’ve given it, and context can lie. Once again I recommend a Mission Control to easily eyeball things occasionally.

5. Trust Logs Over Vibes

At one point I asked my agent which model it had used for a particular task. It confidently told me Sonnet, but the logs showed Opus (via fallback). The model wasn’t lying exactly… it just didn’t know. It reported what it thought was true based on its configuration, not what actually happened at the infrastructure level.

This applies broadly. Just like any chatbot or web-based bot you’ve been talking to for the last 3 years, your AI will sound confident about things it cannot possibly verify or doesn’t want to as it might be a wasteful activity, so it just goes with what it has in context. System level behaviour, actual API calls, real thing live in logs, not in chat responses, so when it matters always go to the source.

(I think of this as the “Did you really brush your teeth? Shall we go check if the brush is wet?” scenario).

What Next

Peter Steinberger’s very high profile move to OpenAI tells you where this is heading. Personal agents aren’t a nerdy hobbyist curiosity anymore, they’re absolutely going mainstream. OpenClaw will continue as open source via a foundation, which is great, but the bigger signal is that OpenAI wants this expertise in house. They’re betting that millions of people will be running agents like this, and you would imagine soon, by default they’ll run on Codex.

When that happens, every lesson I’ve learned will be demonstrated at global scale. People will inevitably burn money on cheap tasks, wonder why their agent forgot last week’s conversation and trust a confident response over a log file.

If you’re thinking about running your own agent, start now while it’s still a bit rough around the edges. The lessons are cheaper to learn on an old laptop in your cupboard (on an isolated network, with isolated accounts!), than in production and connected to all your company’s systems!

Now I’m off to go and find some 10 year old memory DIMMs to sell for a 400% markup.

PS – If you got this far, thanks for reading, and I apologise for the rather click-baity title! Don’t hate the player, etc…

The post 5 Things Running an OpenClaw Personal AI Agent Taught Me (The Hard Way) appeared first on Tekhead.it.

If you somehow missed the hype train, OpenClaw positions itself as an AI assistant that behaves more like a human. It can act proactively, use multiple LLMs as sub-agents, orchestrate tasks, and interact with almost anything on your computer on your behalf. At least in theory. Cue the “beam me up” moment and a strong temptation to believe this might finally be the thing that liquefies your brain in the good way.

That said, there are some fairly substantial security questions still outstanding, particularly around prompt injection and unintended actions, so I approached this very deliberately (unlike some of the horror stories I’ve seen already!). Everything ran in a sandbox, with a carefully limited blast radius, no access to my personal files or accounts, and its own email and calendar. For now, I treated it like a teenager on work experience (keen, capable, occasionally overconfident, and absolutely not to be left unsupervised with anything sharp).

What surprised me most over the weekend wasn’t what it could do, but what it demanded from me in return…

What did I Learn

The first big lesson is that the core capabilities are already solid. File operations, shell commands, and basic system interactions work reliably as long as you give them the permissions they need (and actually understand what you’ve granted). When something went wrong, it was rarely because the system couldn’t do the thing, and far more often because the constraints, context, or guardrails weren’t clear enough.

That quickly leads to the real work, which is teaching. This is not a fire-and-forget setup. You have to approach it like a teacher, because the assistant doesn’t magically infer how you want to work. The upside is that once you explain your processes clearly and correct it when it gets things wrong, it tends to internalise those patterns very quickly (sometimes alarmingly so!). One explicit correction, especially when backed by documented preferences that it stores in workspace md files, often changed behaviour permanently.

Communicating with OpenClaw

Clarity matters more than cleverness. These systems are far better at technical problem solving than mind reading! When I was vague, I paid for it in wasted tokens, odd detours, and solutions that were technically ‘correct’, but practically useless. When I was precise about what I wanted and what I didn’t, the results improved dramatically and stayed that way.

Autonomy turned out to be another important dial. It seems that you need to give an always-on agent enough freedom to be useful, but not so much that it becomes risky or unpredictable. I had the best results when I defined (very!) explicit boundaries around what was safe, what required confirmation from me, and what was simply not allowed. I didnt expect it to be perfect, but it adhered reasonably well to simple, clearly stated rules, which was enough to build confidence over time (and sleep slightly better!). I’m sure there is risk in there of it overstepping some boundaries, so again until this matures, I’m keeping that blast radius as small as possible, even in the worst case scenario.

I also found that you have to accept a certain amount of trial and error. Things don’t always work on the first attempt, and that’s part of the deal. In one case, a system looked “healthy” while doing absolutely nothing useful because it was monitoring the wrong signal. In another, an automation kept hanging because the machine was quietly waiting for a human approval prompt I couldn’t see, despite being on the desktop! These weren’t exotic failures, just the kind you only discover by actually running the thing.

Pro tip: don’t /reset in the middle of a long conversation unless you have to, as it will forget some vital things, but when you finish a piece of work, using /reset will reduce the context window and save you tokens!

Tokens, tokens everywhere…

Tokens deserve special attention, because if you’re not careful, OpenClaw will burn through them with impressive enthusiasm. What worked best for me was treating models as tools with different costs, not interchangeable brains. For routine work and exploratory steps, I have heard good things about cheaper models like Kimi K2.5, that hold up remarkably well. For me, most of the orchestration and day-to-day thinking ran on Anthropic’s Claude Sonnet 4.5, which struck a good balance between capability and cost. When I genuinely needed deep reasoning, I escalated deliberately, rather than by default to Opus 4.5. For code-heavy work, ChatGPT 5.2 performed well and, somewhat surprisingly, survived the token usage better than expected. One practical tip here is to avoid pay-as-you-go APIs unless you enjoy anxiety, and to accept that if you are using this for anything more than extremely light testing, upgrading to the Anthropic Max plan is often the least painful option in the long run (I went for the $100 equivalent tier for this month and it’s holding up well so far).

One habit that paid off faster than expected was documenting as I went, or better yet, having the bot do it for me! Notion worked particularly well for this, and having a written record of decisions, preferences, and fixes turned out to be just as valuable as the automation itself (future me will almost certainly agree).

The Verdict

Stepping back, OpenClaw is clearly bleeding-edge software with some rough, bordering on paper-cut level edges! Some operations are fragile, the learning curve is real, and you are very much learning alongside the system rather than using a polished product. If you’re technical, patient, and comfortable in a terminal, it’s genuinely astounding, and will surprise you regularly (in a good way!), but it’s not going to be a totally smooth ride, and it’s absolutely nowhere near ready for the general public to safely play with!

I also discovered more about ways to use ChatGPT or Claude independently of OpenClaw that I wasnt previously aware of. Simple things like scheduling reminders and information to be sent to you later is all feasible, which actually negates some of the reason (and therefore risk) of using OpenClaw, depending on your use case.

After three days, my takeaway is that an AI assistant isn’t magical or terrible; it’s extremely useful. It’s definitely more like that teenager on work experience, except they rarely forget anything, work continuously, and execute precisely once you’ve taken the time to teach them how you operate (but still under strict supervision!). The value isn’t in a single impressive feature, but in the compound effect of lots of small, but amazing things.

I’m cautiously optimistic.

Ask me again in a couple of weeks.

The post Testing OpenClaw Without Losing Your Mind, Money, or Data appeared first on Tekhead.it.

During one of many hours on the minibus, travelling between regions, my family asked me about the cloud and what impact it has on the environment. This has obviously been a massive topic over the past few years, prompting the hyperscalers to take a very public stance on the matter, for example, the re:Invent 2021 sustainability announcement by AWS.

We all know that cloud computing has become an essential part of modern life, changing the way we work, play, and communicate arguably faster than any other time in history! I would suggest that there are a huge number of sustainability benefits to adopting the cloud, but that doesn’t mean it’s environmental impact is zero. As with all things, we should be looking at the pros, cons and mitigations.

Just some of the Pros

The cloud allows businesses to reduce energy consumption and hardware waste significantly. By using shared cloud resources, organisations can get rid of their low-utilisation, on-premises hardware footprint, unused redundant kit for HA and DR, etc, all of which requires electricity, cooling, shipping, maintenance, etc. Cloud providers typically use state-of-the-art, energy-efficient data centres with huge economies of scale to minimise the overall carbon footprint.

Speaking of which – economies of scale! Hyperscalers benefit from massive economies of scale, making it more efficient for them to build, manage and maintain data centres. They have the budgets to invest in advanced technologies and energy-efficient infrastructure, leading to a lower environmental impact compared to small-scale, on-premises solutions (of even traditional colo).

On-demand scalability in the cloud allows organisations to optimise resource utilisation and remove the need for over-provisioning of hardware for peak demand or HA/DR. This not only reduces waste, ensuring only necessary compute resources are used, but reduces the TCO and frees up budget to be used elsewhere!

Something perhaps overlooked at times is that the cloud increasingly enables remote working, thereby providing better work/life balance for people and reducing the environmental impact of commuting. Greenhouse gas emissions from vehicles have a massive impact, which (especially in temperate countries) can be mitigated by more work from home. Furthermore, with the ubiquity of 4G and 5G mobile communications, this provides access to compute resources from remote locations where they would not have otherwise been available. This will likely increase utilisation and impact, but will help people all over the world benefit their lives and will likely lead to further innovation that will benefit the environment.

Lastly, as bonkers as it is to even needing to remind people of this in 2023, cloud computing virtually forces users to adopt virtualisation, utilising resources far more efficiently than traditional full-fat tin. It’s mind boggling how many companies are still uncomfortable virtualising heavy workloads such as databases today, despite all of the classic concerns being mitigated.

A Few Risks

The largest risk, but possibly the one which may have its own mitigations, comes from increased adoption. The increasing popularity of cloud computing means that the demand for data centre resources is rising massively. As more businesses move their operations to the cloud, energy consumption of centralised, cloud data centres will continue to grow (whilst reducing that of local), but beyond that, the innovation of all those very clever humans who have found new ways to utilise this new technology is likely further driving up utilisation beyond our traditional baselines.

The location choice for data centres can have a significant impact on the environment. In regions where electricity is generated using fossil fuels, cloud computing indirectly contributes to higher greenhouse gas emissions, and cooling data centres in hot climates can be super energy-intensive. If data sovereignty is not an issue, then utilising compute regions close to natural energy / cooling can help to mitigate this.

Inefficient development practices and code bloat further add to the risk landscape. The availability of virtually unlimited resources in the cloud may inadvertently reduce the drive for developers to write efficient code. Promoting clean development practices and optimisation is essential to minimise energy consumption. We should be fostering a culture of efficiency and sustainability right from the early stages of developer education to ensure this issue doesn’t continue to creep into the cloud. The growing trend of of microservices architectures may actually help here, encouraging developers to think small and efficient modules, but that remains to be seen!

One of the fastest growing users of energy and hardware is Cryptocurrencies. The massive amounts of power used to not only generate new coins, but also manage transactions on the chain, are a significant concern. Dedicated crypto hardware, such as ASICs, can help reduce energy consumption and those specifically designed for cryptocurrency mining are more energy-efficient compared to general-purpose hardware like GPUs. I would hope that the miners will adopt these more, if only for their own benefits, if not for the environment!

TLDR

So to respond to the question posed by the title of this post, I believe the answer is yes, but there are some key considerations to ensure it remains so.

To make cloud computing a truly sustainable solution, we need to advocate for the use of renewable energy sources by cloud providers and the drive for net-zero carbon emissions in our cloud platforms (not just through buy carbon credits, but through actual change). Harnessing solar, wind, and hydroelectric power can enable cloud providers to decrease their dependence on fossil fuels and shrink their carbon footprint, but this will always be region-specific and impacted by data sovereignty regulations.

As consumers of the cloud, we have a crucial role to play by opting for cloud service providers that prioritise eco-friendly practices as well as adopting those ourselves, from architecture to development, fostering a culture of well-architected sustainability in our own organisations.

The post Is the Cloud actually greener? appeared first on Tekhead.it.

Challenges

There are many challenges that businesses face when it comes to cloud security and far too many to go into in a TekBytes thought of the day, but let’s look at a few.

One major challenge is the lack of visibility and control over the infrastructure and data that are hosted in the cloud. This can make it very difficult to identify and address security vulnerabilities and threats. Another challenge is the complexity of cloud security, which can be exacerbated by the use of multiple cloud providers, each with their own security protocols and standards. Finally, we have a huge lack of skills in the market, and those few people with the skills are constantly being tempted by offers of outrageous salaries, so retaining your talented teams is really tough!

Despite these, there have been really significant advancements in cloud security in recent years. The hyperscalers have implemented many new security measures, such as encryption, improved access controls and policies, significantly better monitoring tools, to help protect their platforms and their customers’ data. Post-Covid, with customers moving to the cloud in even larger numbers, it’s also great to see that customers have become more aware of the importance of cloud security and are taking steps to prioritise it.

The threat landscape for cloud security continues to evolve, with new and extremely sophisticated attacks emerging all the time. Businesses need to keep up and be proactive in their approach to cloud security.

Tips

So, a couple of quick tips to think about if you haven’t already started taking your cloud security seriously?

1. Implement multi-factor authentication (MFA). A bit like when you hear sports commentators or coaches talking about a losing team, the common thread is simply not doing the fundamentals / basics well. One of the most effective ways to improve cloud security is to require MFA for all users accessing cloud resources (not just root). Lack of MFA is like leaving your car door unlocked and crying out to have your vehicle taken for a Ferris Bueller-style joy ride!
2. Regularly review and update security policies. It’s important for businesses to regularly review and update their security policies to ensure they are aligned with current best practices and standards, and these best practices are constantly evolving. Things like access controls, password policies, data encryption, and incident response plans. By keeping security policies up-to-date and ensuring that all employees are aware of them, businesses can significantly reduce the risk of security breaches.
3. Investigating the used of third-party security tools and services. Tools (if properly implemented) provide additional layers of protection, such as threat detection and monitoring, vulnerability scanning, data encryption, etc. Engaging security experts one-off or regularly to provide recommendations for improving their security posture, or simply outsourcing management of their cloud estates.

I’m genuinely hopeful that the emerging (and frankly astounding) improvements in artificial intelligence will have a positive and significant impact on businesses who don’t or can’t spend the time and resources to protect themselves and their customers effectively. If they don’t we’re only going to see a proliferation of more high profile and high impact cases in the news!

The post TekBytes #5: The Current State of Cloud Security appeared first on Tekhead.it.

I’m always looking for ways to improve my workflow and productivity; most recently I’ve started using Markdown for as many projects as I can, so using Markdown in WordPress is no exception!

If you haven’t seen or used Markdown before; it’s a super-lightweight markup language that allows you to add formatting elements as you go by using special syntax. For example, if you want to make a section of text display in italic, simply put an asterisk at the start of the word or sentence. When the output is then parsed, your *Italics* then becomes Italics).

Why is this useful?

• Like an XML file, it’s open, super portable and easily readable across many applications, operating systems and web platforms (think Reddit, GitHub, Stack Exchange, Confluence, etc).
• It saves time when editing simple documents as you don’t have to go back and highlight/modify formatting, just add the syntax as you go, often with the use of one or two characters at the start of a line. Simple examples might be a bulleted list, where you add an asterisk *, or an H1 heading where you add a single hash symbol #.
• It’s fantastic for writing documentation where you might want to insert a quick code snippet or command just like this!
• Due to the very simple notation, it’s far quicker than writing HTML and can be substituted for HTML on many publishing platforms.
• If Git is already part of your workflow, it makes for easy collaboration with others (ideal for Devs!) and you can use GitHub for both version control and easy access from anywhere to your in-progress content.
• Learning and practising with Markdown opens up future opportunities to move to various publishing platforms such as Jekyll, Hugo, etc. I might even think about giving the site a facelift sometime soon!
• New skill to master, init?

The post TekBytes #4: Why I’ve Switched to Simple Markdown in WordPress appeared first on Tekhead.it.

Most organisations often aspire to increase agility, to respond quicker to their customers and market demands, to innovate. However, many organisations have years of technical debt, monolithic application stacks and shrinking IT budgets. IT is still too often seen as a cost centre instead of an opportunity to become a profit centre and agent for growth.

These organisations have one thing in common; they see lifting and shifting to the cloud as the silver bullet.

I thought Cloud was the silver bullet?

Now don’t get me wrong, cloud is AWESOME! It does help to address some of the challenges identified, but anyone who has been working in this space for any length of time will tell you cloud is an enabler, not the solution.

Moving your workloads to cloud is like moving your business from your garage to a shiny new workshop, with an array of amazing tools hanging on the wall just begging to help you with your next project.

You have room to breathe, so your innovation is now limited by your imagination, far more than your square footage! If you come up with an idea that turns out quickly to be garbage, there’s a handy industrial skip out the back, meaning you don’t have to wait 2 weeks until the next grey bin day to get rid of it!

Of course, that doesn’t mean it’s a free-for-all! You still need to understand the tools, how they work to achieve outcomes faster and what problems they solve, lest you accidently lop off a finger!

Sounds great! Am I Cloud Native now then?

Here’s the key – unless we re-evaluate everything we do today and adopt new ways of working, we are simply not going to realise the benefit of working out of our shiny new workshop, with our huge array of tools!

In the real world this means your entire process from whiteboard ideation to deployment, the ongoing lifecycle of applications and everything / everyone / every process that touches them!

To me, cloud native means a set of technologies, the methodologies and processes to manage them and a state of mind which needs to permeate an organisation!

If you’ve simply lifted and shifted your existing estate and dropped it into the cloud, you’re not cloud native, you’re simply running VMs in a different data centre.

Much like the famed elevator from Lemony Snicket, VMs in the cloud are simply playing at being Cloud, or more accurately, Ersatz Cloud Native.

Further Reading:

I wrote another brief post on cloud native considerations a while back:
The Complexity of Public Cloud Architecture

The post Answer Honestly: Are you Ersatz Cloud Native? appeared first on Tekhead.it.

VMware vExpert 2017 – It’s not just about the schwag!

Instead, I am compelled to write a wee haiku about something which most vExperts hold near and dear to their hearts – IT certification!

I hope you enjoy!

Certification;

Rolling in my hamster wheel,

Will it ever end?

Anyway enough messing about, better get back to the studying!… GCP next! 

The post TekBytes #3: A Certification Haiku for the vExpert Announcement! appeared first on Tekhead.it.

By going all in, however, many modern “cloud-native” applications are built upon a multitude of solutions, services and elements. This could be anything from a third party PaaS / SaaS provider for ID management, to “rolling your own” caching and search solution. It could even be simply implementing a broad set of management tooling for code and infrastructure automation.

The diagram below represents the technologies involved in one such solution. It’s clearly a highly distributed application with dependencies across many different platforms and cloud-vendors! It’s also not the only example of a solution I have seen in the new cloud-native world!

The risk is, the failure of any single one of those SaaS, PaaS or IDM platforms, automation tools or API gateways could leave an application offline and its owners potentially powerless to resolve it! Developers are exchanging the complexity of building elements into their applications natively, for the risk of distributing (out-sourcing?) them out to other cloud platforms.

Public cloud architecture isn’t always simples!

That is not to say this is not a reason to go to cloud and refactor applications to be more cloudy! The relative benefits to an organisation may far outweigh the risks. The key thing is that in any organisation, requirements from the business will always trump any expectations of simplicity or even consistency!

We are simply exchanging one set of complexities for another!

Thoughts? Feel free to discuss in the comments below!

The post TekBytes #2: The Complexity of Public Cloud Architecture appeared first on Tekhead.it.