51–60 of 82 posts
Earlier quoted context omitted.
Does that not mean that you can then only use the common aspects from the various cloud providers, and miss out on the additional features each supports?
The general rule of thumb for building big things that work long term is build anything in-house that you can't source from multiple vendors.
Earlier quoted context omitted.
Does that not mean that you can then only use the common aspects from the various cloud providers, and miss out on the additional features each supports?
The general rule of thumb for building big things that work long term is build anything in-house that you can't source from multiple vendors.
Earlier quoted context omitted.
You just gotta love IT departments at non-tech corporations. Shudder
So you mean the IT departments that represent the majority of all businesses in the entire world? Yes, they work their butts off.
Earlier quoted context omitted.
I was just about to post the same thing. So much business-speak, no idea what in the world this could be.
You might want to brush up on business speak, that's the real reason for writing the vast majority of all software ever written or that will be written in this century.
Also, keep in mind that different industries are accustomed to different sets of terminology. Engineers at tech companies don't usually use terms such as "product delivery" and "Continuous Application Lifecycle Management." To us, "multi-cloud orchestrator" is a much clearer way to describe this technology.
No need to be so condescending.
Earlier quoted context omitted.
Thank you. Now that you've summarized this, this sounds like a great idea, a good way to kill lock-in on cloud platforms. I don't know why they couldn't write something so simple and concise...
...kill lock-in, as long as everyone in the whole world acts like an OpenStack interface. Not interested.
I'm sure if you want OneOps to support a non-OpenStack interface that should be possible too, they already support Microsoft Azure for example.
"Accelerating product delivery in the Digital Economy through Continuous Application Lifecycle Management of Cloud-based Workload, backed by @WalmartLabs" I think you could work on that elevator pitch a little - it seems like it's been workshopped by a committee, and doesn't really tell me anything.
I was just about to post the same thing. So much business-speak, no idea what in the world this could be.
Earlier quoted context omitted.
Thank you. Now that you've summarized this, this sounds like a great idea, a good way to kill lock-in on cloud platforms. I don't know why they couldn't write something so simple and concise...
Does that not mean that you can then only use the common aspects from the various cloud providers, and miss out on the additional features each supports?
If you need a 10 year business plan for a service, you need to limit your choices. I have systems with 40 year history that need to retain data for 30 year into the future. Different thinking.
The chef code that deploys all the apps is pretty old skool, copy pasta'd from opensource cookbooks in alot of places, will never pass food critic or rubocop, and has no tests. I wouldn't really want to run that code on anything.
Because opensource cookbooks are unreliable or people should only rely on your cookbooks? Or old skool isn't new skool so it should be wholly disregarded?
"Accelerating product delivery in the Digital Economy through Continuous Application Lifecycle Management of Cloud-based Workload, backed by @WalmartLabs" I think you could work on that elevator pitch a little - it seems like it's been workshopped by a committee, and doesn't really tell me anything.
You just gotta love IT departments at non-tech corporations. Shudder