Si Novi

Elastic Beanstalk PHP 8.2 on AL2023 retires March 31, 2027

2026-10-02T00:00:00.000Z

You've had an "[Action Required]" email from AWS

If an email has landed from your AWS account with the subject [Action Required] AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027, it means at least one of your Elastic Beanstalk environments is running PHP 8.2, and that PHP version is reaching the end of its life.

Pragmatically, it's likely that nothing will break on March 31, but you have roughly six months to move each affected environment onto PHP 8.3, 8.4 or 8.5. In our experience that's a small project rather than a settings change, so we'd start on it now rather than in March.

We maintain a large number of PHP applications on Elastic Beanstalk, many of them built on Yii, and we're already working through scheduled updates from PHP 8.2 to 8.4 across them. This retirement is fairly routine, but there are a couple of details in the email that are easy to miss.

What "retire" actually means

From March 31, 2027, the PHP 8.2 on 64bit Amazon Linux 2023 platform branch is marked as retired. Under the Elastic Beanstalk platform support policy that means:

Elastic Beanstalk stops providing maintenance updates for the branch, including security updates.
AWS no longer provides technical support for it.
The branch disappears from the Elastic Beanstalk console for creating new environments. Existing environments get a 90 day grace period, and can still be cloned or rebuilt through the CLI and API.

Your existing environments keep running and AWS doesn't delete anything, but from then on nobody is patching the platform underneath your application.

The date that matters more is December 31, 2026

We'd plan around an earlier date than the one in the email, because PHP 8.2 itself reaches end of security support on December 31, 2026, three months before Elastic Beanstalk retires the platform branch.

From January 1 the PHP project stops releasing fixes for 8.2, so any vulnerability found in the language after that date stays unfixed, whatever AWS does with the platform. For an application that handles customer data or payments, we'd treat the end of December as the real deadline. Auditors and cyber insurance questionnaires increasingly ask about unsupported runtimes, so it's often a compliance question as well as a technical one.

Which PHP version should you move to?

The email lists three PHP versions to move to, each with a different amount of support left:

Platform branch	PHP security support ends
PHP 8.3 AL2023	December 31, 2027
PHP 8.4 AL2023	December 31, 2028
PHP 8.5 AL2023	December 31, 2029

PHP 8.3 is the smallest jump from 8.2, but it only buys about a year before you get this same email again. We generally recommend going to PHP 8.4, or PHP 8.5 if the application's dependencies already support it. The extra testing tends to be a modest cost compared with doing the whole exercise twice.

It isn't a button in the console

Elastic Beanstalk can update a platform version in place, but only within the same platform branch. PHP 8.2 to PHP 8.4 is a different branch, and AWS recommends a blue/green deployment for that: build a new environment on the new branch, deploy the application to it, test it, then swap the CNAMEs so traffic moves across. Done properly, your users shouldn't notice any downtime.

The infrastructure side is usually the easy part, and we find most of the time goes on the application itself. PHP 8.2 to 8.4 sounds like a minor version bump, but each release changes enough that application code sometimes needs modifying. PHP 8.4 deprecates implicitly nullable parameter types, a pattern that's all over older codebases, and both 8.3 and 8.4 tighten up behaviour that older code and libraries depend on. Across the updates we've done so far, the work tends to fall into the same few areas:

Test coverage - before changing anything, we make sure the application has a running test suite and that it's green on PHP 8.2. Without that, there's no reliable way to tell whether the upgrade broke something or it was already broken.
Composer dependencies - older packages may not declare support for newer PHP versions, and some will need upgrading or replacing before composer install will even run.
Framework versions - an application on an old release of Yii, Laravel or Symfony may need a framework upgrade before it will run cleanly on PHP 8.4. We've written about the bigger version of this in migrating from Yii 1 to Yii 2.
Deprecation notices - each PHP release deprecates a few more behaviours. They rarely break anything immediately, but they can flood the logs and hide real errors.
.ebextensions and .platform hooks - custom configuration, installed packages and PHP extensions all need checking against the new platform.

For a typical SME application, we'd usually expect this to be a few days of work rather than weeks, but it varies a lot with how long the code has gone without maintenance.

Finding your affected environments

The quickest place to look is the Affected resources tab of the AWS Health Dashboard event the email links to. The Elastic Beanstalk console also shows a Platform state column on the Environments page.

If you'd rather use the CLI, this lists every environment on the retiring branch in one region. The example in the AWS email points at us-east-1, so change the region to wherever your environments actually live:

aws elasticbeanstalk describe-environments \
  --region eu-west-2 \
  --query "Environments[?contains(PlatformArn, 'PHP 8.2 running on 64bit Amazon Linux 2023')].[EnvironmentName,PlatformArn]" \
  --output table

The email is sent per account and per region, so if you run several AWS accounts, check each one. Forgotten staging environments are often where these old platforms hide.

Still on Amazon Linux 2?

If your environments are on an Amazon Linux 2 platform rather than Amazon Linux 2023, they're already retired: AWS retired every AL2 platform branch on August 6, 2026. Moving from AL2 to AL2023 is a bigger change than a PHP version bump, because the operating system changes too, so we'd do both together and going straight to PHP 8.4 or 8.5 on AL2023.

What happens if I ignore it?

At first, not a lot. The environment keeps serving traffic and nothing visibly changes on March 31.

The risk builds up over time, though, with no security patches from PHP after December and none from AWS after March. AWS also warns that an Elastic Beanstalk API action may eventually stop working for an environment on a retired branch, which would be an awkward thing to discover while trying to deploy an urgent fix.

If you don't have the in-house capacity to make the upgrade, get in touch. We're an AWS Partner based in Manchester and we do this kind of PHP and Elastic Beanstalk upgrade work regularly, whether that's a one-off migration or ongoing support and maintenance.

Elastic Beanstalk platform versions scheduled for retirement: https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-retiring.html

PHP supported versions: https://www.php.net/supported-versions.php

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

9th July 20264 min read

Pointing agentic AI at our own bookkeeping

AWS Community Summit Manchester 2026 preview

2026-09-25T00:00:00.000Z

Back to Victoria Warehouse for ComSum 2026, with AI all over the agenda

On Thursday 1st October, Martin and I will be at Victoria Warehouse for the AWS Community Summit. We were there last year too, and the photo above is from Matheus Guimaraes's afternoon session on bringing Generative AI into production. This year the agenda leans much further that way, which probably reflects where most of us are. We're developing in a very different way to how we did six months ago... even three months ago, but it isn't only the developer tooling that's changed - it's how businesses operate and what they choose to automate.

Even in a business our size we've begun to embed AI workflows into what we do, from the tools we've built against Xero to our own knowledge OS. The ecosystem is so new that we're very much looking forward to hearing from and talking to people doing the same - and ComSum is a good chance to catch up with peers, colleagues and friends on how they're approaching this AI era.

Opening keynote: from compilers to copilots

The day opens with David Anderson, Angela Timofte and Sheen Brisals on the evolution of software and the AI-powered future, all three familiar names from the serverless community. I'm expecting it to set up the rest of the day nicely, with a look at how we got from compilers to the copilots and agents most of us now work alongside, from people who've been building on AWS long enough to have seen a few of those shifts first hand.

AI-DLC and organisational context

One session I'm looking forward to is Matt Houghton's Context Over Code: Why AI-DLC Is an Organisational Transformation, Not a Productivity Hack. AI-DLC is the AI-driven development lifecycle AWS has been talking about, where AI takes a part in every stage of delivery rather than just writing the code. The title matches what we've found in our own work - the tooling is usually the easy bit to adopt, and the harder part is giving the models the context they need about how a business actually works, what's been decided and why, and where the boundaries are.

That context is a large part of why we built our knowledge OS, so the agents working on our projects know how we build, what's been planned and decided, and why. I'm keen to hear how Matt frames it for larger engineering organisations, where that context is spread across far more teams and systems than ours.

Looking back at my notes from Matheus's talk last year, I see quaint notes on ideas to "build an MCP server for Si Novi coding standards". It's incredible how far things have come in a short space of time!

Closing keynote: beyond software engineering

Ian Massingham, now at Anthropic, closes the day with a question we've been asking ourselves a lot this year - what should engineers do when writing code is the easy part? His answer is choosing the outcomes, making systems legible to models, and going beyond software to bigger and more impactful problems. That lines up closely with how our own days have shifted, with more of our time going on deciding what should be built and making sure the agents doing the work have what they need to do it well. Ian was a familiar face at AWS events for years, so it'll be interesting to hear the view from inside a model provider, drawing on the thousands of startups building on Claude.

Come and say hello

If you're going too, come and find us - we'll probably be in the Cottonsheds for the keynotes and in the Archives for the AI sessions in between. And if you can't make it, we'll share what we took away from the day afterwards.

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

9th July 20264 min read

Pointing agentic AI at our own bookkeeping

Build the squad. Own the platform.

2026-07-17T00:00:00.000Z

Once the technology works, the bottleneck is the org chart

My wife Helen, who works in HR, sent me an episode of HR Disrupted last week - Lucy Adams interviewing Andy Doyle from Kantar on putting AI agents into production HR workflows.

Andy describes some genuinely impressive work. Kantar had around 4,000 HR policies spread across 63 markets. Twenty-three versions of a single policy were scattered across the intranet, many written by different people at different times, some long out of date. Reviewing and standardising all that by hand would have been the work of years. So they built a set of small, single-purpose agents instead, one to rewrite each policy into a standard format, another to flag where it broke local employment law. The whole lot went into one common framework in a week.

Why now?

It's a real piece of engineering, which is what makes some of the rhetoric around it a shame: you don't train out hallucination, you constrain it with evals and guardrails. But the operational story underneath holds, and the lesson is in what they did, not how they describe it.

Listening to the podcast got me thinking less about Kantar and more about the next move for everyone who hears a story like that and wants to do something similar.

The conversation about AI inside large organisations has shifted in the last six months, from a model problem to a deployment one. AWS's Ishit Vachhrajani describes it as moving from "generate and hope" to systems that plan, decide, and act with human guidance. You can still argue about whether the models are ready, and plenty of people do. But the teams already shipping agents into production - Andy's at Kantar among them - have stopped waiting for that argument to settle. The hard parts that remain, reliability and hallucination, get handled operationally now - not trained away. Those are deployment problems, not model problems. The bottleneck is the org chart.

Where in your organisation does this capability live? Who owns it, who governs it, who carries the risk when something goes wrong? These are organisational design and architectural decisions, and the next ten years of AI in your business will be shaped more by how you answer them than by which models you pick.

And the honest version of where this is heading is bigger than a governance question. The functional org chart - HR over here, IT over there, finance in the corner - has been the default shape of large organisations for the better part of a century. AI may prove to be one of the forces that starts to pull it apart. Get this right and you're not just deploying agents well, you're building the first working piece of an organisation that composes around the work itself rather than the functions that have always owned it. The first step towards that is much smaller.

Faced with the immediate question - where does this capability live - most leaders reach for one of two answers. Both look reasonable. Both have serious problems.

Two easy answers that don't quite work

The first is to outsource the capability wholesale. Buy an agentic platform from one of the workflow-automation or RPA vendors who've rebadged in the last eighteen months, let them run the platform layer, let their workflows define your agents.

This is a mistake, and a specific one. Not that you shouldn't get external help - most organisations will sensibly work with partners. The mistake is handing over the architectural decisions. Rent a vendor's abstraction and your data, governance, audit, and identity story is whatever they ship. When an agent does something it shouldn't, the loop back to the people who can change it goes through a support queue. You've outsourced the part of your business that's about to become strategic.

Building on a hyperscaler is genuinely different. Model behaviour, pricing, and roadmap are externally controlled either way, but on AWS, Azure, or Google you own the IAM, the audit, the cost controls, the integration patterns. You stand on their shoulders without handing over the decisions that shape how your capability evolves.

The second easy answer is to bolt the capability onto an existing function. Hand it to HR, hand it to IT, hand it to whoever has the closest claim, and declare the strategy done.

There are really two layers here, and they want different answers. The platform layer - IAM, audit, cost controls, the cloud foundation the agents run on - IT will rightly own as platform engineering. It's foundational and benefits from standardised delivery, same as any cloud platform.

The harder question is who owns the capability that uses the platform: designing the agents, deploying them into real business problems, shaping how people interact with them, deciding what good looks like. That's where the "give it to a function" answers break down.

Of the single-function answers, HR has the strongest case. Adoption really is the hard part, and behavioural standards and change management live closer to HR than to engineering. None of that is wrong. The problem is that bolting the capability onto any single function inherits that function's operating pattern, and strategically important work inside a shared service ends up under-invested and slow. The interesting question isn't "which function owns it?" It's whether you're building cross-disciplinary capability that lives in the business, or single-discipline capability that gets delivered to the business.

We've done this before

The thing that should give every senior leader pause is that we've already lived through a version of this. It was called Excel.

