Hacker News Reader

Hacker News

Comment by mothsonasloth | Hacker News Reader

Parent Full thread

mothsonasloth

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

View on HN

> 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.

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.

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.

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.

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!

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.

PCF is for those working at scale, and doesn't suit trivial deployments well.

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.

> 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.

Agreed - that is not how the platform should be used.

thanks for the answer

Reply on news.ycombinator.com