Cloud Foundry FAQ

What is Cloud Foundry?

Cloud Foundry is an open source Platform as a Service (PaaS) for hosting stateless applications or microservices.

What is the ideal workload for Cloud Foundry?

12-factor compliant applications are the ideal workloads for running on Cloud Foundry.

Why are developers preferring Kubernetes over Cloud Foundry?

Downloading and configuring Cloud Foundry requires deep infrastructure knowledge (Bosch) and it also requires dedicated infrastructure resources.

When it comes to Kubernetes, it's much easier to consume. It can be configured on a laptop. It is well documented and has a fast learning curve compared to Cloud Foundry.

What is the advantage of Cloud Foundry?

Cloud Foundry is a proven platform/technology, works at scale and hassle free for developers.

It simplifies application deployment through “cf push”, by allowing developers to focus on writing code rather than worry about underline infrastructure.

What are the disadvantages of Cloud Foundry?

Cloud Foundry is designed for 12-factor compliant applications, which are stateless. 

Large corporations have thousands of legacy stateful applications or monoliths and it can be an obstacle for running on Cloud Foundry. 

Kubernetes allows deployment of legacy stateful applications without modifying them.

What is Korifi?

Korifi is the convergence of Cloud Foundry and Kubernetes.

It brings the best of both worlds - Developer experience of Cloud Foundry and power of Kubernetes. Deployed applications run on the underline Kubernetes platform.

https://www.cloudfoundry.org/technology/korifi/

Orchestration and Chorography in Microservices

 Both Orchestration and Choreography are used for Inter Service Communication (ISC) in microservices.

 Example use case - When an order is completed, an invoice should be generated for the order items.

Orchestration:

• One central service controls entire business transactions
• Its ideal for synchronous Inter Service Communication
• Tightly coupled - All the integration logic exists in a single Orchestration service (Often called as God object)
  
• Easier to Rollback business transaction

 

Solution: OrderOrchestration service  to invoke OrderService.CompleteOrder() first, followed by Invoiceservice.GenerateInvoice(). Here entire integration logic present at the OrderOrchestrationService.

 

Choreography 

• Suited for asynchronous Inter Service Communication
• Loosely coupled
• This is implemented using event based architecture (Example: Apache Kafka/Azure Event Hub). Microservices can be configured as both publisher and subscriber of events.
• Harder to Rollback business transactions

 

Solution - Order Microservice can publish an OrderCompleted event to Event Hub. An Invoice Microservice can be subscribed to this event and can generate invoice based on the subscribed events.

Cross cutting concerns in Microservices Architecture

 Here's the list of cross cutting concerns/Common platform services:

1. Logging & Tracing
   
2. Exception Handling
3. Caching
4. Swagger documentation
5. Health Check
6. Dapper
7. ISC (Inter service communication)
8. Resilience
9. Email
10. KeyVault

 

Notes:

Logging & Tracing - Azure Application Insights

Caching - Azure cache for Redis

Swagger - Swashbuckle & ASP.NET Core

Health Check - in ASP.NET Core (HealthStatus.Healthy, Unhealthy, Degraded)

Dapper - Micro ORM for Azure SQL

ISC - Inter service communication  (HttpClient.GetAsync(url))

Resilience - Circuit breaker/polly framework

Email - SendGrind

KeyVault - Azure Key Vault

When will you go for microservice & when will you go for monoliths?

If your company does not have appetite for below, then do NOT go for microservices

• Rapid provisioning (Infrastructure)
• Basic monitoring
• Rapid application deployment (deployment as well as rollback)
• DevOps culture

Another very important point is, if you cannot define the service boundary right at first place, then it will be very difficult to fix later in microservices.

Disadvantages of Microservice

Complexity – Microservices are distributed systems. Application needs to make remote calls. And remote calls tends to fail. This brings in complexity.

Consistency – Each microservices has its own data store. Hence only eventual consistency is possible.

Transactions – Managing transactions needs additional efforts.

Domain boundary – If you have defined the domain boundary (bounded context in DDD) wrong in first place, then it’s very difficult to fix in Microservice.

Advantages of Microservice

Scalability – It’s easy to scale in or scale out services depending on business need. Also doesn’t have to scale the entire application.

Availability – even if one service is down, application can be functional.

Partial deployment – it’s possible to deploy changes to specific to a microservices. This is faster compared to deploying the entire application.

Independently upgradable – each microservices are like components, it’s possible to independently upgrade or replace them.

Multiple platforms/technology - software development can be done using different technologies.  (Polyglot)