Cloud-native Application Lifecycle Management
•Download as PPTX, PDF•
0 likes•641 views
Software development is changing rapidly. Enterprises that want to capture value faster, have to deliver value faster. The way to do that is by delivering software in production fast. Think multiple x a day. How do you transform to a digital enterprise that enables that?
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cloud-native Application Lifecycle Management
Similar to Cloud-native Application Lifecycle Management (20)
Recently uploaded
Recently uploaded (20)
Cloud-native Application Lifecycle Management
- 1. Cloud-native ALM What every business should plan for June 7, 2016 Neil Gehani, Sr. Product Manager, @GehaniNeil
- 2. Forward-looking statements This is a rolling (up to three year) roadmap and is subject to change without notice. This document contains forward looking statements regarding future operations, product development, product capabilities and availability dates. This information is subject to substantial uncertainties and is subject to change at any time without prior notification. Statements contained in this document concerning these matters only reflect Hewlett Packard Enterprise's predictions and / or expectations as of the date of this document and actual results and future plans of Hewlett Packard Enterprise may differ significantly as a result of, among other things, changes in product strategy resulting from technological, internal corporate, market and other changes. This is not a commitment to deliver any material, code or functionality and should not be relied upon in making purchasing decisions.
- 3. Hewlett Packard Enterprise confidential information This is a rolling (up to three year) roadmap and is subject to change without notice. This Roadmap contains Hewlett Packard Enterprise Confidential Information. If you have a valid Confidential Disclosure Agreement with Hewlett Packard Enterprise, disclosure of the Roadmap is subject to that CDA. If not, it is subject to the following terms: for a period of three years after the date of disclosure, you may use the Roadmap solely for the purpose of evaluating purchase decisions from HP and use a reasonable standard of care to prevent disclosures. You will not disclose the contents of the Roadmap to any third party unless it becomes publically known, rightfully received by you from a third party without duty of confidentiality, or disclosed with Hewlett Packard Enterprise’s prior written approval.
- 4. Applications are changing – accelerate to a digital enterprise 4 Courtesy of
- 5. Why accelerate? – Time-to-market driving transformations – Speed - Deliver business value faster – Competitive survival 5
- 6. Feel the need for speed
- 7. Cloud-native Taxonomy – Applications are “services” = business value – Cloud-native is a design pattern – Microservices is an architecture – Containers are portable. “If it works on my machine, it will run in production” is real – Platform to deploy “services” (PaaS) – Infrastructure to run “services (IaaS) – DevOps is a practice 7
- 8. Balancing Time Value of Money – Time value of delivery – Time value of shipping 8 Source: Brandon Chu - Time Value of Shipping
- 9. Microservices - Reducing cycle time minimizes risk, improves quality, speed 9 VS. Faster release cycle Less code to validate Easier to schedule Longer test cycles Less predictability Unable to adapt to change
- 10. Trends enabling cloud-native 10 In the past year alone, the project has experienced a 183% increase in contributors, 515% growth in projects on GitHub, and an astounding 18,082% spike in container downloads. - June 2015 DockerCon
- 11. Cloud applications From cloud deployed to cloud-native Automation Meeting economy, scaling, resiliency and velocity requirements requires standardization and automation Cloud Deployed Cloud Aware Cloud Native
- 12. Modern Application Requirements © Copyright 2015 Hewlett Packard Enterprise Development LP. 2015 Restricted .The information contained herein is subject to change without notice. Economy Scale VelocityResiliency Value
- 13. Modern Teams - Personas and roles 13 Persona Responsibilities and roles Collaborate in realtime through “chatops” integrations. “Bots” are members of the team Product Manager Define, prioritize, measure Create and track KPIs with analytics data coming back from releases Define and execute A/B tests and automatically roll back failed experiments Control feature toggles (mobile-enabled) and measure impact Define problems, not features; write stories Test Engineeris (SEiT, QE) Risk mitigation in production (data-driven) driven) Simulate failure to test application resiliency and degradation behavior Identify code coverage issues based on production analytics Create scaling simulation tests and store test assets with code Chaos testing 24x7x365 Test configuration as code, automatically triggered of any CI/CI pipeline Development Build, test, deploy Track user story connection to commit, build, test and deployment artifacts Identify vulnerable code inline and at each commit Trigger automatic testing at any point in the build to deploy cycle and in production Trigger automatic provisioning and teardown of environments (PaaS enables) Operations (SRE) Scalable infrastructure for automated provisioning, deploys + capacity utilization utilization and planning Blessing base containers; governance and security Build a resilient infrastructure for any developer to deploy Enable a pub/sub infrastructure for data collection Provide a standardized infrastructure for audit and compliance logs from chatops (SoT)
- 14. How software will be consumed – Base blocks – “Extension” blocks – Disposable Blocks Buy the blocks and assemble yourself.
- 15. How software will be buit – On-demand – Customized solutions – REST API – Web Hooks Microservices – Assemble as needed to add more value to create your own solution Scratch Programming Language: MIT
- 16. Business process Teams should be built around business value 16 Microservices Business activity Conway's Law Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations
- 17. This is a bad idea Microservice A Microservice B API team Business logic team Data team Microservice C
- 18. Best practice Follow Conway’s Law Data team Business logic team API team Horizontal teams … Team A data Business logic API Microservice A Team B data Business logic API Microservice B Align teams to services
- 19. Path from monolith to microservices Separate application concerns
- 20. © Copyright 2015 Hewlett Packard Enterprise Development LP. 2015 Restricted .The information contained herein is subject to change without notice. Decoupling Monolith (legacy) to Microservice(s) Façade Service Monolith Adapter Service Translator Service Monolith Domain Microservices System Domain REST API REST API REST API
- 21. Microservices Evolution of decoupling 1990s and earlier Pre-SOA (monolithic) Tight coupling 2000s Traditional SOA Looser coupling 2010s Microservices Decoupled Future Serverless
- 22. The challenge New matrix from hell 22 Courtesy of
- 23. HPE Confidential Cloud-native Application Lifecycle Management Challenges –Plan (Track & Analyze) – For fast cycle times - deploys n x per day – 100’s of thousands of services being built, tested, deployed, and running –Build - automated – Programmatically trigger builds (containers) using any CI/CD – Multiple, flexible, parallel pipelines – Test - automated – Automated - 24x7x365 – Contract (e.g API testing) – Resiliency (e.g. chaos) – Behavior (e.g. costs - containers, instances, infrastructure) –Run – Automated deployment using Helion PaaS to any IaaS (AWS, Azure, vSphere, OpenStack)
- 24. Lifecycle Management Suite - The Revolutionary Evolution This is a rolling (up to 3 year) roadmap and is subject to change without notice Unified Lifecycle Suite Plan Build Test Run Analyze Unified Enterprise Platform Enterprise Agile to DevOps SCM CI Embedded or Connected Deploy Lifecycle Suite Predictive ALM Big ITM Data Reflect Predict Accelerat e Actionable Insights
- 25. “Speed wins in the marketplace” - Adrian Cockcroft, Netflix, Battery Ventures –Deliver value faster to –Capture value faster 25
- 26. Better together ADM + Helion Stackato
- 27. Application Lifecycle Management on multi-cloud platform Universal Control Plane Code Engine ConcourseCI vSphere Cloud Foundry Universal Service Broker Service catalog ADM Services AWSOpenStack Web console ALM Octane Predictive ALM Cloud-native ALM Application Lifecycle Management Helion Stackato (PaaS) Future Kubernetes ADM Microservices Docker Container Platform IaaS
- 28. Resources – 12-Factor Apps – Microservices – Martin Fowler – Testing Strategies in Microservices Architecture – ADM open source contributions for Cloud-native apps built as microservices packaged in cotnainers – “Pumba” - Chaos testing inspired by Netflix simian army - open sourced – Container integration testing framework –Published in docker’s weekly newsletter – Containerized Docker Bench security testing - open sourced – How to reach us – Neil Gehani (PM) - @GehaniNeil 28
Editor's Notes
- The rapid pace of change is giving way to new ways to deliver value. The old way of tightly coupled applications that required a large web app a larger web server and a large database are dissappearing rapidly. Smaller services are loosely couple with well defined API (contracts). The teams developing these new services can deliver value much faster. The need for having to pre-allocate large VM’s for a 1 day event no longer works. Notice the crash of Best buy and others on Black Friday. Accelerating to a digital enterprise requires companies to become software defined businesses. The disruptions are occurring in just about every industry Craigslist to newspaper classfieds Amazon to retail Uber/Lyft to transportation Paypal/Venmo/Betterment/Wealthfront to financial Metromile to Insurance …. If you are not building a software defined business, you are going to loose to one. – A CIO of an airline company said that they are a s/w company with wings.
- ““Open source software (OSS) is changing the face of the IT landscape. In fact, IDC analyst Al Hilwa went so far as to state that OSS is poised to “eat the world” in a recent article.” Software has become disposable. Is cheap - expensive to produce, Value delivered is measured in users and usage Revenue is value captured Is it better to deliver value 2x a year or every day? Do we want to deliver value 2x a year or 2x a day? It takes the same total development regardless of when you deliver. Delivering incremental value faster enables the capturing of value faster. Delivering code to production is different that releasing it to be consumed. Without shipping everyday, product and business owners don’t have the flexibiity to package up the value and make it capturable. In order for you to move, you have to make it real by
- Speed is the name of the game. To capture the revenue faster, business value must be delivered faster. Organizations have to feel the need for speed or get left behind by a whole bunch of tech startups. Software has a lower barrier to entry
- Cloud-native - Resilient, Cost efficient use of resources (auto-scales), Self-healing, Self-provisioning Microservices is an Architecture like Lego blocks Delivers speed, Disposable, Independent empowered teams, language agnostic, flexible talent Language agnostic – people bring their own stack Containers are Portable Software delivery package, runs anywhere, environment agnostic “If it works on my machine, it will run in production” is real Platform is the deployment and delivery vehicle for services (PaaS) Enables Developers to build, test, deploy a service - don’t care how IT maintains and manages the Platform - Infrastructure agnostic (multi-IaaS) Never a black friday moment, never have to plan and pre-allocate resources for a spike. IT capacity planning and resource availability and cost become more important to manage rather than apps DevOps is the how and that can change at any time. e.g there are no DevOps engineers at Google, LinkedIn, Facebook - They are called SRE or Site/Systems Reliability Engineers - DevOps engineers live in Operations DevOps is the practice of delivering value at speed US Depart of Labor - The top 5 jobs for the future are #1 Software Engineers and #5 Product Managers Why should we capture value faster?
- If software is value, then do we want to deliver value 2x a year or 2x a day? It takes the same total development regardless of when you ship. Delivering incremental value faster enables the capturing of value faster. Time Value of Money - A dollar now is worth more than a dollar later So, why is smaller better?
- How big should a microservice be? No bigger than my head or 1 screen – The single responsibility principle
- Cloud Deployed Legacy applications that are virtualized and deployed within a VM or physical server located in the cloud. The cloud is used as a fast provisioning mechanism for virtualized or physical environment. The application does not take advantage of any of the cloud specific features. Cloud Aware An application that is developed using SOA principles and that has the capability, depending on the cloud it is running on, to take advantage of cloud functionality such as load balancing, scale up/down. Application is aware of the environment in which it runs Assumes resiliency within the environment Application is stateful Cloud Native An application that is developed and deployed within an a PaaS environment and relies on that environment to manage its operations within the cloud it is running on. Separation of application from the data Application is state less and data can be state full Application configuration must reside in the environment Declare and isolation of dependencies that allows application to take advantage of Containers Assumes resiliency within the application (assumes resource can disappear at any time) Horizontal scaling - out vs up
- Applications must run economically No massive build out prior to launch – consume on demand instead Applications cannot be unavailable Must scale to demand Must degrade gracefully when infrastructure fails Ease of Feature creation and deployment is paramount Fast feature to market fit wins markets
- Software is built as microservices are like building a bunch of lego blcoks that easily connect to each other. If a block breaks or something new is desired, just replace the block with a new one in production. Because they are small, they are disposable for a new one.
- CS50 is becoming a go to class for computer science and business students as well. One of the best CS classes.
- Microservices architecture style benefits: Independent deployability Language Platform and Technology independence for different components Distinct axis of scalability Increased architectural flexibility - enables flexible slutions Commonly – Microservices are 100’s of lines but can be thousands – no hard and fast rule - http://bovon.org/archives/350 (a screenful or size of your head) Separation of concerns Single respnsibility principle ----- Meeting Notes (12/1/15 07:53) ----- talk about cost here. cost of testing = testing service + dependent services instead of full regression. cost of conways' law allows teams to stay small and focused
- New vs migrate vs extend
- New vs migrate vs extend
- A translator micro service – All it does is translate the communication of requests between legacy and modern REST API A Façade service(s) – Handles one business capability needed from the legacy – each functionality is a separate façade service in the legacy’s domain model The adapter service is requesting all the things that our new features need from the monolith but doing it via REST and also written in as a microservice in a modern tech stack (ie not in COBOL) – Then hands those requests to the translator which translates them to the Facades(s) in a protocol they understand.
- White mask the words.
- Talk about Chaos Monkey vs Functional test - randomly shuts off one of the systems. Create chaos to see how your application reacts. Janitor monkey monitors unused resources on AWS and cleans it up. Conformity monkey applies best practice rules to your cluster (security, etc) - open source used by Netflix - marks and notifies (uses email but Slack will be better) of non-confirming instances or auto scaling group.
- “Open source software (OSS) is changing the face of the IT landscape. In fact, IDC analyst Al Hilwa went so far as to state that OSS is poised to “eat the world” in a recent article.” Software us a declining asset if kept too long Is cheap - expensive to produce Value delivered is measured in users and usage Revenue is value captured If software is value, then do we want to deliver value 2x a year or 2x a day? It takes the same total development regardless of when you ship. Delivering incremental value faster enables the capturing of value faster.
- Regardless if it is built as micro services or in containers
- Working from the bottom: The Universal Control Plane provides lifecycle management for our platform components (code engine, cloud foundry, and our services ecosystem) The Platform services include the code engine (which enables the easy creation of CICD pipelines), our runtimes (CF, CaaS), and our service catalog and hosted services The Developer experience layer is meant to unify the management of applications running across multiple clusters across clouds