What is Cloud Foundry?
“Cloud Foundry makes it faster and easier to build, test, deploy and scale applications, providing a choice of clouds, developer frameworks, and application services. It is an open source project and is available through a variety of private cloud distributions and public cloud instances.” – https://www.cloudfoundry.org/
What is Knative?
“Kubernetes-based platform to build, deploy, and manage modern serverless workloads.” – https://cloud.google.com/knative/
Why are these comparable?
If you have a Kubernetes cluster running by itself, it will give you an API to leverage the underlying hardware. Yet out of the box, it doesn’t have the rest of the features Cloud Foundry has, where you can simply point to a Cloud Foundry’s Cloud Controller API, login and start to push applications, connect to services, and manage the lifecycle of your system.
This is where Knative comes in.
The functionality that Knative brings on top of a running Kubernetes cluster begins to bring feature parity with a platform like Cloud Foundry. And that’s the topic of discussion today, and of the talk, Dr. Nic and Dr. Max had at Cloud Foundry Summit 2019 in Philadelphia his April.
Five Use Cases
To compare the two platforms they decided to look at the following five high level use cases they believed a platform needs to have in order to be considered ready for production use in the enterprise.
- Deploying an application.
- Managing the application.
- Debugging an application.
- Creating and bind services to applications.
- Enterprise features.
1. Deploy an App with Cloud Foundry
Cloud Foundry’s command line tool cf makes it simple to authenticate and push an application. And as you may expect because Cloud Foundry has been around for a while now, it can handle deploying an application with ease.
$ cf login -a API --sso -o myorg -s myspace$ cf push hello \
-p path/to/sweet/code
$ cf push hello \
--docker-image gcr.io/knative-samples/helloworld-go
$ cf set-env hello TARGET “Dr Nic”
$ cf restart hello
1. Deploy an App with Knative
Knative doesn’t have an official CLI tool yet, but you can use knctl written by former BOSH project lead Dmitriy Kalinin. Using the Knative build component allows for a greater range of resources you can use to construct your application than Cloud Foundry.
# set auth token context (login)
$ knctl deploy --service hello \
--image gcr.io/knative-samples/helloworld-go \
--env TARGET=”Dr Max”
# deploy from source (assume setup Docker registry)
$ knctl deploy --service hello \
--directory . \
--service-account docker-hub \
--image docker.io/drmax/simple-app \
--env SIMPLE_MSG=”Dr Max”
1. Deploy an App Results
- Cloud Foundry and Knative are on par with simple deploy of apps from docker image or source (not from git).
- Knative allows flexibility in the build process, that is from buildpack, git, source, and so on.
Score: Cloud Foundry 1, Knative 1
2. Managing an App with Cloud Foundry
The lifecycle management of applications would be anything you do to keep your application running after its initial launch. Cloud Foundry manages well and is keeping pace with Knative with what most people would expect in a modern platform, such as scaling or handling revisions. In order to enable scaling though, you’ll need to add an extension.
# Cloud Foundry has no direct management with revisions *
$ cf push myapp # replaces current version
$ cf map-route myapp \
mycompany --hostname www
$ cf restart myapp
# scale apss by specifying exact number **
$ cf scale myapp -i 4
* coming cf cli v7 with revisions
** see App-AutoScaler community extension
2. Managing an App with Knative
Meanwhile Knative handles revisions and even has the ability scale your app to zero when there isn’t any active demand on the app. Basically if no one hits it in five minutes it will turn itself off. Then the next request, since it takes seconds to start a container, will re-warm a container running the application.
# deploy service again and rev created
$ knctl deploy --service hello \
--image gcr.io/knative-samples/helloworld-go \
--env TARGET=”Dr Max”
Tagging new revision ‘hello-00002’ as ‘latest’
# scaling up and down automated based on traffic
# splitting traffic between revisions
$ knctl curl --service hello
Handling the traffic between revisions “just work” like you’d expect with Knative. And if you’d like to be more specific and send some to v1 and some to v2, you can be more specific too.
$ knctl revision list -s hello
Revisions for service 'hello'
Name Tags Traffic
hello-00002 latest 100% -> hello.default...
hello-00001 previous -
2. Managing an App Results
Cloud Foundry
- Enables direct management of apps.
- Lacks revision and traffic splitting support. *(Coming soon.)
- No native auto-scaling.
Knative
- Built-in direct management of scaling and revisions.
Score: Cloud Foundry 0.5, Knative 1
3. Debugging with Cloud Foundry
Things go wrong. It’s good to know you can use tools to figure out what’s happening.
When debugging with Cloud Foundry, you’ll probably run cf logs myapp name. This is what’s happening “now”. If nothing is hitting the app, no logs will come through. Try instead adding the --recent flag, which will start you off with some of the most recent logs.
And then cf ssh myapp gets you into the container that’s trying to run your app so you can see what’s up.
# see which application is failing
# access the log for application
$ cf logs myapp
$ cf logs myapp --recent
$ cf ssh myapp
3. Debugging with Knative
To do get on the container with Knative, you’ll need to go through a few hoops at this time to get the name of the pod. Then when you connect to the pod, the command looks just like running docker exec -it ... to get in.
# list services and not failing services
$ knctl service list
# access logs of services
$ knctl logs --service hello -f
# find the pod for the service
$ knctl pod list --service hello
# ssh into the pod
$ kubectl exec -ti hello… sh
3. Debugging Results
Cloud Foundry
- Easy to access log from application name.
- With ssh enabled you can directly connect into the containers.
Knative
- Access to log available from pod.
- A benefit of Kubernetes tooling.
Score: Cloud Foundry 1, Knative 1
4. Create/Bind to a Service with Cloud Foundry
Cloud Foundry’s platform is designed not only to make it simple to deploy your 12-factor application but to provision and consume services by using the Open Service Broker API. These capabilities are available now and there are examples you can follow.
$ cf set-env myapp DB_URI mysql:// …
$ cf create-user-provided-service …
# lists services from marketpace, note name
$ cf marketplace
…
# create instance of selected service
$ cf create-service dbname mysql shared
…
# use key info in app. Bind service with app
$ cf bind-service myapp dbname
$ cf restart myapp
4. Create/Bind to a Service with Knative
We’re going to skip over how to get services going and talk mostly here about how to use them with Knative here. In other words you can run services on your Kubernetes cluster. Using Knative you can use the build process to deploy your service. It’s just not built into the system yet. And so because of that we’ll give Knative a lower score because there’s some room for improvement.
# create service, create service key
# create secret with DB URL and kubectl
# deploy service passing DB URL
$ knctl deploy --service mysql \
--directory . \
--image docker.io/dkalinin/sample-mysql \
--service-account docker-hub \
--env-secret DATABASE_URI=mysql-ibm/uri
4. Create/Bind to a Service Results
Cloud Foundry
- Open Service Broker API support makes the listing, creating, binding services easy.
Knative
- No native ideas on services; see Kubernetes for env variables and service catalog.
Score: Cloud Foundry 1, Knative 0.5
5. Enterprising with Cloud Foundry
Some of the most common enterprise needs are access control. With Cloud Foundry and the User Account and Authentication (UAA) server, it’s part of the platform, right from the start.
Another need is to ensure that only the correct application containers can either have access to or be isolated from others. This is usually for security and compliance reasons.
# map your Cloud Foundry orgs and spaces to your enterprise
# teams, groups, divisions
$ cf create-org myorg
$ cf target -o myorg
$ cf create-space myspace
$ cf target -s myspace
$ cf push myapp
# Cloud Foundry also has container-to-container networking,
# and isolation segments
5. Enterprising with Knative
At this time Kubernetes and Knative are allowing tenancy with namespaces inside a single cluster. Let’s say you grow and need multiple Kubernetes clusters you can then isolate your tenants to those clusters. And network containers together with with Istio.
# use Kubernetes namespaces and labels
kubctl create namespace mynamespace
# deploy services in the namespace
$ knctl deploy -s myservice -n mynamespace
# cluster-based isolation
# use istio for container-to-container networking
5. Enterprise Integration Results
Cloud Foundry
- Built with enterprises in mind.
- First-class objects for access control.
- Usage metering.
Knative
- More lax and flexible access control.
- Powerful but limited to cluster.
- Knative/Kubernetes lacks usage metering built-in.
Score: Cloud Foundry 1, Knative 0.5
Results Summary
Let’s take the scores from each use case and total them up.
As we can see, Cloud Foundry edges out Knative at this time. Yet even as Knative is en emerging technology, it has firm grasp on the core features that we expect in an enterprise-grade production platform.
Which leads us to draw the following conclusions.
Conclusions
- Cloud Foundry is a mature Platform-as-a-Service, ready for Enterprises.
- Knative is emerging, incomplete, less secure, yet exciting.
- Many (80%) basic features are on both platforms.
- Kubernetes ubiquity helps Knative’s appeal.
- Missing features in Knative can be built upon Kubernetes/Istio.
As you are evaluating using either of these platforms, we hope this article will have shown some light on how comparable they are. How they are both learning from each other. And what to look for when evaluating a platform.
Spread the word
