Module 5: Deploying and Managing APIs

Table of Contents

About

Deploying-APIs.png
Deploying APIs

This modules is about deploying and managing APIs.

Objectives

  • Describe the options for deploying Mule applications
  • Deploy Mule applications to CloudHub
  • Use API Manager to create and deploy API proxies
  • Use API Manager to restrict access to API proxies

Notes

Intro

Introducing deployment options

Topic video

  • Deploying applications

    • During development, applications are deployed to an embedded Mule runtime in Anypoint Studio

    • For everything else (testing, Q&A, and production), applications can be deployed to

      • CloudHub

        • Platform as a Service (PaaS) component of Anypoint Platform
        • MuleSoft-hosted Mule runtimes on AWS
        • A fully-managed, multi-tenanted, globally available, secure and highly available cloud platform for integrations and APIs

      • Customer-hosted Mule runtimes

        • On bare metal or cloud service providers: AWS, Azure, and Pivotal Cloud Foundry

      • Anypoint Runtime Fabric

        • Customer-hosted container service of the runtime plane

    • CloudHub benefits

      • No hardware to maintain
      • Continuous software updates
      • Provided infrastructure for DNS and load-balancing
      • Built-in elastic scalability for increasing cloud capacity during periods of high demand
      • Globally available with data centers around the world

      • Highly secure

        • PCI, HiTrust, and SSAE-16 certified

    • Customer-hosted Mule runtimes

      • Easy to install
      • Requires minimal resources
      • Can run multiple applications
      • Uses a Java Service Wrapper that controls the JVM from the operating system and starts Mule

      • Can be managed by

        • Runtime Manager in MuleSoft-hosted Anypoint Platform

        • Runtime Manager in customer-hosted Anypoint Platform

          • Anypoint Platform Private Cloud Edition

    • Anypoint Runtime Fabric

      • A deployment model of the runtime plane

        • Container service that automates orchestration of apps and API gateways
        • Anypoint Platform control plane is still hosted by MuleSoft

      • Runs on customer-hosted infrastructure

        • AWS, Azure, virtual machines (VMs) or bare-metal servers

      • Main characteristics and capabilities

        • Security and reliability through isolation between applications
        • Re-deployments with zero downtime
        • Automated application failover through horizontal scaling
        • Run multiple versions of the Mule runtime
        • MuleSoft-supported containerized runtime images

    • Viewing Deployed Applications with Visualizer


      Visualizer

      • Visualizer provides a real-time view into your application architecture in a context that best suits your role

      • Organizes APIs and applications into relational diagrams

        • Promotes best practices and layer-based architectural consistency
        • Pinpoints issues rapidly through root cause analysis
        • Enables visibility into the policy compliance of APIs
      • Diagram data is secure and automatically & dynamically updated

    • Understanding the State of Your Infrastructure with Anypoint Monitoring

      • Anypoint Monitoring provides visibility into integrations across your app network


        Monitoring

      • Its monitoring tools are designed to reduce the time to identify and resolve issues by providing ways to

        • Aggregate and map metrics across dependent systems in real-time
        • Configure dashboards and alerts to reduce issue identification time
        • Store and search log data at scale

