Continuous Everything in a Multi-cloud and Multi-platform Environment

Editor's Notes

• #2: This presentation introduces Pivotal, and our value prop, to a new audience. It’s targeted at executives and decision makers.
• #5: These five services codify Pivotal best practices. The Build Service uses Cloud Native Buildpacks to not just package code into containers, but also patch images on day 2. Our Spring Runtime ensures that you’re in good hands with support for OpenJDK and Spring. Event-driven computing is the next wave, and our Function Service streamlines the deployment of modern apps. Configuring the network and building in logging/observability are roles for a platform, not an individual. Pivotal Service Mesh solves this. Finally, you need an effective way to consume on or off-platform services, and do so with late binding so that you don’t infect your code with environmental details. These services often extend one another, and run on PKS, or in the future, any Kubernetes.
• #6: Here’s what we’re thinking, and it’s definitely not final. With Kubernetes at its core and the option for modular components, we see this as an evolution of PCF. That means that a PAS license would (ideally) entitle you to all components (and the vertically integrated PAS itself), with everything running on a Kubernetes dial tone. The value line is moving up, and now that we don’t need to invest in building our own orchestration layer, we can direct our attention to automating and improving more parts of the developer and operator experience.
• #7: Running software at scale? Not easy.
• #19: Don’t forget: Holistic view of an application’s resources and configuration is hard to obtain with cloud platforms, multiple accounts, regions, or even cloud platforms ACCOUNTS, REGIONS, CLOUDS Consistency is a bitch
• #24: 2012: Asgard built by Netflix for managing cloud-based applications and infrastructure with goal to simplify delivery of Netflix services to Amazon Web Services (AWS). Asgard was great for Netflix, but not easy to build on community input and innovations. 2014: They restarted with Spinnaker, combining the infrastructure management focus of Asgard with sophisticated deployment techniques. Initially this was only consumed internally by Netflix. 2015: They then open sourced the product properly. Netflix partnered with Google, Microsoft and Pivotal to deliver out-of-the-box multi-cluster, multi-cloud management and deployment. 2016: Chaos monkey merged into Spinnaker by Netflix 2017: Google contributed Halyard. 2018-2019: Pivotal for the past year has been doubling down on contributions to ensure full support for PCF and optimal use for our enterprise clients. Pivotal is third largest contributor behind Netflix and Google. Spring 2019: Spinnaker was brought under the newly formed Continuous Delivery Foundation that also includes products like Jenkins and Tekton. This is a great home for the solution to grow even more.
• #25: Spinnaker is a CD platform from Netflix and Google. It’s OSS and has a significant community of contributors. It’s multi cloud and multi platform and a single instance of Spinnaker can work with multiple cloud providers simultaneously.
• #26: As a CD tool, Spinnaker standardizes cloud infrastructure actions, such as provisioning and management, encapsulating a lot of best practices developed through years of continuously delivering software at Netflix, Google, Box and other companies. It’s a mature and feature-rich product that acts as a point of integration for other tools enabling CD. Spinnaker functions as an application-centric control plane, abstracting the details of cloud platforms that are not relevant to developers and organizing cloud resources around applications. Infrastructure and security teams can focus on building in the right defaults and traceability into how Spinnaker provisions these resources. In the end, all applications are deployed in a consistent, secure way. Spinnaker maintains inventory of where applications and their instances are deployed across multiple environments, IaaS and runtimes—enabling continued feedback in production. It is built by querying cloud providers and is even available for applications not deployed by Spinnaker. This level of oversight shows the health of applications and allows you to take corrective actions, such as restarting a failing application or rolling it back. Spinnaker complements traditional CI—by picking up where it leaves off—with complex, rule-driven, cloud-provider-integrated, high-volume deployments. Spinnaker adds CD pipeline workflows to support more advanced rollout, mechanisms like parallel deployments, conditional deployments, time window restrictions, and application canary deployments.
• #27: Better screenshot when a bug is fixed.
• #28: Unlike cloud providers that group resources by types (network, compute, monitoring), spinnaker groups all this resources per application in a single screen. Higher level abstractions on top of these resources as applicable to app developers with the right defaults built in.
• #32: Red black - when two versions cannot coexist Rolling r/b - two versions should be able to coexist Canary - tested against baseline metrics