Mule : Building Blocks for Microservices

All contents © MuleSoft Inc.
Mule: Building blocks for microservices
January 2016
Anirudh Pandit

All contents © MuleSoft Inc.2
•  Debunking the myth that Mule is only an ESB:
– There is ESB as a product, and ESB as an architectural pattern.
– Vendors that had ESBs were heavyweight EAI products.
– Mule is a lightweight runtime, with integration and connectivity patterns built in.
– Mule is NOT an ESB. Mule can be implemented as an ESB architectural pattern.
– Mule is flexible to be implemented as a micro-entity or as a central-entity.
•  Mule is an ideal fit for a foundation for microservices strategy
– Mule provides flexibility by offering various building block forms
•  Mule runtime Natural fit for containers
– How Mule and PaaS go hand in hand to deliver a microservices platform
Context

Mule building block forms
Managed API
Flow Logic
Connectivity
Anypoint Management Center
Design-time
tools & services
Analytics Services
PaaS runtime
services
Engagement tools & services
Identity Services
API runtime
services
API management
Organization and business groups

Mule building block possibilities
Managed API
Flow Logic
Connectivity
•  Central API gateway ( global )
•  Micro API gateway ( local )
•  Managed microservice (if combined )
•  ESB architecture implementation ( global )
•  Micro ESB architecture implementation (local)
•  Un-managed microservice ( local)

Focus of this document is on microservices only
Managed API
Flow Logic
Connectivity
•  Central API gateway ( global )
•  Micro API gateway ( local )
•  Managed microservice (if combined )
•  ESB architecture implementation ( global )
•  Micro ESB architecture implementation (local)
•  Un-managed microservice ( local)

Runtime engine
What goes into a Mule microservice?
Connectivity
•  MQ, Database, SOAP,
HTTP, SaaS, OTS
software
•  Protocol
implementation
•  Connections/resources
management
•  Pooling
…
RAML specification
•  Traits
•  ResourceTypes
•  SecuritySchemes
•  Re-usable properties
•  ….
Logic
Business Logic flows
•  Routing
•  Enrichment
•  Transformation
•  Aggregation
•  Parallel execution
•  Splitting
•  ….
Connectivity
API Contract
Mule
deployable
archive
(.zip)

VM
OS
Container
Java Virtual Machine
Runtime engine
Mule microservice platform
Logic
Connectivity
API Contract
… PaaS

