Downloaded 19 times
Uploaded byVMware Tanzu
Spring Boot & Spring Cloud Apps on Pivotal Application Service - Daniel Lavoie
The document provides an overview of Pivotal's Spring and Pivotal Application Service (PAS), emphasizing market-leading support and a robust ecosystem for developing cloud-native applications. It includes insights into developer time allocation for coding and operations, various services offered for Spring apps, and the advantages of using Spring frameworks for building microservices. The document also highlights next steps for engagement and exploration of Pivotal's offerings.
More Related Content
Similar to Spring Boot & Spring Cloud Apps on Pivotal Application Service - Daniel Lavoie
Spring Boot & Spring Cloud Apps on Pivotal Application Service - Daniel Lavoie
- 1. © Copyright 2018Pivotal Software, Inc. All rights Reserved. Spring and Pivotal Application Service Daniel Lavoie Platform Architect dlavoie@pivotal.io
- 2. Cover w/ Image Agenda ■Why Spring and PAS? ■ Market Leading Spring Support ■ Services Ecosystem for Spring Apps ■ Next Steps
- 3. How much time dodevelopers 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
- 4. How much time dodevelopers 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
- 5. Hardware IaaS Container Orchestrator Application Platform Landing yourworkload 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 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.3 — for everything that matters Concours e
- 7. 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
- 8. 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
- 9. © Copyright 2018Pivotal Software, Inc. All rights Reserved. Market leading Spring Support
- 10. Cloud Foundry UAA OAuth 2Server 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
- 11. Spring Security and CFSSO 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)
- 12. CredHub Secure credential management Implementedas 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
- 13. Implementing monolith or microservicepatterns 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
- 14. Spring Deployment Profiles Transition between environments withoutrecompiling / 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
- 15. Spring Cloud Connector for CloudFoundry 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 *
- 16. Java Buildpack Immutable Infrastructure forJVM 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
- 17. Spring Cloud & SpringCloud 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. SCS: Config Server Zero downtimeapp 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
- 19. SCS: Service Registry NetflixOSS EurekaIntelligent Routing Foundation Service Registry ConsumerProducer 1. register 2. discover 3. connect Service RegistryService RegistryService Registry
- 20. SCS: Circuit Breaker Fault ToleranceLibrary 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
- 21. SCS: CF CLI Plugin SpringCloud 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
- 22. Spring Cloud Pipelines Opinionated templateof 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
- 23. Container to Container Networking Enabling directmicroservice 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
- 24. Apps Manager Rich managementand 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
- 25. PCF Metrics Trace Explorer: Distributedtrace 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
- 26. Container Health & Performance 1stresponder 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)
- 27. Spring Cloud Data Flowfor 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)
- 28. © Copyright 2018Pivotal Software, Inc. All rights Reserved. Services Ecosystem for your Spring Apps
- 29. 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
- 30. The Growing PCFEcosystem 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
- 31. © Copyright 2018Pivotal Software, Inc. All rights Reserved. Next Steps
- 32. © Copyright 2017Pivotal Software, Inc. All rights Reserved. Version 1.0 ● Contact your account team with questions ● Try hosted software now at run.pivotal.io ● On prem software published to network.pivotal.io ● Sign up for the next roadmap call roadmap-registration.cfapps.io (First Thursday of every month, 2pm ET/11am PT)
- 33. Transforming How TheWorld Builds Software © Copyright 2017 Pivotal Software, Inc. All rights Reserved.
Editor's Notes
- #4 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!
- #5 46% spend at least an hour debugging or dealing w/ production support issues… essentially dealing w/ technical debt.
- #6 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)
- #7 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!
- #8 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.
- #9 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.
- #11 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
- #12 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.
- #13 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
- #14 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.
- #15 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
- #16 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
- #17 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)
- #18 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.
- #19 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
- #20 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.
- #21 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.
- #22 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`
- #23 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.
- #24 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
- #25 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.
- #26 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)
- #27 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
- #28 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
- #31 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