A business requirement we have is to have two geo-distributed servers (each in a different country) each running critical Java web app instances and Postgres database service (database is supposed to be clustered and geo-distributed in a master-slave mode).
Is it's possible to accomplish such a configuration with CloudFoundry? I got familiar with CloudFoundry a bit and I see either - one instance of CloudFoundry with multiple app and service nodes (standard way, one physical server) - multiple instances of CloudFoundry with service brokers for getting remote services info (not sure how to run distributed app this way)
Can this be acchieved at IaaS layer so hardware would be on two location and there would be just one instance of CloudFoundry? Is our only option to use third party "entry point" to the app to route and load balance between the two Clouds? Or we should just avoid CloudFoundry as an inadequate solution.
Thank you in advance.
Like others I can vote negative and move on.
Your question makes it clear that you have very little knowledge of Cloud Foundry.
I strongly believe no one of this planet was born with knowledge. So, I fell I should help explain you Cloud Foundry. That said, I am no expert. So, I may get few things wrong.
I do encourage experts out there, to please correct me (I am always willing to learn).
You must have already heard of Quickbooks, ADP etc. They are called as Software As A Service (SAAS).
Amazon Web Services (AWS), MS-Azure, and Google Computing Engine (GCE/GCP) provide you infrastructure in the cloud. They are known as Infrastructure As A Service (IAAS).
Cloud Foundry is known as Platform As A Service (PAAS).
Cloud Foundry, provides consistent, and standardize platform that is elastic, scalable, self-healing, distributed environment. Please check out What is Cloud Foundry? Key benefits and real use case. The advantage of Cloud Foundry, you can run build your private cloud on AWS, GPC, Azure, or in your own data center on VMWare.
In Cloud Foundry, your apps are deployed as a collection of microservices. A microservice can be individally deployed, scaled and managed. A micorservice can be individually called. The micorservices architecture allows frequent changes, reduced turn around time, and increased agility. This helps overall quality and customer satisfaction.
Another advantage, you can push the same micro-service to two different clouds. And that is your use case. You don't have to maintain two different code lines for two different geographical areas. This off-course is on the assumption that your business requirements are the same in both geo locations. If the requirements do change, you can adapt easily by builiding new micro-services.
As you can imagine cloud foundry is a viable platform. Cloud Foundry is by no mean cheap. It is lot of work upfront for the longer term payoff. So, I would not suggest cloud foundry for one or two apps.
In your question, you mention, the apps won't be called directly but through a 3rd party entry point. Given that, why do you really need two different clouds in two geo-locations? If you need distinct url's, that can achieved by creating specific routes and publishing them.
If data separation is a concern, you can create two different spaces or two different orgs and isolate the services and or data.
If goverment regulations is what driving the two cloud requirement, then you have no choice but to have two cloud. This where an AWS, GCP, or MS-Azure will come really handy as they probably have IAAS offerings in the geo-locations you are looking for.
My answer is very cursory and is more like a 10,000 feet view. Your requirements need to be hashed out and properly implemented. If you do decide to go cloud native, please hire a very good guide. On this journey you do not want to go alone. I can suggest one great company - ECS Team.