![• PaaS and IaaS is exceptionally
easy to provision
• Cloud offers a large elastic pool
of resources to pull from. Not
worth the time to fix
• If you automate your
environment setup, it’s quick to
deploy more hardware
• VMs should be ephemeral -
nothing worth saving
56
IF SOMETHING BREAKS, RE-DEPLOY IT ON NEW INFRASTRUCTURE
In each cluster’s [of 10,000 servers] first year, it’s
typical that 1,000 individual machine failures will
occur; thousands of hard drive failures will occur;
one power distribution unit will fail, bringing
down 500 to 1,000 machines for about 6 hours;
20 racks will fail, each time causing 40 to 80
machines to vanish from the network; 5 racks will
“go wonky,” with half their network packets
missing in action; and the cluster will have to be
rewired once, affecting 5 percent of the machines
at any given moment over a 2-day span, Dean
said. And there’s about a 50 percent chance that
the cluster will overheat, taking down most of
the servers in less than 5 minutes and taking 1 to
2 days to recover.
Jeff Dean, Fellow, Google](https://image.slidesharecdn.com/cloudnative-detailed-171112040910/85/Cloud-Native-In-Depth-56-320.jpg)
More Related Content
Similar to Cloud Native In-Depth
![Lect 1 Number systems and base conversions. [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/lect1numbersystemsandbaseconversions-260111134109-67c2d865-thumbnail.jpg?width=640&height=640&fit=bounds)
Cloud Native In-Depth
- 1. CLOUD NATIVE SHIFT INAPPLICATION DEVELOPMENT PARADIGM SIVA RAMA KRISHNA
- 2. @sivachunduru linkedin.com/in/chunduru slideshare.net/sivachunduru SIVA RAMA KRISHNA– SOLUTION SPECIALIST 2
- 3. WHAT & WHY? • History • Analyst perspective • Scope for community
- 4.
- 5. “Six decades intothe computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.” - Marc Andreessen Co-Founder, Andreessen Horowitz WHAT IS COMMON IN THEM ? SPEED OF BUSINESS INNOVATION, ENABLED BY SOFTWARE Uber was founded in 2009 and launched its service in 2010. Airbedandbreakfast.com (later to be renamed Airbnb) was founded in 2008, but only reached 1 million listings in 2014. Netflix — from a startup in 2011 - they took the discontinuous leap from technology provider and service to content creator in 2013. - HOMOGENIZED software limits innovation - CUSTOM software enables innovation & differentiation 5
- 6. IS THE TREATMENTOF AN ERP SYSTEM AND A WEBSITE SAME ? PACE LAYERED ARCHITECTURE Growth Release Cycles Fail Points Development Methodologies Execution Affinity Center of Gravity 6
- 7. NEW AD PROJECTSWITH IN IT ORGANIZATIONS ANALYST PERSPECTIVE 1 Focus on functional and non-functional requirements to drive what “cloudiness” characteristics are needed to deliver 2 Choose both an application architecture and runtime environment that supports the application’s requisite “cloudiness‟ characteristics. 3 The burden of responsibility required to meet these “cloudiness” characteristics within application code versus the system infrastructure. 4 Real world limitations in developer resources, skills, time, etc. may force you to reconsider either the choice of deployment platform OR the degree of “cloudiness” present in the application 5 Rinse and repeat until you find the solution that best balances “cloudiness” with both development and runtime constraints. STEPS TO BUILD A CLOUD APPLICATION 75% 7
- 8. WE MUST RE-INVENT OUR PROFESSION Thenonly we can do better Cloud Native is difficult But not doing it is worse The gist is that applications should be, - built in the cloud - for the cloud - maximizing the benefits of the cloud 8
- 9. VOICE OF THEVENDORS 9
- 10. 10 VALUE OF CLOUDNATIVE Quickly Capitalize on Business OpportunitiesSpeed Quickly move changes to production Survive failures. Highly available in production Resiliency Change your practices as needed Agility
- 11. Application Architectures MicroServices DevOps * asa Service Distributed Computing TOPICS TO LEARN 11
- 12. TOPICS TO LEARN ApplicationArchitectures MicroServices DevOps * as a Service Distributed Computing • Deployment Target Types • Development Methodology • Legacy Architectures • Service Based Architectures 12
- 13. — Brian Foote andJoseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs, Monticello, Illinois, September 1997 A big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer turnover and code entropy. BIG BALL OF MUD – AN ANTI-PATTERN 13
- 14. QUARRY THE DEPLOYMENTTARGET TYPES Virtual Machine Compute with Operating System, Networking and attached Storage Container An Operating System level virtualization method Application Platform as a Service (aPaaS) Application deployment in Containers Functions (Serverless) …code execution model in which cloud provider fully manages starting and stopping of the function’s container platform as a service as necessary to serve requests 14
- 15. QUARRY THE DEPLOYMENTTARGET TYPES - EXAMPLE Virtual Machine AWS Azure Oracle Cloud IBM …. Container Docker, Rocket, RunC, LXC, …. Application Platform as a Service (aPaaS) Heroku, Bluemix, Oracle Application Container Functions (Serverless) Amazon Lambda Bluemix OpenWhisk Microsoft Functions Oracle Functions …. 15
- 16.
- 17. THE 12 FACTORS I.Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing Services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port Binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep dev, staging and prod as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes 17
- 18. LEGACY ARCHITECTURES 18 Source: SoftwareArchitecture Patterns by Mark Richards Layered Architecture Event Driven Architecture Micro Kernel Architecture Analysis Agility Deployment Testability Performance Scalability Development 12-Factor Code Runtime Admin Layered Event Driven Microkernel
- 19. MICROSERVICES ARCHITECTURE –HELPS IN SEPARATELY DEPLOYED UNITS 19 Source: Software Architecture Patterns by Mark Richards Analysis Agility Deployment Testability Performance Scalability Development 12-Factor Code Runtime Admin MicroServices
- 20. CLOUD ARCHITECTURE –HELPS IN SCALABILITY AND CONCURRENCY 20 Source: Software Architecture Patterns by Mark Richards Analysis Agility Deployment Testability Performance Scalability Development 12-Factor Code Runtime Admin Cloud Based
- 21. ARCHITECTURES - ANALYSIS 21 Source:Software Architecture Patterns by Mark Richards
- 22. SERVICE BASED ARCHITECTURE– SOI (SERVICE ORIENTED INTEGRATION) Consumer Consumer Consumer Intermediary Application Function API exposed by Application Published Service Interface • Expose Application Functionality as Service • Application - Hosted by SaaS providers - Hosted by PaaS providers - Hosted by IaaS providers • Intermediary - Mediation, routing - Security enforcements - Smart endpoints, Dumb pipes • Integrate with in the DC / Across the DCs • Use APIs to integrate both Enterprise / Mobile Apps 12-F Treatment for Source Code Runtime Environment Administration SOI 22
- 23. SERVICE BASED ARCHITECTURE– SOA (SERVICE ORIENTED ARCHITECTURE) Application Consumer Consumer Consumer Intermediary Service API exposed by Service Published Service Interface • Service orientation to the architecture of the application • Application - Functions as services - Service code is built as separate, independent entity - Services are logically separated - Service identification basis of reuse potential - To enable reuse, service contract is must additional to interface specification - Services can be deployed with application or independently • Addresses Agility and Scalability 12-F Treatment for Source Code Runtime Environment Administration SOA 23
- 24. SERVICE BASED ARCHITECTURE- MICROSERVICES Consumer Service Discovery Service Service Service API access can be direct or mediated Discovery Query Service self-registration 12-F Treatment for Source Code Runtime Environment Administration MicroServices • Designed for maximum agility • Size of the service is limited • Unit of deployment to 1 service • Each service is autonomous • Between services - - Eliminates dependencies - No synchronous interactions • Not focused on enterprise level reuse • Addresses the Agility, Rapid deployment and Scalability 24
- 25. OTHER PATTERNS YOUHEAR IN THE FIELD • Externalization Patterns Externalized Configuration Pattern Externalized State Pattern Externalized Channels Pattern • Runtime Patterns Runtime Reconfiguration Pattern Concurrent Execution Pattern Brick Telemetry Pattern 25 • Integration Patterns Event Driven System Pattern Contract Management Pattern Integration Telemetry Pattern • Distributed System Patterns Service Discovery Pattern Edge Gateway Pattern Fault Tolerance Pattern
- 26. Application Architectures MicroServices DevOps * asa Service Distributed Computing • Minimal Function • Service Discovery • API-first • Polyglot • Choreography • Loose Coupling TOPICS TO LEARN 26
- 27. “Erik Doernenburg firstshared with me the idea that we should think of our role more as town planners than architects for the built environment” - Sam Newman 27
- 28. MICROSERVICES Break up yourapplication into many small pieces to get features to market quickly. Each MicroService Characteristics – Small & Independently deployable De-coupled Has its own team to design, develop, deploy and maintain Exposes an API Has its own databases 28
- 29. A SIMPLE RUBRIC– MINIMUM VIABLE PLATFORM • Optimize SDLC and Delivery Pipeline with tenets of Cloud Native operability • It requires Operationally mature platform • Minimum capabilities of MVP • Dynamic DNS, routing and load balancing • Automated service discovery and brokering • Infrastructure automation • Health Management, monitoring and recovery • Immutable artifact repository • Log aggregation 29
- 30. • Perform asingle function • should do a small set of things (ideally one thing) really well • Exposed thru a simple API • modern cloud-native microservices tend to favor protocols like REST • reject protocols that are heavily dependent on specific programming ecosystems • Upgraded and evolved independently • is independent and decoupled from the clients that use it • fix or evolve it without rewriting or stopping the applications that use it • Architected for fault-tolerance • failure of a single microservice can result in the failures of multiple different applications • Accessed over the network • are designed to run in the cloud and be accessed over the network from other peers and applications • Perform a single function • the DNS does a single thing: map human readable names into IP addresses • Exposed thru a simple API • DNS is typically accessed by clients using a simple UDP- based request-response protocol • Upgraded and evolved independently • DNS names are hierarchical and are administered at different levels • Architected for fault-tolerance • DNS servers are typically deployed in at least pairs and often in triplicate • Accessed over the network • DNS is certainly made to by accessed over the network, with its popular UDP-based protocol MICROSERVICES – PROPERTIES & DNS USE CASE 30
- 31. 31 X-axis scaling • consistsof running multiple copies of an application behind a load balancer. Y-axis scaling • splits the application into multiple, different services. Z-axis scaling • Each server run identical copy of code. • Each server responsible for subset of data. THE ART OF SCALABILITY – ACOLYTE SYSTEM y-axis Functionaldecomposition
- 32. 32 DEVELOPERS WANT POLYGLOTSUPPORT • Different languages for different specialized microservices • Remember – the goal of cloud native is time to market. It is NOT about long-term maintainability • If maintenance becomes an issue, rewrite the microservice over a weekend Use the language that works best API Application Data Store Infrastructure Inventory Microservice Chat Microservice Product Recommendation Microservice API Application Data Store Infrastructure API Application Data Store Infrastructure
- 33. EACH MICROSERVICE USEITS OWN DATABASE 33RDBMS is great but not necessary for all use cases Relational Database ACID-compliant, suitable for a wide range of workloads. Trusted, reliable, wide client support, easy to use Object GridsNoSQL Store objects in and move business logic into the server- side grid. Non-relational organization of data, including key/value, graph, document, tabular, etc. Always BASE and sometimes ACID compliant
- 34. 34 REMEMBER THAT LATENCYIS EVERYWHERE Asynchronously make calls to all remote systems High latency within a single cloud. Can no longer assume 2ms between application and data tiers Application is now comprised of many different microservices, each with its own data store/database Application is now deployed to multiple data centers, in multiple availability zones, in multiple regions
- 35. SYNCHRONOUS CALLS WITHMICROSERVICES ARE VERY BAD 35 Product Catalog Product Pricing Inventory Chaining == coupling == downtime The availability of microservice A depends on B, B depends on C, etc
- 36. 36 AVOID SYNCHRONOUS CALLSFOR READ-ONLY DATA BY COPYING Product Pricing Inventory Promotions Product Pricing Inventory Promotions Product Pricing Inventory Promotions Product Catalog • Synchronous in-memory calls • Data is 100% consistent • No data is duplicated Request for Category Page Product Catalog Product Pricing Inventory Promotions • Synchronous calls to product catalog microservice • Product, pricing, inventory and promotions microservices are systems of record; they publish asynchronously to Product Catalog microservice when updated • Product Catalog microservice is not always consistent • Data is duplicated – two or more microservices may contain the same data Traditional Monoliths New Microservices
- 37. CIRCUIT BREAKERS PREVENTCASCADING FAILURES • Rule #1 of microservices – avoid coupling! • Synchronous = two systems are coupled • Asynchronous = no coupling • Cascading failures happen when request-handling threads are waiting on a response from a remote system • Circuit breakers make synchronous calls from another thread pool to avoid binding up request-handling threads • Hystrix (Java-based) is well-known and solves this problem 37Cascading failures are more common with microservices
- 38. USE A HIGHERLEVEL OF REST 38REST is the currency of cloud native • Level 1 – Start requesting individual resources – Interact with /OrderService/12345 • Level 2 – Start using HTTP verbs - HTTP GET/POST/PUT/DELETE/etc – Responses come back using correct HTTP codes – e.g. HTTP 409 for a conflict • Level 3 – Application itself tells client how to interact with it - similar to hyperlinks in a web page – <link rel = "delete" uri = "/OrderService/12345/delete"/> under <order id="12345"> Richardson Maturity Model • Level 0 • Use HTTP as a tunneling mechanism only • Interact with /OrderService • Use HTTP GET/POST only
- 39. 39 EMIT LOGS ASEVENT STREAMS Can’t do anything with log files sitting on a container’s local storage volume Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Container Instance of Application Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Container Instance of Application Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Log Entry Container Instance of Application Capture, Aggregate, Search, Troubleshoot, etc
- 40. Orchestration • Top-down coordinationof discrete actions • Used in centralized, monolithic applications • Brittle – centralized by nature • Each “action” registers with centralized system – single point of failure that is not very flexible Choreography • Bottom-up coordination of discrete actions • Used in distributed, microservice applications • Resilient – distributed by nature • Each microservice asynchronously throws up a message that other microservices can consume 40 CHOREOGRAPHY OVER ORCHESTRATION BETWEEN MICROSERVICES
- 41. 41 EXAMPLE OF CHOREOGRAPHY Scenario:eCommerce user returns a widget through web-facing .com Centralized Workflow Self Service Help Initiate Return Workflow Increment Inventory Done Inventory Record Refund Done Customer Profile Done Payment Refund Money Brittle | Centralized | Tightly Coupled
- 42. 42 EXAMPLE OF CHOREOGRAPHY Scenario:Inventory microservice Inventory Microservice All asynchronous Event Bus New Inventory Events This Microservice Cares About Events This Microservice Emits Product Returned Product Sold Product Recalled Inventory Incremented Inventory Created Inventory Decremented Inventory Deleted For Anyone Who Cares...
- 43. 43 ADOPT AN APIGATEWAY API gateways provide a "backend for each frontend" • Builds a XML or JSON response for each type of client – web, mobile, etc • Asynchronously calls each of the N microservices required to build a response • Handles security and hides back-end • Load balances • Applies limited business logic • Meters APIs • Logs centrally Client Public Internet Microservice Microservice Microservice Microservice Microservice Microservice Data Center API Gateway Microservice Microservice Microservice
- 44. Application Architectures MicroServices DevOps * asa Service Distributed Computing TOPICS TO LEARN •Automated Provisioning •Automated Setup •Continuous Integration •Continuous Delivery •Automated Testing •Agile •Culture Change 44
- 45. 45 The nicest thingabout Teamwork is that You always have others on your side.
- 46. GARTNER DEVOPS MODEL- CATALOG OF DEVOPS PRACTICES 46 People Process Culture Technical Debt Test-driven Development Test-Driven Deployment Test Everything Instrument Everything Trust Culture Engineering Culture Collective Ownership Autonomous Teams Joint Meetings Learning Culture Job RotationFull-Stack Teams Minimum Viable Process Common Metrics Feature Flags Optimize Flow Chaos Monkey Value Streams Collaborative Culture Never Done Small Batches Automated Testing Minimum Viable Product Release Automation Automated Builds Canary Rollouts Fail Forward Version Everything Servant Leadership Site Reliability Engineers Platform Engineers Technology Continuous Monitoring Integrated Tool Chains Monitor Everything Infrastructure as Code Developer Self- Service Continuous Testing Continuous Integration ChatOpsOne-Step Build, Test, Deploy Continuous Delivery Feature Teams Starting point of DevOps could be from any of the categories: People, Process, Culture or Technology.
- 47. TAKE THE BARRICADESOUT TO KICK START THE DISCUSSION • Code Quality • MTBF • MTTR • Bug Escape Distance • Code Complexity • Impacts the speed • Unit Test Coverage • Lower values turns to risk • Commit Rates • Longer the rates, more code to be merged – can cause problems, delays, bugs 47 • Environment Stability • Continuous Automated Tests • Combine Tests & System Monitoring • Real time Application Monitoring • Faster Platform Upgradation • Business Metrics • # of deployments • Time to production • # of release candidates built • Software stack under CD pipeline Engineering Operations
- 48. 48 3 WAYS –THE PRINCIPLES BENEATH DEVOPS http://itrevolution.com/the-three-ways-principles-underpinning-devops/ Standardized Environments Automated Provisioning Continuous Integration Continuous Delivery Developer Self Service Rapid Prototyping Learn from failures Amplify +ve feedback
- 49. Plan Code Build Test Package Release Deploy Monitor DEVOPS PIPELINE Pattern Description PlanAgile Project Management Code Team Infrastructure (Code, Review, Merging, Version Control, Documentation etc.) Build Continuous Integration Test Continuous Testing Package Artifact repository Release Change Management, Release automation Deploy Deployment plans, Infra provisioning, Infra configuration & management Monitor Application performance monitoring, End user experience 49
- 50. Plan Code Build Test Package Release Deploy Monitor HARNESS THE DELIVERYPROCESS Plan Code Build Test Package Release Deploy Monitor Agile Continuous Integration Plan Code Build Test Package Release Deploy Monitor Continuous Delivery If Agile software development was the opening act to a great performance, continuous delivery is the headliner. - Kurt Bittner, Principle Analyst 50
- 51. DEVOPS PATTERNS ANDTOOLSET AVAILABLE IN MARKET 51 A shared version control system that contains system provisioning scripts as well as application code. One tool to manage both application configuration and infrastructure configuration. Common methods and tools for building, testing and quality assurance. Dev Ops Both Coding & Platform for Application Both System & Application on Platform Source Code Management Continuous Integration/ Deployment Configuration Management Software defined Infrastructure Monitoring
- 52. 52 INFRASTRUCTURE AS CODE Manageit as you would do any other source code Base Image Install Binaries Configure Software Make Software Work Together Patch/Push Config Changes Step 1 Pick a Tool Step 2 Script your environment Step 3 Run your scripts against all hosts
- 53. • Single systemfor code and build artifacts • Every time someone commits a change, consider triggering a build + automatic verification tests • Always ship trunk! • Enable features through flags 53 SHARED VERSION CONTROL
- 54. •Manual one button build/deploy •Scheduledbuilds - every day, every week, etc •Builds triggered by code checkins •If post-build validation fails, report it 54 ONE STEP BUILD/DEPLOY
- 55. 55 EXAMPLE OF AUTOMATEDTESTING USING ROBOT 1. Integrate Robot With Maven 2. Write a Simple Selenium-based Test 4. View Results3. Run Test
- 56. • PaaS andIaaS is exceptionally easy to provision • Cloud offers a large elastic pool of resources to pull from. Not worth the time to fix • If you automate your environment setup, it’s quick to deploy more hardware • VMs should be ephemeral - nothing worth saving 56 IF SOMETHING BREAKS, RE-DEPLOY IT ON NEW INFRASTRUCTURE In each cluster’s [of 10,000 servers] first year, it’s typical that 1,000 individual machine failures will occur; thousands of hard drive failures will occur; one power distribution unit will fail, bringing down 500 to 1,000 machines for about 6 hours; 20 racks will fail, each time causing 40 to 80 machines to vanish from the network; 5 racks will “go wonky,” with half their network packets missing in action; and the cluster will have to be rewired once, affecting 5 percent of the machines at any given moment over a 2-day span, Dean said. And there’s about a 50 percent chance that the cluster will overheat, taking down most of the servers in less than 5 minutes and taking 1 to 2 days to recover. Jeff Dean, Fellow, Google
- 57. Application Architectures MicroServices DevOps * asa Service Distributed Computing TOPICS TO LEARN •Consume IaaS and PaaS •Fault Tolerant by Definition •Auto-scaling •Infinite Elasticity 57
- 58.
- 59. * AS ASERVICE Requires fundamental shift in how applications are built 59 Your Code Highly innovative, differentiated, etc Configuration Caching Load Balancing Eventing Logging Monitoring Database NoSQLState Messaging Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Where you’re not differentiating, consume building blocks from 3rd party cloud vendor
- 60. EVERYTHING IS NOWSOFTWARE 60 Person p = new Person(); $ docker run -v /host:/container example/myapp curl -X POST "name=MyFirstApp" "runtime=java” "archiveURL=/binaries/myapp.zip" $ puppet module install puppetlabs-java Today, Everything is 100% Code. Automation at scale is standard Provision a new server just like you would provision a new object in Java
- 61. CONTAINERS Is it compulsionto be part of? 61
- 62. 62 DISPOSABILITY RULES OF12-FACTOR APP Start with one script – no manual intervention. This script will be called when container is provisioned Start up quickly – try for under 10 seconds. If it takes minutes, auto-scaling won’t work properly Shut down cleanly without warning. Containers will be killed with no warning whatsoever
- 63. CLOUD NATIVE VS CONTAINER NATIVE •Create highly differentiated apps & services Faster With high quality Geo reach Compelling CX
- 64. SOFTWARE LANDSCAPE INCONTAINER ARCHITECTURE •Container strategies are critical to digital business •Container based application platforms are key to container strategies •Container software vendor landscape is diversified and growing fast Source: Forrester - Master The Cloud-Native Solution Ecosystem Of Container Software 64
- 65. • #1 value– app packaging • MicroServices doesn't rely on containers but they do help: • Higher density • Easy to start/stop • Portability • Containers are lightweight, just like MicroServices themselves • Containers can run in VMs too 65 Helpful to MicroServices but not a requirement Hardware Hypervisor VM 1 OS App VM 2 OS App Hardware Virtualization Hardware Operating System Hypervisor VM 1 OS App VM 2 OS App Para-virtualization Hardware Operating System Container 1 App Container 2 App Containers START USING CONTAINERS
- 66. 66 CONTAINERS – DIFFERENTUSE CASES Hardware Operating System Container App Container App Container App Container App Container App Container App Container App Container App Container App Application Packaging Continuous Integration DIY PaaS Infrastructure Consolidation Neatly package applications and supporting environment in immutable, portable containers All changes to an app are contained in one immutable container image. Container is tested and deployed as one atomic unit Get infrastructure utilization up to 100% (vs 5-10% with VMs) due to over-subscription of resources and near bare metal performance. Build a simple PaaS by wiring up containers to a load balancer. New code, patches, etc pushed as new immutable containers. Hardware Operating System Container App Container App Container App Container App Container App Container App Container App Container App Container App Hardware Operating System Container App Container App Container App Container App Container App Container App Container App Container App Container App Hardware Operating System Container App Container App Container App Container App Container App Container App Container App Container App Container App Hardware Operating System Container App Container App Container App Container App Container App Container App Container App Container App Container App Hardware Operating System Container App Container App Container App Container App Container App Container App Container App Container App Container App
- 67. STRICT REQUIREMENT: ONEINSTANCE PER CONTAINER • Run ONE instance (unique host/port combination) per container • Running multiple instances of the same application or different applications will make scheduling very difficult • Expose one port per container 67 Physical Host Operating System Container App Container App Just One Per Container
- 68. 68 CONTAINER ORCHESTRATION Host Host Host Host Host Host Host Host Host Host Container • Inventory Microserv ice •AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container App Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container • Inventory Microserv ice • AcmeCo • v1.2 Container App Many Containers Host Host Host Host Host Host Host Host Host Host Many Hosts Docker Swarm • Map containers back to physical hosts, taking into account user- defined placement rules, the utilization of each host, and the needs of each container. Can be very complex • Set up overlay networking, firewalls, ensure network QoS, etc • Auto-scaling • Local and external load balancers • Service registry / discovery
- 69. 69 ADOPT AUTO-SCALING Hardware ProvisionedWithout Auto-scaling Time Traffic Resources Provisioned Try to track
- 70. CONTAINERS VS FUNCTIONS •Containers - A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. • Functions - Functions are blocks of code, ideally small and single-purpose. In the context of serverless, they are coordinated and scheduled by a Functions-as-a-service (FaaS) platform such as vendor services AWS Lambda, Azure Functions, and Google Cloud Functions, or open source frameworks such as the Fn Project (by Oracle), OpenWhisk, and OpenFaas. • Serverless - A category of software design where the abstraction layer for developers is at the application tier, above the operating system, infrastructure, and cloud IaaS API’s. In other words, developers never think about infrastructure. 70
- 71. CHARACTERISTICS OF AFUNCTION • Short Running – function live for a short amount of time and then the process ends. • Ephemeral – the outer container running the function may only live for a single invocation of the function. • Stateless – function does not inherently hold any state. All state must be pushed to structured or unstructured storage. • Invoked – function is invoked by defined events over either HTTP, TCP, or some other protocol. • Single Purpose – function have a clear and defined purpose with minimal API surface area, meaning it takes a reasonably short input, and provide a reasonably short output. • Autonomous – function can run and serve it’s purpose by itself. Although a function is likely just part of a broader grouping of functions, by itself, it can run independently as long as it gets it’s required input. 71 A function packaged in a container gives us a new “atomic unit of computing”
- 72. ATOMIC UNIT –RELEVANT CONCEPTS • Functions as Unit of Scaling - Scale Up/Down at much finer grained precision than machines (precision of single process) - Effective way of scaling of functions coupled with universal packaging/runtime of containers • Functions as Unit of Billing - No baseline on Servers or VMs - Enables huge cost reduction of lightly used applications • Functions as Unit of Design - Functions in containers with their own contract are shareable, so that composite applications can be built and reused - This requires function orchestration tools 72
- 73. APP RUNTIME PLATFORM(APAAS) • Useful for Cloud Native Application Developers • Value Proposition Let developers focus on building awesome applications Platform handles the complexity of running and scaling an application CONTAINER RUNTIME PLATFORM • Useful for Cloud Native Ops, IT Administrators • Value Proposition Developers/DevOps collaborate with IT Ops to deploy, scale the applications 73 DEPLOYMENT MODELS UNDER CONTAINERS
- 74. APP RUNTIME PLATFORM(APAAS) Lambda, Elastic Beanstalk Web Apps, Functions App Engine, Functions Pivotal Cloud Service OpenShift Origin Dynos ACCS, ACCS Functions CONTAINER RUNTIME PLATFORM 74 DEPLOYMENT MODELS UNDER CONTAINERS - POPULAR CHOICES Elastic Container Service Container Service/Instance App Engine Flex, GKE Pivotal Container Service OpenShift Container Runtime Container Engine, Functions
- 75. App tier 75 CLOUD NATIVETRANSITION TO APAAS Web tier WebLogic Cluster DB tier Customer Catalog Order Load Balancer Service APIGateway/Security Events Customer Order Catalog
- 76. Application Architectures MicroServices DevOps * asa Service Distributed Computing TOPICS TO LEARN •Multi-master •Many Data Centers •Many Fault Domains •Many Regions •Global Server Load Balancing •Replication 76
- 77. "I don't needa hard disk in my computer if I can get to the server faster... carrying around these non- connected computers is byzantine by comparison." - Steve Jobs 77
- 78. 78 EVERYTHING IS NOWDISTRIBUTED. GET USED TO IT Applications Infrastructure Teams Applications are now broken up into small microservices, with separate frontends and back-ends Different data centers, fault domains, regions, etc. Even within the same data center, latency may be unacceptably high Many small teams, each responsible for their own microservice. Each team is often geographically distributed
- 79. DISTRIBUTED COMPUTING Run yourapplications across multiple data centers, fault domains, regions, etc79 Cloud Region Fault Domain Data Center Host Container Microservice Microservice Microservice Microservice Hundreds of milliseconds of latency Everything is now distributed Even within the same data center
- 80. 80 SMUGLY OPTION TOCHOOSE Consistency Each node shows the same data at all times Availability Each node is available for writes at all times Partition Tolerance Able to handle network outages CAP Theorem – Pick Any Two C A P Theory Practice Pick One Partition Tolerance is non-negotiable because we have networks that can always fail Enterprise IT Systems: Often CP Microservice Systems: Often AP Each microservice can be CP, AP or CA but the system as a whole is always CP or AP Pick Any Two Computer science is all about tradeoffs
- 81. 81 MICROSERVICES FORCES MOVETO DISTRIBUTED COMPUTING • Distributed computing is a natural consequence of microservices because each microservice has its own data store • Sharing data stores across microservices introduces coupling – very bad! • There will always be latency between microservices • Latency leads to eventual consistency API Application Datastore Infrastructure API Application Datastore Infrastructure API Application Datastore Infrastructure API Application Datastore Infrastructure Microservice A Microservice B Microservice C Microservice D Monoliths don’t suffer from this
- 82. 82 MAKE YOUR MIDDLETIER STATELESS Push all state and configuration down to highly available cloud services Application Server File System Application Server File System Application Server File System Application Server File System Application Instance File System Load Balancer Sticky to an Individual Instance Application InstanceApplication InstanceApplication InstanceApplication Instance Load Balancer NOT Sticky to an Individual Instance State Service Configuration Service Application Instance Key to Cloud Native Session State Shopping cart contents, page view data, personalization, etc Application Configuration Port numbers, file system paths, host names, etc Legacy Cloud Native
- 83. 83 REMOVE ALL HARD-CODEDIPS, HOST NAMES ETC. Use service discovery, DNS, Environment Variables etc. Everything should be dynamic
- 84. DevOps + *as a Service + Microservices + Distributed Make Cloud Native Available to Everyone Else 84
- 85.