OneOps – Open-source cloud ops platform from Walmart
oneops.com
oneops.com
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.
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.
At the moment it supports any cloud with a OpenStack endpoint/integration.
Blog post: http://www.walmartlabs.com/2016/01/oneops-now-available/
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.
- What types of systems are these?
- When you say "40 year history", do you mean the system was originally written in the 70's, or do you mean it has data going back to then?
- Why do you need to keep data for 30 years? Regulatory reasons? Reporting? Or just long-lived data?
I'm not doubting anything you're saying. It's easy to imagine systems with those attributes, say, in banking, insurance, legal records, etc. I'm just curious about your specific case. :)
Long after the logic of your system has been replaced, the data will live on. It's something I think people tend to undervalue.
.gov stuff. Every state in the union has social services systems that were stood up in the 60s and 70s, and have or are being transitioned over time from whatever mainframe they were in to modern stuff.
Usually the long term stuff is retained. These folks deal with situations like disabled children who become wards of the state. Their records need to exist well until those children are in their 40s.
Thats just one example -- Public works projects are built with 50+ year lifespans, and many of those records are expected to exist for at least that long.
There's also a whole historical responsibility thing that I think will become more important. You can develop a deep understanding of how a governor or Mayor made certain decisions going back to the American revolution (my county has records of the legislative body from the Dutch colonial period). Digitalization has erased a lot of that -- in many cases we cannot read data from the 1980s.
I think issues like this are already starting to appear on a small/personal scale -- when my grandfather died in 1980s, all of his business records, personal records, pictures, etc were on paper somewhere in his home. You could sift through and keep important things. What do you do when the only protection your data in Dropbox/et al is one missed credit card transaction away from oblivion?
BTW, I think you're 100% correct about this becoming more important / more of a visible problem. On a small scale, it's something I wrestle with often. For example, I love the convenience of buying a book on my Kindle, but I'm reminded of the joy of wandering through my grandparents' library and wonder if my daughter (and so on) will be able to have a similar experience – what happens to those my Amazon purchases after I'm gone? Another example is that I keep a sporadic journal in Evernote. Should I really be printing out those writings in case I have a curious descendant? I've enjoyed reading letters and journals of ancestors.
On the other hand, digitalization has obvious benefits too. But we have to be deliberate in our curation and storage format.
For example, it's great that correspondence (email) is now automatically archived rather than it being a tedious process (carbon copy, hand-copying, etc.). But how many people backup their email out of their cloud provider to a personally owned copy in a human-readable format? I actually do backup my Gmail account occasionally. But I doubt my wife knows where it is. Or if she'd be able to look past the XML format. And even if she did, there are literally millions of emails in there from mailing lists and work stuff and spam and whatever. The percentage of actual meaningful correspondence is unbelievably low.
I don't know. It's a big problem, I think.
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.
Looks fairly complete and extensible, though.
And by the way, it's not just OpenStack. Looks like it's also tooled for AWS.
Has anyone seen anything talking about resource requirements for deploying this? The fact that Cassandra, ElasticSearch, PostgreSQL are all involved plus much more makes me think the requirements must be quite high.
Edit: nevermind http://oneops.github.io/admin/prerequisites/
http://oneops.github.io/admin/key-concepts/#oneops-system-ar...
Side note, every-time I see an enterprise message bus, I throw up in my mouth a little.
It's the cloud equivalent of a Super Wal*Mart
https://www.openstack.org/summit/vancouver-2015/summit-video...
You might also want to quickly gain a presence in a geographical region you don't have hardware in (ever or yet).
* cloud bursting during high load
* disaster recovery
* putting things in geographic regions where they don't have their own hardware
Since Amazon is basically Walmart without brick and mortar and they make some compelling money from their AWS, why wouldn't Walmart be interested in getting in to that business?
Christmas / Thanksgiving shopping in the US would be my guesses.
They should have put up a blog post with an overview like this one: http://techblog.netflix.com/2015/11/global-continuous-delive...
At my previous employer the loaded TCO for running in-house OpenStack was 45-50% of AWS (the company used both).
If you have the talent and scale it's certainly doable, and like I said, we were at less than half of AWS. There are plenty of examples, one that comes to mind that is NOT hyper-scale is Server Fault.
Why, for the love of God, why?
Disclaimer: I am a programmer at StackStorm. I'd be happy to help.
Edit: Full disclosure, I am the founder of ContainerShip.