Extras

  • Runtime vs Plane vs. Control Plane Explained | Lightboard Series


    Runtime Plane vs Control Plane

    • Runtime Plane

      • There are three options

        • CloudHub

          • Hosted by MuleSoft (vendor) and runs in the Amazon AWS ecosystem
          • Allows provisionability of Mule Runtime
          • Has zero downtime deployments
          • Includes a load balancer with every application
          • New upgrades are a new deployment target

        • Runtime Fabric

          • It’s like CloudHub and it’s an Integration Platform as a Service (iPaaS) solution
          • It include a load balancer
          • It provides provisionability through being a Docker and Kubernetes cluster
          • It can be running on your ecosystem in Azure, AWS or in your own data center

        • Customer Hosted

          • Download the same Mule runtime and install it in your own infrastracture
          • The client is responsible for provisioning it

    • Control Plane

      • Oversees the running of the Runtime Plane
      • It is the anypoint.mulesoft.com, which is the web interface hosted by MuleSoft
      • Allows you to manage Runtime Planes through a web/ cloud hosted control plane
      • Private cloud edition is also available as a customer hosted control plane

  • CloudHub Architecture Explained | Lightboard Series

    • Mule is an application server, it needs some infrastructure to run
    • In the Amazon ecosystem that’s called an EC2 instance, which is a virtual machine that has a certain amount of CPI and memory available

    • Deployment model


      Deployment Model

      • The Mule Runtime is deployed into the EC2 and you have one application deployed per piece of infrastructure
      • This is to keep the deployment model simple, and makes maintanability simpler

      • Load Balancer

        • In order to support zero downtime deployments or deployments without outage, a load balancer sits in front of the client
        • Communicates from port 80 (Load Balancer) to 8081 (Mule Runtim/ Applicatione) for HTTP and 443 (Load Balancer) to 8082 for HTTPS (Mule Runtime/ Application)
        • To make any updates eto your application, e.g. sizing up or down the instance, CloudHub spins up an new EC2 instance, instead of making the changes over a running server, with a new version of Mule and your application
        • When it is up and listening, it gets added to the load balancer; for a brief moment you have to applications deployed, it then takes out the original one, and leaves the new update version
        • It works like this even with one worker, and provides zero down time deployment

  • Customer-Hosted Mule Runtime Explained | Lightboard Series

    • On-premise or customer-hosted Mule runtime is hosted using the cloud-hosted control pane i.e. anypoint.mulesoft.com
    • Runtime Manager is part of control plane, whic comes with the MuleSoft-hosted infrastructure
    • Runtime Manager is the key operations tool to give visibility
    • Self-hosted platform is installed by first downloading the zip and installing the licenses
    • You then communicate with the Control Plane, using an agent by running a command to register or notify the Control Plane of the existance of the Mule runtime instance
    • This agent is part of the Mule runtime installation
    • The Mule runtime needs to be started and then the agent opens a secure web socket, and keeps it open
    • The agent also works in the same way to restart servers, stop applications, change logging levels etc

  • Runtime Fabric Explained | Lightboard Series

    • The Control Plane plays an important role in providing the management interface, but infrastructure needs to be setup as part of Runtime Fabric because it’s running on a self-hosted infrastructure
    • Run time fabric is a Integration Platform as a Service (iPaaS), so it is provisionable
    • It is on your own infrastructure: AWS, Azure or even on your own data center
    • It is more flexible as compared to CloudHub which is managed by MuleSoft

    • There are two parts to this (multiple servers playing a role of providing maximum availability in a production environment):


      Parts of Runtime Fabric

      • Controller

        • Provides the admin capabilities for coordinating the deployment, the management, and also for load balancing
        • Load balancer provides distribution of requests across your different applications
        • The load balancer also provides zero downtime deployments
        • Communication is done with the Runtime Manager

      • Worker

        • Mule applications get deployed in a pod, running inside a Mule runtime

Deploying applications to CloudHub

Topic video

  • Deploying applications to CloudHub

    • Can deploy from Anypoint Studio or from Anypoint Platform using Runtime Manager

    • You must set worker size and number

      • For apps deployed from Flow Designer, these values were set automatically
      • A Worker is a dedicated instance of Mule that runs an app

      • Each worker

        • Runs in a separate VM container from every other application
        • Is deployed and monitored independently
        • Runs in a specific worker cloud in a region of the world

      • Workers can have a different memory capacity and processing power

        • Applications can be scaled vertically by changing the worker size
        • Applications can be scaled horizontally by adding multiple workers

      • There are workers in different environments

        • Design, Sandbox, Production, …
        • Applications can be promoted form one environment to another

  • Walkthrough 5-1: Deploy an application to CloudHub

    • Deploy an application from Anypoint Studio to CloudHub
    • Run the application on its new, hosted domain
    • Make calls to the web service
    • Update an API implementation deployed to CloudHub

