4 ms·

That's a very interesting point for me. Our company is in discussion with Pivotal to use PAS or PKS on prem. Do you have a specific example or something similar

That's a very interesting point for me. Our company is in discussion with Pivotal to use PAS or PKS on prem. Do you have a specific example or something similar what was the problem ? I've only seen the slides which should sell the products to OPS guys and the idea looked promising.

mothsonasloth 8y ago
I can only comment on PAS but the main issues I've experienced are: I have to login to PCF to check environments or add services to bind to an app. The CF cli is not very easy to understand compared to aws eb cli or herokus toolbelt The login screen says "email" but you actually have to enter your user ID Devops become your enemies, especially if they lock down PCF environments. I don't want to beg for a redis tile. PCF eats a lot of ram from our virtual servers. The PCF support is layered with different urgency levels, most of the time they ignore you or are slow to respond Basically I think it's a tool that gets in the way of developers and gives headaches to the platform team. However my company signed a contract with them, so we're tied in for a year.... I might quit before then
- codingminds 8y ago
  thanks for the answer
- twic 8y ago
  I remember being in a meeting with a client, with a Pivotal salesman alongside me, when the question of PCF's overhead came up. We managed to work out that a PCF installation required about 10 separate VMs before you even got to the ones that would run applications.
  - latchkey 8y ago
    The point being that those VM can be distributed across multiple hosts for scalability and reliability. I'm sure that if you wanted to really package it all up into a single VM, you could... but that wouldn't make much sense when you're building an onpremis deployment cloud.
    - twic 8y ago
      No, the ten VMs are not there for scalability or reliability, they're there because there are ten teams building the essential components of Cloud Foundry, and the BOSH model is that each component gets its own VM. You could squeeze them onto one VM, but that would require that CF teams cooperate on manifests. Inconceivable!
      - latchkey 8y ago
        Maybe you could fathom that the BOSH model is designed the way it is, for scalability and reliability purposes. The CF team is a bunch of Pivots... they cooperate quite well and probably better than most other teams, especially since they rotate across projects fairly often. Disclosure, I worked on CF in the early days, on a number of teams.
  - EngineerBetter 8y ago
    PCF is for those working at scale, and doesn't suit trivial deployments well.
    - twic 8y ago
      Someone really should have told the salesman that, then - they were trying to sell the client on the idea that they could have a separate PCF foundation for each project.
      - jacques_chester 8y ago
        > they were trying to sell the client on the idea that they could have a separate PCF foundation for each project. Cloud Foundry (PAS) is not designed to be used this way -- it had multitenancy designed in from the beginning. For PKS the idea of cluster-per-project makes more sense, given that Kubernetes doesn't reaaaally have multitenancy in the same sense.
      - EngineerBetter 8y ago
        Agreed - that is not how the platform should be used.
- insomniacity 8y ago
  I use PCF at work. I’ve noticed most of these but they didn’t really bother me... We have low timeouts on most logins anyway, so having it on PCF isn’t a big deal. We have a CI/CD workflow, so I don’t really have to login to the CLI that much. Locked down environments are always a pain - but it would be no different if your org locked down AWS or Heroku, which they could.
- EngineerBetter 8y ago
  > Devops become your enemies You're doing devops wrong, which may explain why you're having a bad time with the platform. > I have to login to PCF to check environments or add services to bind to an app. You should automate this with CI servers and pipelines. The complaints about RAM usage and support service I agree with. It sounds like your organisation is disfunctional, and its treatment of PCF is the symptom not the cause.
nunez 8y ago
PCF works best with the VMware stack (vSphere + vROPs) hence the sell to Operations. It is an absolute beast to install. You can do a PoC with PCF Dev to see what using it as a developer will be like, but the actual implementation of it will absolutely require Pivotal consultants to get going. PCF itself is also very expensive. I'm not sure if they charge per node or per app; they've changed it over the last few years. I would get the skinny on that before committing to anything and do a TCO/ROI analysis. If you are going to go this route, I would also consider doing a PoC with OpenShift or Rancher. These are managed Kubernetes offerings, both on prem. Both have free open-source editions that mostly mirror what you'll get in the Enterprise offering at smaller scale. Rancher is also less "enterprisey" in that they aren't as aggressive about enterprise support or upsells, at least from what I've heard. I think you'll be locked into big contracts with either option, but Pivotal's lock-in is tighter, at least from what I can tell. This could change after IBM fully moves in, however.

