Chapter Conclusion

Summary #

For synchronous microservices, Cloud Foundry’s solutions are very similar to those of Kubernetes.

• Service discovery also works via DNS making it transparent for client and server. In addition, no code needs to be written for the registration.

• Load balancing is also transparently implemented by Cloud Foundry. If several instances of a microservice are deployed, the requests are automatically distributed to these instances.

• For the routing of external requests, Cloud Foundry relies on DNS and a distribution of the requests to the various microservice instances.

• For resilience, the Cloud Foundry example uses the Hystrix library. Cloud Foundry itself does not offer a solution in this area.

In addition, a PaaS provides a standardized runtime environment for microservices and can be an important antidote to the high level of operational complexity that microservices bring. Thus, a PaaS enforces a standardization that is often desirable in the context of macro architecture.

Compared to Docker or Kubernetes (chapter 13), a PaaS provides less flexibility. This can also be a strength due to the standardization that goes hand in hand with reduced flexibility.

Modern PaaS also offers the possibility of adapting the environment with concepts like buildpacks or running Docker containers with arbitrary applications.

Benefits #

• PaaS solves typical problems of microservices like load balancing, routing, and service discovery.

• Cloud Foundry introduces no code dependencies.

• PaaS cover operation and deployment.

• PaaS enforce standardization and are thereby the definition of a macro architecture.

• Developers only have to deliver applications. Docker is hidden.

Challenges #

• Cloud Foundry requires a complete switch of the operation approach.

• Cloud Foundry is powerful, but also complex.

• Cloud Foundry provides a high degree of flexibility, however, compared to Docker containers this flexibility still has its limits.