Extras

  • CloudHub Terminology Explained | Lightboard Series

    • AWS terminology to know when deploying your application to CloudHub

    • Region: where you want your application to be deployed

      • Availability Zone (Data Center) - picked by CloudHub, two or more a spread across availability zones

        • Each worker (EC2 instance) - virtual machine in AWS lives in an Availability Zone; one worker means single point of failure

  • CloudHub Scaling Explained | Lightboard Series

    • There are two types of scaling available

      • Horizontally

        • E.g. scaling from one worker to more
        • You add extra workers
        • Considerations: state (Object Store, VM Queues)
        • Use the persistant queues
        • Inbound requests need to be funneled to all the workers using load balancers
        • The load balancer provides a united front so that requests can come in and then get distributed
        • Load balancers also provide zero downtime deployment
        • Load balancers become essential when you scale horizontally, unless the client can balance the requests between the endpoints
        • Sometimes scaling horizontally is done for availability to avoid having a single point of failure
        • It can even be done for performance

      • Vertically

        • Throw more CPU and memory on the problem i.e. add more memory
        • Start at 0.1 vCore
        • Memory - scale CPU
        • Scales the CPU scales the memory

Creating API proxies

Topic video

  • Creating API proxies

    • Restricting access to APIs

      Restricting access to APIs

      • An API proxy is an application that controls access to a web service, restricting access and usage through the use of an API gateway

      • The API Gateway is a runtime designed and optimized to host an API or to open a connection to an API deployed to another runtime

        • Included as part of the Mule runtime

          • Separate licences required
        • Separates orchestration form implementation concerns

    • The API Gateway is the point of control

      • Determines which traffic is authorized to pass through the API to backend services
      • Meters the traffic flowing through
      • Logs all transactions, collecting and tracking analytics data
      • Applies runtime policies to enforce governance like rate limiting, throttling, and caching

    • Using API Manager to manage access to APIs

      • Create proxy applications

      • Deploy proxies to an API Gateway runtime

        • Mule Gateway: On CloudHub or a customer-hosted runtime
        • Flex Gateway: fast, lightweight, environment-independent
        • Specify throttling, security, and other policies
        • Specify tiers with different types of access
        • Approve, reject, or revoke access to APIs by clients
        • Promote managed APIs between environments
        • Review analytics

      • Walkthrough 5-2: Create and deploy an API proxy

        • Add an API to API Manager
        • Use API Manager to create and deploy an API proxy application
        • Set a proxy consumer endpoint so requests can be made to it from Exchange
        • Make calls to an API proxy from API portals for internal and external developers
        • View API request data in API Manager.

Restricting access to APIs

Topic video

  • Restricting access to APIs


    Restricting API Access

    • Use API Manager to manage access to API proxies

      • Define SLA tiers
      • Apply runtime policies
    • The API Gateway enforces the policies

    • API Autodiscovery is a mechanism that enables a deployed Mule application to

      • Download policies from API Manager
      • Act as its own proxy

  • Applying policies to restrict access

    • There are out-of-the box policies for many common use cases

      • Rate limiting
      • Spike control
      • Security
    • You can define custom policies (using XML and YAML)
    • You can apply multiple policies and set the order

    • You can define automated policies to comply with common requirements

      • Requires a MuleSoft-hosted control plane

  • Using SLA tiers to restrict access by client ID


    SLA Restrict Access

    • A Service Level Agreement tier defines the # of requests that can be made per time frame to an API

      • Request approval can be set to automatic (free) or manual (for tiers that cost $)

  • Walkthrough 5-3: Restrict API access with policies and SLAs

    • Add and test a rate limiting policy
    • Add SLA tiers, one with manual approval required
    • Add and test a rate limiting SLA based policy

