How HP Transformed its Architecture with Microservices and API Management

#58 on theFortune 1001

$58.5Brevenue in FY18

Operations in

170 countries~55,000employees

#24 Fortune Best Workplaces in Technology 2

250,000+channel partners

26,000+patents

1. HP ranking in 2018 - please see http://fortune.com/fortune500/list2. HP ranking as of January 2019 – please see http://fortune.com/2019/01/17/50-best-workplaces-in-technology/ 3. HP ranking as of February 2019 – please see https://www.barrons.com/articles/these-stocks-are-winning-as-ceos-push-for-a-sustainable-future-51549657527

#4 Barron’s Most Sustainable Companies 3

HP today

Trends Driving

Transformation

AS-A-SERVICEONE LIFE SECURITY

One Life

© Copyright 2019 HP Development Company, L.P. The information contained herein is subject to change without notice.4

As-A-Service

© Copyright 2019 HP Development Company, L.P. The information contained herein is subject to change without notice.5

Security

© Copyright 2019 HP Development Company, L.P. The information contained herein is subject to change without notice.6

3D

Computing

PrintCTOInnovationBest practices in tech communityShared servicesGlobal privacy and compliance

ITPublic cloud Security & privacyCostShared Services

HP cloud applications principles

Security & privacyCloud nativeAgileCI/CDDevopsMicroservicesSLA contracts API contracts

Why microservices?

The answer is: Velocity

B C

A

D E

● Complex sync across functional areas and distributed teams

● Dependencies block teams

● CI/CD pipelines taking hours, multiple validation gates

● Long time to production of new features

API

SLA

Monolith Hurdles

A1..N

B1..N

C1..N

D1..NE1..N

API

SLA

API

SLA

API

SLA

API

SLA

API

SLA

● Manage the complexity of the code base

● Independently deploy and scale different functional areas

● Smaller teams with effective and local communication

● Encourage cross functional ownership of the solution by developers

Microservices to Increase Product Velocity

More powerful higher level services created from lower level services

Service Service

Service Service Service

Service Service Service Service

Exponential Velocity

Microservices are awesome!

But microservices introduce technical problems

Infrastructure costs

CI/CD pipelines speed & costs

Orchestration & discovery

Dependency versioning Integration testing Monitoring

AvailabilityAuth{N|Z}

Distributed systems

challenges

Policy ...

We can address most problems

• Central authorization

• Traffic management

• Centralize policy• Security: OWASP

• Authorization • Traffic telemetry• Traffic management• Transport encryption• Centralized L7/L4 policy

• Written contracts• API versioning• Quotas & rates• Usage visibility

• Deployment density• Immutable infra• Fast provisioning• Orchestration &

discovery• Monitoring

Containers & Kubernetes

API Management

App Gateways & ProxiesService Mesh

Policy

Services Mesh

17

C1..N

F1..N

D1..N E1..N

A1..N B1..N

G1..NPersonal Data

Global Data

App Data

7 microservices, 5 data stores

Services mesh – service versionsΔ, ß service variants

C1..N

F1..N

D1..N E1..N

A1..N B1..N

G1..N

Δ1..N

ß1..N

Personal data

Global Data

App local data

Services mesh in two clusters

C

F1..N

D1..N E1..N

A1..N B1..N

G1..N

Personal data

Global data

Local app data

C’1..N

F’1..N

E’1..N

B’1..N

G’1..N

Data center

ß1..Nß’1..N

Δ1..N

Two regional data centers

• Client AuthZ• User AuthN• Consent• Embargo • Quotas• Audit• Trace/Telemetry• Input validation

• Client AuthZ• User AuthN• Service RBAC• User RBAC• Consent• Embargo • Quotas• Audit• Trace/Telemetry• Input validation• Data residency

• Client AuthZ• User AuthN• Service RBAC• User RBAC• Consent• Embargo • Quotas• Audit• Trace/Telemetry• Input validation• Data residency

• Client AuthZ• User AuthN• Service RBAC• User RBAC• Consent• Embargo • Quotas• Audit• Trace/Telemetry• Input validation• Data residency

• Client AuthZ• User AuthN• Service RBAC• User RBAC• Consent• Embargo • Quotas• Audit• Trace/Telemetry• Input validation