Spreadsheets put powerful data manipulation in the hands of capable people with no engineering scaffolding around them. Net positive on the whole, but it also gave us the London Whale loss at JPMorgan and a generation of businesses running critical processes on undocumented workbooks built by an analyst who left two roles ago. We're still cleaning that up decades later.

"Buy some licences and see what people can do" is the same energy. Powerful tools, capable hands, no scaffolding. Except an agent doesn't sit in a workbook waiting to be opened - it acts. Put one on top of a broken process and it won't just record the mess, it'll run it. We learned the lesson once. This time the spreadsheet could fire people.

What to do instead: build a squad

The answer isn't a new department. It's a deployment squad - and you can see the shape of one in the Kantar story, even if Andy doesn't call it that. The top agent builders are spread across HR, payroll, and analytics. The payroll manager who happened to be in the room when the Copilot licences went out became the AI manager. The head of analytics built the finance/HR reconciliation agent herself, eighty hours by her own count. The job title may be useful political cover, but it isn't the operating model. What Andy describes is a squad, not a function.

I'm extrapolating here. I haven't run an internal AI deployment squad inside a large enterprise. What I have watched, up close, is the pattern AWS Professional Services and the Partner Network use to ship production work inside customer organisations - and the forward-deployed engineer roles that Anthropic, OpenAI, and Google are now pitching look like the same shape. The underlying logic is one AWS worked out long ago: access alone isn't the bottleneck. Deployment is.

So build your own version. A small, cross-functional squad: platform engineers who can operate like internal forward-deployed engineers, IT people who already know your data and systems, HR expertise on behavioural standards and adoption, and line-of-business owners who know what good looks like. It embeds into specific problems and ships production agents. Not an innovation pod or a tiger team that spins up a demo and disbands. It owns what it ships, it integrates properly with the platform, and it stays.

The squad needs two things to work.

The first is platform discipline. The agents it builds are applications. They live on a platform layer that decides who an agent is allowed to be, what it can touch, what records it leaves, what it costs, and what it's allowed to do with sensitive data. Most of that comes from the cloud platform you already use. What it doesn't give you, you build and maintain yourself. Be clear from day one about which decisions belong to the platform and which belong to the agent, and resist the urge to rebuild platform-level safeguards inside every individual agent. Andy's team raced past the audit trail and had to come back to it later; he notes it would have been far more costly in a regulated industry. The discipline matters from the start, not as a retrofit.

The second is a sponsor senior enough to clear blockers but light enough not to slow it down, with the authority to ship without permission from every adjacent function. Andy had exactly this: permission to think bigger and permission to fail visibly. The sponsor's risk tolerance is what lets the squad ship and learn. The platform discipline is what decides whether the inevitable failures are recoverable embarrassments or unrecoverable disasters.

Where the squad sits on the org chart matters less than these two things.

One thing the podcast skips is how the rest of the organisation reacts. A cross-cutting squad shipping into work that IT, finance, or operations think of as theirs can be read as a threat, even when it's there to help. Handling that is real work, and it gets easier each time: squads that do it well don't stay one-offs. They become the prototype for how AI capability spreads, and the platform team scales with them.

What this means for HR, and for Helen

The more forward-looking parts of the profession have been moving from a roles-based view of the workforce to a skills-based one, where the unit of work is the skill, not the job title, and teams get composed from skills as the business needs them. Mercer's Jess Von Bank, in a recent People Management feature, pushes HR to design itself from first principles - for what the business needs now, not what the org chart has always done. A deployment squad, assembled from the skills a problem needs, is exactly what that model produces, which is why HR shouldn't try to own the AI capability but should help compose the team that delivers it. That's a craft the profession has spent a decade building, and it deserves better than to be flattened into change management.

For someone like Helen, that means becoming genuinely literate in the platform layer - what agents do, how they fail - without becoming an engineer. The more HR understands how these systems work in practice, the more useful it is to the teams that build and deploy them.

The squad is the starting move. Build enough of them and the question stops being "which function owns AI" and starts being "why are we organised around functions at all". That's a bigger argument, and not one for today - but you don't have to settle it to start.

Don't wait for a reorg to make it official. The future organisation doesn't arrive by redrawing the chart - it arrives one shipped agent at a time. The org chart will catch up when the work has earned it.

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

9th July 20264 min read

Pointing agentic AI at our own bookkeeping

Agentic AI for operations: experimenting on our own bookkeeping

2026-07-09T00:00:00.000Z

View full-size screenshot

We've been using agentic tooling for a while now, and lately we've started turning it towards how we actually run Si Novi. Our Xero bookkeeping is one area of pain. I do our books myself, so I know exactly which jobs take the most time each month. Those are the ones I've been handing to an agent, in the shape of a little suite of tools we've built against the Xero API and can drive from inside a Claude Code session. The first results are really exciting and have already saved me a bunch of time and effort this quarter.

Where I aimed it, and why

I set the agent a task list of the fiddly, repetitive jobs I already know inside out and would happily never do by hand again. The big one, and where most of my monthly grief lives, is draft supplier bills, because every month there's a run of them to work through: converting the dollar receipts from the likes of GitHub into the pounds that actually left the bank, spotting where a supplier has sent both an invoice and a receipt for the same payment so one can be dropped, and setting the right tax treatment across reverse charge, No VAT, and plain 20%. None of it is hard, it's just fiddly and it mounts up, and one batch had five duplicate invoice-and-receipt pairs to weed out on its own.

I knew that with draft bills cleaned up I could then focus on reconciliation - which would be a much easier task even still using the Xero UI. But automating reconciliation is unlocked by the bills being clean.

The shape that's working so far

The pattern underneath it is what I'd call AI in the loop rather than AI in a box, and it falls into three clean roles. The scripts do the deterministic donkey work of authenticating, pulling the bills and the bank lines, and writing approved changes back. The agent does the judgement I actually point it at, reading a receipt, matching a foreign-currency bill to the sterling that left the bank, working out the category and flagging anything that looks off. And I sit in the middle, setting the task and approving every write, so nothing reaches Xero until I've looked at it, which is the entire point when it's the live accounts.

Where the API runs out

The one real limit I've hit is that the data you want isn't always where the API reaches. It seems that raw unreconciled bank transactions are not available via the Xero API, so for now I'm bridging the gap with a once-per-batch XLSX report export. I can hand that to our Xero Tools agent to be extracted via a script and included in the data processing. It works fine but isn't quite the elegant answer I'd have liked. One manual step but still a huge improvement overall.

Guardrails, because it's live accounts

Because this is pointed at the live accounts, everything runs as a dry run by default and won't write a thing until I confirm against named targets, each change is atomic so there's no half-finished mess to unpick, and a re-run knows what it has already done and skips it. The one time it genuinely hit a wall it stopped cleanly, refusing a couple of bills it shouldn't have touched rather than mangling them, which is exactly the behaviour you want the first time you let a tool near the books.

In summary... well, it's brilliant

This is early and I'm still very much playing, but it's a genuinely exciting way to work.

The part I like most is quiet: the supplier quirks and billing rules and tax treatments I know are getting written down as we go, as versioned notes the agent picks up on its own, so it starts each session already knowing what I taught it last time. And I love the compounding knowledge of the codified work I've done here - this is operations software we can iterate over time and further optimise our workflows, saving ourselves time.

If you've got a repetitive, fiddly corner of your own operations that you know better than anyone, that's just the sort of thing we like getting our teeth into, so do get in touch and we'll talk it through.

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

What is AI-native? A clear definition

2026-06-05T00:00:00.000Z

AI-native means designing the product around AI from the ground up

Designing around AI changes what gets built underneath it, from where the data lives to what the product can promise its users. The models, agents and tools doing that work shape the system rather than sitting on top of it.

It's fast becoming a buzzword, and the useful way to get your head around what it actually means is by analogy to something most people building on the web already know well: cloud-native.

The cloud-native analogy

Cloud-native never just meant "it runs on the cloud". You could lift an old application onto a virtual machine in AWS and change nothing about how it was built - that's hosting, not cloud-native. The term meant something more specific: software designed around the cloud's actual properties. Elasticity, managed services, ephemerality, microservices. Architected from the outset to take advantage of what the platform does well, rather than treated as a server that happens to live somewhere else.

AI-native is the same move, applied to AI. The system is architected around the model's properties from day one, and without the model there would be no product. Take the same step that cloud-native took, and point it at large language models instead of infrastructure.

A spectrum, not a binary

The term AI-native and its derivatives are everywhere at the moment, so here's an attempt to clarify. In my view the spectrum has three clear points on it:

AI-washed. The marketing claims AI, there's very little real substance behind it. A logo on a landing page and a press release. But what does it actually DO? And WHY?

AI-enabled, or AI-powered. A working product with AI added as a genuine feature - a chatbot stapled onto an existing CRM, say, or a summarise button in a tool that got along fine without one. The key test: remove the AI and the product still stands. It's diminished, maybe, but it's still a product.

AI-native. Remove the AI and there's no product left. The model is doing the central job, and without it you're holding an empty shell.

Most of what gets called AI-native is really AI-enabled, and that's fine - there's nothing wrong with adding AI to a solid product.

What's actually different about it

The difference shows up in how the thing is actually built, not in the marketing.

The AI runs through it, not beside it. Genuinely AI-native isn't a single API call to a model provider tacked onto one screen. The model shapes the whole design - how data is stored and retrieved, which cloud services you reach for, how a request flows through the system. Pull on almost any part of it and the AI is there.

It handles what you never specified. Traditional software makes you build for every expected input and every branch in advance, and anything outside that list just isn't supported. A model doesn't need a list. The clearest case is unstructured input: free text, emails, PDFs, scanned invoices, photos. Each of those used to need either a person or a parser written for one supplier's exact layout, and now a single path deals with all of them however the document happens to arrive. Also the input can be the user's own words, not items from a dropdown list.

It can act on your systems. An AI-enabled feature answers a question and hands the result back for you to do something with. An AI-native product gives the model tools and lets it get on with the job: read the message, pull the right record, check it against what is already there, and draft whatever comes next. That changes what you are building, because the model now needs tools it can call, permissions bounding what it is allowed to touch, and a record of what it did. We've been doing this on our own books, pointing agentic tooling at the Xero jobs nobody enjoys doing by hand.

The costs and risks are different. You tend to pay per use rather than a flat monthly bill, and there's a new set of safety problems to worry about - the model being tricked into misbehaving, or confidently making things up. Older security thinking doesn't fully cover these, which is why OWASP now keeps a dedicated Top 10 for AI applications.

AI you didn't ask for

What really gets me is that plenty of software you've happily paid for and used for years is suddenly sprouting AI features, and the price is going up to cover them. You didn't ask for the AI, you might not even want it, and now you're paying for it whether you use it or not.

That's the wrong way round. If a tool has done the job for five years, I should get to decide whether the AI is worth it to me. If it isn't, I shouldn't be paying for it. Opt in, not opt out with a price rise quietly attached.

There's a fairer model more software could offer, and it's one I'd love to see more of: bring your own key. Let me plug in my own account with the AI provider and pay the real cost of what I use directly, instead of a marked-up rate on top. The software gives me the clever part - the AI built sensibly into the tool - and I bring the fuel. Everyone can see exactly what they're paying for.

Done well, the AI is woven into what the app is actually for and stays in step with what you're trying to do. It works for the person using it, rather than being bolted on to tick a box or grow the invoice. Who the AI is really serving is the question to ask.

How we build AI-native systems

For us it starts before the technology. The first job is to understand what the business is trying to achieve and what the people using the software are actually trying to get done, then design from there. Get the goal clear and the question of where AI belongs - and where it doesn't - gets a lot easier to answer.

From there it builds on how we already work. We've been building cloud-native on AWS for years - serverless, event-driven, managed services, infrastructure as code - and AI-native sits naturally within that. The same foundation that lets a system scale and stay maintainable is what gives a model somewhere solid to live: your own data to draw on, events to react to, and the compute to run it all without servers to babysit. Amazon Bedrock is one piece of it, letting us use a range of AI models through a single managed service, grounded in your data, with the tools and safety guardrails a serious AI feature needs. AI-native done well is cloud-native with the model treated as a first-class part of the design, rather than bolted on the side.

This is still early doors. The tools are evolving fast, which is part of what makes it an amazing time to be building.

Further reading: OWASP Top 10 for Large Language Model Applications

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

Re-platforming a live insurance book with event-sourced architecture

2026-04-13T00:00:00.000Z

What we built

Insurance platform rebuild

Published 2026

Re-platforming a fintech insurance business

Rubber Ring set out to make insurance feel like modern fintech - simple, fast and app-like. Since launching in 2020 their platform had grown and evolved: first a serverless Progressive Web App for tyre insurance, then a re-platform onto a modern, serverless JavaScript stack that brought golf, sports and new products into the fold. By 2026, to scale further - more products, more customers, and richer operations - it was ready for a new architectural foundation. We rebuilt the entire platform on modern technology and an event-sourced architecture, and migrated the live book of policies in a single, carefully planned cutover.

The challenge: modernise a working business, without disruption