Microservices with Mule
Legacy EAI middleware
System/data
microservices
Process
microservices
Experience
microservices
Reverse Proxy Mule Custom ( e.g., Node.js, C# , Java etc. )
Databases, Business Apps and Legacy Systems
Legend:

Using Mule for both managed
and un-managed microservices
(including API management)

Level setting
Proxy
This is the protection above the microservice
MicroService
This is actually the service
Data / System / Backend
Consumer
Mobile, web, or even another service / API

Possible deployment options
11
Mule Proxy API
Mule Service API
Other Service API
Business
IT
•  LOB may own the gateway/proxies
•  Typically done in settings where
there is little to no LOB IT
•  ESB architectural pattern
•  IT owns all the services
Edge gateway and services runtimes deployed in ESB pattern

Mule Proxy API
Mule Service API
Other Service API
Business
IT
•  LOB may own some lightweight
orchestration services
•  LOB may own the gateway/proxies
•  LOB owns IT resources
•  ESB architectural pattern for the
lower level services. IT owns all the
services at the lower levels.
Combination of edge gateways at different logical levels and services
runtimes in a similar pattern as the overlaying gateways

Each level has separate governance patterns
Mule Proxy API
Mule Service API
Other Service API
Business
IT
•  LOB may own some lightweight
orchestration services
•  Collaboration between LOB and
central IT
•  IT owns all the services at the
lower levels.
Combination of edge gateways at different logical levels and services
runtimes in a similar pattern as the overlaying gateways

Mule Proxy API
Mule Service API
Other Service API
Business
IT
•  Each group ( LOB, and IT ) will be
responsible for their own destinies
•  Microservice runtimes
•  Micro-gateway implementations
•  DevOps at scale
•  Heavy dependence on PaaS
platforms
Micro-gateway and runtime entities at each logical level

Microservices – what are they?
-  Smaller services, with a clear business capability purpose
-  Bounded context
-  Single purpose
-  Experience APIs
-  Loosely coupled
-  Autonomous / Loosely held dependencies
-  Explicitly addressing dependencies and minimising their impact through tooling
and practice
-  Technology agnostic
-  There are no hard rules
-  Design for change and replacement
-  Iterate and improve
-  No need to be religious

APIs in a microservices context
•  APIs are a technology-agnostic way to interface between two software
components. These can be implicit or explicit (i.e. formally defined by a
machine-readable specification and managed).
•  In this context, we note that microservices are implementations of APIs.
-  APIs don’t have to be synchronous (although they could be)
-  APIs don’t have to be request-reply (although they could be)
-  APIs don’t have to implement specific protocols
•  … in other words, they conform to the microservices definition of loose
coupling: APIs are completely appropriate as a way of defining a microservice
boundary.

API first microservices
-  We can apply the API-first approach to microservices, where we
specify microservices by their interface (their only touchpoint with the
outside world) before we implement them. A single-purpose design
makes this even easier than before.
-  Smaller services are inherently defined by their boundary (contract)
-  Start with an API specification
-  API contracts make it easier to manage change
-  Automation and policies over microservices streamlines coupling and allows
easy linking
-  API-based testing improves quality and predictability and can act as
heartbeats

Productized APIs with microservices
-  API specification defines precise functional contract between the creator of
the API and its consumers
-  what are the operations, what data do they require or provide, and what happens when
you invoke them?
-  Access control (authentication, authorization, tokens)
-  SLA definition and management (e.g. rate limiting or caching)
-  Dependency tracking, collaboration and change notification
-  Provides primitives to manage change (API specifications, versions)
-  A powerful counterpart to operational automation for a resilient system

Connecting microservices
- Microservices aren’t “islands” - they work together for
customer and business outcomes
-  And most of the time, with things that aren’t microservices
- There are three key areas that Anypoint makes easy:
-  connecting microservices
-  connecting mixed models (microservices with non-
microservices)
-  building microservices

API Led Capability Architecture

API Consumer Capabilities
API-led microservices and connectivity reference
API
API Provider Capabilities

Application development accelerators
API Consumer ( App Developer) Portal
API-led connectivity reference capabilities
API Connectivity
API
Design
Runtime
Policy
Mgmt
Security
API Gateway
API
API Discovery API Onboarding
API Provider ( Administrator ) Portal
API Build
Operational
Management
AnalyticsAnalytics

API-led connectivity reference capabilities
API spec creation
API doc
generation
API mocking
API use case
modelling
API design
patterns
Traffic mgmt.
Custom runtime
policy
SLA/contract
mgmt.
Dev portal
generation
Multi-org setup
Authentication
Authorization
IP white/black list
Digital certificates
Payload encryption
Protocol connectors
SaaS / On-prem
connectors
Custom connectors
Caching
Transformation Orchestration Routing
Runtime policy enforcement gateway
API
Connectivity patterns
Versionings
Environment
promotion
Deprecation
Design
API provider / administrator portal
Manage Security Gateway Lifecycle
API façade
mapping
Server side
generation
Backend
modelling
Deployment
automation
API backend
patterns
Implement
API catalog/registry
API Directory Text search
Metadata / tag search Application registry
Portal theming
API key management
Indexed facet searchAPI rating
Developer Portal
API Portal
Forums
Blogs Code samples
Clients, SDKs Interactive docs
Shareable use cases
Static docsAPI Sandbox Self service sign-up
Portal Branding URL customization
Applicationconsumption
dashboard
Analytics
Providersideanalytics.
Customizationdashboardsand
exportablereporting.
End–Endbackendeventtracking,visualizationanderrorreporting
Synchronization Service
Optimization &
Transformation
Mobile Services (Push, GIS,
IDM)
App container & hosting
Aggregation &
Normalization
Platform libraries MDM

MuleSoft
API spec creation
API doc
generation
API mocking
API use case
modelling
API design
patterns
Traffic mgmt.
Custom runtime
policy
SLA/contract
mgmt.
Dev portal
generation
Multi-org setup
Authentication
Authorization
IP white/black list
Payload
encryption
Protocol connectors
SaaS / On-prem
connectors
Custom connectors
Caching
API
Integration patterns
Versioning
Environment
promotion
Deprecation
API consumer / developer portal
Design
API façade
mapping
Server side
generation
Backend
modelling
Deployment
automation
API backend
patterns
Implement
dashboard
Analytics
API key management
Indexed facet searchAPI rating Dev Portal
Forums
Blogs Code samples
Clients, SDK generation Interactive docs
Shareable use cases
Optimization &
Transformation
IDM)
Aggregation &
Normalization
Portal theming Portal Branding URL customization

