Over the past few months, I’ve spoken to people across a variety of companies, and one thing has become quite obvious: with today’s tooling, employees are eager and able(!) to build their own applications. Whether it’s a small script to automate a tedious task or a full-fledged web application to solve a very specific problem, they’re motivated to create solutions – both in their personal time (and often even on their own personal expense) and, increasingly, in a business context.
But there’s also a pattern that I recognized: There usually is no process and environment where people can simply deploy their applications in a business context. Those applications are built with great enthusiasm – an enthusiasm that you wouldn’t even create with cool company events – only to hit a wall when it comes to deployment. Employees either lack the infrastructure to run their applications, face weeks of approvals, or hit unexpected cost barriers – all of which kill innovation and drive shadow IT. The result? Wasted potential, security risks, and frustrated teams that could be building solutions for your business.
What if they also take the role of a hosting provider
This got me thinking: What if IT departments expanded their role? Instead of acting purely as a service provider for infrastructure and/or implementation, what if they also take the role of a hosting provider? What if they channeled this energy and provided a platform where employees could safely deploy their applications, turning shadow IT into visible, manageable, and secure IT?
But let’s be realistic: Even if IT wants to take on this role, it’s not as simple as buying a product off the shelf. External hosting providers like Hetzner or Strato have spent years refining their platforms because it’s their core business. For a company, building a comparable internal solution requires a considerable strategic investment in people, processes, and last but not least tooling and technology (which should also pay off!).
That said, the alternative of relying on closed-source, third-party solutions comes with its own risks. Vendor lock-in can be just as limiting as internal bureaucracy, and it can mean giving up control over data, costs, and future flexibility. The question isn’t just “Can we do this?” – it might also be “How do we do this without creating new dependencies?”
I mean, the goal can’t be to replicate Hetzner overnight – it’s to gradually build a platform that works for your company’s needs, with the same ease of use but tailored governance.
Imagine if companies would offer the same experience internally as one can have privaetly with a hosting provider: go to your internal software shop, request an environment and database and whether you need an AI connection or not. Depending on the size you have to bring budget, and there you go – including major connectivity enabled!
A platform team provides a deployment pipeline that handles everything from security scans to container deployment. The result? A hosting environment that’s just as scalable as what you’d get from an external provider. But with the added benefit of being tailored to your company’s needs. And the governance comes as an added value: Every requested environment is added to your internal inventory of applications, including contact person and the possibility to shut it down if something is wrong. No hidden applications on some mysterious servers or VMs somewhere. (Every hosting provider wants to know which application belongs to which client and whether the fees are paid!)
The key is to shift from manual processes to automated, self-service platforms. And with self-service I mean the full process from requesting to my own deployment. No meetings “to clarify” things, no additional requests, etc.
“This isn’t possible in our enterprise environment!” is what I’ve heard a lot. And I’ve listened to the reasons. The most common ones are:
You simply Have to Deal with Infrastructure
Well, I don’t even know if I want to argue there. Because with external hosting providers, I don’t have to. So why should I have to? No one could give me a valid reason why I have to deal with Terraform, service principals, key vaults, networking, and policies when all I want is to deploy a container, connect to a database, and serve a website. Decades of public hosting show that customers do not want or have to deal with the underlying infrastructure.
Btw: Ages ago, I used OpenShift. As a user: Amazing! Exactly what I wanted: A web portal where you just selected, for example, a Tomcat server, a relational or NoSQL database, hit okay, and there were the credentials, a git repo ready to push and deploy. Well – Until they decided to raise prices to an insane amount, and I left (I mentioned the vendor lock in above for some reason … I went through it myself).
Security and Deployment
Of course, such a deployment and application must fulfill corporate standards. Full stop, no discussion. But how is this enforced right now? And I mean technically enforced – not by scanning environments and reminding teams to add checks or maintaining lists of which teams do and which don’t. I mean enforced by: you can’t deploy if xyz isn’t fulfilled.
As soon as you allow independent teams to build their applications, in their own environments, I’m not convinced that you have this under 100% control right now. There will be some outdated deployment pipeline that doesn’t use the latest security recommendations.Or applications deployed once and then forgotten, running for years without updates or scans. Even when security checks are recommended, they might be inconsistent or overlooked in the rush to get things live.
But, consider: If your IT department already enforces regular security checks and container scanning, then providing a self-service platform won’t make things worse. In fact, it could make them better by standardizing the process and ensuring that every tool—no matter who builds it or how – goes through the same automated checks. Because those deployments are standardized and cannot be overridden.
And if your organization isn’t enforcing regular scans yet? Then the situation is already far riskier than it would be. A self-service platform with built-in security checks would be a massive improvement, ensuring that at least the basics are covered.
Of course, the key is of course to use the full range of available tools: static code analysis, dynamic security testing, container scanning, and dependency checks. And to run them automatically and frequently. This doesn’t eliminate all risks, but it ensures that applications aren’t deployed with outdated dependencies or obvious security flaws. If critical vulnerabilities are found, the responsible contact is notified, and the application can be taken down if necessary – automatically.
Compliance: Make Processes Efficient
Data protection was often cited as a reason to avoid self-service IT. But the core issue isn’t data protection per se – it’s that many companies’ data protection processes are inefficient, slow, and manual. If a process is broken, it needs to be fixed. But yes, if there is no will to fix or improve this, a platform will suffer from it as well.
But to be direct: The goal isn’t to cut corners on compliance – it’s to make it faster and more reliable than the current state. If your processes today are a bottleneck, then automation and standardization might be a possible way forward.
And of course it might be asked: is it the responsibility of the platform, whether a use case is legit? That all data protection rules are met? Or does this simply remain at the application owner? If you buy a car and your’re caught speeding, it’s your responsibility, not the one who sold the car or the company building the road.
IT as an Internal Hosting Provider
In some companies, IT teams still see themselves as gatekeepers out of fear of chaos or liability. And this isn’t bad per se: Business units usually aren’t IT professionals. They might violate rules on their first deployment attempt. But isn’t that more a point of clarifying the responsibilities? A Strato or Hetzner won’t pick up my application either. They might even shut it down if they see that it was hacked.
What I see as a responsibility here is to make automatic, robust and secure deployments including the scans. All applications must pass a this controlled, governed pipeline. And let’s face the inconvenient truth: Employees will build tools – with or without IT’s approval. The question is: Do they do it in the shadows, or within a framework that ensures security and compliance?
It’s Not a Silver Bullet
“But what about SOX, audit trails, high availability, …?”
Right! If an application has to fulfill very high standards, then this model might simply not be applicable, and it really should go to a specialized developer team.
“What if I have very special demands? This deployment pipeline can’t cover everyting!”
Exactly! Just look again at the hosting providers: There are predefined packages that you can book. If none of them fit, you have to go to a cloud and infrastructure provider!
There is no silver bullet, and self-service isn’t one either. But there are plenty of applications that don’t have to fulfill such standards. Think about many cases in marketing, brand or communication. Those are rarely SOX relevant or have scalability issues.
It Will Be an Investment
“Okay, sounds great, let’s do it! Go for it,” you might hopefully say. And hopefully, you’ll bring the according budget as well. In most companies, this will require quite some effort to develop such an environment and to change the corresponding processes. The bigger the company, the worse it might be. (especially the processes part!)
This change requires commitment from the company itself – not just from IT.
It’s All About Enablement
So it wouldn’t cover mission critical applications, no SOX relevant applications and no applications that are really really custom built that they can’t use the default deployment … Why should we even care?
Well – All the hyperscalers do care: they provide Agent frameworks from No code, to Low code to Pro code. Especially No and Low Code is “deployed” directly in their environment. – Just think about PowerAutomate. Do you have to deal with an IT environment to “deploy” your automation flow? I guess no.
I think, IT departments need to evolve. Instead of acting as developers and maintainers of every application or pure providers of infrastructure, they should take on the additional role of hosting providers – offering standardized, secure, and scalable environments embedded into security checks and automated governance.
Or I’m totally wrong and
- everyone will just make Agents that are deployed directly to the hyperscaler .. (yet I wonder which application those agents are then talking to).
- the effort to set such things up is just too big, especially when key stakeholders aren’t commited
Leave a Reply