The platform that preceded this rebuild was already cloud-native and serverless, and it had served Rubber Ring well. But a growing, multi-product insurance business needed more than that design could offer: a clean separation between the systems that write data and those that report on it, infrastructure defined entirely in code, far richer back-office tooling, and the headroom to add new products quickly. Left unaddressed, the older design would increasingly slow the pace of new products and cap how far the business could scale. And it all had to happen around a live book of customers, with no interruption to cover or claims.

An event-sourced architecture (CQRS)

Rather than simply refresh the old stack, we rebuilt the platform around a clear separation of concerns - known as CQRS - splitting the write side from the read side:

A single-table Amazon DynamoDB store is the source of truth for every policy, quote, customer and claim - fast and endlessly scalable.
Change data streams from DynamoDB are processed in real time and projected into an Amazon RDS PostgreSQL read model, purpose-built for querying, reporting and the admin experience.
The customer application, built with React Router 7 on Node.js, reads and writes against DynamoDB directly, giving customers a fast, server-rendered, app-like experience.
The admin application, a Laravel application (PHP) with two-factor authentication, queries the PostgreSQL read model to power policy and customer management, claims triage, reporting and a configurable pricing model.

A modern stack, containerised and defined in code

The customer and admin applications run as containers on Amazon ECS Fargate - the right home for two long-running, framework-rich apps - fronted by CloudFront and a web application firewall. Around them sits a set of serverless microservices (AWS Lambda) that each do one job well. And the entire cloud environment is provisioned with the AWS Cloud Development Kit (CDK), so every piece of infrastructure is version-controlled, repeatable and reviewable. AWS lets us run this deliberate mix of containers and serverless under one roof, with the security and compliance controls a regulated insurance business depends on.

React Router 7 on Node.js: a modern, server-rendered customer application, containerised on ECS Fargate.
Laravel admin application: a rich back-office for the Rubber Ring team, also on ECS Fargate.
Amazon DynamoDB & change streams: the event-sourced write store and the backbone of the CQRS design.
Amazon RDS (PostgreSQL) with RDS Proxy: the queryable read model behind the admin and reporting.
Serverless microservices (AWS Lambda, SQS, SNS & EventBridge): focused, event-driven and scheduled jobs - document generation, customer communications, renewals and expiries, and automated regulatory compliance screening.
AWS CDK: the whole environment defined as code across multiple stacks, with CloudFront, WAF, ACM and Secrets Manager for secure, fast delivery.

A single, planned cutover

Migrating a live insurance book is unforgiving work. We built and rehearsed a one-shot migration that transformed every existing policy into the new platform's shape, and cut the business over in April 2026.

Proving that out safely meant working with real data shapes rather than synthetic fixtures: we imported S3 backups of the live legacy DynamoDB table into Dynoxide, our own open-source DynamoDB engine, and used its anonymisation to strip customer data, so the team could dry-run the migration against production-shaped records without ever handling real customer information. Security, resilience and data integrity were designed in and proven well before that switch, so from the moment new and existing customers were served entirely by the new platform, our focus was operational tuning and refinement rather than shoring up foundations.

Results: a platform built to scale

Room to grow: adding new insurance products and features is faster and safer on the new architecture.
Clean separation of concerns: the CQRS design keeps the fast customer experience and the rich back-office reporting independent and independently scalable.
Infrastructure as code: everything is defined in CDK - repeatable, reviewable and easy to evolve.
Compliance built in: regulatory checks and back-office workflows are automated rather than manual.
A clean cutover: the entire live book migrated in a single, planned switch-over with no interruption to cover.

A partnership that keeps building

Having designed, built and evolved the platform since 2019, we were uniquely placed to re-architect it without losing the hard-won detail that keeps an insurance business running day to day. The re-platform is the latest chapter in that partnership - and with a modern foundation now in place, we continue to work with Rubber Ring to grow the business, shipping new products and improvements on an architecture built to keep up.

About Si Novi: cloud-native engineering partners

Si Novi is an AWS Select Tier Services Partner. We design, build and modernise cloud-native platforms on AWS across a wide range of industries - and we're at our best re-architecting live systems without disrupting the businesses that depend on them.

From event-sourced architectures to careful, high-stakes migrations, we help businesses like Rubber Ring move onto foundations built to scale - safely.

The best migrations are the ones you've already run a hundred times. We rehearsed this cutover against real, anonymised data until the surprises were out of it, then moved the entire live book across in one go. That's the standard a live insurance book deserves.

Martin Hicks, Principal Consultant, Si Novi

From Early AWS Adopters to Select Tier Partner

2026-03-25T00:00:00.000Z

Si Novi is now a Select Tier partner in the AWS Partner Network

We've recently been validated as a Select Tier partner in the AWS Partner Network, on the Services path. It's a milestone worth marking because it formally recognises how we've been working for a long time.

Early adoption

We started using AWS in the early 2010s, at a time when most of the projects we worked on were heading to traditional hosting providers with a single server running a web application, database and file storage all on one box. When we started exploring AWS, what struck us wasn't just that you could host things differently, it was that you could separate concerns entirely. S3 for storage, RDS for databases, EC2 for compute - each one a managed service you could rely on independently, with its own durability, scaling and lifecycle.

That's a more significant transition than it sounds. It's not just swapping one server provider for another, it changes how you approach architecture, application and business logic, deployment and scaling from the ground up.

Infrastructure evolution

How we manage infrastructure has evolved significantly too. In the early days on AWS it was console work - clicking through the AWS dashboard, configuring things manually, and doing your best to document what you'd done so you could replicate it later. CloudFormation brought infrastructure-as-code into the picture, which was a step forward, though debugging huge JSON or YAML templates could be frustrating. But the shift that's made the biggest difference for us has been AWS CDK, where we can define infrastructure in real code, with the expressiveness and reuse that brings.

Founding Si Novi and choosing serverless

When we founded Si Novi in 2018, we made a conscious decision to add serverless application development to our practice, using Lambda and DynamoDB. That was a natural extension of our experience with AWS and the direction we were already heading in. Serverless felt like the next step in the evolution with even more managed services, more abstraction, and an even greater emphasis on building applications without worrying about the underlying infrastructure.

Serverless structures aligned perfectly with our approach to building well-architected systems that could scale and evolve over time, and put more tools in our hands to choose the right components for each client project.

In the years that followed we began to blend serverless with event-driven architectures and containerised workloads, building applications which draw on the whole ecosystem of AWS services. A web-based application is no longer an app on a server - it's a system built on cloud infrastructure.

Shaped by client work

This evolution over 10-15 years has been shaped almost entirely by our client work. The systems we build have become more ambitious as the AWS platform has matured, and as our clients' needs have grown.

The work now involves well-architected systems with clear separation of concerns, managed services where they make sense, and infrastructure that can scale without requiring a rethink every time something changes.

Many of our clients have been with us for years, and their platforms have evolved alongside our approach. That long-term relationship is a big part of how we've got here.

Becoming a partner

Becoming a partner grew out of all this quite naturally. We've been attending AWS events for years - summits, partner days, community meetups - and engaging more closely with AWS teams along the way. At a certain point, formalising the relationship just made sense.

The Select Tier validation isn't a case of signing up, but rather it requires demonstrated client workloads, ongoing revenue, technical certifications, and accreditations across the team and the wider network we work with. Meeting those requirements felt less like reaching for something new and more like a recognition of what was already in place.

What it validates, more than anything, is consistency.

We've been building and supporting web applications on AWS for over a decade. Not proofs of concept or short-lived experiments, but production systems that businesses rely on - the kind of systems where decisions made early on have a long tail, and where getting the fundamentals right at the start genuinely matters. That's been our focus throughout, and this is an external confirmation of it.

What it means for our clients

For our clients, the day-to-day doesn't change. Same team, same approach, same focus on building things well and then staying involved to support and evolve them over time. What the partnership does provide is a closer alignment with AWS, and better access to partner programmes, support resources, and the ability to engage more directly with AWS where it benefits a project. The fundamentals remain exactly as they were with our passion for technology and the web brought to life on the AWS platform.

We didn't set out to become a partner. We set out to build good systems on AWS, and this is where that's led.

View our AWS Partner Network profile: https://partners.amazonaws.com/partners/0018a00001oDg3GAAS/Si%20Novi%20Limited

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

High availability strategies for web applications on AWS

2026-03-02T00:00:00.000Z

Designing for the moment your website actually gets attention

There is a very predictable pattern every time a founder walks into Dragon's Den. The pitch lands, thousands of people reach for their phones to Google the business and within minutes the site is either crawling or completely gone. It gets blamed on 'too much traffic', as if success itself broke the thing, when in reality the infrastructure was probably only ever designed for a quiet Tuesday afternoon.

Lately I've noticed more and more sites that just feel... tired. Slow to respond, occasionally throwing a 502, sometimes fine, sometimes not. In many cases it is not a dramatic failure, just a system running close to the edge because it was never designed with peaks in mind, or because it is sharing infrastructure with who-knows-what, or because it is quietly serving a steady stream of bot traffic that nobody has really taken seriously.

High availability is not about ticking a box that says 'multi-az enabled'. It is about stepping back and asking how this thing behaves when real life happens.

Start with the business model, not the instance size

Before we talk about ECS clusters or Lambda concurrency, we talk about the business. When does traffic spike? Is it predictable, like race weekends or product launches, or is it chaotic and campaign-driven? Does traffic double on a Friday afternoon newsletter, or is it a steady hum all week and then madness once a month?

Designing around the average is usually the mistake. Systems do not fail on average days. They fail on peak days, and peak days are often entirely foreseeable if you look at the commercial model rather than the CPU graph.

If you know that 80 percent of your revenue lands in a tight window, then your infrastructure should reflect that. Autoscaling policies can be tuned around known patterns, capacity can be biased toward expected surges, and testing can focus on the moments that matter rather than some artificial steady state that never really happens.

Elasticity is powerful, but only if the app allows it

On Amazon Web Services, scaling out is mechanically straightforward. ECS will happily run more tasks, whether on EC2 or Fargate. Lambda will spin up additional executions at an impressive rate. The cloud is not usually the bottleneck.

The application often is.

If session state is tied to a single container, horizontal scaling becomes awkward. If health checks always return 200 even when the database is on fire, the load balancer has no idea anything is wrong. If the database connection pool is undersized, doubling your task count may simply move the bottleneck from CPU to connection exhaustion.

With Lambda, concurrency can scale rapidly, but downstream systems still have limits. A burst of invocations hitting a relational database with tight connection caps can cause more harm than good. In those cases we tend to introduce queues, limit concurrency deliberately, or move expensive work out of the request path altogether.

Elasticity works best when the application is stateless, decoupled and designed to share load cleanly across multiple instances and availability zones.

High availability is not about ticking a box that says 'multi-az enabled'. It is about stepping back and asking how this thing behaves when real life happens.

Unwanted traffic is still traffic

One of the more sobering realisations for many clients is how much of their traffic is not customers at all. It is bots scraping content, automated scanners wandering through random URLs looking for something exploitable, scripts poking at old WordPress paths on a stack that has never seen WordPress, and the occasional overenthusiastic client retrying failed requests in tight loops until something gives.

Left unchecked, your application will serve all of it quite happily.

This is where WAF and CloudFront earn their keep. Managed rule sets take care of a lot of commodity attack patterns. Rate-based rules allow you to say, calmly and automatically, that 400 requests per minute to a login endpoint from a single IP is not normal behaviour. Bot control lets you distinguish between genuine search engine crawlers and suspicious automation so that you can treat them differently rather than blocking blindly.

We often add pragmatic rules around excessive 404 responses as well. If a client is requesting dozens of non-existent paths in quick succession, that is rarely someone browsing politely. Blocking that at the edge means the request never reaches your containers, never opens a database connection, never consumes application CPU. It is a small decision that adds up quickly.

High availability is partly about capacity, but it is also about refusing to waste it.

Build for scale by offloading aggressively

A common anti-pattern is letting the application server do everything. Serving large images, streaming downloads, rendering identical responses repeatedly for anonymous users, performing heavy computations inline with web requests. It works when traffic is low, then creaks under load.

Static assets belong in S3, fronted by CloudFront. That single move can remove a surprising amount of pressure from the origin. Assets are cached at the edge, delivered closer to users and scaled automatically. Your containers can then focus on actual application logic rather than acting as a file server.

Background processing should be decoupled from user-facing requests. Queues absorb spikes. Workers process jobs at a controlled rate. Managed services such as RDS, ElastiCache and S3 are designed to scale in ways that a single VM simply is not.

The more work you can push to services that are effectively 'limitless' from your perspective, the more headroom your core application retains when traffic surges.

Caching is where performance is won or lost

Caching tends to be either ignored or overused.

At the edge, CloudFront can cache not just assets but API responses and even full HTML pages. For content that does not change per user, this can reduce origin load dramatically. But cache keys need care. Forget to vary by query string or header and you may serve the wrong thing. Cache personalised content and you create problems that are far worse than a slow page.

