Slightly nitpicky, but is something a PaaS if you run it yourself? Anything as a Service isn't a service if you're running it yourself. It's just ... infrastructure.
This product is undoubtedly the P in PaaS, but there is no service behind it. If your company uses this as an alternative to a real Heroku/AWS/xyz PaaS, you must have engineers at hand for 24/7 ops, scaling servers and fixing bugs. In my opinion, this is quite risky for anything running in production and should not survive a cost-benefit analysis.
I completely disagree, the difference of price between dedicated servers and even EC2 instances is completely amazing.
This is what you get for less than $200/month with a dedicated server:
1× AMD EPYC 7281 CPU - 16C/32T - 2.1 GHz, 2 × 1 To NVMe, 96 Go DDR4 ECC, unmetered 750 Mbps
In one of my companies the AWS bill is just completely insane, we have like half that hardware, with a really small bandwidth, which is metered, for more than $800/month, which is fine while we're on free credits.
I love working for cloud companies, it's a lot of fun, but when it comes to my money then I never go for anything but a dedicated server.
As an example of the latter bit, if you are running your own hardware and need to add another host and you do not have a spare lying around, then you need to order one. It has to be shipped. Someone has to unpack it. Someone has to make sure that the data centre has sufficient power. Someone has to install it, its power and its network cables. Each of these steps takes time, but also each step is an opportunity for friction.
By contrast, with a service, you would just add a new host. Five minutes later you are up and running. That gives you an operational nimbleness that you wouldn't otherwise have had.
And my experience from providing devops services to clients on a contract basis is that the clients who use cloud services tends to need more, not less, devops assistance.
Servers, for the most part, just work. In DC climate-controlled environments, hardware failures is exceedingly rare. Apart from harddrives, most hardware will happily tick along for a decade, if not longer.
Sane production-grade OSes (read: not Ubuntu) will also happily run for literal years with zero human intervention. For obvious reasons, it's a bad idea to not patch your systems, but things will continue to "just work" pretty much forever unless you're running really shitty code.
For renting vs buying servers, there's upsides and downsides. Buying gear is far far cheaper if you plan to be around for more than a year, but renting dedicated servers gives you a lot more flexibility -- to provision a new server, you hit a button in their online panel, wait 15 minutes, then let your deployment strategy take care of the rest.
I find it almost mind-boggling that AWS and friends have convinced people that it's normal to spend ridiculous amounts of money for fairly "meh" service specs in what's essentially VMs.
Not to mention that at that scale you have plenty of redundancy and, if your ops team knows what they're doing, automagic failover / HA. Anything that happens can easily "wait till Monday", no need for 24/7 anything.
When you got applications that don't require high availability while needing a very low cost per CPU, dedicated servers just make sense. We are running a cluster of a few high-CPU dedicated servers for our data-science team, and it just makes sense: we don't need 99.99%+ availability, and the servers we rent are cheaper than the equivalent AWS storage cost alone ... The op cost of managing these is exactly the same as managing equivalent EC2 instances. We don't need backups either.
On the other side, we got some low-CPU web services that require high availability, redundancy and reliable backups. For these I just use Heroku. It's extremely reliable and easy to operate, while only costing about $100/month (a few hobby dynos + a fully managed PgSQL DB). Sure it's probably 5x more expensive than a dedicated server with 10x the performance, but I don't have to worry about backups, availability and scalability. And these apps just don't need this 10x faster CPUs anyway.
How do you handle Heroku outages then?
I am not affiliated nor haven't tried CapRover (for special reason of: coding my own for my tastytastes), but I would bet any standard system administrator could get a 99.9% uptime after the second month of production without particular effort (unless they don't know underlying technologies ie. "what a container" "what http" "what is namespace" "what iptables" ...)
The idea is that you ask OpenStack a VM and it will give it to you, dealing with the lower level details for you.
PaaS means that you ask it to deploy a service and it will deploy it for you, dealing with lower level details for you.
You're probably more likely to see OpenStack called a private cloud or on-prem cloud than "IaaS" these days. And OpenShift is usually called a Container Platform rather than a PaaS.
"Container platform" seems pretty vague to me, PaaS means something I know right away.
I mean, k8s is a container platform too isn't it ? But you'll need to build what we called a PaaS on top of it yourself (or use something like Kelproject, OpenShift ...)
PaaS isn't a verboten term or anything like that. But it turns some people off because it was most associated with services/products/projects that mostly focused on a simplified developer experience at the cost of flexibility.
k8s for me is a framework, OpenShit, Rancher, KelProject would be "distributions" of k8s, just like Linux kernel and distributions including it.
As a person who writes technical requirements and implementation document, it strikes to me when I'm asked to document implementation of a "SaaS" that there will be paid accounts and billing.
Maybe CapRover will provide paid accounts on managed servers in which case they would be creating a SaaS with their PaaS solution.
But again I'm not talking from a "managerial" perspective of the definitions, rather from a technical one. I suppose at this stage CapRover is trying to attract technical users rather than managerial ones (unless they have something to sell for cash but I didn't see it on their site or just missed it)
Many IT depts would do themselves a massive favor to deliver actual services instead of “just infra and some stuff thrown on top” and call it service delivery.
Tools like in this link can help, but a big part is simply about automation and delegation/self provisioning.
Platform as a Service or anything "as a Service" means someone else provides it as a service (ie subscription). The Platform part is all this is offering. So it is not a Platform as a Service.
It is not necessarily hard tied to a business model, but of course I understand that this is the common usage.
It’s really about abstractions and consumability.
This is my interpretation of the NIST meaning of aaS.
My read on whether something is a service or not is, can I make a request of the thing in simple terms, and have the thing carry out all the messy details on my behalf?