IBM Cloud Foundry Reviews

We use IBM Cloud Foundry as our primary PaaS for our cloud product deployment. We have set up our CI/CD process with Cloud Foundry for development, staging, and production environments, so pushing and deploying changes is as simple as a button click. This dramatically simplifies our processes and speeds up our ability to bring new features to our product.

We are currently evaluating the Bluemix stack to get more insights and to be able to identify relevant business cases. We are not yet using it as a production system, but only for test purposes. There are a lot of interesting services included, and we are also interested in offering our own services.

We used Cloud Foundry to deploy with a few clicks a secure and scalable web app using a simple web console. Our web app needed to have a CD/CI integration. Cloud Foundry helps us to have user-friendly PaaS.

Recently I've built and run a web-app (trindfl.com) within IBM Cloud Foundry, which is drafting a tax declaration for interactive brokers (IBKR) traders. A user downloads her IBKR yearly activity reports (csv files), and then she uploads them to the web-app (IBM Cloud Foundry). In a few seconds the web-app, first, parses the uploaded reports, second, prepares the tax declaration file (xml), and, last, prepares an explanatory note (xlsx), which shows how IBKR report is aligned with Russian tax law. Brief analysis results are presented to the user so she can make a decision to purchase and download tax declaration and explanatory note files. All the uploaded and created files are deleted after a while.

At my work place, most of the in house web solutions and client projects we built is being hosted on IBM Cloud Foundry. Its being used majorly by Engineering team which I co-managed for the firm, and I also assist in tutoring new developer on how to make use of IBM Cloud foundry and other IBM Paas or resources that will make use by the Engineering team. It provide us flexibility in hosting, which there is option for continuous delivery which can be make use when you setup continuous delivery toolchain, which I have make use when I am given role to set up the environment for a new project and a starter content for the project. Secondly, make use of terminal command to push project to IBM Cloud foundry, which I can configure the custom domain which I want to assign to particular project through my terminal. Thirdly, I can allocate max memory which my application should make use of especially when we implement Proof of Concept to pitch our idea, so i reduce it from the default 256mb to 64mb which helps to save cost and waste of cloud resources, which other applications can make use of. Fourthly, there is provision for secure and non secure subdomain url for hosted application which is very good startup at-least when sharing our POC link, investor won't be worried since we would be providing with secure url to access our ideas which in return make them trust us and give us audience.

IBM cloud foundry is used by our IT department to mange and deploy web apps within the cloud. It is simple to manage in our staging and production process, thus we are able to focus more on development rather than managing deployments. Its salability has been able to improve our web performance.

It was used as a development and runtime platform for new applications. We changed the development mode from monolith to microservices. CF supported us in this matter. By using CF it allows us to deploy fast and change the code. Further IBM is perfect to use in combination with other IBM services. All you need is to develop our code, and all other services are available in the IBM cloud.

IBM Cloud Foundry is the main repository of APIs for our organization. We are migrating some we have internally already developed in loopback and developing from scratch, and some others in other frameworks. For those already in loopback, we just check that we are taking advantage of all the new features in the cloud. For the rest, we started with a new basic ground API and start reusing most of it.
With this approach, we are increasing the API response time and availability and getting rid of local hardware.

IBM Cloud Foundry is used on IBM Cloud for applications across the organization.

All the RESTful APIs and SPA applications are deployed to Cloud Foundry. We also use P2P security for the private services which is good and eliminates external security measures. CI/CD is much easier with CLI and infrastructure is of course not a big deal anymore.

It is currently used across the whole organization.

Cloud Foundry is used for a few of the apps in our projects. Since this is in the cloud, it's reduced the overhead of maintaining a server dedicated for all our server requests.

We use Cloud Foundry to simply to manage our applications. Using Cloud Foundry allows us to deploy quickly and easily with no hassles. It is simple to manage multiple environments such as staging and production. Thus we are able to focus on development rather than managing deployments. Moreover, Cloud Foundry provides a good performance.

We use IBM Cloud Foundry to deploy multiple micro services which are a part of our product offering. It the the main deployment model we use right now across our organization.