For content-heavy sites, short-lived HTML caching for anonymous users can transform performance. A page that would normally execute several database queries and render templates becomes a simple cache lookup for the majority of traffic. Multiply that by thousands of requests and the impact is obvious.

At the application layer, Redis is invaluable for session storage and frequently accessed lookups. It reduces database pressure and smooths out spikes. But cache invalidation still needs thought. Expiry times, write-through strategies and fallback behaviour when the cache is cold all matter. Cache should accelerate a well-behaved system, not hide an inefficient one.

If your website collapses the moment it receives attention, that is not success exposing a flaw in the cloud. It is a design that never expected to succeed.

Resilience across availability zones

Single availability zone deployments are cheaper and simpler, right up until they are not.

We generally deploy across at least two zones, with load balancers distributing traffic and replacing unhealthy targets automatically. Databases are configured for multi-az where the business case justifies it, so that failover is automatic rather than a panicked manual exercise.

The aim is not perfection, it is resilience. When something degrades, traffic shifts. When an instance fails, another takes its place. Users ideally do not notice.

In summary

High availability is not magic and it is not a single feature toggle. It is the accumulation of sensible, sometimes unglamorous decisions:

Understand real traffic patterns and design for peaks, not averages
Scale horizontally with proper guardrails around databases and downstream systems
Filter and rate limit unwanted traffic at the edge
Offload static and heavy work to services built to scale
Use caching carefully and deliberately
Monitor the system so you can see problems before users do

If your website collapses the moment it receives attention, that is not success exposing a flaw in the cloud. It is a design that never expected to succeed.

When done properly, a traffic spike should feel almost boring. Instances scale out, caches warm up, unwanted traffic is filtered quietly at the edge and users simply carry on. That kind of boring is exactly what you want.

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

AWS Lambda Node.js 18 and 16 end of support: March 2026

2025-10-29T00:00:00.000Z

AWS extends Node 18 and Node 16 support - what this reprieve means

If you were gearing up for AWS Lambda to pull the plug on Node.js 18 and Node.js 16 this week, you can breathe - but only a little. AWS has announced a new date: 9 March 2026. The 1 November cutoff has officially been pushed back by four months. A stay of execution, then - not a pardon.

AWS quietly updated its Lambda runtimes documentation in August 2025 to reflect the new March 2026 deadline. The change effectively gives everyone a bit more breathing space, but it doesn't change the outcome: Node 18 and 16 are still heading for retirement.

For those who've spent the last fortnight frantically auditing functions, this is welcome news. For everyone else, it's a reminder that AWS can (and will) change course, but the end result is the same. These runtimes are still on borrowed time.

So rather than tearing up the migration checklist, keep it open. The extra time is there to test, not to procrastinate!

What actually happens now

AWS has essentially hit snooze on the final phase of the Node 18 and 16 deprecation plan. Here's the updated picture:

September 2025: AWS stopped releasing patches for Node 18. No more bug fixes or performance updates.
October 2025: New function creation using Node 18 / 16 disabled in the console and APIs.
9 March 2026: The hard stop. From this date you won't be able to update, redeploy or modify existing functions using those runtimes.

The illusion of "it still works"

The tricky part of these runtime deprecations is that, on the surface, nothing breaks immediately. Your users won't see errors, dashboards won't flash red, and your automated monitoring probably won't flag anything. It lulls teams into thinking they can postpone the work. But this is one of those rare moments where inaction quietly increases risk every day.

Unsupported runtimes are more than a theoretical problem. Once Node 18 and 16 fall off the patch cycle, any new vulnerabilities discovered in the Node core or dependent libraries remain unpatched. For functions that process customer data, interact with AWS services, or connect to public APIs, that's a material security exposure. Auditors and cyber teams will spot it quickly, and regulators increasingly view unsupported environments as a compliance failure.

Even if security isn't your main concern, there's a reliability angle. Lambda itself continues to evolve behind the scenes. Over time, infrastructure updates or changes in AWS's internal execution environment can cause older runtimes to behave unpredictably. It doesn't happen overnight - but when it does, you won't get support for it.

Why this isn't just a developer problem

CTOs, engineering directors and founders often underestimate how many small but critical systems depend on Lambda. It's the unsung hero behind automation, cron jobs, image resizing, S3 triggers, and internal APIs. These are the "set and forget" functions that quietly power your operations. Because they require no infrastructure management, they tend to go untouched for years - until something like this deadline brings them back into view.

In a typical SME environment, you might find dozens of small Lambda functions scattered across multiple AWS accounts. Some run every minute, others only on specific events. They all need reviewing. Treat this like a digital MOT: the sooner you inspect them, the less likely you'll be caught out when one stops behaving after an AWS change next spring.

Node 22 is the new standard - but it's not a quick switch

The newest supported runtime is Node 22 and is a likely candidate for upgrading legacy functions. On paper, that sounds simple - change the runtime setting, redeploy, done. In reality, it rarely goes that smoothly.

Functions built years ago on older Node runtimes tend to come with older npm packages. Some of those dependencies may have since been deprecated, changed APIs, or dropped Node 20+ compatibility altogether. In many cases, the runtime upgrade exposes these buried issues. Code that once compiled fine on Node 14 or 16 can suddenly fail because of stricter syntax checks, ES module changes, or transitive dependency mismatches.

So each function should be evaluated. Review its dependencies, rebuild its package-lock file, and test locally under Node 22 before deploying. The aim isn't just to "get it running", but to ensure the entire dependency chain is healthy and supported. If you're using a CI/CD pipeline, now's the time to add automated tests that run against the new runtime - not just unit tests, but integration checks that confirm AWS service calls still behave as expected.

The AWS SDK surprise - v2 is gone

One significant change is that the AWS SDK for JavaScript v2 is no longer included in the Node 20 runtime. For years, AWS shipped v2 as part of the runtime, so you could simply write:

const AWS = require('aws-sdk');
const s3 = new AWS.S3();

That's no longer the case. Node 20 only includes AWS SDK v3, which is modular and imported per service. It looks more like this:

import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client();

The change is positive in the long run - v3 loads faster and reduces cold start times - but it means older functions won't work without adjustment. If you're still using v2, you'll need to either include it in your deployment bundle or refactor your code to v3 syntax. Including v2 manually works as a stopgap, but refactoring is cleaner and avoids future runtime surprises.

For larger teams, this is a good opportunity to standardise on v3 across the codebase. It simplifies dependency management and aligns with AWS's own documentation going forward.

Finding what's affected

The easiest way to see which of your Lambda functions still use deprecated runtimes is through the AWS CLI. Run this for each region:

aws lambda list-functions \
  --region eu-west-2 \
  --query "Functions[?Runtime=='nodejs18.x' || Runtime=='nodejs16.x'].FunctionName"

Alternatively, you can use Trusted Advisor or the AWS Health Dashboard which now highlights deprecated runtime usage across your organisation. The Health event includes a list of affected functions by name and region - worth reviewing even if you think everything's up to date. Forgotten test environments and legacy staging stacks are often where these old functions hide.

For businesses with multiple AWS accounts, it's wise to script the discovery process. Loop through all accounts via AWS Organizations or a central credentials profile and generate a simple report. It's not glamorous work, but it's better than a support call from a client wondering why their nightly export job hasn't run for two days.

Practical migration strategy

Once you've identified affected functions, follow a structured plan:

Audit: List every function still running Node 18 or 16. Include its triggers (S3, API Gateway, EventBridge, etc.) and dependencies.
Assess: Note which ones handle sensitive data, customer-facing workloads, or high-volume traffic. Prioritise those first.
Test locally: Run each function under Node 22, installing dependencies fresh. Resolve compatibility issues early.
Refactor: Update AWS SDK usage and replace deprecated npm packages. Consider upgrading to ES modules if appropriate.
Redeploy: Once tested, deploy to production using Node 22. Monitor logs closely for the first 24 hours.
Automate: Add a runtime check to your CI/CD pipeline so future deployments can't accidentally use old runtimes.

Treat this not as a one-off patch but as an opportunity to tighten your development process. Runtime upgrades tend to expose where the gaps are - missing documentation, untested code paths, or inconsistent packaging workflows.

What if you do nothing?

The honest answer: nothing dramatic, at first. Your functions won't suddenly stop running on 9th March. But from that day onwards, you'll be locked out of making any modifications, and over time that turns into operational risk.

AWS will eventually remove support entirely, and while they rarely pull the plug abruptly, history suggests they will start restricting functionality more aggressively in 2026. When that happens, upgrading late will become more painful because the code will have drifted even further from current standards.

If your Lambdas still run Node 18 or Node 16, the best course of action is clear: upgrade them to Node 22, retest, and redeploy before the March lockout hits. Don't assume it's a quick runtime flip - evaluate each function, check dependencies, and modernise where needed.

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

Duwio: A cloud-native platform for image management

2025-10-29T00:00:00.000Z

What we built

Cloud-native SaaS platform

Published 2025

Visit project websiteOpens in a new tab

About Spacesuit Media

Spacesuit Media is a specialist photography and film-making agency working across international motorsport - including Formula 1, Formula E, IndyCar and the British Rally Championship - and other global events. Its in-house software platform, Spacesuit Collections, had become an indispensable tool for delivering and managing large volumes of imagery across multiple clients and teams.

The opportunity for evolution

With almost a decade of success behind them, Spacesuit wanted to take the next step - to evolve their proven concept into a full SaaS product. Duwio would offer dedicated workspaces for subscribers, modern collaboration tools, and a fresh user experience, all underpinned by a scalable and secure cloud architecture.

The challenge

Creative teams were stuck between consumer tools like Dropbox, Google Drive and WeTransfer - none built for high-volume image workflows - and enterprise DAM platforms with enterprise price tags. Rebuilding a mature application as a multi-tenant platform required more than a design refresh. The system needed to handle isolated data per workspace, user roles and permissions, real-time collaboration and global content delivery - without introducing complexity or performance overheads. At the same time, Spacesuit wanted a foundation that could grow to include new media types such as video and design assets.

Partnering for transformation

Our previous work with Spacesuit Media had laid the groundwork for both the collaborative relationships and the technical discovery required to wholistically understand the project and the business goals.

Si Novi worked alongside Spacesuit's core team - Ross (Managing Director), Adam (Designer & Operations) and Jamie (Compliance & Security) - to design both the product experience and the technical framework. Spacesuit Media leaned on our AWS Partner status and extensive AWS experience, with our role combining software engineering, AWS architecture and long-term cloud strategy, guiding the business from traditional hosting to a resilient, automated AWS environment.

Our Solution

Duwio was built as a cloud-native application using the AWS Well-Architected Framework as its guide. Inheriting its core from the original Spacesuit Collections application, the platform runs a containerised PHP stack on Amazon ECS with Amazon RDS for MySQL providing reliable data storage. Assets are served through Amazon S3 with an authenticated Amazon CloudFront CDN, ensuring fast, secure delivery to global audiences.

Amazon ECS for containerised application services and managed scaling.
Amazon RDS (MySQL) for relational data and workspace isolation.
Amazon S3 + CloudFront for deduplicated, high-speed media delivery.
AWS Lambda for background automation such as metadata extraction, thumbnailing and user event notifications.
AWS Backup for cross-region and cross-account protection and recovery of both RDS and S3 data.
AWS CloudTrail for auditing and continuous security visibility.

Designed for creative workflows

The new interface prioritises clarity and flow: tagging and folder organisation feel effortless, previews respond instantly, and every workspace has its own secure customer area for gallery delivery. Role-based permissions make collaboration straightforward, letting photographers, editors and assistants work together safely under one account.

Results and early feedback

Duwio is now live and trusted by global brands including Nissan, Envision Racing and OX Delivers. Spacesuit Media have migrated their entire archive of 600,000 high-res images onto the platform, and users have praised its simplicity, performance and visual cohesion. The AWS foundation allows Spacesuit Media to onboard new clients with confidence while maintaining strict security and performance standards.

What's next

Si Novi continues to support Spacesuit Media as Duwio grows - adding billing automation, advanced reporting and expanded media support. The platform's architecture is designed to scale gracefully as the customer base and content volume increase.

We're so confident in Duwio that we made Spacesuit the ultimate test case. We've moved our entire archive of 600,000 high-res images from our legacy platform into a Duwio workspace. Duwio really is a better way to manage images.

Ross Ringham, Managing Director & Duwio Founder, Spacesuit Media

Amazon RDS MySQL 8.0 deprecation and Extended Support

2025-07-28T00:00:00.000Z

Database Management

AWS has announced that Amazon RDS for MySQL 8.0 will reach end of standard support on July 31, 2026, following the MySQL community's end of life timeline. This affects all RDS MySQL 8.0 database instances and requires immediate planning for either migration to a newer version or transition to Extended Support.

The MySQL community will stop providing bug fixes and security patches for MySQL 8.0 in April 2026, and AWS follows this community timeline for their managed database services. This means organisations running MySQL 8.0 on RDS must make important decisions about their database strategy.

