[wdewind]

> This is, in theory, why microservices with APIs mean that it really doesn't matter.

No it still really does matter, because if your company needs to deploy those microservices in different ways then you need more people to support the deployment infrastructure. If you need to test those microservices in more ways you need more people to support the testing infrastructure. For engineers it's the amount of friction felt when trying to move around and work on new and different problems in your company because they're one of five people who knows how the hell the Java infrastructure works.

If you have an existing testing and deployment infrastructure etc. your team gets those for free and doesn't need to reinvent (and support) those wheels.

> As long as there are sufficient hire-able engineers who know that technology, it can be used.

Yikes. Hiring and firing engineers is pretty hugely expensive and something you want to help avoid having to do.

[jacques_chester]

> No it still really does matter, because if your company needs to deploy those microservices in different ways then you need more people to support the deployment infrastructure.

This is what PaaSes make a non-problem.

I should know, I worked on Cloud Foundry Buildpacks.

Here's how to deploy the PHP app:

    cf push your-php-app

And the Nodejs app:

    cf push your-nodejs-app

And hell, why not a Ruby app too:

    cf push your-ruby-app

And let's not forget that Python microservice:

    cf push python-code-works-the-same-way

We also kept up with the cool kids:

    cf push your-go-code-with-a-godeps-file

And for the "boring" crowd:

    cf push your-java-app-too

In general, these are all intended to Just Work™.

You know how making these surprisingly unalike systems deploy identically is really hard?

So does Heroku, from whom a large body of Cloud Foundry buildpacks code is derived. So did we, when we found issues specific to making code that assumes a connected environment work in a disconnected environment.

The point is, if you're doing this all by hand, you're doing it wrong. You should rent or install a PaaS and move along to the part where you create value instead of inventing a cool-sounding wheel.

[wdewind]

> The point is, if you're doing this all by hand, you're doing it wrong. You should rent or install a PaaS and move along to the part where you create value instead of inventing a cool-sounding wheel.

That makes a lot of sense for small organizations, but I'm sorry PaaSs absolutely do not scale to the needs of many organizations.

> In general, these are all intended to Just Work™.

My emphasis added. When they don't Just Work it's really nice to own that infrastructure and be able to fix it yourself. It's also nice to be able to tailor things more specifically to your needs. Again, I agree that owning that infrastructure is not the right solution for organizations of all sizes, but neither are PaaSs.

[jacques_chester]

> That makes a lot of sense for small organizations, but I'm sorry PaaSs absolutely do not scale to the needs of many organizations.

Outside of the giants who rolled their own because there was nothing around in the early 2000s, who?

> When they don't Just Work it's really nice to own that infrastructure and be able to fix it yourself.

Cloud Foundry is specifically designed to run either in the public cloud, the private cloud, or both. You can get it hosted it from Pivotal or IBM, amongst others.

The work of my peers and I made that possible.

> It's also nice to be able to tailor things more specifically to your needs.

Cloud Foundry is opensource and the IP belongs to an independent foundation. I am personally aware of at least two companies who have private forks of buildpacks because that suited their extremely precise requirements. It took them about two developer days, tops.

And their modified buildpacks also Just Work™, because they're based on a robust design that Just Works™.

[wdewind]

That's really cool, I did not know about that. You were talking about PaaS and Heroku, which I don't think is the same as forking an OS project and owning it yourself, which is fine for what I was talking about. I don't think it's difficult to name companies for whom Heroku is not appropriate. Regardless, it's all about where you draw the line, gradations not black and white.

I still stick to my main point: your organization gets a massive benefit by all using the same toolset. If you are using Cloud Foundry, I'd still suggest the whole company stick with one language, one deployment infrastructure etc.

To be clear, if you're google I'm not suggesting the entire company all be forced to use one language or something. In that case your company is likely working on products that are different enough that it makes sense to do away with some global optimization. Some judgment is obviously required. But if you're in the sub-500 range (which the vast majority are) it makes a lot of sense to really optimize globally with your toolset, even if deployment infrastructure is relatively easy to setup.

PS I love that you are using the phrase Just Works - the company I work for is called Justworks :)

[jacques_chester]

I mentioned Heroku for two reasons. First, they are the pioneers of public PaaSes. Second, several Cloud Foundry buildpacks are extensions of Heroku's buildpacks.

I think that the nice thing about something like CF is that a whole range of problems just goes away. On the other hand, as Weinberg observed, when you solve the worst problem, the second worst problem gets a promotion :)

Cloud Foundry doesn't get much buzz on HN. But I'm a one-eyed bigoted fan, so I mention it whenever I can. I'm actually a Pivotal Labs employee, my main work is agile consulting. But I've seen enough gigantoglobomegacorps who are choking on their own impossibly heavyweight deployment/ops mechanisms that I am a bit of a bore about talking up Cloud Foundry.

[wdewind]

It definitely sounds awesome. We've got a pretty simple deployment system at the moment and so it's a solved problem for us, but when it starts to breakdown we'll definitely take a look at CF.