3 ms·
Here's how I deploy code, without having to modify it: cf push myapp It figures out the language/runtime I'm using (Java, Ruby, Go, NodeJS, PHP), builds t
by jacques_chester 11y ago
Here's how I deploy code, without having to modify it:
cf push myapp
It figures out the language/runtime I'm using (Java, Ruby, Go, NodeJS, PHP), builds the code with a buildpack, then hands it off to a cloud controller which places it in a container. My code gets wired to traffic routing, log collection and injected services. I can deploy a 600Mb Java blockbuster using 8Gb of RAM per instance or I can push a 400kb Go app that needs 8Mb of RAM per instance.
I don't need to read special documentation, I don't need special Java annotations.
I just push. And it just works.
I'm talking about Cloud Foundry. It runs on AWS. And vSphere. And OpenStack. It's opensource and doesn't tie you to a single vendor or cloud forever.
I worked on it for a while, in the buildpacks team, so I'm a one-eyed fan.
Seriously: why are we still talking about devops? It's a solved problem. Use Heroku. Install Cloud Foundry. Install OpenShift. And get back to focusing on user value, not tinkering.
Disclaimer: I work for Pivotal Labs, part of Pivotal, which donates the largest amount of engineering effort on Cloud Foundry (followed by IBM).
- cpitman 11y agoBecause DevOps != CICD, and a PaaS doesn't cover the most important parts of DevOps (creating feedback channels between your Dev and Ops teams and a structure for continuous process improvement). PaaS just makes life easier by reducing the amount of communication needed. It's more like a fancy wall that makes it easier for developers to throw code over it.
- jacques_chester 11y agoI'm not sure I agree (insofar as CI is in our DNA and CD is what we're trying to make normal). To me the point of PaaS is to remove the need for a specialist gatekeeper in the feedback loop. It makes Ops happy by isolating the damage Devs can do. It makes Devs happy by removing Ops roadblocks and allowing Devs to see, immediately and directly, what their apps are doing. Classic ops culture emerged because computing was an expensive shared resource. Early tooling favoured utilisation over isolation because the latter is expensive. So it became possible for devs to accidentally or deliberately step on each other's toes. Ops was like the mature adult in a shared house: making sure everyone kept their junk out of the living room, restocking the bathroom, insisting that dishes get washed. With a PaaS that changes radically. Devs can't burst out of the box they assign themselves, subject to Ops-set resource pools. Ops hands Devs keys to personal apartments that are created on demand. What they do inside is up to them, Ops needn't worry or care.
- MichaelGG 11y agoAs a note, I decided to look up CF based on this comment. This lead me to cloudfoundry.org, which appears entirely devoid of content. Just useless talk about "heavyweights" and so on. The menu didn't appear to have any links to anything useful either. Clicking on products lead to a page with three product names. Having visited the site, I'm actually now negatively disposed towards it (but your comment outweighs my experience, and I'll still attempt to check it out). Granted I only spent a minute, but if this is a typical experience, I'm unsure how anyone would come to the conclusion that there's any software worth using there.
- jacques_chester 11y agoFrankly, I agree with you. We suck at developer outreach. It bugs me. Unless you know where to find the docs[0], they're not obvious. There's a single master repo[1], but it's oriented at deployment and works by aggregating dozens of sub-projects[2] into a BOSH release and BOSH deployment. ... which requires you to know what the hell BOSH[3] is ... So recently we started trying to make it easier. The best place to start tinkering is Lattice[4], which is a cutdown extract of Cloud Foundry. or Pivotal Web Services[5]. Or IBM BlueMix, I guess[6]. [0] http://docs.cloudfoundry.org/ http://docs.cloudfoundry.org/ [1] https://github.com/cloudfoundry/cf-release https://github.com/cloudfoundry/cf-release [2] https://github.com/cloudfoundry https://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator https://github.com/cloudfoundry-incubator [3] http://bosh.io/docs http://bosh.io/docs [4] http://lattice.cf/docs http://lattice.cf/docs [5] https://run.pivotal.io/ https://run.pivotal.io/ [6] https://console.ng.bluemix.net/ https://console.ng.bluemix.net/
- MichaelGG 11y agoThanks for the links, much appreciated! How does CF compare to go.cd? Will there be a lot of setup work required?
- jacques_chester 11y agogo.cd fills a different role. Funnily enough go.cd was the main CI system used for Cloud Foundry, though it's being steadily replaced by concourse.ci. Cloud Foundry is a bear to install because you will probably wind up needing to wrap your head around BOSH, the IaaS orchestration tool. Once you get past that hump it's relatively obvious. Getting past the hump is tough. Bear in mind that it's a complete PaaS. The kind of thing you bet your company on (and our customers do). BOSH is a heavyweight system that predates a lot of later tools like Terraform or Cloud Formation. On the other hand, we use BOSH to update Pivotal Web Services to the latest cf-release every 2 weeks or so and basically, nobody ever notices. It just works. The easiest way to start is either Lattice or a public Cloud Foundry installation. The former has the advantage of being easy to install on a laptop, and it's intended for developers to tinker with. The latter has the advantage that someone else ran `bosh deploy` and is provisioning the VMs that Cloud Foundry runs on. Pivotal Web Service (based on AWS) and IBM BlueMix (based on SoftLayer, I think) are the two main ones.