Hacker Newsnew | past | comments | ask | show | jobs | submit | more codingminds's commentslogin

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.


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


> 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


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.


I'd find a HN post about this project and it's results very interesting


There was an interesting post a few weeks back on Autotrader moving all of their online properties over to LetsEncrypt https://news.ycombinator.com/item?id=17949741


Certificate monitoring would be a good idea.


CTS Eventim: Linux administrator | Bremen, Germany | Full-time | Open space office | ONSITE

Multiple DCs in FFM, heterogeneous environment with custom developed applications mostly on Ubuntu. Also a Kubernetes environment for newer applications. SaltStack for configuration management, close collaboration with round about five main development teams.

Apply here: https://ctseventim.softgarden.io/job/2500811/Systemadministr...


> Microservices from a startup perspective: don't.

Like staticassertion already mentioned, it depends on the real project and problem to solve.

I've pitched a startup which started directly with an microservice like architecture. It was the best possible approach for the given problem.


We use Racktables [0] (currently migrating to Netbox [1]) and a naming scheme like $product-$environment$servertype-$optDetails0[1..n] with a well known set of abbreviations.

So if I need to check the production nameserver it's ns-pdap-01.internal.tld and so on.

[0] https://www.racktables.org/ [1] https://github.com/digitalocean/netbox



That's bad of course. But after a short time people can live there again. If something like Chernobyl or Fukushima happens the land is lost for decades and has a very huge impact (fallout, radioactive waste, groundwater contamination, etc.). You may argue that these are just two big incidents but with all the old plants with bad condition (e.g. Beznau, Fessenheim, etc.) in mind I'd say we'll see more bigger incidents in the next years.

In most discussions the time is ignored. Nuclear power plants already produced waste for many generations which is irresponsible.


You're seriously comparing thousands of dead people favourably to thousands of displaced people?


Both incidents kill many people. Hydro plant failures in short term - Nuclear plant failures in long term. Both is bad. But additionally nuclear plant failures also make the affected environment for a long time unusable. And I'd say harm more people because of the long term effects.



The problem with trotting out the Banqiao Dam as proof of the dangers of hydroelectric is that it was a dual-purpose dam built to prevent downstream flooding as well as providing power, and it failed due to mismanagement of the flood control aspect. So even if nuclear power had existed at the time, and even if the idea of building a nuclear power plant with the same quality of engineering used in the dam wasn't a utterly terrifying idea that would make Chernobyl look safe, not using hydroelectic power wouldn't have solved the problem. The dam would still have been built and those hundred thousand people would still have died due to dam failure, all that would changed is that nuclear proponents couldn't point to their deaths as proof nuclear is the safer option.


From 1: The total number of deaths, including future deaths, is highly controversial, and estimates range from "up to" 4,000 (by a team of over 100 scientists[9][3]) to the Union of Concerned Scientists estimate is approximately 27,000 based on the LNT model[10], to 93,000—200,000 (by Greenpeace[11]). Chernobyl: Consequences of the Catastrophe for People and the Environment, published by the Annals of the New York Academy of Sciences, but without NYAS explicit approval,[12][Notes 1] is a 2007 Russian publication that concludes that there were 985,000 premature deaths as a result of the radioactivity released.[13]

From 3: It has been reported that 90,000 - 230,000 people were killed as a result of the dam breaking.

I don't see your point


I made my point, I can’t help you if you refuse to see it.


Sometimes you don't expect such situations/events. And then it's to late.


When your European region exists: I'd love to see Hetzner(.com) connected.


Looks like they're in Germany/Finland. We'll try.


Be still my beating heart. Seriously? I would drop my Hetzner storage boxes in a heartbeat if I could connect to you instead on a fast link. I have, through the years, have used their auctions to snatch quite a few SSD only boxes and so I need external mass storage their network storage offer is ... ahem ... not the fastest! I would welcome something better :)


I'll second what the others have said. Especially their new Hetzner Cloud would be a perfect fit. It's one of the cheapest (if not the cheapest) cloud option I could find. Combining that with your B2 storage would be a perfect match.

And the best thing: They don't only focus on price but the quality is great as well.

And for us being a german/european provider is a bonus (GDPR).


Yeah Hetzner would be awesome. We already run some stuff over there so I could foresee spinning up some transcoders if you have connectivity there.


Just to second that. Hetzner has a great product in Europe for compute but they lack simple storage options. Connecting both would be great.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: