3 ms·

> If Otto wants to gain mindshare of the devops people who will be forced to support it, I strongly suggest they reconsider their branding. It sounds like Otto

by biomene 11y ago

> If Otto wants to gain mindshare of the devops people who will be forced to support it, I strongly suggest they reconsider their branding. It sounds like Otto isn't aimed at devops people at all. It's aimed at the poor (in the material sense) developers who have to churn out 10 Wordpress sites a year to make a living wage and don't want to spend half their time figuring out how the permission system works.

gcr 11y ago
That's....a great point. As the saying goes, "If you don't like the advertisement, you're not in the target market."
- jacques_chester 11y ago
  On Cloud Foundry we've found that we get buy-in from both operators and developers. Operators heave a sigh of relief: "Finally, I don't have to clean up after devs! They can't break the platform for everyone else! I don't get 3AM phonecalls to fix someone else's mess!" Developers heave a sigh of relief: "Finally, I can just deploy without dealing with suspicious operators! If it breaks I don't get berated by an operator who got a 3AM phonecall!" I imagine OpenShift and Heroku guys can tell the same stories. I work for Pivotal Labs, so I get to see projects with PaaSes and projects without PaaSes in a variety of companies, on a variety of platforms, with a variety of goals. But one thing remains constant: PaaS-deployed projects are easier. In a PaaS-deployment project, you set up your credentials, set up CI/CD, then you just get on with doing the thing that matters: building a product. In non-PaaS projects, you spend eye-blistering amounts of time and money trying to just deploy the damn software. The whole feedback loop turns into a tangled pile of spaghetti behind somebody's bespoke deployment process. Backpressure causes enormous shear stresses throughout the project because development is iterating quickly but there's no way to, you know, see if the users like it or to know if it actually works in the real environment. It always boggles my mind that folk are happier to squander amazing amounts of engineering time and salary dollars instead of just renting or installing a PaaS.

by biomene 11y ago

gcr 11y ago

That's....a great point. As the saying goes, "If you don't like the advertisement, you're not in the target market."

jacques_chester 11y ago
On Cloud Foundry we've found that we get buy-in from both operators and developers. Operators heave a sigh of relief: "Finally, I don't have to clean up after devs! They can't break the platform for everyone else! I don't get 3AM phonecalls to fix someone else's mess!" Developers heave a sigh of relief: "Finally, I can just deploy without dealing with suspicious operators! If it breaks I don't get berated by an operator who got a 3AM phonecall!" I imagine OpenShift and Heroku guys can tell the same stories. I work for Pivotal Labs, so I get to see projects with PaaSes and projects without PaaSes in a variety of companies, on a variety of platforms, with a variety of goals. But one thing remains constant: PaaS-deployed projects are easier. In a PaaS-deployment project, you set up your credentials, set up CI/CD, then you just get on with doing the thing that matters: building a product. In non-PaaS projects, you spend eye-blistering amounts of time and money trying to just deploy the damn software. The whole feedback loop turns into a tangled pile of spaghetti behind somebody's bespoke deployment process. Backpressure causes enormous shear stresses throughout the project because development is iterating quickly but there's no way to, you know, see if the users like it or to know if it actually works in the real environment. It always boggles my mind that folk are happier to squander amazing amounts of engineering time and salary dollars instead of just renting or installing a PaaS.