VetGroep: Choosing a Service Model per Workload and Drawing the Responsibility Line
VetGroep runs 38 veterinary clinics across the Netherlands and Flanders on a single on-premise estate. Three workloads are in scope for a nine-month cloud programme. (a) Email, calendar and shared document editing for 620 staff. (b) 'Praxis', a 14-year-old practice-management suite: the vendor supports it only when it runs on customer-managed virtual machines with a specific database engine, and will not certify any hosted variant before 2027. (c) 'Remind', a small Node.js service written in-house last year that reads appointments and sends SMS reminders; it needs a message queue, a scheduled job runner and a relational database, and the two developers who built it are the only people who understand it. A fourth requirement has appeared: X-ray images, 4 TB today, growing roughly 25% per year, which must remain in the EU and be retained for ten years. The IT manager proposes putting everything on virtual machines 'so it all looks the same', and the security officer wants to know who patches what.
1. Assign workloads (a), (b), (c) and the X-ray archive to a service model, and justify each choice by what the organisation gains and gives up.
Read the worked answer
The service model is a decision about which layer you want to keep operating, so justify each by that layer, not by fashion.
(a) Email, calendar, document editing - SaaS. These are undifferentiated functions with well-understood requirements. SaaS removes the mail server, the storage cluster and the patch treadmill, and gives 620 staff a working service in weeks. What is given up: control of release cadence, granular configuration, and much of the ability to prove where data sits beyond what the vendor's documentation and contract say.
(b) Praxis - IaaS. The constraint is not technical preference but vendor certification: the vendor supports only customer-managed virtual machines. IaaS preserves the support contract while removing the physical estate. The organisation keeps the guest OS, the database engine and the application, and therefore keeps the patching obligation for those layers. Choosing PaaS here would void vendor support; choosing to stay on-premise would keep the estate problem the programme exists to solve.
(c) Remind - PaaS. The team must own the application logic - that is where their value and their risk sit - but should not own operating systems, queue clustering or database failover. Managed queue, managed scheduler and managed relational database shift the operational burden to the provider. The trade-off is dependency on provider-specific APIs; a two-person team should accept that consciously rather than build a portable abstraction they cannot maintain.
X-ray archive - object storage service, with a retention policy. Bulk write-once data with a ten-year retention obligation belongs in object storage with lifecycle rules and a region restriction, not on a virtual machine's disks. It also needs an active check that the chosen region and any replication stay inside the EU.
2. The security officer asks 'who patches what' for the Remind service if it is built on PaaS, and what changes if the team instead runs the same code in containers on IaaS.
Read the worked answer
The shared responsibility model moves with the service model, and the answer must be stated layer by layer.
On PaaS, the provider owns: physical security, hosts, hypervisor, the managed runtime and middleware versions, patching and failover of the managed queue, scheduler and database engine, and the underlying storage and network fabric.
VetGroep still owns: the application code and its dependencies (a vulnerable npm package is VetGroep's problem, not the provider's), configuration and secrets, the identity and access model for who can deploy and who can read the database, the data itself - classification, retention, deletion, lawful basis - network exposure choices such as public endpoints versus private links, and the audit of provider-side access.
If the same code moves to containers on IaaS, VetGroep takes back: the guest operating system and its patching, the container runtime and orchestration control plane upgrades, node image hardening and scanning, cluster network policy, and the availability design of the cluster itself. The provider is then responsible only for the physical facility, hosts, hypervisor and the virtual network primitives.
The practical point for the officer. PaaS does not make the application secure; it removes a category of toil and shrinks the audit surface, but the higher-level controls remain human work. Conversely, moving to containers does not automatically reduce lock-in - a well-managed Kubernetes footprint carries its own skills requirement, and VetGroep's two developers are not a platform team. The IT manager's 'everything on VMs so it all looks the same' proposal should be judged on this table: uniformity of interface is bought with a permanent operating burden the organisation has just decided it does not want to carry.