At some point in every custom software project, the question comes up where the software will run. These days the default answer is the cloud, and usually that is the right one. But it is a design decision, not an automatic one. The advantages are real; the marketing version of them just promises more than practice delivers.
First, what it means. Custom software in the cloud is your own application, developed for your organisation, running on servers you rent from a cloud provider instead of on hardware in your own building. The code and the data remain yours; only the infrastructure underneath is rented. That is different from SaaS, where you subscribe to software the provider owns and shares with all its other customers. We covered the difference between custom software and SaaS earlier; here the question is where your own software runs best.
What the cloud gets you in practice
The biggest advantage is that you don’t have to buy and maintain your own servers. Procurement, power supply, physical security and the replacement cycle sit with the cloud provider; you pay for what you use. A large upfront investment turns into a monthly cost that moves with your usage.
The environment also grows with your organisation. More users, more storage or a peak in processing means adding capacity, not ordering servers, and after the peak you scale back down. Releasing new versions gets simpler too: a release goes live centrally and everyone works with it straight away, with nothing to install on individual workstations. We describe how that works in practice in custom software and automatic updates. And the building blocks for continuity, from automatic backups to a second data centre, are available from a cloud provider without you putting any hardware in place.
What the cloud doesn’t arrange for you
Available is not the same as arranged. The cloud provider keeps the hardware and the network running; everything above that is your responsibility, or your development partner’s. Backups have to be set up and restored now and then to prove they work. Failover to a second location has to be designed and paid for. Access rights, encryption, updates to the software itself and monitoring remain work that someone has to do. An application in the cloud without those arrangements is no safer than a server in an office cupboard, just further away.
The costs deserve a sober look as well. Paying for what you use is attractive as long as usage varies. If a system runs at full capacity day and night, the meter keeps running, and a test environment nobody switches off costs money every month. Choosing the cloud also means choosing someone who keeps an eye on consumption.
Finally, dependency. Every major cloud provider offers its own services that speed up development: managed databases, queues, functions that run without a server of their own. The more of those you use, the more tightly you are tied to that provider, because moving means rebuilding those parts. That is no reason to avoid them, but it is a reason to make the choice deliberately. We described earlier how to prevent vendor lock-in in custom software.
When on-premise or hybrid wins
There are situations where the cloud loses out. Sometimes contracts or regulators require that data stays within your own walls, or you want to hold the encryption keys yourself. Sometimes the software sits literally next to the machinery it controls: there every millisecond counts and the work has to continue if the internet connection drops. And under a heavy, constant and predictable load, your own hardware can work out cheaper over the years than renting.
Often the answer then is not either-or but hybrid. Take a production environment where machines continuously report measurements and are controlled directly. The part of the software that controls those machines runs on a server on the factory floor itself: fast, and independent of the connection to the outside world. That local part passes its data on to a cloud part, where planning, reporting and the integration with the ERP system run, and where management and field staff can reach it from anywhere. If the connection drops, the floor keeps working and the cloud catches up later. That is not a compromise, but a design that lets each part run where it performs best.
Five questions that decide the choice
Choosing where software runs doesn’t start with technology, but with a handful of questions about your organisation:
- What data does the system process, and where is it allowed to sit? What GDPR requires from your custom software applies wherever the software runs, and some sectors add their own rules on top.
- What does an hour of downtime cost, and who needs to be able to act when it happens?
- Which systems does the software need to connect to, and where do those run?
- How predictable is the load, now and a few years from now?
- Who will manage the environment, and what knowledge is in house for that?
In most projects the answers point towards the cloud, regularly towards hybrid, and occasionally towards fully self-managed. It is not the label that counts, but what fits your organisation, your data and your people. And the choice is less final than it looks: well-structured software can move later, as long as you haven’t grown too deep into one provider’s own services.
Facing this choice, or wondering whether your current system still runs in the right place? Developing custom applications includes advice on the environment they run in, and that conversation starts with your question, not with a data centre.