We all use cars. Some prefer to own a car while others prefer to rent. Which model is better is an individual question.

When it comes to enterprise computing, there have long been a single operation model – to own the computing resource. With the advent of virtualization technology, data centre co-location model, the cloud became popular. Cloud computing is essentially the same delivery model as renting a car.

Cloud Computing in Construction: Trends identified by GlobalData

The table compares the two delivery models with car and computing resource as examples

Delivery ModelOwnRent
Examplebuying a car
buying servers and operating on-premise
renting a car (e.g. by mileage and time)
Renting computing resource (from public cloud)
Costone upfront cost plus on-going maintenance usage-based billing, with potential discount on fix-term rent (leases)
How trade happenscars are sold in dealership
computing resources are sold by hardware vendors
car rental service is delivered physically at the rental agency
computing resource in the cloud is delivered over high speed network, in response to API request to public cloud vendors
ProsCost is relatively predictable regardless of usagesubscribe to the latest technology (or model, version, security patch, etc) without additional cost
ConsMaintenance responsibility.
Technology becomes out of date
Cost can spin out of control if usage is not being monitored closely

In the cloud, it is significantly cheaper to provision computing resources. However, moving to cloud does not automatically guarantee cost effectiveness. It is important to architect cloud-based solution the right way for the best return on investment.

Read more about cloud:

  • FluxCD: Continuous Deployment with GitOps - Background In the Korthweb project, I landed on Istio for the Ingress Gateway technology. I first attempted to expand the orthanc Helm Chart to bring Istio as dependency (sub-chart). One of the external chart for Istio gateway needs to be referenced multiple times (for ingress and egress). However, it cannot… ... Read moreFluxCD: Continuous Deployment with GitOps
  • AKS Lessons Learned 2 of 2 - Even though Azure Kubernetes Service (AKS) is a managed service, building a cluster is not trivial. For help resources, I would start with the webinar "Configure Your AKS cluster with Confidence" from April 2021, which focuses on a set of working best practices (convention over configuration) but obviously not every… ... Read moreAKS Lessons Learned 2 of 2
  • AKS Lessons Learned 1 of 2 - In general, troubleshooting Kubernetes is tricky. That is because one has to get in and out of pods. I took two days to troubleshoot some networking issues with private AKS cluster. For the amount of of tricks I had to employ, I need to take some notes. The issue After… ... Read moreAKS Lessons Learned 1 of 2
  • From Microservice to Service Mesh - Microservice Microservice as an architecture was firstly conceptualized in this article by Martin Fowler in 2014. It covers the pros (strong module boundaries, independent deployment, technology diversity) and cons (dealing with distributed system, eventual consistency, operational complexity). The reality is, many teams develops their product with the microservice architectural pattern.… ... Read moreFrom Microservice to Service Mesh
  • Single-node Kubernetes cluster – docker desktop - While there are many tools to set up single-node Kubernetes cluster (e.g. minikube, MicroK8s, kind, or k3s with the k3d wrapper), docker-desktop has a significant advantage: it comes with Docker installation, on MacOS, or on Windows. It is installed simply by enabling the option "Enable Kubernetes". It can be blown… ... Read moreSingle-node Kubernetes cluster – docker desktop

Contact Digi Hunch for Professional Services.