Having done both significant work developing and maintaining first on-prem and then SaaS, I will never go back to on-prem. NEVER! It’s an overhead nightmare. You will always have stubborn customers that refuse to upgrade and demand support for a 3 year old system getting older by the day. And you’ll need to keep copies of old configurations lying around that can be ready in a heartbeat to debug some problem that inevitably impacts your SLA.
Maybe there are some cases where you may consider on-prem. But if you have a sufficiently complicated system and deployment, with a decent amount of customers, no amount of container magic sauce will fix the fact that you effectively give up control of the environment and upgrade path. Go on-prem, and enjoy the inescapable pain and suffering you are guaranteed to face.
EDIT - the above is a bit ranty and not in the context of the article, so I should note that for GDPR, the reasons given are IMO not good enough, and just offloads the problems to your customers, requiring more hassle for you in the long run. GDPR compliance isn’t something that is solved with a technical and operational punt. And making the improvements in your own SaaS will be easier technically, operationally, and compliance-wise. We are neck deep in GDPR refactoring (organization and system wise), and if you make good informed design decisions the regulation will end up improving your application and your processes. An on-prem system still needs to do this. You would still need to be able to give end users their data inventory and right to be forgotten. But with on-prem you now need to train all your IT customers how to use it, and deal with all the overhead of things inevitably going wrong or being misunderstood.
Saying GDPR is a good reason to go on-prem is like saying fire-safety is a good reason to have lots more houses.
We are neck deep in GDPR refactoring (organization and system wise), and if you make good informed design decisions the regulation will end up improving your application and your processes.
Well said.
The issue I see at times is people trying to workaround GDPR instead of embracing it.
And if you embrace it, you just see how much more control you get on your system, for example:
it forces you to understand those components that just work but nobody want to touch
it forces management to ponder the legal risks of bad engineering practices, carefully pondering if “move fast and break things” is a good idea, after all
it forces you to add tons of logs and updated documentation, to be able to explain automated decision in court
it forces you to adopt basic engineering practices like automated build and test processes, to be able to reproduce everything in a digital forensic environment
All in all, GDPR is one of the best laws I’ve read in ages.
It’s designed to protect people by improving software quality.
Related, but when the company I worked for previously was purchased by a publicly listed US company, the SarbOx regulations forced us to implement much better processes for development. For example, a QA department was mandated (we didn’t have one before).
Regulations can be onerous, but the best way to handle them is to try to work them to your favor.
You will always have stubborn customers that refuse to upgrade and demand support for a 3 year old system getting older by the day.
Sounds like you can just force the upgrade or deny service like the cloud players do. You have to be willing to loose some customers. Some subset of these will upgrade because the reason they don’t is that the behavior is tolerated.
This is a pretty interesting take that I hadn’t thought of before. Some comments:
In my mind, GDPR (hopefully) shouldn’t influence business behavior – whether or not your company delivers software via on-prem solutions or SaaS solutions is an outcome of some combination of headcount, cost, and other factors. Also anecdotally, selling SaaS products is much much easier.
On that note, I see GDPR as the logical response to our SaaS world and ultimately an improvement of it. Having worked at a few SaaS companies that worked with medium to large data, I can say with a certainty that companies weren’t thinking about a full purge of data when a customer leaves, even if they request it. SOC2 and it’s ilk are arcane and very poorly enforced. Let’s hope this is better – things like recent Palantir stories in the news show how necessary legislation like this is.
One last thought – I’m now wondering how GDPR will influence software that companies make their employees use. Could I as an employee request data a third party vendor is keeping regarding me on behalf of my employer?
Having done both significant work developing and maintaining first on-prem and then SaaS, I will never go back to on-prem. NEVER! It’s an overhead nightmare. You will always have stubborn customers that refuse to upgrade and demand support for a 3 year old system getting older by the day. And you’ll need to keep copies of old configurations lying around that can be ready in a heartbeat to debug some problem that inevitably impacts your SLA.
Maybe there are some cases where you may consider on-prem. But if you have a sufficiently complicated system and deployment, with a decent amount of customers, no amount of container magic sauce will fix the fact that you effectively give up control of the environment and upgrade path. Go on-prem, and enjoy the inescapable pain and suffering you are guaranteed to face.
EDIT - the above is a bit ranty and not in the context of the article, so I should note that for GDPR, the reasons given are IMO not good enough, and just offloads the problems to your customers, requiring more hassle for you in the long run. GDPR compliance isn’t something that is solved with a technical and operational punt. And making the improvements in your own SaaS will be easier technically, operationally, and compliance-wise. We are neck deep in GDPR refactoring (organization and system wise), and if you make good informed design decisions the regulation will end up improving your application and your processes. An on-prem system still needs to do this. You would still need to be able to give end users their data inventory and right to be forgotten. But with on-prem you now need to train all your IT customers how to use it, and deal with all the overhead of things inevitably going wrong or being misunderstood.
Saying GDPR is a good reason to go on-prem is like saying fire-safety is a good reason to have lots more houses.
Well said.
The issue I see at times is people trying to workaround GDPR instead of embracing it.
And if you embrace it, you just see how much more control you get on your system, for example:
All in all, GDPR is one of the best laws I’ve read in ages.
It’s designed to protect people by improving software quality.
Related, but when the company I worked for previously was purchased by a publicly listed US company, the SarbOx regulations forced us to implement much better processes for development. For example, a QA department was mandated (we didn’t have one before).
Regulations can be onerous, but the best way to handle them is to try to work them to your favor.
Sounds like you can just force the upgrade or deny service like the cloud players do. You have to be willing to loose some customers. Some subset of these will upgrade because the reason they don’t is that the behavior is tolerated.
This is a pretty interesting take that I hadn’t thought of before. Some comments: