What is the differnce between a Cloud Foundry and A Web Server - cloud-foundry

Question

So being an SAP consultant , I am trying to understand the SAP cloud foundry .
As per understanding till now , Cloud Foundry is a runtime engine provider (on the cloud ) .
There are many Cloud Foundry like SUSE , IBM , SAP Cloud Foundry .
Doubt:-
I develop an application for Android ,
I deploy the application in a Web Server ,
Now everybody can download it from Google Play and use it .
I deploy the same application in one of the Cloud Foundry .
Now everybody can download it from Google Play and use it .
Is there any difference between a Cloud Foundry and A Web Server ? Or both are same
EDIT :- Question Clarification
What is the difference between products like SUSE , IBM , SAP Cloud Foundry and Cloud services like AWS , Google Cloud , AZURE

Answer 1

So being an SAP consultant , I am trying to understand the SAP cloud foundry .
I can't talk to anything specific that SAP is doing, but to be called Cloud Foundry you need to be certified which tests compatibility and interoperability (and prohibits lock-in). SAP is certified so there's a base set of functionalty that is common with it and any other provider. I'll only be referencing that here.
There are many Cloud Foundry like SUSE , IBM , SAP Cloud Foundry .
Correct, just a minor terminology note. Each vendor with a certified Cloud Foundry offering is called a provider. Cloud Foundry is the service, the company offering it is the provider.
Oh, you can also run your own, if you or your company prefers that route.
Doubt:- I develop an application for Android , I deploy the application in a Web Server , Now everybody can download it from Google Play and use it .
I deploy the same application in one of the Cloud Foundry . Now everybody can download it from Google Play and use it .
Is there any difference between a Cloud Foundry and A Web Server ? Or both are same
Let's say that you have an Android app. It talks to some services.
For example:
Android Phones 1..X (possibly millions) talking to Servers 1..Y (hopefully not millions).
Each Android phone runs a client, the client talks to the server to perform work
The server provides some functionality, like storing data or performing expensive calculations you wouldn't/can't do on the phone
There's no difference when it comes to the Android app. You're building that. It's running on someone's phone. It's talking over HTTP (or some other protocol) to a service. It's installed through the Play Store (not from your servers).
The main difference is with the services to which your Android app communicates. Specifically, between how you deploy your app on a server/VM directly or on Cloud Foundry and the amount of work required to do so.
For a server you might:
need to request hardware or request a VM from IT, if you're lucky you can provision this on-demand
you need to install an OS, if you're doing this right you have a tool to install this for you, but that tool might need some configuration/tuning
you need to install any software required to run your app (JVM, Dotnet, Python, etc...), including servers like Nginx, Tomcat, Apache Web Server, etc...
you need to configure software and servers (again if you're doing it right you have a tool that helps you manage this, which may require some configuration)
then you build your app (or perhaps take bits from a CI server)
last you set up your app to run, including some sort of watcher/service management software to make sure that when your app crashes it is automatically restarted
There could be more (network/firewall/service work) or less (like if you deploy to a public cloud IaaS) tasks here depending on what it takes to deploy an app in your environment.
This also doesn't touch on the fact that you need to maintain all this. Ensure that you're updating software and the OS in a timely fashion.
For Cloud Foundry:
You do a cf push which takes your code and automatically adds and configures the software needed to run your app (through buildpacks).
Your app is then run on Cloud Foundry.
You're back to writing code.
Other benefits:
It's watched automatically, so if it crashes it restarts. No intervention required.
Logs are captured and made easily available to you, the developer
Network access & TLS are already set up and managed by your provider.
There's a catalog of on-demand and easy to consume services available to your app.
Software is automatically updated whenever you push code.
You can scale up/down easily with load, no new servers to provision and set up.
There's even an autoscaler to automatically scale up/down based on provided rules to save resources/money.
tl;dr - it is an easy button for developers. You just write code and push. All the other stuff you don't want to worry about is done for you.