• Client AuthZ• User AuthN• Service RBAC• User RBAC• Consent• Embargo • Quotas• Audit• Trace/Telemetry• Input validation• Data residency

Policy enforcement is typically done by a proxy or a gateway

A group or cluster of gateways for all APIs

Dedicated gateways for business units or environments (ex: production)

Typically require load balancers before and after the API gateway

Typical patterns:

● OAuth or API keys

● Aggregate two or more APIs into a single facade

● Orchestrate or sequence services

Centralized API Gateway

Edge Gateway LB

Service A Pod

Service A

Service B VM

Service B

Internet

TLS mTLShttp

LB

API Management

API Gateway

NGINX Ingress

Centralized gateways don't always work for microservices

Also known as Microgateways

A sidecar proxy is a pattern where the gateway or proxy is co-deployed with the app

Service Meshes tools like Istio already have sidecars

The sidecar takes certain responsibilities (like TLS termination, security etc.) away from the microservice

For all practical purposes, the sidecar is part of the microservice

Sidecar API Gateways

API Management with Microgateway

LB

Service A Pod

Service A

Service B VM

Service B

Internet

NGINX Ingress

TLS mTLShttp

API Management

Microgateway Microgateway

A dedicated infrastructure layer for handling service-to-service communication.

The service mesh provides a systematic mechanism to enforce and manage policies outside the applications, by moving policy enforcement to an external control plane.

A proxy in the form of a sidecar is injected to handle all ingress and egress traffic

ServiceMesh

API Management with Service Mesh

LB

Service A Pod

Service A

Service B Pod

Service B

Internet

Istio

TLS mTLShttp

API Management

Envoy Envoy

Gateway Pilot Mixer Citadel

Not everything in your enterprise is a microservice!

A typical enterprise will also have

APIs and SOA: Have their applications on VMs (non- microservices) and some of them will be considered "legacy applications". APIs published for consumption by apps

● Could be either be built by the developers working for the enterprise or by developers from customers/partners of the enterprise.

Vendor APIs: consume vendor APIs, esp. from SaaS applications like SalesForce, Workday etc.

Which gateway pattern is right for you?

A single gateway pattern is going to be insufficient to meet all the requirements

● Use the ingress to decide which pattern is best applicable to the service

● Service that don't require advanced features/policies can be enforced by a sidecar Gateway, other services will use an enterprise gateway

● Some services will use both gateways!

You don't need to choose!

Authentication and Authorization

Microservices Authorization

33

C1..ND1..N

A1..N B1..N

Global Data

Personal Data

Authenticate Alice her Client

Authorize A has access to B

Authorize A can read data from D

Authorize A has access Alice’s data in C

Alice

Gateway

Service A

Service B Service D

DMZ

Zone 1

Zone 3

Service A Service C Service DService B

Network Segmentation Single Sign On

Service C

Zone 2

TCP TLShttp

Service A Service B

Secure Token Service

Workload Identity

TLS mTLShttp

GatewayOAuth2 and OpenID Connect

Users and Clients. Distinction between user access and service to service access.

Tokens are not propagated around, instead are exchanged using the Token Exchange Draft Specification

JWT claims enable attribute based access control policies - XACML, NGAC,...

Workload Identity - Service Accounts, AIM Roles, SPIFEE

Microservices Authorization Fabric

API Management

Envoy Envoy

Samples

App deployment architecture (Microgateway)

Microgateway

US-East-1 EU-Central-1

us-east-1a us-east-1b us-east-1c eu-central-1a eu-central-1b eu-central-1c

M M M M M M

Ingestto S3

KinesisStream

S3

KMS

Push to ES

EBS

Ingestto S3

KinesisStream

S3

KMS

Push to ES

EBS

LB LB

App deployment architecture (Istio)

Envoy

When microservices are consumed by different teams, use API management

Use sidecar gateways, preferably provided by the service management itself (like Istio), for most API policy enforcement

Use centralized API gateways to orchestrate multiple microservices, to mediate access to legacy systems, and to handle external requests from untrusted systems that require extra validation

OAuth2 and Token Exchange . Do not trust your network, do not trust other services, treat authentication and authorization of internal services as if they where external customers.

Recommendations

Questions?

What is next...