Cloud caster explained

So, I read on Cloud Foundry, and yet I'm still confused as to what it is. Here is my welcome PaaS CF anyway, and I hope you guys could tell me if I am wrong and explain it a little better.

A traditional PaaS offering, such as Microsoft Azure or Google AppEngine, provides a complete platform for developing, testing, hosting, and managing your web application. However, you must use their APIs and are limited to the services they offer and the languages ​​/ frameworks that they support.

Cloud Foundry is a kind of “average person,” thanks to which your application can use services from many public clouds. How is this achieved? Is there one API you are using, something like LibCloud or JCloud? Can you use one service from one provider and, for example, another service from another provider? And does Cloud Foundry really offer any services, or is it just the average person who makes it easy to transfer from one platform to another and use different combinations of services from different providers in one application?

+49
web-applications cloud service paas cloudfoundry
Apr 29 '13 at 14:15
source share
4 answers

I'm a developer at Cloud Foundry - and yes, Cloud Foundry is really a bit foggy (no pun intended). I hope I can help clarify the situation a bit.

Cloud Foundry is a platform as a service , but it needs an infrastructure as a service under it. Cloud Foundry supports vSphere , vCloud , OpenStack, and Amazon AWS as infrastructure through BOSH . Most web application developers do not care about this, but it is really great for people who have to worry about a large IT infrastructure.

Say you are responsible for IT for AcmeCorp. You have 50,000 employees who use your internal Fizzbuzz web service to help them do their job. To support all employees, you need dozens of instances of the Fizzbuzz application running on several machines with powerful processors and large memory, and you need a huge amount of disk space to store information created by the Foo, Bar, and Baz applications that you use internally, too. You have moved far beyond what you would like to manage on your blade servers, so you decided to rent a data center.

Unfortunately, AcmeCorp is terribly dysfunctional. The finance department is of the utmost importance in which data center you use, and every couple of years they make you switch from one data center to another. Every couple of years you have several weeks of downtime, while your engineers are trying to fix errors in Fizzbuzz that have been switched between vSphere, vCloud, OpenStack, or something else.

If your engineers wrote Fizzbuzz, Foo, Bar and Baz against Cloud Foundry, and not directly against the underlying infrastructure, downtime would be minimized. You would not have to worry so much about being tied to a particular data center, because this level of hosting was distracted by Cloud Foundry. Cloud Foundry supports a specific set of services, including PostgreSQL, MySQL, Mongo, Redis, and RabbitMQ, to name a few. If Foo, Bar, and Baz use these services provided by Cloud Foundry, this is least worrying when you migrate between infrastructures.

Later, on the way, you realize that you can make a fortune by selling Fizzbuzz as a service to other large companies. You really have a good shape for this: because your engineers have fixed Fizzbuzz to work in Cloud Foundry, you can simply deploy Cloud Foundry to AWS as much as you need. The client tried it for six months and decided not to renew the service? No problem, you don't have any data center rentals to worry about - just stop all these EC2 instances and go. You can easily have one Cloud Foundry deployment for each Fizzbuzz instance as a service so that your customer data is completely isolated from each other.

The icing on the cake says Cloud Foundry is open source. If you find that this doesn’t quite suit your needs, you don’t just have to keep your email and wait for Cloud Foundry engineers to realize your dream - you also have a source, so you can make any changes that you need. And it is available in the Apache 2.0 license , so download requests are gladly accepted, although not required.

I hope that paints a picture of the problems that Cloud Foundry solves. Feel free to request more information in the comments, or you can check out the Cloud Foundry mailing list if that makes more sense for future questions.

+67
May 03 '13 at 4:51
source share

I’m a developer advocate for Cloud Foundry and want to add a little to mark the answer, to focus on some other details that you mentioned in your original question.

First, you mention GAE and Azure. Both of them have certain limitations - for example, GAE restricts you to specific languages ​​and APIs. Also there is no Open Source. CF is extensible (for example, the new version supports buildpack, allowing you to choose "any" language execution), and you can choose it wherever you want.

Mark mentions 4 IaaS providers on which we can run CF today, but assuming that the IaaS in question (let's say we will include Azure, CloudStack, Google Compute Engine, etc. as future targets) may support a small amount of what we call Cloud Provider Interfaces (CPI), then you can also install Cloud Foundry on these infrastructures.

You ask how you can use services from different providers. Like Heroku, the upcoming version of Cloud Foundry (.com) will support a “market” where you can connect features from additional providers, and if you use your own instance of Cloud Foundry, you can choose which services to deploy and connect to your applications.

It's pretty cool :-) come talk to us on the mailing list if you want to know more!

+19
May 03 '13 at 18:22
source share

I would like to add this as a comment regarding the API for Andy's answer, but unfortunately does not have enough reputation for that. As far as I understand, Cloud Foundry really does not have a specific API, but it provides a lot of useful information through environment variables (for example, VCAP_SERVICES, VCAP_APPLICATION, VCAP_CONSOLE_IP, VCAP_APP_PORT ), which can be accessed from any language or framework. While much of the data from such variables is internal to Cloud Foundry, some of it can be quite useful. The main VCAP_SERVICES that provides information about the services associated with your application.

For example, if I wanted to collect information about the Azure Cloud Service instance (for example, its identifier) ​​that my application is currently running on, I would use this from the Azure management library.

Cloud Foundry, in turn, provides the VCAP_APPLICATION env. a variable that will contain the following fields:

 {"application_users": [], "instance_id":"97467a9cf508cb75273284b948b6319b", "instance_index":1, "application_version":"330b7caf-50e5-48f4-8792-1c80a90b06f1", "application_name":"helloworld", "application_uris":["helloworld.vcap.me"], "started_at":"2013-07-22 10:58:16 +0300", "started_at_timestamp":1374479896, "host":"0.0.0.0", "port":61014, "limits":{"mem":256,"disk":1024,"fds":16384}, "version":"330b7caf-50e5-48f4-8792-1c80a90b06f1", "name":"helloworld", "uris":["helloworld.vcap.me"], "users":[], "start":"2013-07-22 10:58:16 +0300", "state_timestamp":1374479896} 

And finally, a few words about the logs, monitoring and diagnostics. This is not currently implemented at the CF PaaS level, but I hope that it will be implemented (as it is a really useful feature) and maybe some new envs. variables (say VCAP_LOGS, VCAP_PERFORMANCE_COUNTERS ) will be displayed in our applications.

+6
Jul 26 '13 at 10:48 on
source share

Of course, CF is the level of abstraction between your IaaS (servers, storage and network) and your application, which gives you the ability to transfer your application among public and private clouds, but it is also much more:

1. Platform with high horizontal platform

Applications run in containers, which allows better resource management than assigning applications to hosts (virtual machines). Warden / Garden is CF-based container technology, although Docker is also supported in recent versions.

2. Self-healing platform for applying multiple HA layers to your application

The health management system resurrects failed application instances, containers, platform processes, and virtual machines without any glitches. Availability coverage is provided by HA at the infrastructure level. Updates for rolling and deploying canaries provide zero downtime even during deployments or platform updates.

3. Satisfactory runtime of the polyglot application

Using the heroku buildpack construct, the application language is automatically detected, and the corresponding runtime stack is created on top of the vanilla operating system image, which allows developers to focus on writing code.

4. On-demand developer to provide stateful data services

Developers can independently provide a cluster slice of MySQL, RabbitMQ, Redis, etc., using uri / credentials automatically inserted into their application environment.

+1
Jan 19 '16 at 1:29
source share



All Articles