This document summarizes a presentation about Spring and Pivotal Application Service (PAS). It discusses why developers use Spring and PAS, the market-leading Spring support in PAS, and the ecosystem of services available for Spring applications on PAS. It also provides an agenda that covers these topics and next steps.
3. Cover w/ Image
Agenda
■ Why Spring and PAS?
■ Market Leading Spring Support
■ Services Ecosystem for Spring Apps
■ Next Steps
4. How much time
do developers
spend
developing?
Source: Forrester Business
Technographics Global
Developer Survey, 2016
Base: 719 Developers who work
for a software company, as a
game developer, for internal IT,
or in technology services
13%
18%
34%
33%
25%
24%
42%
31%
23%
26%
30%
26%
15%
17%
19%
18%
7%
7%
9%
6%
10%
5%
3%
4%
4%
None
<15 Min
15-59 Min
1-2 Hr
3-4 Hr
4+ Hr
Writing new / changing existing
code
email
miscellaneous tasks
deploying code
configuring infrastructure
5. How much time
do developers
spend
operating?
Source: Forrester
Business Technographics
Global Developer Survey,
2016
13%
14%
16%
21%
21%
24%
30%
30%
29%
32%
30%
27%
32%
28%
22%
18%
14%
10%
12%
8%
10%
7%
4%
5%
3%
None
<15 Min
15-59 Min
1-2 Hr
3-4 Hr
4+ Hr
Writing new / changing existing
code
Building or integrating code
Debugging / production support
Designing new functionality
Unit testing
7. 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
8. 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
9. 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
Any App
Every Cloud
One Platform
PCF 2.0 — for
everything that matters
Concours
e
10. Pivotal Application Service (PAS) App Runtime
DYNAMIC ROUTE SERVICES / API MANAGEMENT
APP MICROSERVICES TECHNOLOGY
Spring Boot Steeltoe
Spring Cloud
Services
DATA MICROSERVICES TECHNOLOGY
Spring
Cloud Data
Flow
Cloud
Cache
RabbitMQ MySQL
YOUR APPLICATIONS
PLATFORM
Elastic Runtime Concourse
App
Autoscaler
PCF Metrics CredHub
Orgs, Spaces,
Roles and
Permissions
EMBEDDED OS
CLOUD ORCHESTRATION
CONTAINER ORCHESTRATIONWindows Linux
Amazon
Web Services
Microsoft
Azure
Google
Cloud
Platform
Open Stack VMWare
SERVICE
BROKER API
PIVOTAL
APPLICATION
SERVICE
PIVOTAL
CLOUD FOUNDRY
BOSH
MODERN
CLOUD NATIVE
PLATFORM
MULTI CLOUD
11. Eliminate Boilerplate Code, Focus on Business Logic
Spring Framework Spring
Security
Spring Data Reactor Spring Batch Spring Integration
Spring Boot
Spring Cloud
Spring Cloud Pipeilnes
12. Cover w/ Image
Live Demo
■ Push an app (Spring Boot)
■ Scale an app
■ Observe logs
■ Bind a service
■ Apps Manager
■ Spring Cloud Services
■ Repositories
https://github.com/fmarinelli/spring-music
https://github.com/fmarinelli/fortune-teller-demo
14. 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
15. 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
16. Spring Cloud
Connector for
Cloud Foundry
Bring Cloud Foundry service
connection data directly into your
Spring Beans
Auto-enabled if VCAP_APPLICATION is detected
Check for VCAP_SERVICES and parse common
data for supported services *
17. 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
18. Spring Cloud
Pipelines
Opinionated template of a
deployment pipeline
Jumpstart your CI / CD pipeline setup!
Packaged up best practices from Pivotal
Each pipeline step is an (editable) bash script
Supports Jenkins, Concourse, Maven, Gradle
Target PAS or PKS
19. CredHub
Secure credential management
Implemented as a Spring Boot app
Provides an API for storing, generating, and retrieving
credentials
Supports credentials of different types: simple strings,
passwords, certificates, keypairs, JSON objects
Supports pluggable Hardware Security Modules
20. Container to
Container
Networking
Enabling direct microservice to
microservice communication
Improve on legacy CF ASG experience:
Order of magnitude latency reduction
No expensive “hairpin” trip through LB/FW
Support for multiple TCP/UDP ports
Allow SDN traffic like VMware NSX
Support for “Zero Trust” security posture
B
C
A
21. Cloud Foundry
UAA
OAuth 2 Server for centralized ID
management
Implemented as a standard Spring MVC Webapp
Deploy Local Tomcat for testing, Cloud Foundry for
production
Support for open Auth / AuthZ standards:
● Oauth
● OpenID Connect
● SAML
● LDAP
● SCIM
22. Spring Security
and CF SSO
Cloud Foundry UAA (built-in)
Active Directory FS
Azure Active Directory
(SAML/OIDC)
CA SSO
GCP OpenID Connect
Okta
PingFederate
PingOne Cloud
Integrates to any ID Federation via (SAML/OpenID)
IDMs are self – service for DevOps via a marketplace
Converts complex SAML interactions into basic OAuth
tokens
Works great with Spring Security (Java), Steeltoe.io
(.NET)
23. Implementing monolith or
microservice patterns on the cloud
with Spring Boot
I. One Codebase, One App
II. Dependency Management
V. Build, Release, Run
XI. Logs
IX. Disposability
IV. Backing Services
X. Environmental Parity
XII. Administrative Process
VII. Port Binding
VI. Process
VIII. Concurrency
III. Configuration
Spring Boot makes 12+ factor
style apps easy.
Microservices requires a lot of
repetitive:
Property Configuration
Port Binding
Connecting to Backing
Services
Logging
Deployment, Redeployment
12 Factor Apps
24. 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
25. SCS:
Service Registry
NetflixOSS Eureka Intelligent
Routing Foundation
Service
Registry
ConsumerProducer
1. register
2. discover
3. connect
Service
RegistryService
RegistryService
Registry
26. 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
27. SCS:
CF CLI Plugin
Spring Cloud Services integration
for the CF Command Line
Interface
Provides SCS Dev Tools directly from CF CLI
- List apps in eureka instance
- Enable/disable Eureka registration
- Deregister service in Eureka
- Encrypt config server values
28. Apps Manager
Rich management and
observability of Spring Boot
applications
Transparent security integration with Pivotal Cloud
Foundry UAA, icon recognition for boot apps
/loggers to list or modify log levels at runtime
/mapping for all @RequestMapping paths
/info for env, build & Git info
/health information
/dump and /heapdump
/trace for recent HTTP requests
29. 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
30. 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)
31. 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)
33. 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
34. 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
35. Cover w/ Image
Agenda
■ Why Spring and PAS?
■ Market Leading Spring Support
■ Services Ecosystem for Spring Apps
■ Next Steps
58% of developers spend an hour or more a day writing code, but only 28% - a bit more that 1 in 4 spend 3 or more hours a day writing code.
38% spend at least an hour a day on e-mail
30% spend and hour a day deploying code! - that seems like too much to me!
29% spend and hour a day configuring infrastructure!
46% spend at least an hour debugging or dealing w/ production support issues… essentially dealing w/ technical debt.
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!
Best runtime for Spring and Spring Boot — Spring’s microservice patterns—and Spring Boot’s executable jars—are ready-made for PAS.
Turnkey microservices foundation — Spring Cloud Services provides a built-in Config Server, Service Registry, and Circuit Breaker Dashboard and Cloud Foundry UAA integration.
Advanced Networking — Automated DNS, HTTP/TCP routing, C2C networking, SDDN integration, Load Balancing
CI/CD Pipeline Ready — Fully integrated with continuous integration/continuous delivery (CI/CD) tools like Concourse.
Storage-ready — Run stateful apps in a modern application runtime using the Volume Services NFS v3 service broker.
Container-ready — PAS supports the OCI format for Docker images. Run platform-built and developer-built containers.
Monitoring, Metrics, Logging, Dev Tools — PCF Metrics reimagines monitoring for microservices, while loggregator and advanced CLI / GUI dev tools make apps easy.
PAS is at it’s best when used for stateless workloads, like web apps, REST APIs, etc. While it can handle NFS v3 mounts, PKS is a better choice for databases, search engines, etc.
Spring excels at these stateless workloads, making it an ideal fit.
When making everything from 12 factor to fully Cloud Native apps, Spring & PAS both work overtime to eliminate repetitive, boilerplate code so you can focus on what matters.
By contrast, Java EE servers were designed to be stateful, mutable, things that had to be kept alive due to instance – specific data.
If a Java Application Server process is now only starting a statically known set of Java code; the very idea of an application server changes drastically to be more about a way of performing dependency injection and including the modular services you need; that sounds more like a framework than what we’ve come to think of as a Java Application Server.
Learn more here from Redhat:
https://blog.fabric8.io/the-decline-of-java-application-servers-when-using-docker-containers-edbe032e1f30#.osullguxl
Running Spring requires only a JVM, but is also designed to automate working with lightweight Java webservers like Apache Tomcat, Netty and Undertow.
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.
Every company sets up a pipeline to take code from your source control, through unit testing and integration testing, to production from scratch. Every company creates some sort of automation to deploy its applications to servers. Enough is enough - time to automate that and focus on delivering business value. Remove manual, error prone steps, enable rollback and blue/green deployments, and much more. CI / CD pipelines are a critical part of achieving the development and deployment velocity you want – in a safe land repeatable fashion.
“I have stopped counting how many times I’ve done this from scratch” - was one of the responses to the tweet about starting the project called Spring Cloud Pipelines.
UAA provides identity based security for applications and APIs. It supports open standards for authentication and authorization, including the following:
Oauth, OpenID Connect, SAML, LDAP, SCIM
The major features of UAA include the following:
User Single Sign-On (SSO) using federated identity protocols
API security with OAuth
User and group management
Multi-tenancy support
Support for JWT and opaque as a token format
Token revocation
Operational flexibility (BOSH release for multicloud, or push as web app)
Database flexibility, including support for MySQL, Postgres, and SQL Server
Auditing, logging, and monitoring
Token exchange for SAML and JWT bearers
Rest APIs for authentication, authorization, and configuration management
ASG == Application Security Groups, the V1 implementation that predated C2C networking.
This enables microservice discovery, client LB
Description
Operators enable/disable Container to Container communication as a global policy
Developers specify which Apps and on which ports direct communication is permitted
Application traffic tagged with VXLAN group policy tag, allowing tag-based access control
Key Use Case(s)
Applications composed of many interconnected microservices
Efficient network traversal when using Spring Cloud Services, no gorouter “hairpinning”
Notes
Containers communicate using a single, system-wide routed (L3) IP network
Changing policy does not require an application restart
Policy is configured through use of a cf CLI plugin or directly via the CF Networking API
UAA provides identity based security for applications and APIs. It supports open standards for authentication and authorization, including the following:
Oauth, OpenID Connect, SAML, LDAP, SCIM
The major features of UAA include the following:
User Single Sign-On (SSO) using federated identity protocols
API security with OAuth
User and group management
Multi-tenancy support
Support for JWT and opaque as a token format
Token revocation
Operational flexibility (BOSH release for multicloud, or push as web app)
Database flexibility, including support for MySQL, Postgres, and SQL Server
Auditing, logging, and monitoring
Token exchange for SAML and JWT bearers
Rest APIs for authentication, authorization, and configuration management
The Single Sign-On service is an all-in-one solution for securing access to applications and APIs on PCF. The Single Sign-On service provides support for native authentication, federated single sign-on, and authorization. Operators can configure native authentication and federated single sign-on, for example SAML, to verify the identities of application users. After authentication, the Single Sign-On service uses OAuth 2.0 to secure resources or APIs.
Single Sign-On
The Single Sign-On service allows users to log in through a single sign-on service and access other applications that are hosted or protected by the service. This improves security and productivity since users do not have to log in to individual applications.
Developers are responsible for selecting the authentication method for application users. They can select native authentication provided by the User Account and Authentication (UAA) or external identity providers. UAA is an open source identity server project under the Cloud Foundry (CF) foundation that provides identity based security for applications and APIs.
SSO supports service provider-initiated authentication flow and single logout. It does not support identity provider-initiated authentication flow. All SSO communication takes place over SSL.
OAuth 2.0 Authorization
After authentication, the Single Sign-On service uses OAuth 2.0 for authorization. OAuth 2.0 is an authorization framework that delegates access to applications to access resources on behalf of a resource owner.
Developers define resources required by an application bound to a Single Sign-On (SSO) service instance and administrators grant resource permissions.
Boot and Cloud Foundry together make it easy to develop 12 Factor applications.
Boot handles II, III and plays a supporting or enabling role in IV, V, VII (port binding)
Declare dependencies == boot offers 1st class Maven / Gradle with Boot starters, Starters (automatic project dependency management)
Autconfiguration for Spring Boot removes boilerplate application configuration work
Environment and @Profile = makes it simple to adapt from dev, stage to prod without recompile, automatically
Actuators = built in metrics / monitoring, integrated into PCF Apps Man console
@profile -- Segregate parts of the application configuration and make it available in certain environments via
-Annotations
-Properties file
Spring Cloud Connectors are a Spring library that exposes application information, cloud information, and discovered services as Spring beans of the appropriate type (for example, an SQL service will be exposed as a javax.sql.DataSource with optional connection pooling)
12 Factors and PCF:
One Codebase: Single code base managed in SCC; or set of repositories from a common root. Look for “the seams” in the “app” and try and break things up a bit if possible. Getting to a single codebase makes it cleaner to build and push any number of immutable releases across various environments. The best example of violating this is when your app is composed of a dozen or more code repos. Or when one code repo is used to produce a bunch of applications.
Dependency Management: The classic enterprise might rely on either “bootstrapping” (bundling all dependencies with the app binary) or use of a “mommy server” (providing everything the app needs – a server to host and all it’s dependencies). Most contemporary languages take advantage of facilities like Maven and Gradle or Nuget for .NET. Regardless of tool the idea is … allow developers to declare dependencies and let the tool ensure it’s satisfied. Just need to ensure the tool being used doesn’t package dependencies in a folder structure under the app itself.
Build, Release, Run: a single codebase taken through a build process to produce a single artifact; then merged with configuration information external to the app. This is then delivered to cloud environments and run.
Configuration: this is about externalizing your config is easy to say but can be challenging depending on how the app was built. There are various solutions – refactor your code to look for environment variables. You could use Spring Config server or other products
Logs: should be treated as event streams, that is a time-ordered sequence of events emitted from an app. You can’t log to a file in a cloud. You log to stdout / stderr and let the cloud provider or related tools deal with it
Disposability: in a cloud process is disposable – it can be destroyed and created at any time. Designing for this is important to ensure good uptime and to get the benefit of auto scaling, etc. If you have processes that take a while to start up or shut down they should be separated as a backing service and optimized to accelerate performance
Backing Services: a backing service is something your app depends on – like a database or some kind of REST service. The app should declare it needs a backing service via external config. The Cloud will bind your app to the service. And it should be possible to attach and reattach without restarting the app. This loose coupling has a LOT of advantages. It also allows you to use a circuit breaker (part of the Netflix OSS and SCS) to gracefully handle an outage scenario.
Environmental Parity: we’ve all probably worked in situations where a shared dev sandbox has a different scale and reliability profile than QA, which is also different than prod. Keeping environmental consistency is much easier in a Cloud environment like PCF. Doing this and automating as much of the SDLC as possible will help you confidently deploy smaller things more often. Spring Boot executable JAR embed
Administrative Process: these are things like timer jobs, one-off scripts and other things you might have done using a programming shell. These are fine in the monolithic world but get complicated when you scale horizontally with multiple instances of the same app trying to kickoff a job. An alternate approach might be to break apart the job into it’s own microservice with a rest end point for controlled invocation
Port Binding: in the non-cloud world it’s typical to see a bunch of apps running in the same container, separating each app by port number and then using DNS to provide a friendly name to access. In the Cloud you avoid this micro-management – the Cloud provider will manage port assignment along with routing, scaling, etc.
Process: the original 12-factor definition here says that apps must be stateless. But state needs to be somewhere! Our guidance is to move any long-running state into external, logical backing services that rely on Redis or Mongo or whatever to manage what they need.
Concurrency: PCF and other cloud platforms are built to scale horizontally. There are design considerations here – your app should be disposable, stateless and use share-nothing processes. This allows you to leverage features like auto-scale, blue-green deployment, etc.
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.
The powerfully simple cloud foundry CLI tool makes interacting with PAS easy for developers. This plugin extends the CF CLI for SCS by adding management, and lifecycle commands.
List Applications registered with Service Registry
`cf service-registry-list service-registry`
Service Registry Info
`cf service-registry-info service-registry`
Enable/Disable Application registration on Service Registry
`cf service-registry-enable service-registry app_name`
`cf service-registry-disable service-registry app_name`
Deregister Application from Service Registry
`cf service-registry-deregister service-registry appname [-i #instance]`
Encrypt value via Config Server
`cf config-server-encrypt-value config-server mysecret`
Value generated can be used in Config Server configuration file with `{crypt}` prefix
Manage SCS service instance backing applications’ state
View status - `cf scs-status scs-si-name`
Stop - `cf scs-stop scs-si-name`
Start - `cf scs-start scs-si-name`
Restart - `cf scs-restart scs-si-name`
Restage - `cf scs-restage scs-si-name`
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