As an AWS Partner supporting clients with RDS MySQL deployments, we're already helping them plan upgrades or manage the transition to Extended Support - ensuring there's no disruption and no surprise costs.

MySQL 8.0 end of life timeline

The key dates for MySQL 8.0 deprecation are:

April 2026 - MySQL community ends support for MySQL 8.0, no more bug fixes or security patches
July 31, 2026 - Amazon RDS ends standard support for MySQL 8.0
August 1, 2026 onwards - MySQL 8.0 available only under Amazon RDS Extended Support (additional charges apply)

Understanding extended support costs

Extended Support allows you to continue running RDS MySQL 8.0 beyond the end-of-life window - but it comes at a price. From 1 August 2026, AWS will apply per-vCPU-hour charges based on your instance size:

Duration	Cost per vCPU-hour, eu-west-2
Year 1 & 2	$0.118
Year 3	$0.235

For example, a 4-vCPU instance would cost an additional $676.80 a month in Year 3 - and that's just one database. These charges apply to each provisioned RDS instance running MySQL 8.0 under Extended Support - so if you're multi-AZ then it's double the cost.

While Extended Support can be a lifeline for critical applications, it is not a long-term solution. The costs can quickly add up, especially for larger instances or multiple databases. We recommend planning your migration to a newer MySQL version as soon as possible to avoid these charges.

Why extended support is not a long-term solution

Extended Support is designed to provide temporary relief, not a permanent fix. It allows you to continue using MySQL 8.0 while you plan your migration, but it does not address the underlying issues of running an unsupported database version:

Security Risks: No security patches means increased vulnerability to exploits.
Compliance Issues: Many regulations require running supported software versions.
Performance Limitations: Newer MySQL versions include performance improvements and features that are not available in 8.0.

Furthermore, Extended Support is only available for a three year period following deprecation of the database version. In short, Extended Support is a stopgap measure. It buys you time to migrate, but it does not provide a sustainable solution for your database needs.

Cost vs value of Extended Support

When considering Extended Support, it's important to weigh the costs against the value it provides. While it may seem cheaper than an immediate migration, the long-term costs can be significant.

In comparison the costs of migrating to a newer MySQL version may be higher upfront, but they can lead to greater savings in the long run by eliminating Extended Support fees and providing access to new features and optimisations. A typical investment for SME's may range from hundreds to a few thousand pounds, depending on the number and complexity of RDS MySQL instances and dependent applications.

Migration options and strategies

MySQL 8.4 (a Long-Term Support release) is already available on RDS and will be the natural upgrade path for most users. AWS may also support MySQL 9.x or beyond by the time the deadline arrives.

Strategies for replacement will depend on your specific use case and requirements. Consider factors such as application compatibility, downtime tolerance, and resource availability when planning your migration.

A database that's used as a read-only data source will be easier to migrate, however in cases of typical web applications a more comprehensive approach will be needed including pausing or queuing writes during the migration process.

Planning your database upgrade

If you're unsure what version of MySQL you're running in AWS, now's the time to find out.

Here's what to do:

Audit your AWS estate: Identify any RDS instances running MySQL 8.0, and check which apps depend on them.
Evaluate downtime tolerance: Can you afford a short outage, or is a Blue/Green deployment a better fit?
Test the upgrade: Take a snapshot, try the upgrade in a staging environment, and time the process.
Set a deadline: Aim to upgrade by early 2026 - well before AWS forces your hand.

If you rely on a consultancy to manage your AWS setup, this is something they should already be raising with you. If not - we'd be happy to help.

Read more about Amazon RDS Extended Support: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support-charges.html

AWS MySQL on RDS: https://aws.amazon.com/rds/mysql/

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

Bringing every SRO championship into a single cross-platform app

2025-07-02T00:00:00.000Z

What we built

React Native mobile app

Published 2025

Every SRO championship, in one app

SRO Motorsports Group run GT racing across four continents, but their previous app covered Europe alone. Working with design partner Whiteflame, Si Novi built a single app for iOS and Android that brings all of SRO's championships together - live video, timing, schedules, team data and race reminders each fan can tune to the series they follow - and that holds up when a race weekend puts the whole audience on it at once.

The GT World app brings live coverage, schedules and content from across SRO's motorsport ecosystem into one place, replacing the previous Europe-only GT World Challenge app. It covers:

GT World Challenge in Europe, America, Asia and Australia
GT4 championships across the UK, Europe, America and Australia
TC America and other regional series

SRO, with design partner Whiteflame, commissioned a complete rebuild to match the scale of its international championships. Si Novi was brought in for the engineering and infrastructure: turning a spread of separate series data and broadcast feeds into one coherent mobile app.

About SRO Motorsports Group

SRO Motorsports Group is a global leader in GT racing, behind some of the most competitive GT3, GT4 and touring car championships in the world. Its events span four continents and a large international following, live and online.

Launched at the CrowdStrike 24 Hours of Spa

The app launched during the CrowdStrike 24 Hours of Spa, one of motorsport's great endurance races, held at Circuit de Spa-Francorchamps. It is one of the busiest weekends in SRO's calendar, which made it both the obvious stage for the launch and a real test of the app under load.

The engineering challenge

SRO do not run one championship, they run around sixteen, and each has grown up with its own separate data system. The app had to pull all of that into a single, consistent experience, run on both iOS and Android from one codebase, keep responding when a fan is in a grandstand with barely any signal, and stay fast on a race weekend when the whole audience opens it at once.

Why SRO partnered with Si Novi

Si Novi was chosen for our record building fast, cloud-native applications on AWS, and for working closely with design teams. Many SRO series are already sponsored and powered by AWS, and SRO's existing content systems run in the same AWS estate, so fitting a new serverless application in alongside them was familiar ground. We took the app from concept to release with Whiteflame, across engineering, architecture, testing and deployment.

How we built it

One codebase, both app stores

The app is built with React Native through Expo, so a single codebase produces both the iOS and the Android version. We worked from Whiteflame's Figma designs, building them into a reusable component library so the two apps stay visually consistent and design and engineering could move in step. The interface is tuned to render without the jumps and reflows that make an app feel cheap, and to scale cleanly from small phones up to tablets. Because it runs on Expo, we can push updates to the JavaScript layer over the air, and the app checks for them both on launch and each time a fan reopens it, so a fix reaches people without waiting on an app-store review.

Built to keep working when the signal drops

Grandstands and paddocks are not known for their mobile coverage. Every screen reads through a two-tier cache - an in-memory layer over on-device file storage, indexed so a lookup is a single quick check rather than a scan - and falls back to the last data it holds whenever the connection is missing or a request fails. In practice the app keeps showing schedules, standings and team data whether or not there is a usable signal.

Race reminders each fan tunes themselves

A fan following British GT does not want alerts for a series on another continent. Each person chooses the championships they care about and how much warning they want before a session - an hour, fifteen minutes, five - and the app turns those choices into the exact set of notifications it subscribes them to. The same choices filter the content they see.

On the backend, every reminder for every upcoming session is worked out in advance and filed by the minute it needs to go out. Once a minute, a small job asks for everything due right now and sends it. That makes reminding a hundred thousand fans about a session start as cheap as reminding ten, and costs almost nothing between race weekends.

Sixteen feeds behind one clean app

Behind the app, a scheduled process reaches out across all of SRO's separate championship systems, normalises what comes back, and writes it into one store the app reads from cleanly. Each item is fingerprinted so unchanged data is left alone and only genuine changes are written, and anything removed upstream is cleared out. The app talks to one tidy, consistent feed instead of sixteen inconsistent ones.

Ready for race day

The whole backend is serverless, so it scales with demand and costs little when nothing is racing. In front of it sits a short cache: when thousands of fans refresh the standings within the same few seconds, they are served the same cached response instead of every request reaching the origin. Live video comes through the series' existing YouTube broadcasts, embedded in the app with the different-language commentary feeds, and the live timing screen brings in SRO's timing provider, so the heavy real-time work stays with the systems built for it.

Features at a glance

Live video and replays (subject to region availability)
Live session timing and status
Detailed team and driver directories
Event calendar with circuits, schedules and links
News and video content across all GT World series
Push reminders each fan sets per series and per session

The outcome

The app launched at Spa to strong early adoption, and gave SRO a single place for fans of every one of its championships, on either kind of phone. For SRO it is one digital home for a growing, international audience. For us it is a good example of taking a project with several moving parts - the rights holder, the design studio and a spread of upstream data systems - from architecture through to a release on both stores.

Who we are: Si Novi

Si Novi designs and builds secure, scalable applications and runs them for the long term. As AWS specialists and mobile app developers, we work with clients and their creative partners to take ambitious products from idea to release, across platforms and time zones.

This all new app replaces the highly successful GT World Challenge Europe app delivering content from across the GT racing world. It's the complete GT World experience.

SRO Motorsports Group

Exportable SSL Certificates from AWS ACM

2025-06-17T00:00:00.000Z

AWS Certificate Manager now supports exportable SSL certificates

In June 2025, AWS announced a long-awaited update to AWS Certificate Manager (ACM): the ability to request exportable public SSL/TLS certificates. This brings significant flexibility for organisations that want to standardise certificate management through ACM, even beyond the AWS ecosystem.

Previously, ACM-issued certificates were restricted to use with AWS-managed services such as CloudFront, Elastic Load Balancing, and API Gateway. This limitation meant teams with hybrid infrastructure or external dependencies needed to source certificates elsewhere - typically via Let’s Encrypt or commercial certificate authorities.

With this update, AWS has positioned ACM as a viable alternative for managing public-facing certificates across diverse environments.

Key capabilities

Exportable ACM certificates now support:

Standard domain validation (FQDN or wildcard)
Private key export in encrypted PEM format
Full trust chain download, including intermediate certificates
13-month validity with managed renewal
Secure key access, governed by IAM policies and audit logging

These certificates are issued by Amazon Trust Services, rooted in widely trusted certificate chains and recognised across all major browsers and operating systems.

Pricing for AWS ACM exportable certificates

The exportable certificate model is based on charge per domain, applied at issuance and renewal:

Certificate type	Price per renewal cycle
Fully Qualified Domain (`example.com` or `api.example.com`)	$15 per domain
Wildcard Domain (`*.example.com`)	$149

This pricing structure makes ACM cost-effective for environments with a modest number of domains, while wildcard certificates are well-suited for large-scale or subdomain-heavy deployments.

However, bear in mind that for a typical website, you might want to run the www subdomain and the non-www version (with a redirect from one to the other), so that's two FQDN's and a base price of $30.

Also, the wildcard cert doesn't include the apex domain (example.com) so that's $15 on top of the $149 if you need the apex and all subdomains.

But, the prices are comparible to other commercial TLS certificate issuers and the ease of use through the ACM API and AWS SDK ecosystem brings additional value.

Practical applications

This enhancement is particularly beneficial for:

Hybrid infrastructure: Use the same certs across on-prem, AWS, and other cloud providers.
Self-managed environments or legacy apps not integrated with ACM : apps running on EC2 or containers that don't use ALB or CloudFront but still need HTTPS - now you can issue certs centrally with ACM.
Third-party systems: Apply ACM-managed certificates to external CDNs, proxies, or hosted platforms that support manual certificate upload.

By consolidating certificate management under ACM, organisations can reduce operational risk, improve renewal workflows, and ensure consistent security policies.

Considerations

Exportable certificates must be requested specifically as exportable - standard ACM certificates remain non-exportable and limited to AWS services.

The certificate, trust chain and private key are retrievable through secure, authenticated API requests and - making it suitable for controlled use in CI/CD pipelines or deployment workflows where certificates need to be programmatically rotated and deployed.

Managed renewal requires re-exporting the new certificate upon renewal, which can be automated using the ACM API.

Conclusion

This is a significant step forward for ACM, making it a practical certificate authority not just for AWS-native workloads but for the broader infrastructure landscape. It offers teams a consistent, secure, and reliable way to issue and manage SSL/TLS certificates across environments, while remaining under AWS governance and audit controls.

If you're exploring a more unified approach to certificate management - especially as part of a broader AWS migration or infrastructure modernisation - this new capability may come in handy.

Read more about AWS Certificate Manager exportable certificates on the official blog: https://aws.amazon.com/blogs/aws/aws-certificate-manager-introduces-exportable-public-ssl-tls-certificates-to-use-anywhere/

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

AWS Summit London 2025: From meh to wow

2025-05-29T00:00:00.000Z

AWS Summit London, 2025

This year was different. And incredible. In many ways.

The reasons? Twofold:

As an AWS partner now we extended our trip to include the Partner Summit
The Customer Summit itself was off the charts

I'll discuss the latter first.

We've been attending the AWS Summit London for years and it's become an annual highlight for Martin and I to break away from the coal face of software engineering and expand our minds at the summit.

In recent years though I've been getting increasingly "meh" about the summits. Yes I always find it refreshing and inspiring to be there, there's always nuggets of useful insight and it's a really good way to refocus on the business rather than delivery. The summit trip is pretty much our AGM with opportunities for Martin and I to discuss the business: strategy, technology and plans for the year.

