D2iQ (formerly Mesosphere) still supports the Mesosphere solution, which is designed for operations at a very large scale. It's powered by DC/OS, a production-proven cloud native platform that runs containers and data services on the same infrastructure.
D2iQ rebranded to reflect their change and broadening of focus towards Kubernetes but other services such as Cassandra, Kafka, and Spark. D2iQ also now offers IT professional services in tandem with its products.
N/A
Red Hat OpenShift
Score 9.3 out of 10
N/A
OpenShift is Red Hat's Cloud Computing Platform as a Service (PaaS) offering. OpenShift is an application platform in the cloud where application developers and teams can build, test, deploy, and run their applications.
Mesosphere is well suited for orchestrating workloads. It supports Docker as a container as well as support others. It is highly suitable for running resilient and auto recovering big data/application containers. Mesosphere has proven time and again to be production ready at a massive scale. It supports native single button/API call scale up and scale down and supports various deployment patterns like Blue-Green and others.
Stateful pods and DBs can be challenging to manage in OpenShifts. Depending on the configuration, lost deployments could result in data loss. The best use case for OpenShifts is any instance where agile and quick deployments are needed. Thanks to the OCP git runner, we can implement new builds across all environments quickly.
One thing is the way how it works with the GitHubs model on an enterprise business, how the hub and spoke topology works. Hub cluster topology works the way how there is a governance model to enforce policies. The R back models, the Red Hat OpenShift virtualization that supports the cube board and developer workspace is one big feature within. So yes, these are all some features I would call out.
Setting up is a bit of a hassle, especially ZooKeeper state management and mesos and marathon quorum.
Occasionally, I observed some failures when deploying something onto Marathon. Logging or detailed error reporting can help.
Stale containers and inconsistent states resultant of the cluster failure are hard to solve and need a complete system restart to get it back to normal state.
So I don't know that this is a specific disadvantage for Red Hat OpenShift. It's a challenge for anything that Kubernetes face is. There's an extremely large learning curve associated with it and once you get to the point where you're comfortable with it, it's really not bad. But beating that learning curve is a challenge. I've done a couple presentations on our implementation of Red Hat OpenShift at various conferences and one of the slides I always have in there is a tweet from years ago that said, "I tried to teach somebody Kubernetes once. Now neither of us knows what it is."
OpenShift is really easy of use through its management console. OpenShift gives a very large flexibility through many inbuilt functionalities, all gathered in the same place (it's a very convenient tool to learn DevOps technics hands on) OpenShift is an ideal integrated development / deployment platform for containers
The virtualization part takes some getting used to it you are coming from a more traditional hypervisor. Customization options are not intuitive to these users. The process should be more clear. Perhaps a guide to Openshift Virtualization for users of RHV, VMware, etc. would ease this transition into the new platform
Redhat openshift is generally reliable and available platform, it ensures high availability for most the situations. in fact the product where we put openshift in a box, we ensure that the availability is also happening at node and network level and also at storage level, so some of the factors that are outside of Openshift realm are also working in HA manner.
I've not noticed any significant performance impacts with Red Hat OpenShift. I think the development team has put a lot of effort into ensuring that it is performant. And so performance typically is not a major concern for us with Red Hat OpenShift.
Every time we need to get support all the Red Hat team move forward looking to solve the problem. Sometimes this was not easy and requires the scalation to product team, and we always get a response. Most of the minor issues were solved with the information from access.redhat.com
I was not involved in the in person training, so i can not answer this question, but the team in my org worked directly with Openshift and able to get the in person training done easily, i did not hear problem or complain in this space, so i hope things happen seamlessly without any issue.
We went thru the training material on RH webesite, i think its very descriptive and the handson lab sesssions are very useful. It would be good to create more short duration videos covering one single aspect of openshift, this wll keep the interest and also it breaks down the complexity to reasonable chunks.
I happen to like mesosphere because it integrates well with a Jenkins based workflow, Deis is a little more Heroku like and it's not clear how to fit that model into a continuous-integration process. Kubernetes has also been criticized for being complicated.
Our developer community is using Red Hat OpenShift for years and they are familiar and comfortable with the product. Red Hat OpenShift UI makes it easier for new developers to adopt without knowing much of Kubernetes. Our platform team feels it’s easy to mange the cluster and upgrades. Other options has more operation overhead and less friendly to developers not have in-depth knowledge of Kubernetes.
It's easy to understand what are being billed and what's included in each type of subscription. Same with the support (Std or Premium) you know exactly what to expect when you need to use it. The "core" unit approach on the subscription made really simple to scale and carry the workloads from one site to another.
This is a great platform to deployment container applications designed for multiple use cases. Its reasonably scalable platform, that can host multiple instances of applications, which can seamlessly handle the node and pod failure, if they are configured properly. There should be some scalability best practices guide would be very useful