Traditional API Management Vendor
API spec creation
API doc
generation
API mocking
API use case
modelling
API design
patterns
Traffic mgmt.
Custom runtime
policy
SLA/contract
mgmt.
Dev portal
generation
Multi-org setup
Authentication
Authorization
IP white/black list
Payload
encryption
Protocol connectors
SaaS / On-prem
connectors
Custom connectors
Caching
API
Versioning
Environment
promotion
Deprecation
Design
API façade
mapping
Server side
generation
Backend
modelling
Deployment
automation
API backend
patterns
Implement
dashboard
Analytics
API key management
Forums
Blogs Code samples
Shareable use cases
Optimization &
Transformation
IDM)
Aggregation &
Normalization

Traditional Integration Vendor
27All contents Copyright © 2014, MuleSoft Inc.
API spec creation
API doc
generation
API mocking
API use case
modelling
API design
patterns
Traffic mgmt.
Custom runtime
policy
SLA/contract
mgmt.
Dev portal
generation
Multi-org setup
Authentication
Authorization
IP white/black list
Payload encryption
Protocol connectors
SaaS / On-prem
connectors
Custom connectors
Caching
API
Versioning
Environment
promotion
Deprecation
API key management
Forums
Blogs Code samples
Shareable use cases
Design
API façade
mapping
Server side
generation
Backend
modelling
Deployment
automation
API backend
patterns
Implement
dashboard
Analytics
Optimization &
Transformation
IDM)
Aggregation &
Normalization

Primary Roles concerned with the Anypoint Platform
EA
AD
AO
AC
•  Enterprise Architect: strategy and evangelism of architectural best
practices, for both design and runtimes
•  API Developer: Responsible for developing the API / service
•  API Owner: Responsible for the productization, operations and
continuous improvement of the API
•  API Consumer: Could be either an API developer, or a builder of
mobile, web and other apps

Organization and business group configuration
30
Design-time
tools & services
Analytics Services
iPaaS runtime
services
Identity Services
API runtime
services
API management
Enterprise administrators, API owners and enterprise
architects create business groups and environments

Configure identity services and permissions
31
Design-time
tools & services
Analytics Services
iPaaS runtime
services
Identity Services
API runtime
services
API management
API Owners to configure identity services for each
organization or business group
•  Configure RBAC permission models for the business groups and
environments.
•  Map from LDAP groups within your own enterprise LDAP to
the Anypoint platform.
•  To ensure proper access within the Anypoint platform, the
organization owner must ensure that each of the groups is
mapped to a role with appropriate permissions.
•  Custom roles could also be created as needed.
•  Leverage out of the box configurations to Ping and OpenAM

Enable developers throughout the enterprise
32
•  DIY developer culture
•  Training and skill building
•  Easy to use tooling
•  Access to building blocks
•  Best practices

Begin by hand writing the API’s contract
AD
API developer creates RAML spec in API Designer
Design-time
tools & services
Analytics Services
iPaaS runtime
services
Identity Services
API runtime
services
API management

Mock up the API, validate it with the consumer
AD AC
API Designer and API Consumer exchange feedback
Stub to the
backend

Create Notebooks against the mocked up API, in order to to
illustrate various scenarios and use cases of the API
Example: Zendesk API Notebooks
AC API Consumer creates Notebooks to tinker with the mocked up API
Stub to the
backend

Anypoint Exchange: a repository of API design best
practices
EA Enterprise architect sets up a repository of API design best practices for architectural governance. E.g.,
response code templates, pagination traits etc. and other subsets of RAML contracts.

Leverage best practice RAML snippets ( traits, resourceTypes,
securitySchemes, or others ) from Exchange
Repository of RAML snippets
RAML
Import
AD
API developer leverages RAML snippets to design the API

Unlock assets with governance
•  APIs for governance
•  Access with policies
•  Documented, communicated
•  Security built in
•  Identity authentication
•  Alerts & notifications
38

API implementation
SaaS apps
DB
ERP
Stub to the
backend
AD Once receiving validation from the API consumers around how the API contract is modeled, the
API developer is now able to move on towards implementing the API.

API implementation
Leverage power of a suite of
connectors, transformations,
templates, filters, flow control
mechanisms in the
implementation logic
Quick testing and feedback
through built-in RAML console
AD API developer creates backend integration, transformation, routing, mapping and connectivity
logic
Edit RAML contracts

Anypoint Exchange: a repository of architectural best
practices
EA Enterprise architect sets framework up a repository of API implementation and other integration
transformation/routing/mapping and connectivity best practices

Leverage best practice RAML snippets ( traits, resourceTypes,
securitySchemes, or others ) from Exchange
Repository of Integration and Connectivity
patterns
API Implementation flow
Import
AD API developer leverages integration and connectivity templates to implement the API in a manner that
is governed, and compliant to IT standards.

