Cloud

Cloud Foundry – An Overview

Last updated on October 1, 2020

Cloud platforms today let any business deploy network applications and services with ease, and make them available to the world in minutes or days. When any app comes into heavy use or needs scaling, the cloud helps make it more robust to handle more traffic, add customizations and more – without having to worry about the underlying infrastructure.

Not all cloud platforms and applications however, are designed in the same way. They need continuous support for maintenance, framework, key app services, security and more across the full application lifecycle, so that the business doesn’t suffer any downtime.

Cloud Foundry is a popular and industry-standard PaaS (platform-as-a-Service) that ensures that your cloud apps are deployed quickly, with ease and high reliability. To illustrate, Cloud Foundry users save nearly ten weeks and $100,000 on average per application development cycle . But what is it? Why do businesses – from small to large – need Cloud Foundry in the first place?

This introductory blog will walk you through an overview of the fundamental business impacts and the reasons CF users love it.

What is Cloud Foundry

Cloud Foundry is a collection of APIs and implementation of core services to offer a cloud-based Platform as a Service (PaaS) on top of a virtual infrastructure, such as an IaaS. The platform supports the Microservices architectural style. As an open platform, all service implementations can be replaced by more adequate versions, for example, by a high-performance version supporting massive clustering.

Cloud Foundry offers services that automate the steps needed to deploy and scale cloud-based applications, supporting a DevOps model where a solution’s development and operations go hand in hand. It was initially developed as a Java PaaS for Amazon EC2 by Chris Richardson, in 2009 acquired by SpringSource, which was then acquired by VMWare, then handed over to Pivotal.

Compared with other PaaS offerings, Cloud Foundry has some unique features:

  • Runs on different IaaS offerings (e.g., OpenStack, Amazon Elastic Cloud 2 (EC2), etc.)
  • Enables application development on different runtimes (e.g., Node.js, Java, Ruby, .NET) under common deployment and scalability idiom
  • Allows integration of arbitrary platform services (e.g., MongoDB, RabbitMQ, …) and applications services (e.g., mail, document)

 

The Cloud Foundry Foundation (http://www.cloudfoundry.org/) now maintains Cloud Foundry. More than 50 companies are members of this foundation, including Pivotal, EMC, HP, IBM, Rackspace, SAP, and VMWare.

That said, when talking about cloud offerings, terms like IaaS, PaaS, or SaaS are used frequently. It is thus important to distinguish the various types of offerings because they are involved when using Cloud Foundry.

Offering Type Provided Entities (Examples) Users
IaaS Infrastructure as a Service (Virtual) Machines (VMs), Disk images (with pre-installed Operating System – OS), block storage (disks), virtual network routers System Operator / Administrator / Developer of a platform
PaaS Platform as a Service Load Balancer, Services (DB, Document, Authentication, Billing, Deployment), Application runtime environments, Application Monitoring Developer / Operator of a solution
SaaS Software as a Service Web Shops, Groupware, Ariba, SuccessFactors Business users

Cloud Foundry provides an extensible architecture and core components for a PaaS offering. Primary users are, therefore, developers and administrators of solutions and SaaS offerings.

Cloud Foundry aims at the following architecture goals for business impact:

  • No single point of failure
  • Distributed state
  • Self-healing
  • Horizontally scalable
  • Loose coupling
  • Event-driven and asynchronous communication (Cloud Foundry components mainly communicate via a message bus)
  • Allows distributed data storage, eventually consistent.

Developing an application in Cloud Foundry

Developers typically create applications using services provided by Cloud Foundry instances.
After installing the CLI (cf command), we connect it to the Cloud Foundry instance by entering the API endpoint and log in. Our primary considerations here include checking the organization’s spaces to understand which build packs are available (for the choice of programming language) and which services are offered in the space.

Deployment and Execution of Applications in Cloud Foundry

Cloud Foundry supports the polyglot approach of microservices by shifting as much deployment logic as possible into the so-called Build Packs.

A typical deployment of an application on Cloud Foundry takes place in the following order:

  • The developer has finished the development and local testing of the application and asks the CLI to deploy the application using the cf push command on the app’s file directory. This directory contains executables such as a .war archive, configuration files, and static content.
  • The CLI contacts the Cloud Controller that stores the application code in the Blob Store.
  • Using the PaaS Metadata, the Cloud Controller determines the most appropriate Build Pack (if not defined with the push command), identifies an existing DEA, and uploads both Build Pack and application code to this DEA.
  • The DEA executes the Build Pack (Staging).
  • The new droplet is stored in the Blob Store. The Cloud Controller can now instantiate as many application instances as needed by pushing this droplet to an appropriate DEA instance.
  • The new droplet is stored in the Blob Store. The Cloud Controller can now instantiate as many application instances as needed by pushing this droplet to an appropriate DEA instance.
  • The Cloud Controller tells one or more DEAs to run the application using the droplet and the given resource parameters (memory, CPUs, etc.).
  • A Droplet contains the app code and all further resources needed to run the app. It can be uploaded to a DEA and run by Warden containerization.
Cloud Foundry at SAP

Several projects and cloud services at SAP are currently evaluating/integrating into Cloud Foundry as mentioned above.

SAP XS2 is the new platform for non-ABAP applications with HANA supporting a polyglot application development model of micro service-oriented cloud applications. The XS2 cloud deployment holds Cloud Foundry. Hybris as a Service (YaaS), for example, is a SaaS commerce offering using a microservices architectural style on Cloud Foundry. This involves the creation of several services on a different level (Core services, which are

domain agnostic such as a document repository, and Commerce Services such as a Shopping Cart of a Pricing service).

SAP Cloud Platform (SCP) is a PaaS offering for customers and partners. The CF@SCP project works closely together with hybris as a Service (YaaS) on integrating Cloud Foundry service APIs in SCP.

The freedom to create

The diversity of thought, experience, innovation, and ideas is what makes the digital ecosystem stronger against constant disruptions. Cloud Foundry automates almost everything and therefore gives developers the freedom to focus on innovating and creating apps that solve real-problems with quick app development cycles – within a few days or weeks rather than the traditional months (or years!).

Related Posts.

Azure , CapEx To OpEx , Cloud , SAP , SAP Applications To Azure
Cloud , DevOps , Salesforce , SFDX
AMS , Cloud , Cloud Management , Cloud Vs. On-premise , Infrastructure Management
AWS , Cloud , Landing Zones , Large-scale Migrations
AWS , Cloud , Landing Zones
Analytics , Cloud , Serverless Data Lake
Cloud , Infrastructure Servies

The cloud quandary

Rakesh Thakur

AWS , AWS Greengrass , Cloud , IoT
Cloud , Cloud Computing

Multicloud strategy

Pravish Jain

AWS , AWS Cloud Services , Cloud , Data Governance , Data Management
AWS Cloud Services , AWS Control Tower , Cloud , Cloud Migration
Amazon S3 , AWS , Cloud , EBS , Elastic Compute Cloud

Add Comments