But last couple of years I've had some gripes… last year in 2024 was unpleasantly busy and the logistics of moving around the spaces was nigh on impossible. The keynote queue was out of control. The security gates were a terrifying bottleneck. The queues for breakout sessions and horribly slow scanning of passes meant that sessions were missed. Everything was about AI but without any actual real use-cases. Plus, with many of the sessions at an introductory technical level we were starting to feel like we had outgrown the customer summit. And the food was dreadful (it's free I know, but still…).

However. I always fill in the feedback forms, and this year it really feels like the summit team sat down with my feedback in front of them and pointed at it:

This guy… this guy speaks the truth. For 2025 we do all these things."

Every single gripe I had was smashed out of the park.

Keynote

The AWS Summit London keynote was a breath of fresh air with the main auditorium set up like a theatre in the round with a cube screen in the middle and no stage... Cue lots of murmuring about what was about to happen and where the speakers would stand.

Well... the house lights dimmed and music, dancing, lights and atmosphere kicked off an F1 season launch style intro, with the cube lifting up to reveal the stage. What followed was a superb keynote series from the various speakers.

The keynotes were shorter, more direct and some of the client testimonials were stunning - particularly Untold Studios whose portfolio was incredible and whose videos captured everyone's attention. The audience thinned out during the FinOps case studies at the end, perhaps a combination of the drier subject matter and the temptation to head out to the Expo, breakouts or Workshops.

I enjoyed the keynote this year and it was well worth being in the main auditorium for the experience.

Organisation / Logistics / Layout

Given the growth and success of the summit and the crushes last year, AWS solved this by going big on the venue. Soon there won't be anything left of the Excel in April because AWS will use it all. The summit layout was vast. Completely reorganised from last year, the first clue was that security was completed at the entrance to the Excel - once you were in, you were in. No mad queues for scanners or bag checks every time you wanted to move around.

The new layout of the Expo on the south side and the AWS areas on the north side - with the breakout theatres equally split - made for easy navigation and a different feel to each area.

The Expo area was busier and noisier, with the usual mix of ISV stands and the AWS Village attractions such as Ask an Architect. There were expanded demo spaces for chats with AWS teams on subjects like Data & AI, Modernisation and Security, plus a range of small open theatres for lightning talks. One issue here was that the small theatres were often oversubscribed and additional wireless headsets would have been used by the many standing attendees that didn't have a seat. Positioned at the entrance from the registration checkin, this side of the London Summit was really buzzing throughout the day.