Extras

  • API Policy Enforcement Explained | Lightboard Series

    • API Policy Enforcement using a Proxy is runtime governance, where you are controlling access to a downstream implementation
    • The proxy is the point of enforcement: the API clients communicate with this
    • Policies are for quality of service, security, and other concerns, they are like aspects in Aspect Oriented Programming (OAP)
    • The proxy has to have some configurations on how to communicate with the downstream implementation, which is done through API Manager, which is part of the Control Plane
    • When an API instance is created, it is given an ID, which keeps track of what policies have been put on that API instance
    • It gets policies and keeps them on disk in a local cache
    • When HTTP requests come in, they talk to the policies of a locally cached policy configuration to avoid making a call to the Control Plane
    • Auto discovery allows you to combine proxy capabilities and implementation, it will then apply the policies before executing the code
    • That’s the advantage of having Mule as both the implementation and proxy

    • How updates to policies take effect

      • It kicks off at startup
      • There are some scheduled tasks when it’s up and running that periodically come back and does the same request to get a list of policies
      • There are some Gatekeeper features at startup to protect your downstrea implementation from having requests passed across until it knows it’s a list of the current policies

Granting access to APIs

Topic video

  • Enforcing access to APIs using SLA tiers

    • To enforce, apply an SLA based rate limiting policy

    • SLA based policies require all applications that consume the API to

      • Register for access to a specific tier

        • From an API portal in private or public Exchange
      • Pass their client credentials in calls made to the API

  • Requesting access to SLA tiers


    Requesting access to SLA tiers

    • If an API has an SLA-based policy, a Request access button appears in API portal
    • To request access, developer must belong to the Anypoint Platform organization and be logged in

    • When developers request access, they must

      • Register/add an app to their Anypoint Platform account
      • Select a tier

  • Approving SLA tier access requests

    ![](/img/Approving SLA-tier-access-requests.png)
    Approving SLA tier access requests

    • For tiers with manual approval, emails are sent to the Organization Administrators when developers request access for applications
    • Organization Administrators can review the applications in API Manager and approve, delete, or revoke requests

  • Walkthrough 5-4: Request and grant access to a managed API

    • Request application access to SLA tiers from private and public API portals
    • Approve application requests to SLA tiers in API Manager

Adding client ID enforcement to API specifications

Topic video

  • Adding client ID enforcement to API specifications

    • You need to add client ID enforcement to the API spec for the

      • REST connector that is created for the API to enforce the authentication
      • Required headers to automatically show up in the API console so you don’t have to manually add them for every call
    • Instructions are in the RAML snippet for a policy in API Manager

  • Walkthrough 5-5: (Optional) Add client ID enforcement to an API specification

    • Modify an API specification to require client id and client secret headers with requests
    • Update a managed API to use a new version of an API specification
    • Call a governed API with client credentials from API portals

Summary

Deploy applications to MuleSoft-hosted or customer-hosted Mule runtimes

CloudHub is the Platform as a Service (PaaS) component of Anypoint Platform

  • Hosted Mule runtimes (workers) on AWS

An API proxy is an application that controls access to a web service, restricting access and usage through the use of an API gateway

The API Gateway runtime controls access to APIs by enforcing policies

  • Is part of the Mule runtime but requires a separate license

Use API Manager to

  • Create and deploy API proxies

  • Define SLA tiers and apply runtime policies

    • Anypoint Platform has out-of-the-box policies for rate-limiting, throttling, security enforcement, and more
    • SLA tiers defines number of requests that can be made per time to an API
  • Approve, reject, or revoke access to APIs by clients
  • Review API analytics

Test your knowledge

Q1 What does an API proxy application NOT do?

  • Determine which response Mule event is allowed to pass through to the API backend service

Q2 API Manager has been configured to enforce an SLA policy and the RAML spec has been updated with the required client_id and client_secret header requirements. The new RAML spec has been published to Anypoint Exchnage. What is the next step to gain access to the APIs?

  • Request access to the API in Anypoint Exchange

Q3 What is the purpose of API autodiscovery?

  • Allows a deployed Mule application to connect with API Manager to download policies and act as its own API proxy

Q4 What does the Mul runtime use to enforce policies and limit access to APIs?

  • The Mule runtime’s embedded API Gateway

Q5 How many Mule applications can runon a CloudHub worker?

  • At most one

Anki

References

Random Posts