Spring Boot & Spring Cloud on k8s and PCF
- 1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 Lars Rosenquist June 2018 Spring Boot & Spring Cloud on k8s and PCF
- 2. Cover w/ Image Topics ■ Introduction ■ Platforms ■ k8s (PKS) vs PCF ○ Spring Boot + Spring Cloud ■ What runtime to pick? Future? ■ Pivotal Cloud Foundry ■ Q&A
- 3. Introduction So what’s this about?
- 4. Lars Rosenquist ● Platform Architect at Pivotal ○ Field organisation ○ Helping companies become great software companies ● Developing software professionally since 1998 ○ Financial, governmental, commercial ○ Java, Spring, Cloud Foundry ● Twitter: @larsrosenquist ● Email: lrosenquist@pivotal.io About me
- 5. Platforms Which platform for which workloads
- 6. CONTAINERS EVENT-DRIVEN FUNCTIONS DATA SERVICES MICROSERVICES Batches MONOLITHIC APPLICATIONS Companies have many ways to package and run their workloads in the cloud
- 7. Pick the right runtime for each workload CONTAINERS EVENT-DRIVEN FUNCTIONS DATA SERVICESMICROSERVICES Batches MONOLITHIC APPLICATIONS IaaS Container Orchestrator (CaaS) Application Platform (PaaS) Serverless Functions (FaaS)
- 8. Container Orchestrator Container Scheduling Primitives for Network, Routing, Logs & Metrics CONTAINER Choose the right tool for the job Developer Provides Tool Provides Application Platform APPLICATION Container Orchestrator Serverless Functions FUNCTION Application Platform IaaS Container Image & build L7 Network & Routing Logs, Metrics, Monitoring Services Marketplace Team, Quotas & Usage Function scheduling Function exec services Container Orchestrator
- 9. Container Orchestrator Container Scheduling Primitives for Network, Routing, Logs & Metrics CONTAINER Choose the right tool for the job Developer Provides Tool Provides Application Platform APPLICATION Container Orchestrator Serverless Functions FUNCTION IaaS Container Image & build L7 Network & Routing Logs, Metrics, Monitoring Services Marketplace Team, Quotas & Usage Application Platform Container Orchestrator Function scheduling Function exec services Lower complexity, higher efficiency Higher flexibility, lower standardization
- 10. Hardware IaaS Container Orchestrator Application Platform Serverless Functions Strategic goal: Push as many workloads as technically feasible to the top of the platform hierarchy Higher flexibility and less enforcement of standards Lower development complexity and higher operational efficiency
- 11. Application runtime <-> Container runtime Which platform for which workloads
- 12. Setup Cloud foundry ● Pivotal Cloud Foundry ● Running on GCP ● OS Cloud Foundry + extras (marketplace) ● Deployment shown here will work on any CF flavor Kubernetes ● Pivotal Container Service ● Running on GCP ● Vanilla k8s + extra (management layer) ● Deployment shown here will work on any k8s flavor
- 13. Application: Fortune teller Simple, multi-tiered Spring Boot application ● Fortune Service - REST endpoint ○ Uses a database, or in-memory if none available ○ Uses service registry ● Fortune Teller UI - Web app ○ Uses Fortune Service ○ Uses service registry ○ Uses circuit breaker ○ Uses config server GITHUB: https://github.com/NLxAROSA/fortune-teller UI Service Service registry MySQL Config server
- 14. Application: Fortune Teller Stack ● Spring Boot ● Spring Cloud ○ Netflix ■ Circuit breaker (Hystrix) ■ Service Registry (Eureka) ○ Spring Cloud Config ○ Spring Cloud Services connectors for CF ● Spring Data JPA
- 15. Building and deploying an application Cloud Foundry ● mvn clean package ● Create/edit manifest.yml ● cf push Kubernetes ● mvn clean package ● Create/edit Dockerfile ● mvn dockerfile:push ● Create/edit deployment and service ymls ● kubectl create -f deployment.yml ● kubectl create -f service.yml
- 16. Viewing application logs Cloud Foundry ● cf logs fortune-service --recent ● cf logs fortune-ui --recent ● Aggregated, streamed to firehose ● Basic options (for extended options use the firehose and a logging solution like Splunk, ELK, etc.) Kubernetes ● kubectl get po ● kubectl logs <podname> -f ● Not aggregated ● More flexible options, like tailing, since, timestamps, etc.
- 17. Distributed tracing Cloud Foundry ● Zipkin tracing built-in GoRouters ○ Can be enabled/disabled via Ops Manager ● Spring Cloud Sleuth makes it easy to add tracing information to logs ● CF integrates all logs into single stream Kubernetes ● Not trivial out of the box ● Experience depends on the tool used (e.g. StackDriver trace or Zipkin-proxy containers ● Other ways to enable Zipkin ● But do we really expect this from a container runtime vs a full blown platform?
- 18. Connecting to a database Cloud Foundry ● Database available via marketplace ○ Implementation depends on vendor ○ User experience should be similar ● cf create-service p-mysql 100mb fortunes-db ● Bind to application either by: ○ cf bind-service fortune-service p-mysql ○ Add to manifest.yml ● No config to maintain for developer ● Allows cool stuff like credential rotation Kubernetes ● Create yourself ○ Create your own pod/cluster ○ Use a Helm chart ● Use Open Service Broker API when available ● kubectl create -f database.yml ● No binding (just point to it via deployment.yml) ● Harder/more to maintain ● No automated capabilities in the platform (yet)
- 19. SSH into running application Cloud Foundry ● cf ssh fortune-service -i 0 Kubernetes ● kubectl get po ● kubectl exec -it <podname> -- /bin/bash
- 20. Developer experience summary Cloud Foundry ● Little overhead/less verbose ○ Specify app ○ Specify dependencies ● Platform handles for you ○ Routing ○ Port mappings ○ Load balancing Kubernetes ● More overhead/verbose ○ Specify app/container ○ Specify dependencies ● You specify ○ Routing ○ Port mapping ○ Load balancing ● Big ball o’yaml ○ Reminds of Spring XML config era ● Not platform by itself, snowflake pitfall
- 21. Regardless of differences Both experiences ● Both experiences are miles ahead of deploying straight to IAAS or bare metal ○ Standardized ways of configuration and deployment ○ Higher level of standardization = higher level of automation = faster time to market ● Both assume infrastructure is managed ○ Explicitly in CF (BOSH) ○ Implicitly on k8s (depending on vendor) ○ Less time spent on ops = faster time to market
- 22. Cloud Foundry or Kubernetes? How to pick where to deploy what workload?
- 23. Run on Pivotal Application Service (CF) Run on VM Run on Pivotal Container Service (K8s) What kind of application is this? Is the application cloud ready? Do you have a docker container? Can you build a docker container? CUSTOM COTS YES NO YES NO YES NOIs the application worth refactoring? NO YES NO Do you need low level control? YES K8s Benefit: Run any non-cloud native applications CF Benefit: Lower development complexity How to decide where to deploy workloads?
- 24. So what about the future? CAAS, PAAS, FAAS, ?
- 25. Some tweets to consider
- 26. Pivotal Cloud Foundry Short commercial break
- 27. vSphere Openstack AWS Google Cloud Azure & Azure Stack Shared Services Shared Security Shared Networking Logging & Metrics / Services Brokers / API Management Credhub / UAA / Single Sign On VMWare NSX Embedded Operating System (Windows / Linux) Application Code & Frameworks Buildpacks / Spring Boot / Spring Cloud / Steeltoe PAS Pivotal Application Service PKS Pivotal Container Service PFS Pivotal Function Service Pivotal Services Marketplace Pivotal and Partner Products Concourse
- 28. Benefits of PCF ● Spring Boot apps integration with AppsManager ● Spring deployment profiles (“cloud” profile) ● Spring Cloud Connector for Cloud Foundry (VCAP_SERVICES, VCAP_APPLICATION) ● Java Buildpack ○ Advanced JVM memory calculator ○ JVM heap dump histograms ○ 3rd party framework integration (APM) ○ Self-executable JARs ● Spring Security integration with CF SSO ● Spring integration with CredHub ● Spring Cloud Services ○ Config Server, Service Registry, Circuit Breaker Dashboard ● Spring Cloud Pipelines ● Spring Cloud Dataflow for PCF ● PCF Metrics
- 29. Q&A
- 30. Transforming How The World Builds Software © Copyright 2018 Pivotal Software, Inc. All rights Reserved.
Editor's Notes
- #7: By making the first task on any software effort “delivery” - deploy the code somewhere, even if it doesn’t do anything. And then keep doing that every time you change anything…
- #8: By making the first task on any software effort “delivery” - deploy the code somewhere, even if it doesn’t do anything. And then keep doing that every time you change anything…