mothsonasloth 8y ago

I can only comment on PAS but the main issues I've experienced are: I have to login to PCF to check environments or add services to bind to an app. The CF cli is not very easy to understand compared to aws eb cli or herokus toolbelt The login screen says "email" but you actually have to enter your user ID Devops become your enemies, especially if they lock down PCF environments. I don't want to beg for a redis tile. PCF eats a lot of ram from our virtual servers. The PCF support is layered with different urgency levels, most of the time they ignore you or are slow to respond Basically I think it's a tool that gets in the way of developers and gives headaches to the platform team. However my company signed a contract with them, so we're tied in for a year.... I might quit before then

codingminds 8y ago
thanks for the answer
twic 8y ago
I remember being in a meeting with a client, with a Pivotal salesman alongside me, when the question of PCF's overhead came up. We managed to work out that a PCF installation required about 10 separate VMs before you even got to the ones that would run applications.
- latchkey 8y ago
  The point being that those VM can be distributed across multiple hosts for scalability and reliability. I'm sure that if you wanted to really package it all up into a single VM, you could... but that wouldn't make much sense when you're building an onpremis deployment cloud.
  - twic 8y ago
    No, the ten VMs are not there for scalability or reliability, they're there because there are ten teams building the essential components of Cloud Foundry, and the BOSH model is that each component gets its own VM. You could squeeze them onto one VM, but that would require that CF teams cooperate on manifests. Inconceivable!
    - latchkey 8y ago
      Maybe you could fathom that the BOSH model is designed the way it is, for scalability and reliability purposes. The CF team is a bunch of Pivots... they cooperate quite well and probably better than most other teams, especially since they rotate across projects fairly often. Disclosure, I worked on CF in the early days, on a number of teams.
- EngineerBetter 8y ago
  PCF is for those working at scale, and doesn't suit trivial deployments well.
  - twic 8y ago
    Someone really should have told the salesman that, then - they were trying to sell the client on the idea that they could have a separate PCF foundation for each project.
    - jacques_chester 8y ago
      > they were trying to sell the client on the idea that they could have a separate PCF foundation for each project. Cloud Foundry (PAS) is not designed to be used this way -- it had multitenancy designed in from the beginning. For PKS the idea of cluster-per-project makes more sense, given that Kubernetes doesn't reaaaally have multitenancy in the same sense.
    - EngineerBetter 8y ago
      Agreed - that is not how the platform should be used.
insomniacity 8y ago
I use PCF at work. I’ve noticed most of these but they didn’t really bother me... We have low timeouts on most logins anyway, so having it on PCF isn’t a big deal. We have a CI/CD workflow, so I don’t really have to login to the CLI that much. Locked down environments are always a pain - but it would be no different if your org locked down AWS or Heroku, which they could.
EngineerBetter 8y ago
> Devops become your enemies You're doing devops wrong, which may explain why you're having a bad time with the platform. > I have to login to PCF to check environments or add services to bind to an app. You should automate this with CI servers and pipelines. The complaints about RAM usage and support service I agree with. It sounds like your organisation is disfunctional, and its treatment of PCF is the symptom not the cause.

nunez 8y ago

PCF works best with the VMware stack (vSphere + vROPs) hence the sell to Operations. It is an absolute beast to install. You can do a PoC with PCF Dev to see what using it as a developer will be like, but the actual implementation of it will absolutely require Pivotal consultants to get going. PCF itself is also very expensive. I'm not sure if they charge per node or per app; they've changed it over the last few years. I would get the skinny on that before committing to anything and do a TCO/ROI analysis. If you are going to go this route, I would also consider doing a PoC with OpenShift or Rancher. These are managed Kubernetes offerings, both on prem. Both have free open-source editions that mostly mirror what you'll get in the Enterprise offering at smaller scale. Rancher is also less "enterprisey" in that they aren't as aggressive about enterprise support or upsells, at least from what I've heard. I think you'll be locked into big contracts with either option, but Pivotal's lock-in is tighter, at least from what I can tell. This could change after IBM fully moves in, however.