- The document discusses how Pivotal Cloud Foundry (PCF) helps developers run Spring applications at scale through features like the Java Buildpack, Spring deployment profiles, Spring Cloud Connector, and Spring Cloud Services for service discovery, configuration, and circuit breaking.
- It also outlines the ecosystem of services on PCF for Spring apps, including Pivotal Cloud Cache, MySQL for PCF, RabbitMQ for PCF, and Redis for PCF.
- The presentation concludes with a demo of pushing a Spring Boot app to PCF, observing logs, binding services, and using Spring Cloud features.
3. Cover w/ Image
Agenda
■ Why Spring and PAS?
■ How PCF helps you run Spring at scale
■ Services Ecosystem for Spring Apps
■ Demo
4. Hardware
IaaS
Container Orchestrator
Application Platform
Landing your workload on the right target is key to
balancing automation vs. desired flexibility required
Higher flexibility and
less enforcement of
standards
Lower development
complexity and higher
operational efficiency
Function
Platform
5. Hardware
IaaS
Container Orchestrator
Application Platform
Landing your workload on the right target is key to
balancing automation vs. desired flexibility required
Higher flexibility and
less enforcement of
standards
Lower development
complexity and higher
operational efficiency
Function
Platform
6. 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
PKS
Pivotal Container
Service
PAS
Pivotal Application
Service
PFS
Pivotal Function
Service
Pivotal Services
Marketplace
Pivotal and
Partner Products
Any App
Every Cloud
One Platform
PCF 2.0 — for everything
that matters
Concourse
8. Java Buildpack
Immutable Infrastructure
for JVM frameworks
Build Containers from a single control point
Robust JRE / JVM Framework options
Self executable JAR / Java main()
Advanced JVM memory calculator
JVM heap dump histograms
Spring Boot CLI apps
Robust 3rd party framework & product support
9. Spring
Deployment
Profiles
Transition between environments
without recompiling / rewriting
Automatic enablement of “cloud” @Profile on deploy
Any @Configuration class in this profile will be
automatically applied
No recompile required to adapt to deployment envs
https://spring.io/blog/2015/01/13/configuring-it-all-out-or-12-factor-app-style-configuration-with-spring
10. Spring Cloud
Connector for
Cloud Foundry
Bring Cloud Foundry service
connection data directly into your
Spring Beans
Automatically binds with platform services:
databases, message broker, etc…
SCC creates beans with relevant properties
11. Spring Cloud &
Spring Cloud
Services (SCS)
Developing on the Desktop
vs.
Deploying in Production
DEV PROD
Security: OAUTH2, TLS, PAS
UAA integration, RBAC
Ops: BOSH release for Config
Server, Service Registry, Circuit
Breaker
12. SCS:
Config Server
Zero downtime app updates –
dynamically update application
configuration
app C
greeting: hi
app B
greeting: hi
app A
greeting: hi
Config Server
2. Source config
1. Push config
1. Pull config
Hashicorp Vault
Git Source Repos
greeting: hi
2. API keys, secrets
Dev Desktop
13. SCS:
Service Registry
NetflixOSS Eureka Intelligent
Routing Foundation
Service
Registry
ConsumerProducer
1. register
2. discover
3. connect
Service
RegistryService
RegistryService
Registry
14. SCS:
Circuit Breaker
Fault Tolerance Library for
Distributed Systems
Closed
on call / pass through
call succeeds / reset count
call fails / count failure
threshold reached / trip
breaker
Half-Open
on call / pass through
call succeeds / reset
call fails / trip breaker
Open
on call / fail
on timeout / attempt reset
trip
breaker
reset
attempt
reset
trip
breaker
15. Apps Manager
Rich management and
observability of Spring Boot
applications
Transparent security integration with Pivotal Cloud
Foundry UAA, icon recognition for boot apps
/actuator//loggers to list or modify log levels at runtime
/actuator/mapping for all @RequestMapping paths
/actuator/info for env, build & Git info
/health information
/actuator/dump + /actuator/heapdump
/actuator/trace for HTTP requests
16. PCF Metrics
Trace Explorer:
Distributed trace call graph &
visually correlated logs
Understand failures and latency in microservice
architecture, no manual zipkin management
Your custom Spring Boot /metrics automatically
display as graphs
Interactive, graphical displays of request traffic
through an app
View correlated logs to time window
Visualize and filter metrics by AI
Integrated with PCF UAA Security
17. Container Health
& Performance
1st responder troubleshooting
tools for DevOps
Shows app developers a real-time view of data
Network metrics: HTTP req/err, and avg latency (every
second)
Container metrics: CPU, disk, and memory (every 30
seconds)
App events: create, update, start, stop, crash (on
occurrence)
18. Spring Cloud
Data Flow for
PCF
Streaming & Batch orchestration
via Cloud Native Data Pipelines
PAS & UAA Security
1. Provision for Ops
SCDF for PCF
tile
BOSH Director
2. Devs make instances
3. Write Apps!
mySQL RabbitMQ Redis
Metrics
Collector
Spring
Cloud
Skipper
CUPS
(e.g.
Kafka)
20. Pivotal Cloud Cache
● High performance, in-
memory, data at scale
for microservices
● Look-aside caches &
HTTP session state
caching
● NEW: WAN replication
MySQL for PCF RabbitMQ for PCF
● Enterprise-ready MySQL
for your developers
● Automate database
operations in developer
workflows
● NEW: Leader-follower
for multi-site HA
● Easily connect
distributed applications
with the most widely
deployed open source
message broker
● Enable connected
scalable, distributed
applications
● NEW: On-demand
clusters
● In-Memory cache and
datastore, configured for
the enterprise
● Efficient provisioning
matched to use cases
Redis for PCF
Enterprise Ready Services
BOSH Managed | On-Demand Provisioning | Dedicated Instances | Custom Service Plans
21. The Growing PCF Ecosystem
Mobile Networking
Storage
BPM
App Integration
DevOps Tooling
Data
Management
Microservices
Management
CRM
CommerceIAMIDE/CodeOther
APM/Monitoring
Search
Security
SIEM/Log/Audit
API Gateways
Messaging
IaaS
The more you can let platforms take over responsibility for running your applications, the more free time you’ll have to add new functionality to those applications.
Whenever you build new application functionality, you should ask yourself “what do you want to manage going forward?” Do you want to have to manage an VM, a container, or just deploy a function?
The further up the stack you can keep your applications, the less overall plumbing you need to worry about maintaining in the future.
Each tool has its own purpose. We should be careful that we articulate the value each tool brings to the table and what it’s strengths and weaknesses are. We need to make sure to point out that as you move “up the stack” from Containers to Serverless, you have less control, but you have less that you are responsible for as well. Users need to make sure they’re picking the right tool for the job they need to accomplish.
Examples:
If you need to be able to run your application on a specific port, or need to co-mingle a couple applications right next to each other, then a Container Orchestrator (PKS) is a great solution.
If you have a webapp that runs without any heroic efforts to change from running on your laptop to production, then an Application Platform (PAS) is a great solution.
If you have a piece of code that needs to run when some event happens, instead of deploying an application with a very limited scope of work, consider writing that functionality to run as a Function as a Service and deploy to a Serverless Infrastructure (PFS)
PCF now includes many abstractions with shared promises striped across each runtime.
-Any app, every cloud, one platform. We offer you the right tool for the job, namely:
-PAS, a runtime for apps. This delivers the best experience for your Java, .NET, and Node.js apps.
-PKS, a runtime for containers. PKS, based on Kubernetes, is now available to select customers. Use it to run developer-built containers, and workloads like Elasticsearch and Apache Spark. Talk to your account team for access!
-PFS, a runtime for functions. This is coming next year (contact us for early access). In the meantime, check out project riff on Github; this is the open source foundation for PFS.
-Services Marketplace. Your software doesn’t live alone. You need to extend it, secure it, observe it. And you want to use the biggest names in tech to do all this. The Services Marketplace has you covered!
Self executable JAR / Java main()
Spring Boot CLI apps
Autoreconfiguration for simple, single datasource apps (prototyping)
Advanced memory calculator
JVM heap dump histograms
Many tunable runtime params
Apps pushed with this buildpack will have:
Improved JVM memory calculation, resulting in fewer app terminations
Improved JVM Out of Memory Behavior - JVM terminal failures now include useful troubleshooting data: a histogram of the heap to the logs
Memory calculator configuration is simplified, with the use of standard Java memory flags.
“Because buildpacks don't "contain" copies of binaries, they provide enterprises with a point of governance over what software is deployed with an application. Choosing to use container images as your deployable artifact means more responsibility falls on the platform operators and developers.” (3rd party software in buildpack)
“Another advantage of using buildpacks is tuning runtime parameters for the software in the buildpack stack. ”
Auto-reconfiguration
Cloud Foundry auto-reconfigures applications only if the following items are true for your application:
Only one service instance of a given service type is bound to the application. In this context, different relational databases services are considered the same service type. For example, if both a MySQL and a PostgreSQL service are bound to the application, auto-reconfiguration does not occur.
Only one bean of a matching type is in the Spring application context. For example, you can have only one bean of type javax.sql.DataSource.
With auto-reconfiguration, Cloud Foundry creates the DataSource or connection factory bean itself, using its own values for properties such as host, port, username and so on. For example, if you have a single javax.sql.DataSource bean in your application context that Cloud Foundry auto-reconfigures and binds to its own database service, Cloud Foundry does not use the username, password and driver URL you originally specified. Instead, it uses its own internal values. This is transparent to the application, which really only cares about having a `DataSource where it can write data but does not really care what the specific properties are that created the database. Also, if you have customized the configuration of a service, such as the pool size or connection properties, Cloud Foundry auto-reconfiguration ignores the customizations.
For more information about auto-reconfiguration of specific services types, see the Service-Specific Details section.
AppDynamics Agent (Configuration)
Container Customizer (Configuration)
Debug (Configuration)
Dyadic EKM Security Provider (Configuration)
Dynatrace Appmon Agent (Configuration)
Dynatrace SaaS/Managed OneAgent (Configuration)
Google Stackdriver Debugger (Configuration)
Introscope Agent (Configuration)
Java Options (Configuration)
JRebel Agent (Configuration)
JMX (Configuration)
Luna Security Provider (Configuration)
MariaDB JDBC (Configuration) (also supports MySQL)
Metric Writer (Configuration)
New Relic Agent (Configuration)
Play Framework Auto Reconfiguration (Configuration)
Play Framework JPA Plugin (Configuration)
PostgreSQL JDBC (Configuration)
ProtectApp Security Provider (Configuration)
Spring Auto Reconfiguration (Configuration)
Spring Insight
YourKit Profiler (Configuration)
When you deploy a Spring application to Cloud Foundry, Cloud Foundry automatically activates the cloud profile, no reboot / recompile / re-deploy required.
Things like service credentials and hostnames.
The Environment also brings the idea of profiles. It lets you ascribe labels (profiles) to groupings of beans. Use profiles to describe beans and bean graphs that change from one environment to another. You can activate one or more profiles at a time. Beans that do not have a profile assigned to them are always activated. Beans that have the profile default are activated only when there are no other profiles are active.
Profiles let you describe sets of beans that need to be created differently in one environment versus another. You might, for example, use an embedded H2 javax.sql.DataSource in your local dev profile, but then switch to a javax.sql.DataSource for PostgreSQL that’s resolved through a JNDI lookup or by reading the properties from an environment variable in Cloud Foundry when the prod profile is active. In both cases, your code works: you get a javax.sql.DataSource, but the decision about which specialized instance is used is decided by the active profile or profiles.
You should use this feature sparingly. Ideally, the object graph between one environment and another should remain fairly fixed.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html
https://spring.io/blog/2015/01/13/configuring-it-all-out-or-12-factor-app-style-configuration-with-spring
Spring Cloud Connectors provides a simple abstraction for JVM-based applications running on cloud platforms to discover bound services and deployment information at runtime, and provides support for registering discovered services as Spring beans.
This connector discovers services that are bound to an application running in Cloud Foundry. (Since Cloud Foundry enumerates each service in a consistent format, Spring Cloud Connectors does not care which service provider is providing it.)
https://www.openservicebrokerapi.org/ (OSB is a CNCF and CFF standard).
http://cloud.spring.io/spring-cloud-connectors/spring-cloud-cloud-foundry-connector.html
New Relic, Cassandra, DB2, MongoDB, MySQL, Oracle, PostgreSQL, RabbitMQ, Redis, SMTP, SQL Server
Eureka, Hystrix, and Configuration servers are a critical underpinning elements to microservices architecture. Spring Cloud Services for Pivotal Cloud Foundry (PCF) packages server-side components of Spring Cloud projects, including Spring Cloud Netflix and Spring Cloud Config, and makes them available as services in the PCF Marketplace. This frees you from having to implement and maintain your own managed services in order to use the included projects. You can create a Config Server, Service Registry, or Circuit Breaker Dashboard service instance on-demand, bind to it and consume its functionality, and return to focusing on the value added by your own microservices.
Spring Cloud is great for working with Eureka, Hystrix, and Configuration servers (and much more) on the local developer desktop or in unit testing environments.
When you need to go to production – just swap out your maven / gradle dependencies for the SCS versions.
On the security side SCS offers
- End to end TLS / SSL communication enforcement for inbound and outbound requests
Full integration with PAS Org/Space permission model (RBAC) and UAA identity zones
OAUTH2 support
On the Ops side, Cloud Foundry goes way beyond automatic provisioning / de-provisioning. Since SCS is a complete BOSH release, it’s fully Cloud Foundry managed, as well as the underpinning infrastructure required for SCS to achieve it’s abilities (mySQL for PCF and RabbitMQ for PCF are required). These capabilities are unmatched by our competitors.
Lightweight daemons are the way to go in supporting microservice architecture. When dealing with stateful data, like configuration as a service, naming registries etc – having a lightweight process that is quick to boot/shutdown, and has the smallest possible scope is a big advantage. The main reason that lightweight daemons are preferable to similar capabilities that might come as part of a larger product, is that daemons boot/shutdown faster, are easier to containerize, cluster and operate. Developing up with a leader election algorithm, or data synch / change notification algorithm, is significantly easier with a server that has a small scope of function.
Config Server for Pivotal Cloud Foundry (PCF) is an externalized application configuration service, which gives you a central place to manage an application’s external properties across all environments. As an application moves through the deployment pipeline from development to test and into production, you can use Config Server to manage the configuration between environments and be certain that the application has everything it needs to run when you migrate it. Config Server easily supports labelled versions of environment-specific configurations and is accessible to a wide range of tooling for managing the content.
The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions. They work very well with Spring applications, but can be applied to applications written in any language. The default implementation of the server storage backend uses Git.
Spring Boot Actuator also adds a refresh endpoint to the application. This endpoint is mapped to /refresh, and a POST request to the refresh endpoint refreshes any beans which are annotated with @RefreshScope. You can thus use @RefreshScope to refresh properties which were initialized with values provided by the Config Server.
http://docs.pivotal.io/spring-cloud-services/1-5/common/config-server/writing-client-applications.html
Service Registry for Pivotal Cloud Foundry (PCF) provides your applications with an implementation of the Service Discovery pattern, one of the key tenets of a microservice-based architecture. Trying to hand-configure each client of a service or adopt some form of access convention can be difficult and prove to be brittle in production. Instead, your applications can use the Service Registry to dynamically discover and call registered services.
When a client registers with the Service Registry, it provides metadata about itself, such as its host and port. The Registry expects a regular heartbeat message from each service instance. If an instance begins to consistently fail to send the heartbeat, the Service Registry will remove the instance from its registry.
Service Registry for Pivotal Cloud Foundry is based on Eureka, Netflix’s Service Discovery server and client.
Circuit Breaker Dashboard for Pivotal Cloud Foundry (PCF) provides Spring applications with an implementation of the Circuit Breaker pattern. Cloud-native architectures are typically composed of multiple layers of distributed services. End-user requests may comprise multiple calls to these services, and if a lower-level service fails, the failure can cascade up to the end user and spread to other dependent services. Heavy traffic to a failing service can also make it difficult to repair. Using Circuit Breaker Dashboard, you can prevent failures from cascading and provide fallback behavior until a failing service is restored to normal operation.
When applied to a service, a circuit breaker watches for failing calls to the service. If failures reach a certain threshold, it “opens” the circuit and automatically redirects calls to the specified fallback mechanism. This gives the failing service time to recover.
Circuit Breaker Dashboard for Pivotal Cloud Foundry is based on Hystrix, Netflix’s latency and fault-tolerance library.
Apps Manager is a GUI that developers use to control applications and their lifecycle.
The Apps Manager UI supports several production-ready endpoints from Spring Boot Actuator, among other useful Spring Boot security integration points and auto-detection capabilities.
https://docs.pivotal.io/pivotalcf/2-0/console/using-actuators.html
Apps Manager is a web-based tool to help manage organizations, spaces, applications, services, and users. Apps Manager provides a visual interface for performing the following subset of functions available through the Cloud Foundry Command Line Interface (cf CLI):
Orgs: You can create and manage orgs.
Spaces: You can create, manage, and delete spaces.
Apps: You can scale apps, bind apps to services, manage environment variables and routes, view logs and usage information, start and stop apps, and delete apps.
Services: You can bind services to apps, unbind services from apps, choose and edit service plans, and rename and delete service instances.
Users: You can invite new users, manage user roles, and delete users.
By simply adding the Spring Cloud Sleuth distributed tracing to your application’s maven or gradle dependencies, then attach it to a binder (say, RabbitMQ). PCF Metrics helps you understand and troubleshoot the health and performance of your apps by displaying a dependency graph that traces a request as it flows through your apps and their endpoints, along with the corresponding logs.
PCF Metrics supports out-of-the-box Spring Boot Actuator metrics, custom app metrics, and instance-level metrics visualization.
Spring Cloud Sleuth is a tracer for Java / Spring. These systems are for Collecting, indexing, viewing the span/trace data. Sleuth / Zipkin aggregates all the info.
Send data from your app via logs, rabbitmq, logs, http…
Demo notes:
mySQL stores spans (single API calls, traces are the end to end)
PCF Metrics also gives you basic, “1st responder” trouble shooting tools to locate where errors may be occurring.
Container Metrics: Three graphs measuring CPU, memory, and disk usage percentages
Network Metrics: Three graphs measuring requests, HTTP errors, and response times
Custom Metrics: User-customizable graphs for measuring app performance, such as Spring Boot Actuator metrics
App Events: A graph of update, start, stop, crash, SSH, and staging failure events
Logs: A list of app logs that you can search, filter, and download
The SCDF for PCF is designed to work with SCS and of course, the RabbitMQ / mySQL, and Redis service broker technology already in the platform.
MySQL for apps, pipelines and task history
RabbitMQ for event messaging
Redis for capturing analytics data
Skipper is for CI of boot apps
CUPS is for user provided services off platform
Metrics Collector is used for throughput rates in Dashboard. It is a REST server that also listens (also a stream consumer) to a common destination (queue or topic) for data. It also performs in-memory metrics aggregation to reconstitute “stream level” throughput rates. SCDF UI hits the REST endpoints via regular polls to get the aggregated metrics to display in the dashboard.
Spring Cloud Data Flow for PCF. This PCF tile auto-provisions all the components (Data Flow server, Redis, RabbitMQ, MySQL) into a managed, cloud-native integration service on PCF.
PCF Scheduler. Extends existing support for one-off tasks with a component that initiates batch jobs on a schedule. Supports Spring Cloud Data Flow task execution. Currently a separate install
What’s at the center of every complex organization? Correction - what should be? Answer: a solid foundation! Pivotal Cloud Foundry has an architecture that allows virtually any vendor, partner, service, product, or stream both into and outside of the platform. PCF exposes simple and flexible APIs for interacting with “service brokers”, an industry standard concept that is implemented at the core of the platform. By flowing transactions and metrics through a reliable, secure, and scalable core, businesses can ensure that anything or anyone they communicate with can be managed.
https://pivotal.io/platform/services-marketplace