IBM Cloud Foundry

As it is an open-source platform as a service, it is very easy to operate, scale, and deploy regardless of what programming language and framework it's written in. However, it could be improved in terms of scalability. There should be proper documentation for easier and clearer understanding to make the process smooth.

IBM Cloud Foundry is a solid service from the IBM Cloud platform. It is easy to learn, and does not usually require you to make drastic changes to your existing applications. It is especially good for new applications that are cloud native, or micro-services, that can be easily updated and deployed. With its blue/green deployment, you can achieve 0 downtime for your customers.

When a company has a small app with lightweight packages, IBM Cloud Foundry is the best option for working ahead. For large packages or heavy applications, IBM Cloud Foundry generally gives throws StagingError or Timeout errors. It is very easy to learn all functionalities simultaneously with documentation. Blue-green deployment is a better option for the apps in IBM Cloud Foundry for avoiding prod downtime, but the routes can be still ghosting around, and only staging(timeout) fixed the routes.

Using existing cognitive services is very easy. Getting things started for a PoC is also easy. More complex scenarios (like offering our own service in the catalog) is hard to achieve. I currently find it difficult to imagine operating a real production system in the cloud.

If you are a developer, it is the perfect service to write code without having trouble with the infrastructure settings. If you are an architect, probably you need something with more options to manage.

Based on the application I have hosted on the IBM Cloud Foundry Platform as a Service, since I have being using it. It best use case for hosting is NodeJS applications, single page applications for professionals like MERN stack Developer, MEAN Stack Developer, JAMStack Developer, PERN Stack Developer. I am learning Flask Framework now, I will write review on that when I host it on IBM Cloud Foundry.

IBM Cloud Foundry is good for the deployment of small applications and scales well, unlike with large apps. It is also challenging to use 3rd party apps on IBM Cloud Foundry.

The IBM Cloud Foundry platform is the perfect starting point for creating a fast new application that needs to leverage from IBM Cloud Services like Blockchain.

Well suited for micro services and web applications.

If you want to start moving your apps to the Cloud, this is a good place to start because all services required for an app have an allowance level so you can try your solution and take it back if you don't like it. Considering a database and the app in IBM Cloud Foundry (CF), you have the option to improve your app with authentication services, monitoring, and some automation. And because CF supports most popular dev environments, there is a good chance that your app is able to be moved to the cloud.

Easier to deploy microservice applications. Buildpacks abstract out quite a bit of configuration. Polyglot development. Abstracts out the containers that are built for the runtimes. Difficult for AI/ML type of workloads. Lacks in observability, trying to work out a custom solution for observability. Still evolving for K8s and not sure how to handle K8 workloads.

IBM Cloud Foundry is easy to use and manage. The application can be deployed on to different versions of buildpacks and managed through one dashboard. The services and features that are provided, is everything an enterprise needs. Security is also built into the provisioned services and IBM provides excellent support.

When you have a small app with lightweight packages, IBM Cloud Foundry works really well. It gets funky when meteor-like apps are highly dependent on large packages and it constantly throws StagingError or Timeout errors. It is easy to understand but some functionalities are more complex when used. We used blue-green deployment for the apps to avoid prod downtime, but the routes were still ghosting around, and only staging(timeout) fixed the routes.

It is appropriate if you are deploying a very lightweight app. It is appropriate if your application is not going to be used in production. It is horrible if you are going to deploy any type of UI that has any level of complexity. Not appropriate for complex processes. Not appropriate for high CPU operations.

Cloud Foundry is well suited for a web application using a monolithic architecture. It works well with a dockerized application as well.

However, Cloud Foundry is not well suited for microservices architecture applications. The pricing model of Cloud Foundry is not thought with microservices in mind.

Quick turnaround for deploying applications, it provides a language/runtime agnostic environment to deploy applications with a simple interface.

If the majority of connections from your applications are IBM partners, using the Cloud Foundry will accelerate your development and deployment.

It is very well suited to create our own platform to provide services to customers, as it is available to multiple locations and provides you with the option to use a lot of API from the catalog which can be consumed seamlessly. I have also seen it better than any other cloud in the market.

Tailored to the PaaS solution better than most, but still has full integration to all of the latest and greatest including push/pull from Git, and app deployment for on/off prem, private or public cloud environments.

I would definitely recommend it for prototypes and, if it seems to work well, maybe in some working environments and production. When I was using it I definitely only would have recommended it for raid prototyping.

Well Suited:
- Development of information architecture/library. It enables better classification/taxonomy, leading to more intuitive findability.
- Dialog design and content retrieval for virtual agents. (e.g. a virtual agent whose content offerings are not hard-coded into the response fields, but instead require crawling/drawing from other pages/libraries)
Not Well Suited:
- Annotation/labeling/clustering of information that will be retrieved using a different search/query service.

It is suited to large businesses with somebody specifically in charge of deployments. He would be a person specifically paid to take care of all the machines through the Bluemix service. It is not a good situation when the teams are small, such as a three-person development team, because there is considerable maintenance that must be taught between them, and this costs a bit of time and hence money in that situation.

For us as a start-up IT company (offering SaaS) whose entire existence revolves so far around the possibilities offered by the cloud and a PaaS like Bluemix, we are building our image on a "Mobile-First" reputation, and have the necessary skills to write our own financial recording/reporting systems, with master ledgers updated from journals, as well as the other bells and whistles required by modern enterprise apps. Bluemix allows our customers, people in businesses, to connect from the field or office, from anywhere in the world, and complete any (100%) of tasks available on the applications. Where the data to be recorded is largely text and numbers encodable in JSON format, real-time internet can be used very effectively to transmit requests and receive responses from the servers in the cloud. We arrange to save images and/or video recordings "on-device" until the user returns to an office or location where a wi-fi modem or hotspot can be connected to.

+ General purpose application hosting (especially that uses relational database backend)
+ Cognitive computing that leverages Watson's capabilities of it's trained models;
- Column database support for internet grade apps and data-heavy solutions is missing
- is Lambda Computing available on Watson? (not that I am fan of it, but it has been getting some attention)