Search for a command to run...
Cloud isn't just for enterprises. A pragmatic guide for mid-sized companies ready to take the first step.
Senior Freelancer & Technical Lead
Working as a Golang developer since 2020. Working as a mobile developer since 2013.
Focussed on architecture, testability and clean code. Open minded & product driven. Based in Rhede, available world-wide
No comments yet. Be the first to comment.
How to implement comprehensive software supply chain tracking using Open Component Model that captures dependencies, deployment artifacts, signatures, and version constraints across distributed systems.
A practical framework for evaluating and migrating from deprecated ingress controllers to Gateway API or Envoy Gateway, including risk assessment and zero-downtime migration patterns.
How modern software supply chains use component models to track dependencies, artifacts, and metadata across distributed systems, moving beyond traditional SBOMs to comprehensive delivery tracking.
How to implement comprehensive software supply chain tracking using the Open Component Model that captures dependencies, deployment artifacts, configurations, and runtime bindings across multi-repository environments.
Master React performance optimization through systematic profiling, efficient rendering patterns, and smart bundle splitting strategies for production applications. Learn practical techniques that actually move the performance needle.
I hear this at least once a week. From managing directors, IT leads, sometimes even from developers. And I get where it comes from.
Google "cloud" and you'll get AWS landing pages with enterprise pricing, Kubernetes architecture diagrams that look like nuclear reactor schematics, and case studies from Netflix and Spotify. Of course you think: That's not for us.
But you're wrong. Fundamentally.
Forget everything you've heard at conferences. At its core, cloud means one thing: Someone else runs the hardware, and you pay for what you use.
That's it. No black magic. No paradigm shift. No reason for an 18-month project with external consultants.
You have a server in the basement or at a data center today? It costs you money — whether you use it or not. It needs updates, backups, someone who gets out of bed at 3 AM when it goes down. And when you need more capacity, you order new hardware. Lead time: weeks.
In the cloud, you spin up a server in 30 seconds. Need more power? Click "resize." Don't need it anymore? Delete it. Done.
I've been working with mid-market companies for years. The concerns are always the same:
Wrong. AWS, Azure, and Google invest billions in security. More than you could ever spend. Your server in the basement that hasn't been patched since 2019? That's insecure. The cloud is not — provided you configure it correctly.
And yes, "configure it correctly" is the key. But that's true for on-premise too.
You lose control over hardware you didn't want to touch anyway. In return, you gain control over what matters: how fast you can deploy, how fast you can scale, how fast you can respond to new requirements.
It can be expensive — if you do it wrong. Just like on-premise is expensive if you do it wrong. The difference: in the cloud, you see every cent on the invoice. With your own data center, costs hide in power, cooling, staff, hardware depreciation, and the admin who comes in on Friday night because a RAID card is failing.
Done right, cloud is cheaper for most mid-sized companies. Not because the prices are low, but because you only pay for what you actually use.
If your software runs on a Linux or Windows server, it runs in the cloud. Full stop. The cloud isn't a different universe — it's perfectly normal servers, just in someone else's data center.
Here's the most important sentence in this entire article: You don't have to migrate everything at once.
The biggest trap in mid-market cloud projects is the big-bang approach. Someone draws a target architecture with everything in the cloud, then a 2-year project kicks off. That's the surest way to burn money.
Instead: Start with a concrete problem.
What annoys you the most? Some typical candidates:
You don't need Kubernetes, Terraform, and a multi-cloud strategy on day one. To start:
# Deployment can be this simple:
# 1. Write a Dockerfile (10 lines)
# 2. Build the image
docker build -t my-app .
# 3. Push to a cloud registry
docker push ecr.aws/my-company/my-app:latest
# 4. Service updates automatically
# Done. No SSH, no FTP, no "just hopping on the server real quick"
After your first service is in the cloud, you'll realize: it's not that bad. You learn the basics, your team builds competence, and the next service gets easier.
That's the way. Not the master plan on 200 slides, but one service at a time, one problem at a time.
Let me be honest: you don't need a cloud architect at €1,800 a day. You need:
If you've read this far, you're ready. Not for a cloud transformation, not for a digitization strategy — for the first step.
Take an hour. Look at which of your services causes the most pain. Then ask yourself: Could this be simpler in the cloud?
The answer is almost always: yes.
And if you're not sure where to start — that's what people like us are here for. No slide deck, no concept paper. We look at what you have and show you the shortest path to your first win.
Cloud isn't rocket science. It's a craft. And crafts can be learned.