This month, Koen Verbeeck invites the blogging community to write about their thoughts on returning to on-premises. What could be struggles, things we have to re-learn, etcetera.
When I read the invite, it immediately sparked inspiration, because there are increasing rumours around cloud exits. People musing about ‘what if’. Some clients reference these questions, but so far no one has directly asked me one with the intent of moving forward with it.
The struggles
I think many people would struggle to migrate. For instance, scaling in the cloud is self-service. You move a slider left or right, you see a change in price, you click next, and it’s done. Well, in some cases. Sometimes you may have to power down resources and restart them. Or wait for the scaling to finish. But you get my point.
On-premises, you need to find the person responsible for the hardware. You have to talk to them nicely and ask if there is an option to add CPU, Memory, or Disk. Usually all of them. And when they say no, you have to figure out what to do next. Who to talk to next.
But this assumes you have on-premises hardware, ready to go. But do you? Or do you have to rebuild it? And find the people who can do that. Who can configure Proxmox, VMware or HyperV. And then install your operating systems. And then all the applications you need.
And, most importantly, you’re responsible for all the security. From the building entrance to data access and everything in between.
No, I’m not telling you to not go there, but you have to be aware of the initial impact of rebuilding your hardware infrastructure.
The knowledge
The other thing I’ve noticed is that many people are increasingly relying on AI. They’re asking a model (GPT, Claude, whatever) to build something for them or generate code. Which is fine. Until it isn’t. For instance, when you find out that the code works, but is highly inefficient.
Also, did you think about hosting a model on your own hardware? If you did, have you included the hardware requirements and the fact that hardware prices are crazy and unpredictable?
I’d argue that it could very well be more efficient and cheaper to hire someone who is well-versed in a language like C#, Java, T-SQL, PySpark, KQL, NodeJS, or whatever floats your app. People who know how to write code efficiently, quickly, without relying on a very advanced text predictor.
My advice
Start planning. It doesn’t have to be extremely detailed. But start planning.
- What do you need
- Infrastructure
- Operating systems
- Virtualisation
- Security
- …
- Who do you need
- Infra management
- OS management
- Virtualisation management
- App developers
- Data engineers
- Programmers
- Database administrators
- Security Experts
- …
- Technical knowledge
- VMware
- HyperV
- Proxmox
- Windows
- Linux
- SQL Server
- Python
- PostgreSql
- Networking
- DNS
- DNS
- DNS
- Your programming languages
- Security experts
- …
This list isn’t complete, because your environment will always require something else.
It’s always DNS
Thanks, Koen, for the inspiration, and I’d love to read or hear your thoughts!
Reitse's blog 