the architecture of continuous innovation - cloud-council.org · 9/10/2015 · • are suitable...
Post on 30-May-2020
2 Views
Preview:
TRANSCRIPT
Christopher Ferris| @christo4ferris
CTO Open Technology | IBM Cloud
The Architecture of Continuous Innovation
Sept 10, 2015
Dieu Cao| @dieuthicao
Cloud Foundry Runtime PMC Lead | Pivotal
Chip Childers | @chipchilders
VP Technology | Cloud Foundry Foundation
Application Patterns Are Changing
Microservices are great.
Per Martin Fowler they lead to specific requirements:
rapid provisioning
basic monitoring
rapid application deployment
devops culture
• Use declarative formats for setup automation, to minimize time and
cost for new developers joining the project;
• Have a clean contract with the underlying OS, offering maximum
portability between execution environments;
• Are suitable for deployment on modern cloud platforms, obviating
the need for servers and systems administration;
• Minimize divergence between development and production,
enabling continuous deployment for maximum agility;
• And can scale up without significant changes to tooling,
architecture, or development practices.
But, even that’s not enough
• Role based access to resources: the right
people should be able to do things and the
wrong people shouldn’t
• Run specified bits on demand: take code, put it
together with all the rest of the things it needs
and and get it running
• Coordinate cross service configurations: in a
service oriented world, services need to be
configured to connect with each other
• Route public requests to running bits: the next
big thing needs access to the internet
• Read and write persistent data: data has to live
somewhere
• Add and remove resources: scaling is a great
problem to have, but still
• Isolate resources and failures without
isolation and decoupling, that is one big
distributed single point of failure
• Measure performance/health: can’t manage
what you don’t measure
• Detect and determine failure: sometimes,
things get real… but how do you know
• Recover failures: someone is going to have
to clean this mess
• Work tomorrow: when everything you’ve
thought to be true has been shown not to
Containers Are Awesome, but Not Enough
Cloud Native Application Platform
Platforms on Platforms
• Better SLAs
• Flexibility
• Speed
• Availability
• Faster Time To Market
• Mobile + Data
Services
• Agile and Iterative
• Leverage OSS
• Continuous Delivery
• No Downtime
• Instant scaling
• Consistency &
Automation
App Dev App Ops IaaS
Understanding Cloud Native Application Platforms
.war .jar
dependencies
libraries
service manifest
App App App
LB
DB
Multi-server run time environment(s)
.tar.gz
Turning this: Into this:
Unit of Value
IaaS == Virtual Machine
• Opaque to the system
• Orchestration is post-hoc
• System changes are imperative
(“launch” stuff)
App Platform == Application
• Containers are transparent
• Lifecycle is fully managed
• System changes are
declarative (manifest.yml)
Removing Developer and Operational Constraints
BUILD APPLICATION
PUSH FIRST RELEASE
MAINTAIN APPLICATION
UPDATE APPLICATIONS
RETIRE APPLICATIONS
• Auto-detect frameworks
• Link to App Platform
• Self-service deploy
• Dynamic routing
• A/B versioning
• Live upgrades
• Self-service
removal
• Elastic scale
• Integrated HA
• Log aggregation
• Policy and Auth
CF
Core
CF
Core
Cloud Foundry Core • Certified Products and “As a
Service” Implementations
• Must Use Specific CF-Release
CFF Maintained Add-ons • Projects owned by the
foundation
• Extend or work with CF Core
• Must meet qualifications for
relevant CF Extension
certification
Certified CF Extensions • Projects and products external to
the foundation
• Are certified by the foundation as
interoperable with CF Core
Extended Ecosystem • Projects and products external to
the foundation
• Not certified
Certifications, Assertions and Ecosystem
BOSH, while not in CF Core, remains
critical to our ecosystem development
efforts and represents several
opportunities for certification programs.
CF
Core
Buildpacks
CLI Plugins
Logging, Usage
Metrics, Billing
BOSH CPIs
Services (non-BOSH)
Services (BOSH-enabled)
BOSH Packaged Software
Architectural Opportunities for Extension
Roadmap
Goals:
• Improve maintainability and extensibility of the runtime layer
• Support Buildpacks + Containers as artifacts
Current Status:
• Running as “Beta” in several service provider environments
• Project team focusing on scaling, hardening and operability
• Expect to see commercial vendors productizing Diego within Q3
Elastic Runtime Re-write – A.K.A. “Diego”
Goals:
• Provide support for .NET running on Windows
• Closely align project to MS Roadmap around containers
Current Status:
• Engineers from Pivotal, HP, and Century Link working together
on the project
• Coordinating with MS around the next release of Windows with
runC support
Greenhouse – Equal Opportunity for .NET
Feature
HTTP Route Services Supports use cases like authorization, auditing, caching, rate limiting,
metering
Platform support for TCP Routing Platform supports for apps and other components receiving TCP
connections
Routing API System components may use an HTTP API to register http and tcp routes
rather than NATS
Securely run Docker Images in multi-tenant envs Requires things like User Namespaces, Dropping Linux capabilities, etc
App Process Types Enables running mulitple app processes from the same codebase
Asynchronous and temporary app processes Enable short-run tasks like batch jobs by exposing Diego Tasks as CF
Application process
Multiple ports per application Apps can have multiple routes on multiple ports
SSH into applications SSH into applications goverened by policy, automated auditing, etc
Lattice able to produce droplets App code can be staged in lattice like in CF to produce a droplet artifact,
which could be promoted to CF
UAA has multi-tenancy with zones Enables multiple user populations - employees, customers partners, etc
System components may use loggregator for metrics Rather than expose /varz, system components may use loggregator, which
is adding a growing number of metrics formats.
What’s Next in the Runtime Layer
Feature
Improve Runtime system components security TLS for all components, rotating certificates
Runtime supports fine grained roles and permissions Enable more flexible role customization compared with pre-canned roles and
permissions
Runtime supports extensible tags or labels Use cases like cost centers, identifying objects with relationships across org/space or
object types
Extensible App Staging Gates Supports use cases like virus and vulnerability scanning, OSS license scanning and
reporting, auditing as mandated by administrators to apps uploaded to the platform
Isolation Groups (formerly placement pools) Enables dedicated VM infrastructure per tenant for app containers and supporting
components
App Containers may use custom CA’s Enable custom CAs to be registered inside the app container, may also support
/etc/resolv.conf extensions
And then
Support for persistence
Container-Container networking
Longer term…
Feature
Compiled Releases Ship releases that contain jobs and compiled packages for a specific stemcell version
https://github.com/cloudfoundry/bosh-notes/blob/master/compiled-releases.md
UAA support in BOSH Director BOSH users can be connected to an identity provider
Pre-start release job scripts Ability to run scripts prior to job deployment, support for migrations
Dynamic Provisioning
Job linking: https://github.com/cloudfoundry/bosh-notes/blob/master/links.md
First class AZs: https://github.com/cloudfoundry/bosh-notes/blob/master/availability-
zones.md
BOSH Roadmap
Feature
Notifications API v2 Updated to the API to support batch sending, test sends, and other features
User Managed Service Brokers (Private Brokers) Enables service broker developers to self-service without admin permissions to develop
and test services for just their own Org/Space
SSO for service dashboards per instance Support for automated generation of OAuth2 clients for service dashboards per service
instance.
Notifications CLI Tool CLI interface to the notifications service to make it easier to operate
Echo Brokers
Replaces user-provided service instances to support user management of all
marketplace metadata for a service which echos back any configuration provided on
create, when bound to an application
Parameter Prompts Brokers can provide fields which CF clients should prompt users for, in order to
construct arbitrary parameters for the request.
Services Roadmap
Project Structure Runtime
PMC
MEGA
CCAPI
LAMB
Identity
Router
Diego*
Garden*
Greenhouse*
Lattice*
BOSH PMC
BOSH Core
BOSH CPIs
Services PMC
Core Services
Notification Service
Abacus*
Brooklyn Service Broker*
MS SQL Server*
Utilities PMC
CLI
CI / Tools
Eclipse Plugin*
Java Tools
Visual Studio Plugin*
Buildpacks PMC
CF Buildpacks
Java Buildpack
Security and
Compliance
Thanks
Christopher Ferris| @christo4ferris
CTO Open Technology | IBM Cloud
Dieu Cao| @dieuthicao
Cloud Foundry Runtime PMC Lead | Pivotal
Chip Childers | @chipchilders
VP Technology | Cloud Foundry Foundation
top related