We’re using these services as a POC to research the validity of our assumptions - as a way to shorten the development cycle. The freedom of turning services on and off is valuable.

We have built our own platform on Cloud Foundry and are using it heavily for internal and external customers. We have built a service management platform and provide all services on this platform. We also use Watson capabilities on IBM Cloud and build our own chat platform for internal and external customers. This is a great platform.

While I am sure there are other orgs/teams within the company that use Bluemix, I am unfamiliar with anybody else's usage outside that of my groups. We use Bluemix for several things, but our main use thus far has been for the Conversation Service. We use this service for the dialog design of our Virtual Agent. Additionally, we are using WKS (which I hear is now no longer a part of bluemix?) for a content annotation project with the end-goal of creating somewhat of a semantic network for our content library. The broader goal here is to improve our content's findability and relevance, so after WKS we will begin piloting WDS as a content retrieval service. That being said, our primary use-case is by far the Conversation Service for dialog design.

It's used across the whole organisation, Bluemix is providing the foundation for our enterprise apps, which we develop as mobile-first developers. The availability of push notifications, the functionality and integrity of the mobile system, as well as the overall security are the keys to its value to us.

We were using container services from Bluemix - CloudFoundry PaaS to manage our applications. Apps were Java wars wrapped in Docker containers. Also Softlayer VPS's were used to provide for our Cassandra cluster, where we installed and managed Cassandra instances manually. Four VPS nodes total were in use.

We were part of the IBM Global Entrepreneur program and were given the opportunity to use Bluemix or SoftLayer. We made an attempt to use Bluemix for a few small applications when were were dabbling with rebuilding the platform Meteor. If it worked out it would have been the main platform for the production distribution of the web application.

Currently, it is used for the development of an API for a payment services directive. We are a bank within EU and have to implement such a solution.

It ran our entire backend functionality. It is used across the entire organization and its impact is seen on every one of our customers. We used it to try to simplify our deployments, as they took a lot of time out of our day.

IBM Bluemix is being used as my primary cloud computing service, having recently replaced AWS as my preferred service. I work with an IT consulting firm, and specialize in designing IT infrastructure for businesses, usually start-ups. My company has changed over the years as technology changes, originally setting servers up at the clients location, then moving to hosting them myself, and now I utilize cloud services with IBM as my primary source of server environments since software development is the focus of 75% of the start-ups I have been encountering, which is where BlueMix shines. Instead of detailing out how I use these services, I am going to explain the differences between IAAS (AWS/Google/Azure) vs PAAS (BlueMix, Redhat). The main difference is what level of control the system focuses on, when it comes to IAAS, the system is focused on infrastructure, such as building a server with x processors, x amount of ram, a storage system with X Gb of data. PAAS on the other hand, is focused on the whole platform that will run your software rather than just the simulated hardware specifications. AWS (IAAS) lets me build a virtual server with 2 processors, 1 gb of ram, 15 Gb of drive space, and 2 network adapters, which I then need to install an OS on, BlueMix (PAAS) lets me setup a geographically clustered environment that can serve HTML, PHP, and MySQL, while also being able to pull Microsoft SQL, while running a version tracking system, such as GIT. So from the start, I specify what I need my system to do to run my software, rather than what I need my server to have to run my OS, to run my server software that I can add additional functionality to in order to allow my custom software to operate best

Cloud Foundry has been fundamental in our initial cloud solution development, hanging over a Bluemix solution to provide the gateway / sandpit environment for our industry to quickly develop and push proof of concept pieces of work without the fear of having the normal business processes hanging over them and getting in the way with red tape.

Although we are now going in the direction of more IBM managed services where the likes of IBM Cloud, IBM Cloud Private and Multicloud Manager link better in those Kubernetes managed solutions, our time using Cloud Foundry is not over by a long shot and can/will seamlessly work with what will become our key tool stack.
Both still have their place, with CF being the better option to keep things standardized, ring fenced and easy for the end user to consume, and then the links in to the K8s services allowing for wider customization.

We have several clients with whom we have used it. We have it in production for both the front and back ends of our implementation. We have it running to serve a web app that is used as a call taking management system. We have it running to serve an application that is used for inventory management, tracking, and purchasing.