Cloud-Native Applications. Copyright 2017 Pivotal Software, Inc. All rights Reserved. Version 1.0

Transcription

1 Cloud-Native Applications Copyright 2017 Pivotal Software, Inc. All rights Reserved. Version 1.0

2 Cloud-Native Characteristics Lean Form a hypothesis, build just enough to validate or disprove it. Learn from your results. Domain-Driven Collaborate with domain experts to understand the problem domain and model it in your software. Anti-Fragile Your system should get stronger in the face of failure. Inject failure into your environment to improve it. Distributed Leverages multiple independent collaborating components communicating over a network. Continuous Builds, test, and package your software continuously. Always have a shippable release available. Self-Service Enable developers to requests and provision infrastructure services automatically.

3 Cloud-Native Workloads Batches CONTAINERS EVENT-DRIVEN FUNCTIONS MICROSERVICES DATA SERVICES MONOLITHIC APPLICATIONS

4 Cloud Native Workload Abstractions Container Orchestrator Application Platform Serverless Runtime Container Application Function Services that require explicit control over their operating environment Long running processes with relatively standardized loads. Short running processes that have unpredictable workloads. GUIDELINES GUIDELINES GUIDELINES Internally managed persistence Custom networking needs Assumptions about file system Commercial packages Interactive applications Long running event flows s Extensive batch tasks Lightweight event responses Services with sporadic demand Simple scheduled/batch tasks

5 Described in a classic manifesto by Heroku 12 Factor Applications Outlines architectural principles and patterns for modern apps Clean contract between applications and the platform they run on Focus on scalability, continuous delivery, portability and cloud readiness Most of these principles are built in to the Cloud Foundry platform...

6 The 12 Factors Codebase Dependency Management Configuration Backing Services One codebase tracked in revision control, many deploys. Explicitly declare and isolate dependencies Store config in the environment. Treat backing services as attached resources. Build, Release, Run Processes Port Binding Concurrency Strictly separate build and run stages. Execute the app as one or more stateless processes. Export services via port binding. Scale out via the process model. Disposability Dev/Prod Parity Logs Admin Processes Maximize robustness with fast startup and graceful shutdown. Keep development, staging, and production as similar as possible. Treat logs as event streams. Run admin/management tasks as one-off processes.

7 I. Codebase An application has a single codebase Multiple codebases = distributed system (not an app) Tracked in version control Git, Subversion, Mercurial, etc. Multiple deployments Development, testing, staging, production, etc. Don't hardcode anything that varies with deployment image from

8 II. Dependencies Explicitly declare and isolate dependencies Dependencies declared in a manifest Maven POM, Gemfile, etc. Use a dependency isolation tool (e.g. bundle exec) to ensure that dependencies don t leak in from the system The dependency management approach is applied uniformly to development and production Results in running the application after a deterministic build command

9 III. Configuration Store config in the environment Anything that varies by deployment should not be included in the code Additionally consider separating config (e.g. database URL or feature flag) from credentials Environment variables or configuration server recommended

10 IV. Backing Services Treat backing services as attached resources Service are consumed by the application Database, message queues, SMTP servers May be locally managed or third-party managed Connected to via URL / configuration Swappable (change MySQL to an in-memory database) The app and backing services are loosely coupled

11 V. Build, Release, Run Strictly separate build and run stages Build stage: converts codebase into build (version) Including managed dependencies Release stage: build + config = release Run: Runs app in execution environment In Cloud Foundry, these stages are clearly separated with cf push Developer executes a build Staging combines the build and config to create a droplet Droplets are copied to a container and run

12 VI. Processes Execute app as stateless processes Stateless Processes should not store internal state Any necessary state is externalized as a backing service Share nothing Data needing to be shared should be persisted Sticky sessions violate 12-factor methodology Consider using Gemfire cache or Redis key-value store Use local memory or the local filesystem only as a single transaction scratchpad Use storage as a service if needed (Amazon S3, MongoDB)

13 VII. Port Binding Export that app s services via port binding Apps are exposed via port binding (including HTTP) Every app instance is accessed via a URI and port number One app can become another app's service

14 VIII. Concurrency Achieve concurrency by scaling out horizontally Scale by adding more app instances Individual processes are free to multithread

15 IX. Disposability Maximize robustness with fast startup and graceful shutdown Processes should be disposable Remember, they're stateless! Should be quick to start Enhances scalability and fault tolerance Apps in containers start very quickly Should exit gracefully / finish current requests Apps should be architected to handle unexpected terminations

16 X. Development/Production Parity Keep development, staging and production as similar as possible This enables high quality, continuous delivery Use common tools and a clear separation of concerns Application vs. operating environment/platform Dependency management Build, compile, release Code, configuration, credentials Use the same services in development and production Minimize surprises in production

17 XI. Logs App logs are streams of aggregated, time-ordered events Apps are not concerned with log management Just write to stdout or stderr Do not write to logfiles Separate log managers handle management, debugging, analytics, monitoring, etc. Papertrail, Splunk

18 XII. Admin Processes Admin processes / management tasks run as one-off processes Applies to developer admin or maintenance tasks like database migrations, clean up scripts, etc. Run admin processes on the platform Leverages platform knowledge and benefits Use the same environment, tools, language as application processes Admin code ships with the application code to avoid synchronization issues

19 The 12 Factors Codebase Dependency Management Configuration Backing Services One codebase tracked in revision control, many deploys. Explicitly declare and isolate dependencies Store config in the environment. Treat backing services as attached resources. Build, Release, Run Processes Port Binding Concurrency Strictly separate build and run stages. Execute the app as one or more stateless processes. Export services via port binding. Scale out via the process model. Disposability Dev/Prod Parity Logs Admin Processes Maximize robustness with fast startup and graceful shutdown. Keep development, staging, and production as similar as possible. Treat logs as event streams. Run admin/management tasks as one-off processes.

20 Beyond the 12 Factors The original 12 factors helped define the discipline of developing Cloud Native applications Technology and our understanding has evolved since the 12 factors were published The priority and value of each factor have changed as we ve learned more Three new factors round our the original twelve API First Define your API before building your user interfaces. Telemetry Capture data to properly assess performance and usage. Authentication & Authorization Build security in to every component of your application.

21 s From

22 Business Characteristics B Built by small, independent, and crossfunctional teams A C Publish-Subscribe (Pub-Sub) Queue First-in First-out (FIFO) Queue E F D Designed and implemented for a single business domain H G

23 Technical Characteristics B A Publish-Subscribe (Pub-Sub) Queue Multiple messaging paradigms C First-in First-out (FIFO) Queue Independent state Explicitly defined contracts E F D No deployment dependencies Independently scalable H G

24 Should that be a? Change Do parts of your system need to evolve at different speeds or in different directions? Life Cycle Does a part of your system need to have an independent flow from commit to production? Scalability Different load or throughput characteristics may have different scaling requirements. Failure Are there types of component or dependency failures that you want to protect the rest of the system from? Dependencies Are there external dependencies that change frequently that you want to isolate your system from? Technology Stacks Are there elements of your solution that are best provided by different technology stacks?

25 Cloud Native Applications Pivotal