Please enable JavaScript.

Coggle requires JavaScript to display documents.

Compute Services - Coggle Diagram

- - - - WebJobs
        
        used to run background tasks as part of your application logic
        
        run a program (.exe, Java, PHP, Python, or Node.js) or script (.cmd, .bat, PowerShell, or Bash) in the app context
    - - Store mobile app data in a cloud-based SQL database
      - Authenticate customers against common social providers, such as MSA, Google, Twitter, and Facebook
      - Send push notifications.
      - Execute custom back-end logic in C# or Node.js.
    - - full Swagger support
  - - - ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python
- - - - much more faster than VMs
  - - - manage the demands of
        containerized applications
    - - container manager automation
      - API
      - cloud native application management
        powrhouse
    - - configure PADs
        
        PADs are one or more containers
      - PADs are managed in
        Kubernetes Cluster Nodes
    - - if one of the PAD crashes
        
        Kubernates can create
        new instances
      - if a Kubernates Cluster Node
        is removed
        
        Kubernates can move effective workload (active containers)
        to a running Node
    - - trigger automatically (autoscaling) or manually
      - create or remove PADs
    - - if application is problematic
        Kubernates can rollback
      - manage application update
        on containers
    - - kubernetes persistence volumes
        
        used to present data storage
        for read/write operations to containers
        
        persist application data across
        many PADs instances
        
        use cloud storage
        
        azure storage
        
        azure cosmos db
    - - expose PADs to the internet
      - load balancing traffic
      - network isolation
      - security policies
    - - overriding extended Kubernetes API
      - custom actions
        
        es. producing custom events on PAD creation
        
        es. custom PADs scheduling logic
  - - - es. website
        
        one container for frontend
        
        one container for backend
        
        one container for storage
      - objective
        
        ogical sections that can be
        maintained, scaled, or updated independently
    - - small well defined scope
        
        each one contain a
        single business capability
      - loosly coupled from any other
        web services
      - each service has a different
        code base
        
        managed by a small development team
        
        indipendent technology
        
        frameworks, tools, libraries
        
        each team decide the best
        implementation
        
        each development team can
        
        build
        
        test
        
        deploy
    - - continuos innovation
      - fast releases
      - easier for new memebers
        to join the team
        
        simple code base easy
        to learn
      - deployment
        
        each service can be updated
        without rebuild the entire application
        
        simpler rollback related to just
        one microservice
        
        each microservice can be scaled indipendently
    - - each microservice should
        manage its own storage
      - ideal is make each microservice
        completely autonomous
        
        no cross dependency from
        a business prospective
        
        if a service goes down the complete
        application still run
    - - by using well defined APIs
      - best practices
        
        reduce interactions
        
        build an upper level orchestrator
        for each consumer application
        that call different microservices
        and prepare results
- - - - availability
      - scalability
      - redundancy
    - - identical, load-balanced VMs
      - additional service to route requests
        between multiple instances
      - centrally manage, configure, and update
        a large number of VMs
        
        instances can automatically increase or decrease in response to demand or a defined schedule
      - build large-scale services for areas such
        as compute, big data, and container workloads
    - - large-scale parallel and high-performance computing (HPC)
      - steps involved
        in dequeing jobs
        
        Starts a pool of compute VMs for you.
        
        Installs applications and staging data.
        
        Runs jobs with as many tasks as you have.
        
        Identifies failures.
        
        Requeues Work
        
        Scales down the pool as work completes.
- - - - pay only for the time their code runs
  - - - es. API and webhook
        scenarios
  - - - ideal when
        
        you're concerned only about the code running your service, and not the underlying platform or infrastructure
        
        commonly used when you need to perform work in response to an event (often via a REST request), timer, or message from another Azure service
        
        work can be completed quickly, within seconds or less
        
        when demand is variable
      - stateless
        
        they behave as if they're restarted every time they respond to an event
      - stetefull (Durable Functions)
        
        context to prior activity
    - - execute workflows
        
        designed to automate business scenarios and are built from predefined logic blocks
        
        as Azure Functions trigger logic based on an event
        
        made by Azure conenctors
        and processing blocks
      - visual designer on the Azure portal or in Visual Studio