> 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.
> 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.
> 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™.
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 :)
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.
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.
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:
And the Nodejs app: And hell, why not a Ruby app too: And let's not forget that Python microservice: We also kept up with the cool kids: And for the "boring" crowd: 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.