The AWS areas on the north side by contrast were airier, more open and calmer, featuring plenty of areas to sit, gather and drink coffee. The sustainability hub was over here, and down in the ground floor the usual fun stuff - AWS DeepRacer, football penalties and this year a Gladiators-style travelator challenge (I was not tempted, at my great middle-age I'd just do myself an injury).

The wifi worked, the scanning of passes was quick and efficient, it was comfortable moving around.

There was no specific "lunch time" as the sessions all overlapped across 12-2pm which meant there was less of a rush for food or space to eat it. And the food was great - just simple sandwiches and pasta salad in easy to manage boxes. Perfect.

I really have to congratulate the organisers and the people who made it all work on the day.

Breakout Sessions

While AI was still a big focus in 2025, I felt there was a much better balance of AI sessions together with "traditional" cloud tech. What's more, the AI sessions - with the technology and adoption being a year older (and what a year!) - the sessions on AI were relevant, applied to real use-cases and could be directly implemented.

There were three breakout sessions that really captured my attention:

Investigate operational issues faster with AI

Delivered by Satya Konathala and Alex Livingstone from AWS this session focused on using Amazon Q Developer alongside CloudWatch and Systems Manager to triage and resolve live operational problems more quickly - with AI doing much of the heavy lifting.

The session demonstrated how Amazon Q can analyse observability data, including metrics, logs, and AWS config information, to automatically generate hypotheses for root causes. Crucially, it doesn't stop there: Q then recommends tailored remediation steps using AWS's curated runbooks, and can bring these suggestions into Slack through the Amazon Q Developer app, making it directly actionable within the team's existing workflows.

From a practical point of view, aside from actual coding this was one of the more convincing examples of AI assisting engineers. Drawing data from your actual application, environment and AWS's own operational best practices to provide insight looks powerful.

For us at Si Novi, this aligns neatly with how we deliver support and maintenance retainers for client applications. We're often tasked with investigating production issues that arise after deployment, and traditionally this means sifting through CloudWatch logs, infrastructure config, and event trails. The ability to accelerate that investigation with AI tooling and generate informed hypotheses in seconds is something we're actively exploring for clients.

AWS infrastructure as code: a year in review

This session - led by Varvara Semenova, Jonah Craig, and Brian Long - offered a strong update on the evolving landscape of Infrastructure as Code (IaC) on AWS. It covered best practices and new tooling across CloudFormation, CDK, and supporting tools like Cloud Control API, showing how they're enabling faster, safer deployments.

The section on Optimistic Stabilisation was fascinating to understand more about the underpinnings, mechanisms and critical paths within the black box of CloudFormation, and how this optimistic strategy is speeding up infrastructure deployments.

The case study was interesting, from Tines - a startup now at unicorn level with a highly automated IaC workflow. Their demo showed an AI assistant using the Cloud Control API to query the live state of AWS resources and propose updates, which were then committed as a GitHub pull request based on the existing CloudFormation templates. It was a neat example of AI + IaC in action - not magic, but genuinely useful for their team.

This talk was especially relevant for us at Si Novi. We've used CloudFormation extensively for years to provision and manage client infrastructure and in the last 12-18 months have increasingly adopted AWS CDK as our default approach for new projects. CDK gives us the expressiveness and reuse of real code, while still deploying safely through CloudFormation under the hood.

What's clear is that modern IaC isn't just about YAML or JSON anymore, it's about integrating your infrastructure lifecycle with version control, review workflows, and now even intelligent tooling. And that aligns perfectly with how we manage client infrastructure today: Git-driven, automated, and consistent.

We'll be exploring more around Q Developer and the Cloud Control API and how they might support smarter diagnostics and remediation in future projects.

Generative AI meets multi-tenancy: inside a working solution

A surprise highlight of the day came right at the end - "Generative AI meets multi-tenancy" - presented by Dr Anil Giri, Mehran Najafi, and Victor Popsecu from SteelEye. This session tackled some of the thornier issues we're actively exploring for a forthcoming project: context-aware, permission-sensitive RAG architectures in a multi-tenant SaaS environment.

SteelEye, a compliance and analytics platform, shared their practical experience of implementing Gen-AI in a regulated multi-tenant context using Amazon Bedrock, vector databases, and knowledge bases. The session stood out not just for the architecture diagrams, but for its real-world grounding: onboarding flows, tenant isolation strategies, and tiered service levels based on customer entitlements.

Crucially, it explored:

Data partitioning and isolation, both at storage and inference level
Multi-tenant RAG patterns, with context retrieved per tenant and tied to access controls
Use of Bedrock and embedding services, abstracting away some of the ops complexity while remaining customisable
How knowledge bases can be scoped per tenant, enforcing data segregation and traceability
Patterns for introducing service tiers (e.g. token limits, custom model access, response filtering) across different customer levels

We'd already had a helpful chat earlier in the day with an AWS Solutions Architect about tenant-aware retrieval strategies, so seeing the concepts reinforced and extended in a proper production case study helped crystallise our thinking.

For Si Novi, this was hugely relevant. We've built multi-tenant B2B platforms for years - often with complex RBAC and data isolation - and we're now applying that same thinking to generative AI integrations. This talk gave us new language, new patterns, a lot of photos of the slides and a few solid "we're not mad" moments. A great end to the day.

Entertainment and networking

We don't attend the summit for networking but it is a nice bonus. This year it was good to catch up with clients and colleagues at various points during the day, and then as the summit came to a close we grabbed a beer and watched the brass brand sign off with a medley of pop hits. It felt like there were probably fun things happening all across the Expo and AWS halls as people started to let their hair down, I bet different experiences were had all over depending on where you found yourself at the end of the day.

Our day was rounded off at the AWS Comsum (AWS Community Summit) networking event held at the nearby Tapas bar after the summit. As big fans of the Comsum this is a regular post-summit event for us. After great chats with peers and AWS partner friends we called it a day. A really good day.

AWS London Partner Summit

The second aspect that made 2025 so special is our status as an AWS Partner and attending the AWS Partner Summit for the first time.

Held at the Royal Lancaster hotel next to Hyde Park, it was a suitably swanky venue for a small and very personal event where parters such as ourselves are able to network with each other and hear from the AWS Partner team.

It was a hugely valuable day, and validated the route we've taken to embrace the Partner Network. It confirmed to us that the value in the network is opening the door to better tools, insights, and support that help us deliver more effectively for our clients.

In hindsight we should have joined the Partner Network years ago, however we can be proud of what we've achieved thus far, and now we can look forward to accelerating our growth and impact for our clients with the support of AWS.

From co-selling and funding programmes to direct access to AWS solution architects, it's already changing the way we approach engagement, project planning and technical discovery.

The Partner Summit gave us a glimpse into that growing ecosystem - one that's collaborative, surprisingly open, and clearly designed to help partners like us scale what we do best: building well-architected, cloud-native solutions that solve real-world problems.

Conclusions

This year felt fresh, new and exciting. The summit was re-energised and I now look forward to going again and see what new things are in place next year. And the Partner Summit is a way to anchor our new AWS Partner engagment and grow.

For our clients, that means more insight, better access, and solutions shaped by the very best of what AWS has to offer.

No longer am I meh about the AWS Summit, I'm simply excited for the next one.

Read more about AWS Summit London on the offical AWS page: https://aws.amazon.com/events/summits/london/

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

CloudFront Anycast Static IPs now support apex domains

2025-04-18T00:00:00.000Z

View full-size screenshot

How to point an apex domain to CloudFront without using a CNAME

If your website, app, or API is hosted on AWS, there's a good chance you're already using CloudFront - Amazon's global content delivery network (CDN) that helps improve performance, scalability, and security.

But until now, pointing an apex domain like example.com directly at CloudFront has been... fiddly.

Because CloudFront requires a CNAME, and CNAMEs aren't supported at the apex level in DNS, many teams have found themselves jumping through hoops. That might mean transferring the domain to Route 53 so you can use an ALIAS record, or Cloudflare for their CNAME flattening - or perhaps an another third-party service with redirection support for apex CNAMEs.

Migrating a domain's DNS can be a pain, particularly for an established business with a wide range of IT services hanging off their primary domain. There's likely to be email MX, DKIM and DMARC records, verification TXT records for TLS certificates and integrations with other tools like CRM, analytics, or newsletter platforms.

That workaround of moving DNS just became unnecessary. AWS has introduced Anycast Static IPs for apex domains, letting you connect your apex domain directly to CloudFront using simple A records - no tricks, no DNS migrations.

However... it comes at a cost.

What is CloudFront and why use it?

CloudFront is AWS's global content delivery network. When someone visits your site or hits your API, CloudFront routes their request to the nearest edge location to the user. At this edge location content such as images, web pages and data can be cached - stored for repeated use without needing to go all the way from the origin server which may be in a different country.

By delivering content in this way CloudFront reduces latency and boosts the speed of your web service. CloudFront also helps reduce load on your origin servers and offers built-in security benefits like DDoS protection and TLS.

From marketing sites to complex applications, CloudFront is a solid default for modern web delivery.

But until now, its reliance on CNAMEs has meant some friction when it comes to domain setup.

What's new: static Anycast IPs for apex domains in CloudFront

In late 2024, AWS rolled out a new Anycast IP option for CloudFront, allowing single static IPs to route traffic to the nearest CloudFront edge location. It was a quiet but welcome improvement to network routing.

Now in April 2025, they've gone a step further: you can request three Anycast static IPs that support apex domains. These IPs work globally and can be pointed to from your domain's A records.

No more workarounds. No need to change DNS providers. Just three IPs you can drop into your existing setup.

What is the cost of Anycast static IPs?

While a powerful new feature, the cost of using Anycast static IPs is not trivial. The current pricing is an additional $3,000 USD per month for each Anycast Static IP list. This also applies for the new feature of provisioning just 3 IPs for domain apex DNS configurations. This is a significant investment, especially for smaller businesses or startups, and really limits the use-cases to larger organisations and specific workloads.

Why apex domains are tricky with traditional CDN setups

While many sites use www.example.com for their front-end, most modern sites and services want their main site or app served from the root domain - example.com. It's cleaner and more memorable. But it's also important to support both www and non-www, choosing one as the primary source of the website.

But root domains can't have CNAMEs, which CloudFront has historically required. That's what's made this problem so persistent. It wasn't a blocker, but it was a hassle - especially for businesses who didn't want to move DNS providers just to get their domain to work with CloudFront.

How to use Anycast Static IPs with your CloudFront distribution

There are some prerequisites for your CloudFront distribution: IPv6 disabled and price class set to "Use all edge locations". AWS will provide you with three Anycast static IPs, and these three IPs can be added as three A records to your DNS. These IPs act globally, meaning requests from users in different regions will be routed to the nearest edge location, just like before. But now, everything is behind simple A records.

The benefits and alternatives of Anycast Static IPs

This update reduces complexity, removes an awkward dependency, and gives you more control over how your domain is managed. But at a cost.

For most users, the traditional workarounds of migrating a domain to Route 53 or Cloudflare, or using extra apex-pointing services will probably remain more cost-effective. However as ever with AWS services, new developments and features or even updates to pricing may change the landscape over time.

Read more about the new CloudFront Anycast static IPs on AWS: https://aws.amazon.com/about-aws/whats-new/2025/04/amazon-cloudfront-anycast-static-ips-apex-domains/

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

Maintenance vs value creation: proactive upkeep and agility

2025-03-12T00:00:00.000Z

In the world of software development, there's a constant tension between maintaining existing systems and building new, value-driven features. Many engineering teams find themselves unable to spend time on necessary maintenance due to the pressures of delivering new features.

Their insistence that it would be better to address maintenance first can often be seen as an unwanted extra cost, and be deprioritised or ignored, leading to increasing technical debt and inefficiencies. Future feature development then takes longer as teams must navigate outdated systems, implement temporary fixes, and work around legacy constraints instead of building efficiently on a solid foundation.

This slowdown frustrates clients, creates the perception that development of new features is costly and inefficient, and ultimately impacts the business's ability to innovate at speed.

This is precisely the challenge Angela Timofte explored in her keynote at ServerlessDays Manchester, Engineering for Impact: Shifting from Maintenance to Value Creation. She shared her experience of joining a team that had reached a critical pain point in their workflow balance where maintenance had become a huge burden due to legacy software and decisions made (or not made) previously.

Angela shared how she and her team were challenged to reduce the maintenance burden from 70% of their time to just 30%, allowing them to focus more on impactful, high-value work.

Her talk introduced a framework for shifting this balance, which she called the "70/30 flip," which involved three key steps:

1. Making use of supporting data - Gathering relevant metrics and KPIs to track maintenance vs. value creation efforts.
2. Writing out a plan - Defining clear actions to reduce maintenance overhead and improve system efficiency.
3. Communicating the plan effectively - Ensuring buy-in from stakeholders and engineering teams to implement changes successfully. Stakeholders must acknowledge and accept the time and costs of change, with future efficiency improvements as the reward.

Our approach

Hearing Angela's talk made me reflect on how we approach maintenance and value creation at Si Novi.

We have embedded proactive maintenance as a core practice of our support retainer service, to make sure we never arrive at that pain point where maintenance becomes a blocker.

Our approach ensures that supported applications remain well-maintained and up-to-date, which allows us to deliver high-value features quickly and cost-effectively.

Instead of tracking KPIs on maintenance vs. value work, we focus on a simple measure: Are our supported applications up to date?

Keeping our clients' supported apps up to date and "developer ready" at all times by performing regular code updates and deployments means that when a client asks for a new feature, or a new phase of work - the app is ready to be worked on.

A real-world example: Medem's enhanced quotation tool

Medem, a leader in gas safety and control systems, relies on a bespoke sales and quotation application we developed and maintain on AWS.

Their team requested a feature update to enhance their quoting process - introducing new product layout capabilities, subtotals, and dynamic total calculations.

Previously, their quoting process required manual calculations, which introduced inefficiencies and the risk of human error. As they put it:

"Adding a total line to the quote is something we've discussed before. It needs to be dynamic and sum everything above it. Lately, we've been hearing more and more: 'Just give me a total!!'"

Because we maintain Medem's application proactively - including regular PHP updates, dependency management, and infrastructure upkeep - we were able to deliver this enhancement quickly. We didn't need to spend time getting the development environment up and running, dealing with outdated libraries, or untangling technical debt.

The result? A swift, seamless deployment within a few days, and a delighted client:

"Definitely making things easier and the new layout I feel has improved it greatly."

The hidden cost of neglected maintenance

So what's the alternative to proactive maintenance? Often, it's a situation where even small feature updates become big projects because the underlying system isn't in a healthy state. Teams may find themselves needing to:

Upgrade legacy dependencies before new features can be added.
Address security vulnerabilities before deployments can proceed.
Rework outdated development environments before coding can begin.

Worse still, when maintenance is continually deferred, technical debt accumulates, and the cost of change increases.

Eventually, businesses may find themselves struggling to release updates or new features. Engineers or service agencies will have to increase durations and pricing for new features to include the battles with unmaintained software, which can make development seem expensive and untenable.

Shifting the mindset: maintenance as an enabler

For many organisations, maintenance is seen as a cost centre - something that must be done but doesn't contribute directly to business goals. In reality, proactive maintenance is an enabler of value creation. By keeping systems in a healthy state, businesses gain:

Faster feature development - New capabilities can be delivered rapidly without first tackling technical debt.
Improved reliability - Fewer production issues mean less time firefighting and more time innovating.
Happier developers - Teams can work on meaningful improvements rather than struggling with brittle, outdated systems.
Cost savings - Avoiding the need for large-scale rework or emergency fixes reduces long-term expenses.

Practical steps to reduce the maintenance burden

Reducing maintenance overhead and enabling value creation requires a technical approach that prioritises efficiency, resilience, and automation. Here are some key engineering practices that help achieve this:

Implement continuous maintenance

Rather than treating maintenance as a separate, periodic task, integrate it into your regular development workflow. Automate dependency updates, schedule routine code reviews, and adopt a “fix it when you see it” mentality to keep issues from accumulating.

Keep development environments ready to go

One of the most common blockers to fast feature development is a cumbersome setup process. Ensure that developers can spin up a local or cloud-based environment quickly, without needing to troubleshoot outdated dependencies or configuration issues.

Prioritise tech debt reduction

Technical debt is inevitable, but it should be actively managed. Establish a backlog of maintenance tasks and address them alongside new feature development, rather than letting them pile up.

Invest in automated testing and monitoring

High test coverage and robust monitoring reduce the time spent diagnosing and fixing production issues. This allows teams to focus on delivering improvements rather than firefighting.

Shift the mindset: maintenance is part of delivering value

Encourage teams and stakeholders to see maintenance not as a drain on resources but as an essential component of business agility. Transparency of maintenance with stakeholders allows them to make informed decisions. A well-maintained system enables faster iteration, improved user experience, and ultimately, a stronger competitive position.

Conclusion: maintenance as a competitive advantage

At Si Novi, we believe that proactive maintenance isn't just about keeping the lights on - it's about enabling businesses to move faster, respond to customer needs, and continuously create value. Our work with Medem illustrates how a well-maintained system allows for rapid innovation, rather than being a bottleneck.

By shifting focus from maintenance as a burden to maintenance as an enabler, businesses can achieve the same transformation Angela Timofte described - freeing engineering teams to focus on impactful, high-value work.

As an AWS Partner, we leverage the AWS Cloud Value Framework (CVF) as part of our consultancy and engineering activities with clients. One of the pillars of the CVF is Business Agility, which describes how the cloud facilitates rapid experimentation and scalability. By using AWS we can help businesses to deploy resources in minutes and experiment with new ideas quickly. This enhanced business agility helps organisations respond rapidly to market changes and innovate and grow the business more quickly.

If your business is struggling to move quickly due to technical debt and maintenance overhead, it might be time for a different approach. Get in touch to find out how we can help.

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

Rebuilding a travel packages API on serverless AWS

2025-03-01T00:00:00.000Z

What we built

Serverless API rebuild

Published 2025

A live API, rebuilt underneath its own consumers

Distribute distributes package-holiday data to downstream partners through a business-critical API. The original service was showing its age, and Distribute wanted a modern, scalable, cost-efficient replacement - but one that existing partners could keep relying on without disruption. We rebuilt the API as a fully serverless service on AWS, pairing a clean, modern interface with a genuinely zero-downtime migration path for the systems that already depended on it.

The migration challenge

A live API is a contract. Partners had integrated against the existing service - a legacy VB.NET/SOAP application - and any breaking change risked interrupting the flow of data they relied on. The rebuild therefore had two goals that usually pull in opposite directions: modernise the platform completely, and change nothing that existing consumers could see.

A modern serverless API

We built the new API on Amazon API Gateway's HTTP API, with each endpoint served by its own single-purpose AWS Lambda function. A single-table Amazon DynamoDB design holds the service's own domain - partners, brands and access rules - alongside a fast cache of the package data itself, for predictable low-latency reads at any scale. Access is gated per partner with API keys, and a purpose-built admin interface lets the team manage partners and configuration directly.

Modern JSON/HTTP interface for new integrations, defined by a clear API specification.
Serverless throughout - no servers to run, and cost scales with actual usage.
Single-table DynamoDB for consistent, low-latency reads under variable load.
Per-partner API keys for secure, controlled, multi-tenant access.

Zero-downtime migration

The key to a seamless cutover was backward compatibility. Alongside the modern JSON interface, the new service exposes a compatibility layer that speaks the same SOAP/XML protocol as the legacy API - serving the same contract, operation for operation. Existing consumers continued to call the service exactly as before, unaware that everything behind the interface had been rebuilt, while new integrations could adopt the modern interface at their own pace.

To give everyone confidence in the switch, we built a harness that fired identical queries at the old service and the new one in parallel and put their responses side by side - confirming the rebuilt API returned equivalent results before anything was moved across.

Cost-optimised by design

Because serverless bills per request, efficiency is a design concern rather than an afterthought. Two ideas do most of the work. First, the service resolves its filtering rules before it fans out to the data store: any request combination that a rule excludes outright never triggers a function invocation at all, and the rest are refined afterwards. Second, each request carries a response-time budget - the service fans a query out across every relevant combination and returns whatever has resolved within that budget, so it honours a real latency target rather than waiting on the slowest shard. The effect is a service that is both faster to respond and cheaper to run.

Key AWS services

Amazon API Gateway (HTTP API): the modern, low-overhead front door to the service.
AWS Lambda: a dedicated serverless function behind each endpoint.
Amazon DynamoDB: a single-table design for fast, scalable data access.
Amazon S3: storage for the admin interface's assets and supporting files.

Results: modernised, without disruption

No consumer disruption: existing partners kept working unchanged throughout the migration.
A modern interface: new integrations use a clean, well-documented HTTP/JSON API.
Lower running costs: serverless compute and query optimisation cut the cost of every request.
Latency you can budget for: each request returns within a response-time target rather than blocking on the slowest lookup.
Elastic scale: the service handles variable demand automatically, with no capacity to manage.
Simple administration: partner and configuration management is handled through a purpose-built admin interface.

About Si Novi: serverless API specialists

We design and build serverless APIs and cloud-native applications on AWS, with a particular focus on modernising legacy systems safely.

By combining modern architecture with careful, backward-compatible migration, we help businesses like Distribute move their platforms forward without putting the integrations their partners depend on at risk.

The measure of this one was that the partners calling the API couldn't tell it had happened. We rebuilt the whole thing on serverless, then taught it to speak the old protocol word for word, so every existing integration kept working untouched while the platform underneath became something completely new.

James Galley, Principal Consultant, Si Novi

Youtube playlists of AWS re:Invent 2024 Breakout Sessions

2024-12-04T00:00:00.000Z

If you missed re:Invent this year, the breakout sessions are all up on YouTube. AWS has sorted them into playlists by topic, so you can watch on demand.

We've picked one session from each category as a starting point. Each embed below links through to the full playlist for that topic.

AI/ML

Artificial intelligence and machine learning, including Amazon SageMaker, generative AI, and customer case studies.

Analytics

Working with data on AWS analytics services such as Amazon Redshift, EMR, and Athena.

Architecture

Architectural patterns and best practices, with real-world examples of systems built on AWS.

Business applications

Enterprise applications and productivity tools running on AWS.

Community

AWS user groups, community projects, and talks from people building on AWS.

Compute

EC2, Graviton processors, and high-performance computing.

Customer enablement

Training, support, and enablement to help customers get more out of AWS.

Operations

Monitoring, automation, and incident management on AWS.

Databases

Amazon DynamoDB, RDS, Aurora, and the purpose-built databases on AWS.

Developer productivity & DevOps

CI/CD, infrastructure as code, and developer tooling on AWS.

End-user computing

Virtual desktops and app streaming on AWS.

Hybrid cloud

Connecting on-premises environments to AWS, including AWS Outposts and hybrid architectures.

Industry

Sessions grouped by sector - healthcare, financial services, gaming, and others.

IoT & robotics

AWS IoT services, RoboMaker, and edge computing.

Kubernetes

Amazon EKS, containers, and orchestration on AWS.

Networking & content delivery

AWS networking, content delivery, and building applications for a global audience.

New to AWS

Sessions for newcomers getting started with AWS.

Migration & modernisation

Migrating and modernising applications and infrastructure with AWS.

Partner enablement

How AWS partners build and deliver solutions for customers.

Partner sessions

Talks from AWS partners.

Security, compliance & identity

Security practices, compliance, and identity management on AWS.

Serverless compute

Serverless on AWS - Lambda, EventBridge, and the wider ecosystem.

Storage

Storage options on AWS for a range of workloads.

View all AWS re:Invent 2024 Youtube videos here: https://www.youtube.com/@AWSEventsChannel

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

Amazon Aurora DSQL: a new era for serverless databases?

2024-12-03T00:00:00.000Z

View full-size screenshot

Exploring Amazon Aurora Distributed SQL: our first impressions

Amazon Aurora Distributed SQL (DSQL) was just unveiled at re:Invent 2024 earlier today, and we're buzzing with excitement about what this new offering could mean for businesses running growing, global, web applications. AWS promises a service that marries global scalability with the convenience of serverless architecture, and while it's early days, the possibilities are thrilling.

What is Aurora DSQL?

At its core, Aurora DSQL builds on the familiar Aurora platform but introduces groundbreaking features designed for distributed workloads. AWS highlights its active-active multi-region availability and distributed SQL architecture, which promise robust fault tolerance and seamless global operations.

Hidden in there somewhere is the fact that a DSQL cluster doesn't require a Virtual Private Cloud (VPC) and other network gubbins. Which is amazing.

The expansion of PostgreSQL compatibility is another highlight. PostgreSQL's popularity among developers makes this a welcome feature, potentially simplifying cloud migrations and development for businesses already using relational databases and open-source tools.

Why DSQL caught our attention

We've spent plenty of time working with relational SQL databases through RDS, as well as DynamoDB for schemaless data storage and scalability. Both have been great in their own right, but we've always felt there was a bit of a gap - something that could offer the best of both worlds: the querying power and familiarity of SQL, combined with the scalability and flexibility of serverless.

Aurora Serverless seemed like a great option for a while, offering auto-scaling without the need for manual provisioning. However, it still required being within a VPC, which didn't quite fit with the event-driven, fully-serverless architecture that we were hoping for. This added complexity and for us, made the service less useful than it could have been.

So what really stands out to us is the truly serverless architecture. I noticed the separation in the AWS console of DSQL from the RDS platform which runs the other Aurora services is a telling sign of the differing nature of DSQL. At a simplistic level the choice now seems to be RDS || DSQL || DynamoDB which is an exciting concept. Hooking up a Lambda to a DSQL cluster will be my first experiment to see how this feels in comparison to connecting to an RDS or Aurora cluster.

The potential for Aurora DSQL to address scaling challenges is particularly intriguing. For businesses running web applications with unpredictable traffic, the serverless, distributed model could offer the right balance of performance and cost. Imagine a web app serving users globally with minimal latency or downtime, but pulling big SQL queries and working with relational data, and scaling to nothing when unused.

The cost efficiency of paying only for what you use remains a hallmark of Aurora, but DSQL could take this to another level by removing the need for overprovisioning resources in multi-region setups. It also hints at a future where SMBs can compete with larger enterprises in delivering reliable, scalable services.

the separation in the AWS console of DSQL from the RDS platform which runs the other Aurora services is a telling sign of the differing nature of DSQL

Questions we're asking

While we're excited about the potential, we still have a few questions. How does the pricing really stack up for global deployments? What's the learning curve when it comes to adopting a distributed SQL model? Is the easy-to-use developer experience really just that? Which use cases will best suit DSQL?

What's next?

For now, Aurora DSQL feels like an evolution that could redefine how businesses think about scaling their database-driven web applications. We'll be digging deeper into its features as more details emerge and experimenting in our own Si Novi sandbox accounts. Whether it's about creating globally resilient web apps or optimising costs with serverless flexibility, Aurora DSQL is a development we're eager to explore further.

As we learn more, we'll share updates and insights on how this service might fit into SMB strategies. If AWS's promises hold true, Aurora DSQL could be the start of a new era for accessible, high-performance database solutions. Stay tuned!

Find out more about Amazon Aurora DSQL on the official service feature page: https://aws.amazon.com/rds/aurora/dsql/features/

Questions or thoughts? Email us at hello@sinovi.uk.

Articles

What we’re learning and working on

2nd October 20266 min read

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

25th September 20263 min read

We're heading to AWS Community Summit Manchester

17th July 20269 min read

Build the squad. Own the platform. The org chart will catch up.

Transforming global tooling distribution for Jaguar Land Rover with AWS

2024-11-25T00:00:00.000Z

What we built

Distribution web platform

Delivered 2015

Transforming business processes

Jaguar Land Rover (JLR) required a scalable and reliable solution to manage and distribute its global tooling information. Si Novi partnered with JLR and automotive consultancy Redsnipe to develop a web-based application powered by Amazon Web Services (AWS). The solution replaced a legacy Excel-based process and leveraged AWS infrastructure to deliver high availability, scalability, and security. Since its launch in 2015, the application has enabled online auditing capabilities and rapid, global distribution of tooling information in 13 languages and over 40 regions. The solution has improved operational efficiency, compliance monitoring, and reporting for JLR's retailer network, ensuring tools are always available when needed.

About Jaguar Land Rover

Jaguar Land Rover is a leading global automotive manufacturer, producing premium vehicles with advanced technology, luxury, and performance at the core of their brand. With a vast network of retailers and an ever-evolving vehicle fleet, JLR faces the complex challenge of ensuring that its retailer network has access to the most current and approved tooling information, essential for servicing their vehicles across multiple global regions.

The Need for a Scalable, Global Tooling Solution

JLR needed a robust, reliable solution to distribute tooling and equipment information to its global network of retailers. The process was initially managed using Excel spreadsheets and Visual Basic macros, which became inefficient and prone to errors, particularly as the vehicle fleet grew and the retailer network expanded across more than 40 regions.

As the demand for real-time information grew, it became clear that JLR's solution would require modernisation. If the challenge was not addressed, it risked disrupting the ability of retailers to service vehicles efficiently and could lead to delays, compliance issues, and a lack of control over the tooling distribution process. JLR needed a secure, scalable, and easily accessible solution that could handle the complexities of a global operation.

Why We Chose AWS for this transformation

We chose AWS as the foundation for its solution due to its proven scalability, global reach, and reliable infrastructure. AWS offers a wide range of services, such as auto-scaling, load balancing, and multi-region availability, which provided the perfect environment to host JLR's mission-critical tooling application. Additionally, AWS's robust security features and extensive compliance certifications aligned with JLR's high standards for data protection and regulatory requirements.

Why JLR partnered with Si Novi

Si Novi was uniquely qualified to tackle JLR's tooling distribution challenge due to our deep expertise in designing, developing, and deploying high-performance, cloud-native web applications. Our experience with AWS infrastructure and commitment to delivering secure, scalable solutions made us the ideal partner for this project. Additionally, our partnership with Redsnipe, a specialist automotive consultancy, brought valuable industry insights to the solution, ensuring it met the specific needs of JLR's retailer network.

JLR chose Si Novi due to our track record of successful cloud transformations and our ability to deliver a comprehensive, end-to-end solution that aligned with their business objectives. Our team demonstrated a deep understanding of the challenges involved in managing and distributing critical tooling information on a global scale.

How we delivered a robust, cloud-native solution

Si Novi designed and built a web-based application that mirrored and enhanced the legacy tooling distribution process, providing JLR with a modern, efficient solution. The application was developed on a LAMP stack (Linux, Apache, MySQL, PHP) and fully integrated into AWS, leveraging a variety of AWS services to ensure high performance, availability, and security.

In a recent enhancement delivered in 2024, Si Novi again collaborated closely with JLR to introduce functionality specifically for electric vehicle (EV) tooling. This new feature supports the distribution of essential tooling information tailored to the unique needs of EV maintenance, ensuring JLR's global retailer network is prepared for the growing shift to electric mobility. Using an agile methodology, we worked iteratively with JLR stakeholders to design, prototype, and develop this capability, ensuring it seamlessly integrated into the existing application. This enhancement not only expands the application's utility but also underscores JLR's commitment to innovation in the automotive sector.

Key AWS services used in the solution include:

AWS Elastic Beanstalk: Powers the deployment and management of the application by providing an easy-to-use platform for deploying and scaling the LAMP stack environment, with built-in monitoring and management capabilities.
Amazon S3: Used for reliable storage of application data and tooling documents.
Amazon CloudFront: Ensured fast content delivery to users worldwide by leveraging its Content Delivery Network (CDN).
Amazon Route 53: Managed DNS to route users to the current application version and ensure high availability.
AWS Auto Scaling and Elastic Load Balancing: Ensured the application could handle traffic spikes and distribute user requests across multiple servers for optimal performance.

The application's design allows for rapid distribution of tooling updates globally, enabling JLR's retailer network to access the latest information at the click of a button. The solution also includes features for auditing, reporting, and PDF document generation for physical copies of tool compliance reports.

The Impact: Streamlining Tooling Distribution

Since its launch, the tooling application has provided significant operational benefits for JLR and its global retailer network:

Over 18,000 tooling audits have been performed using the application, improving compliance tracking.
Quarterly tooling updates are now released on a fixed schedule, ensuring all retailers have access to the latest information.
Global distribution of tooling information has become faster and more efficient, supporting JLR's operations in over 40 regions.
Retailers now benefit from real-time access to tooling information, reducing delays and improving service efficiency.

The application's integration with JLR's Single Sign-On (SSO) and its secure cloud infrastructure provide a seamless and secure user experience, reinforcing trust among JLR's retailers and reducing the risk of data breaches.

What's Next: Continued Innovation and Collaboration

Si Novi and JLR plan to continue their collaboration to further enhance the tooling application's capabilities. Future improvements may include extending the functionality to additional JLR departments, integrating more advanced reporting features, and exploring AI-driven tools to enhance tool compliance analysis.

Who We Are: Si Novi and Our AWS Expertise

Si Novi is a cloud services and web application development company specialising in AWS-powered solutions. With expertise in building scalable, secure, and high-performance web applications, Si Novi helps businesses across various industries leverage the cloud for digital transformation. Si Novi is a member of the AWS Partner Network (APN), offering a wide range of services, from cloud architecture design to application management and support.

Changes are inevitable in our business but have presented no problems with Si Novi adapting to our needs seamlessly

Martyn Talbot, Tooling and Equipment Team Leader, Technical Service Operations, Jaguar Land Rover

Si Novi

Elastic Beanstalk PHP 8.2 on AL2023 retires March 31, 2027

You've had an "[Action Required]" email from AWS

What "retire" actually means

The date that matters more is December 31, 2026

Which PHP version should you move to?

It isn't a button in the console

Finding your affected environments

Still on Amazon Linux 2?

What happens if I ignore it?

What we’re learning and working on

We're heading to AWS Community Summit Manchester

Build the squad. Own the platform. The org chart will catch up.

Pointing agentic AI at our own bookkeeping

AWS Community Summit Manchester 2026 preview

Back to Victoria Warehouse for ComSum 2026, with AI all over the agenda

Opening keynote: from compilers to copilots

AI-DLC and organisational context

Closing keynote: beyond software engineering

Come and say hello

What we’re learning and working on

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

Build the squad. Own the platform. The org chart will catch up.

Pointing agentic AI at our own bookkeeping

Build the squad. Own the platform.

Once the technology works, the bottleneck is the org chart

Why now?

Two easy answers that don't quite work

We've done this before

What to do instead: build a squad

What this means for HR, and for Helen

What we’re learning and working on

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

We're heading to AWS Community Summit Manchester

Pointing agentic AI at our own bookkeeping

Agentic AI for operations: experimenting on our own bookkeeping

Where I aimed it, and why

The shape that's working so far

Where the API runs out

Guardrails, because it's live accounts

In summary... well, it's brilliant

What we’re learning and working on

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

We're heading to AWS Community Summit Manchester

Build the squad. Own the platform. The org chart will catch up.

What is AI-native? A clear definition

AI-native means designing the product around AI from the ground up

The cloud-native analogy

A spectrum, not a binary

What's actually different about it

AI you didn't ask for

How we build AI-native systems

What we’re learning and working on

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

We're heading to AWS Community Summit Manchester

Build the squad. Own the platform. The org chart will catch up.

Re-platforming a live insurance book with event-sourced architecture

Re-platforming a fintech insurance business

The challenge: modernise a working business, without disruption

An event-sourced architecture (CQRS)

A modern stack, containerised and defined in code

A single, planned cutover

Results: a platform built to scale

A partnership that keeps building

About Si Novi: cloud-native engineering partners

Work we have done for businesses like yours

Duwio

SRO Motorsports Group

From Early AWS Adopters to Select Tier Partner

Si Novi is now a Select Tier partner in the AWS Partner Network

Early adoption

Infrastructure evolution

Founding Si Novi and choosing serverless

Shaped by client work

Becoming a partner

What it means for our clients

What we’re learning and working on

AWS Elastic Beanstalk PHP 8.2 on Amazon Linux 2023 platform branches retire on March 31, 2027

We're heading to AWS Community Summit Manchester

Build the squad. Own the platform. The org chart will catch up.