Managing Micro-Services for your Company

Justin Lovell

Web First

Web First Mobile First

Web First Mobile First

API First

API-first really resonates well with our mission to build micro-services. It just seems natural, and you just have to ask yourself why this is the case?

Our API’s are the platform and not the product on show. We need other developers outside of the team to employ our platform so that the product which the API supports could organically grow. By itself!

Organic Growth vs. Team Delivery

API First in 20021. All teams henceforth will expose their data and functionality

through interfaces

2. Teams must communicate with each other through these interfaces

3. There should be no other form of inter-process communications allowed; no direct linking, no direct reads of another team’s data store, no back-doors whatsoever. The only communication allowed is via service interface calls over the network

4. All service interfaces, without exception, must be designed from the ground up to be externalized. That is to say the team must plan and design to expose the interface to developers to the outside world. No exceptions

The Parallel: Micro-Services1. Expose data and functionality via interfaces. Ditto for micro-

services

2. Standard protocols for communications. Micro-services expose a contract for the standard interfaces it exposes

3. Use the advertised interfaces and contracts only; no back-doors. Segregation and independence is strongly encouraged by micro-services

4. All API’s are to be exposed and consumable within the public domain. Yup, this is still a scary proposition so let’s explore it with API Management services. We will get to that shortly

Developer Support and Service Contracts are ImportantDon’t break your API users Provide support when they want to adopt your platform

SecurityEvery team becomes a target for a Denial of Service (DOS) Attack

Monitoring and Quality AssuranceBoth are interconnected Healthy services is not whether it is up or not; facets of good health • Response times • Correctness • Durable • Resiliency

DiscoverabilityWhat API’s does my organization already have?

API Management in ActionAPI#1 API#2 API#3Micro-Services

API Management

Product #A Product #BProducts for Consumers

Policies Policy Policy Policy Policy

Developer Apps Foo Bar

Dev Portal API and Docs Exposed to the World

Don't Defer APIm Current API Consumers are SmallNever underestimate organic growth. When your API consumers grow, find ways to automate.

Your API is already easy to understandSo you don’t write documentation? Not all your users are so savvy implementing others’ code.

It’s easy to control access to your APITomorrow’s requirement: have multiple tier levels of products with various throttle controls. Now what?

Don't Defer APIm

There is no money in the API!Yes, indirectly, you are exposing your product on a platform which can organically grow

Designed for once off special use APIProbably today, yes. However, that mobile app now has other feeds from IoT. Now what?

Partner API already has a dashboardGood luck in trying to troubleshoot latency issues when you rely on other people’s numbers

Other APIm Use Cases?

SOAP

Monitor external service providers for free by routing your API calls through the API Manager.AKA: Lie Detector :)

MonetizationCharge for using your API Allocate the costs of your API to a “cost centre”

Composability

Conclusion (It’s all about the Platforms)• Expose your API as soon as possible; it’s a platform

for organic growth outside of your teams’ efforts

• Publishers and consumers should have a first class experience in experiencing the platform which you expose

• Keep micro-services as lean as possible. Utilize the abstractions provided for by the API Manager to manage the more complex and common aspects of your API exposure.