IBM Cloud Foundry

IBM Cloud Foundry is our first choice industry-standard platform as a service (PaaS) which has always provided us with quicker, simpler, and more consistent ways for the deployment of the cloud-native applications which in result saved us lots of time and money.

IBM Cloud Foundry is easier and faster to get going and offers the same benefits we needed.

When I started with prototyping five months ago, I tried IBM Cloud Foundry and AWS, but finally I preferred IBM Cloud Foundry.

I selected IBM Cloud Foundry because IBM service CLI is quite simple to use in devops. It works with the recent versions of Python and it's not changing my Mac OS environment (and it doesn't try to install old versions of Python on my laptop as AWS CF CLI does). In addition, many IBM services provide free trials, so I don't need to pay for it during the system selection and prototyping stages.

Why I prefer IBM Cloud Foundry platform over AWS Elastic Beanstalk or Heroku Platform is the automation of development process and pushing of projects to cloud with clear step by step instructions - which is available on the documentation. I can say categorically, the terminal mode of interaction with IBM Cloud Foundry, which I can use to customise settings for my project - which is not limited to setting of custom route - selecting region which the application will be serve from. Availability of enough terminal commands, well written documentation with affordable price packages.

IBM Cloud Foundry is easy to use and allows for fast and easy deployment of web apps.

IBM Cloud Foundry provides many programming languages. It is a managed service and it allows us to use only the resouces without the managed overhead.

Ease of use and all the capabilities we need are well built-in. Though we had to work around for p2p security and log draining which is not bad.

IBM Cloud Foundry (CF) is simpler and there is a service model that fits most of our internal services. We are going to Loopback for API and Node.js and we have an easy path to go with Bluemix. It's a very easy way to start if you are moving to the cloud and mainly if you are going to Node.js.

You can use CF to keep your old Frontends with PHP, Asp or Ruby while moving your APIs to other services inside Bluemix. API Connect is particularly good and of course, you can run them locally during development. Also, it's particularly good for us because we are kind of leaving relational database for front ends, keeping our biggest relational databases still inside. For this, CF is more than ok because there are several NOSQL with good implementations inside Bluemix like Cloudant and Redis.

Cloud Foundry has lot of benefits because platform as a service provided for the developers to implement applications based on the use cases. Different use cases required different buildpacks to run on. It has flexibility to code, push, and run flexibility. Provided ease of use and manage the applications at runtime.

We have had to move our deployments to Kubernetes because we needed more reliability. We moved to Google because IBM rates and billing was so backward and expensive. Our client was also very angry at all the outages, lost revenue, production down time and inordinately expensive costs that all the outages cost them.

IBM Cloud Foundry is among the services provided by our cloud provider. This is why we choose to go with Cloud Foundry.

While we are still looking at Kubernetes and other services, we will continue to use Cloud Foundry because of the advantages it provides. The support from IBM is good and take a lot of work that our developers and ops had to do away.

AWS and Digital Ocean; Access to a larger pool of services; whatever your business needs, IBM provides it.

It is a cloud-based solution and for all my customers that want to migrate to cloud, this is the solution that we are proposing to customers, as it provides a lot of benefits over private cloud. Scalability and resiliency are not a major challenge and it can be used with other platforms.

CF is what we initially went with to establish a development pipeline and start our cloud journey, now we are expanding this and although we are now pulling in many other tools and functions around CF, it is not being replaced. It stands out as having a key place working ‘with’ git, Kubernetes, IBM cloud etc, not against or segregated from it.

We chose to go with more bare metal options since Bluemix didn't really offer these at the time. It was simpler to get up and running with the bare metal service, and we felt that any problems we ran into would be a result of our own incompetence rather than problems with the platform. In fact, we never ran into a single issue we needed to contact support for with DigitalOcean or SoftLayer.

I have use EC2 and Microsoft's Azure. To me, both Azure and Bluemix were fantastic, but they each had some pros and cons. Azure had more services to offer, but their biggest flaw was in their inability to integrate and work with external platforms, APIs, Programs, etc.. Like Azure, Bluemix services work really well together, but unlike Azure they also integrated well with the other programs we were using for our work.

While IBM works well is when being used by large organizations, these other vendors work well with smaller organizations. We ended up being willing to pay more for Heroku, as they have such an easy-to-use service, and our deployments worked as expected every time.

Used AWS and Azure.
AWS has more features and a far superior interface responsivesness. It's actually usable! That being said default configurations and menus in AWS are more cryptic then necessary.
Azure seems to be the gold standard for pre-configuration and ease of use. Too flashy though. Keep it simple. Keep it fast.

Bluemix had a much easier route to get into the artificial intelligence side of things with Watson skills. It also seemed a lot more straightforward to use things like the Weather Channel data, sentiment analysis... etc., than the others. I'd also had a bad experience with AWS charging me money for a web app that was under prototype and not being accessed by anyone (so wasn't sure where the usage was coming from). Didn't like AWS not notifying me or anything about taking me off the free plan. IBM seems at least a little more open about their charges.

Not even close--as noted in previous answers, we will likely use the competition before even considering IBM Bluemix.

We have used Red Hat which does not do business in Australia with people like us. They were a promising service (PaaS) while we were able to use the free version but as soon as we needed access to serious mobile-first services we had to pay and their policy meant we had to leave. Don't know why they don't want to do this sort of low-end business in Australia.

We briefly looked at Heroku and others but quickly realised that since we demand enterprise strength security, strength insight, and reliability, we had to choose IBM Bluemix.

I like when the provider offers cloud deployment via standard orchestration mechanisms (like Docker, Kubernetes, DCOS) This is currently well covered by Azure. Amazon also has good flexibility (supports Kubernetes, DCOS). It's good that Bluemix added support for Docker and Kubernetes, but addition of DCOS would be great to complete the offering.