AO
Secure and manage the API proxy, and API service
•  policies
•  orchestration
•  transformation
•  caching
•  Policies
•  Traffic mgmt
•  Security
•  Caching
Design-time
tools & services
Analytics Services
iPaaS runtime
services
Identity Services
API runtime
services
API management
API gateway
API runtime
Proxy
Service
API owner sets up the end-end API stack: proxy, gateway, management policies and service runtime
environment

AO
Publish the API and engage application developers
•  API onboarding and
documentation
•  Client libraries, SDKs
•  Collaboration
Design-time
tools & services
Analytics Services
iPaaS runtime
services
Identity Services
API runtime
services
API management
Developer Portal
API owners catalog all APIs and set up the developer portals
•  Directory
•  Search, indexing
•  Metadata, tags
•  Versioning,
deprecation,
promotion
API catalog

Rich Developer Portal
45

Analyze, monitor, and diagnose
46
•  Usage analysis
•  End to end visibility
•  Monitor against SLAs
•  Diagnose low performance

Analytics
View analytics of API consumption, and the API implementation ( backend ) metrics, both from a
consumer and provider perspective
Design-time
tools & services
Analytics Services
iPaaS runtime
services
Identity Services
API runtime
services
API management
API Analytics Backend Analytics

MuleSoft leverages broadly adopted tools
JUnit
Deployment/
Ops
Development
Functional/
Unit Testing
Build
Continuous
Integration
Developer
Ecosystem
49

Release
Component
Mule SDLC Overview
Development
Production
1
2
Anypoint Studio
Developer
3
4
5
6
7
8
9
Run Mocked TestsRun Unit Tests
Run TestsRun Build Process
DEVELOPMENT
RELEASE
PRODUCTION
Create Mocked TestsCreate Unit Tests Functional Tests
Create and Run Tests
Mule
App
Mule
App

All contents © MuleSoft Inc. 51
DEV
Runtime Platform
Management
CI/CD
Studio
JUnit
Anypoint
management Center
(Monitoring: Insights,
Logs, Alerts, Data
Correlation, etc.)
Dev
Test
Stage
Prod

Point Of View on PaaS enablement
53
•  Run cloud-native applications per cncf.io
–  container-packaged, dynamically scheduled, microservices-based dev/ops
•  On any cloud (public or private) environments
–  Docker, Kubernetes, Mesos, Tectronic, …
–  OpenShift v3, CloudFoundry/Diego, …
•  Leveraging lowest-common-denominator
–  Enabling friction-free containerization of Mule services
–  Fundamental solution loosely based on CaaS (Containers as a service)
•  For all our runtime services
–  Mule workers (API/gateway/orchestration/connectivity workers)
–  Management Center (for API/Mule lifecycle/management/governance)

Development
Operations
Build
Ship
Run
Secure Content
Collaborate
Deploy
Manage
Scale
Development Environments

Worker: Model: Runtime Container
55
•  Make Mule runtime a container
–  Logging configured to standard output/error via log4j.(properties|xml)
–  Map MULE_INSTALL_DIR/apps to an external folder
•  Use published ways of (un)deploying applications
–  Copy/remove from externalized apps folder
–  Use Runtime Manager to deploy apps
–  Use published lifecycle APIs to deploy apps
•  Ramifications
–  Only 1 container image is maintained
–  Standard methods of application lifecycle are maintained (pro or con)
–  Service lifecycle is not tied to container lifecycle (con)

Worker: Model: Runtime+Application Container
56
•  Make Mule runtime+application a container
–  Mule installation is a container image
–  Mule application is a container image
•  Layered atop the mule installation image (via docker containers efficiency layering)
•  CANNOT Use published ways of starting/stopping containers
–  Service lifecycle bound natively to container lifecycle
•  Ramifications
–  One container image maintained for runtime (pro)
•  Each service is thin layer atop mule container overriding MULE_INSTALL_DIR/apps
–  Published methods of Mule application lifecycle no longer apply (pro or con)
–  Service lifecycle is tied to container lifecycle (pro)
•  Friction-free model for container orchestration management systems

Applicability to OpenShift V3
57
•  Layered system atop
–  Docker: Lightweight Container Model
–  Kubernetes: Container Orchestration across multiple hosts
•  OpenShift Value Adds:
–  Source code management, builds, and deployments for developers
–  Managing and promoting images at scale as they flow through your system
–  Application management at scale
–  Team and user tracking for organizing a large developer organization

58Applicability to Openshift: https://docs.openshift.org/latest/architecture/index.html

Mule : Building Blocks for Microservices

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Mule : Building Blocks for Microservices

Similaire à Mule : Building Blocks for Microservices (20)

Dernier

Dernier (20)

Mule : Building Blocks for Microservices