Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud Native In-Depth

504 views

Published on

This session introduces the key patterns in Cloud Native application development. It highlights the need of a unique architecture style, further, the fitment of DevOps, usage of Microservices and the runtime of Cloud Native application (* as a Service). The precautions of distributed computing gives insights of how to plan the application design and architecture.

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Cloud Native In-Depth

  1. 1. CLOUD NATIVE SHIFT IN APPLICATION DEVELOPMENT PARADIGM SIVA RAMA KRISHNA
  2. 2. @sivachunduru linkedin.com/in/chunduru slideshare.net/sivachunduru SIVA RAMA KRISHNA – SOLUTION SPECIALIST 2
  3. 3. WHAT & WHY ? • History • Analyst perspective • Scope for community
  4. 4. CLOUD NATIVE ORIGINATED IN CUSTOMER FACING TECH COMPANIES
  5. 5. “Six decades into the 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. 6. IS THE TREATMENT OF AN ERP SYSTEM AND A WEBSITE SAME ? PACE LAYERED ARCHITECTURE Growth Release Cycles Fail Points Development Methodologies Execution Affinity Center of Gravity 6
  7. 7. NEW AD PROJECTS WITH 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. 8. WE MUST RE-INVENT OUR PROFESSION Then only 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. 9. VOICE OF THE VENDORS 9
  10. 10. 10 VALUE OF CLOUD NATIVE Quickly Capitalize on Business OpportunitiesSpeed Quickly move changes to production Survive failures. Highly available in production Resiliency Change your practices as needed Agility
  11. 11. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN 11
  12. 12. TOPICS TO LEARN Application Architectures MicroServices DevOps * as a Service Distributed Computing • Deployment Target Types • Development Methodology • Legacy Architectures • Service Based Architectures 12
  13. 13. — Brian Foote and Joseph 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. 14. QUARRY THE DEPLOYMENT TARGET 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. 15. QUARRY THE DEPLOYMENT TARGET 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. 16. https://12factor.net Adam Wiggins Co-Founder Heroku Cloud 16
  17. 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. 18. LEGACY ARCHITECTURES 18 Source: Software Architecture 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. 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. 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. 21. ARCHITECTURES - ANALYSIS 21 Source: Software Architecture Patterns by Mark Richards
  22. 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. 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. 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. 25. OTHER PATTERNS YOU HEAR 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. 26. Application Architectures MicroServices DevOps * as a Service Distributed Computing • Minimal Function • Service Discovery • API-first • Polyglot • Choreography • Loose Coupling TOPICS TO LEARN 26
  27. 27. “Erik Doernenburg first shared 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. 28. MICROSERVICES Break up your application 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. 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. 30. • Perform a single 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. 31 X-axis scaling • consists of 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. 32 DEVELOPERS WANT POLYGLOT SUPPORT • 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. 33. EACH MICROSERVICE USE ITS 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. 34 REMEMBER THAT LATENCY IS 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. 35. SYNCHRONOUS CALLS WITH MICROSERVICES 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. 36 AVOID SYNCHRONOUS CALLS FOR 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. 37. CIRCUIT BREAKERS PREVENT CASCADING 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. 38. USE A HIGHER LEVEL 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. 39 EMIT LOGS AS EVENT 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. 40. Orchestration • Top-down coordination of 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. 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. 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. 43 ADOPT AN API GATEWAY 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. 44. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN •Automated Provisioning •Automated Setup •Continuous Integration •Continuous Delivery •Automated Testing •Agile •Culture Change 44
  45. 45. 45 The nicest thing about Teamwork is that You always have others on your side.
  46. 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. 47. TAKE THE BARRICADES OUT 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. 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. 49. Plan Code Build Test Package Release Deploy Monitor DEVOPS PIPELINE Pattern Description Plan Agile 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. 50. Plan Code Build Test Package Release Deploy Monitor HARNESS THE DELIVERY PROCESS 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. 51. DEVOPS PATTERNS AND TOOLSET 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. 52 INFRASTRUCTURE AS CODE Manage it 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. 53. • Single system for 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. 54. •Manual one button build/deploy •Scheduled builds - every day, every week, etc •Builds triggered by code checkins •If post-build validation fails, report it 54 ONE STEP BUILD/DEPLOY
  55. 55. 55 EXAMPLE OF AUTOMATED TESTING USING ROBOT 1. Integrate Robot With Maven 2. Write a Simple Selenium-based Test 4. View Results3. Run Test
  56. 56. • 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
  57. 57. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN •Consume IaaS and PaaS •Fault Tolerant by Definition •Auto-scaling •Infinite Elasticity 57
  58. 58. 58
  59. 59. * AS A SERVICE 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. 60. EVERYTHING IS NOW SOFTWARE 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. 61. CONTAINERS Is it compulsion to be part of? 61
  62. 62. 62 DISPOSABILITY RULES OF 12-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. 63. CLOUD NATIVE VS CONTAINER NATIVE • Create highly differentiated apps & services  Faster  With high quality  Geo reach  Compelling CX
  64. 64. SOFTWARE LANDSCAPE IN CONTAINER 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. 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. 66 CONTAINERS – DIFFERENT USE 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. 67. STRICT REQUIREMENT: ONE INSTANCE 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. 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. 69 ADOPT AUTO-SCALING Hardware Provisioned Without Auto-scaling Time Traffic Resources Provisioned Try to track
  70. 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. 71. CHARACTERISTICS OF A FUNCTION • 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. 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. 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. 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. 75. App tier 75 CLOUD NATIVE TRANSITION TO APAAS Web tier WebLogic Cluster DB tier Customer Catalog Order Load Balancer Service APIGateway/Security Events Customer Order Catalog
  76. 76. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN •Multi-master •Many Data Centers •Many Fault Domains •Many Regions •Global Server Load Balancing •Replication 76
  77. 77. "I don't need a 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. 78 EVERYTHING IS NOW DISTRIBUTED. 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. 79. DISTRIBUTED COMPUTING Run your applications 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. 80 SMUGLY OPTION TO CHOOSE 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. 81 MICROSERVICES FORCES MOVE TO 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. 82 MAKE YOUR MIDDLE TIER 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. 83 REMOVE ALL HARD-CODED IPS, HOST NAMES ETC. Use service discovery, DNS, Environment Variables etc. Everything should be dynamic
  84. 84. DevOps + * as a Service + Microservices + Distributed Make Cloud Native Available to Everyone Else 84
  85. 85. 85

×