1. Microservices under the microscope
QCon – São Paulo
#APIFirst
@rdmeyersf
March 24, 2015

2. “To Improve Is to Change; To Be Perfect Is to Change Often”
Sir Winston Churchill

3. Digital Business Changes Everything

4. Digital Business has no Border
Architecting for Mobile isn’t enough
Omni-channel experiences require a new approach
Digital products are King

5. Digital Business has no Speed Limit

6. BMW i Remote App Status of car Charging status Doors, windows…
Inspection due
Range
Route to car / to public transportation
You call these APIs through your phone, or smartwatch like the samsung smartwatch which they highlighted early on, or now the apple watch. There are some great features which on their own are great. You can unlock your car if needed, or start it and warm it up. I think that’s pretty useful here. But you can also mash these APIs up with other APIs from other companies and can create a great customer experience. For example, I can tell you how far you can go on a charge in a google map, or where you need to go to charge along the way, or how long it will take for charging to be finished. Or I can see an issue and merge it with a service site to help you book an appointment, reserve a backup car, and tell you how long it will be. That’s all a great experience!
With the BMW i Remote App for iOS and Android, you can receive detailed information about the current status of the BMW i3 at any time. This includes, for example, range display, battery condition and charge level, service messages and also the vehicle location. With Charge Control, the charging procedure at the charging station can be controlled or ended remotely. The climate control of the passenger cell and the high-voltage battery can be activated before the journey via smart phone so that the BMW i3 is already set to the ideal temperature when entering the vehicle and to ensure that the performance of the high-voltage battery is optimised. The BMW i Remote App Also supports your route planning. Important goals, such as available charging stations can easily be sent to the vehicle before starting the journey.
Interpretation: When driving an electric vehicle, you will still face some challenges compared to a vehicle with a traditional combustion engine: you need more time to charge it, and you won’t find charging stations anywhere. So you need to plan ahead. The BMW i Remote App gives you all the control over your electric vehicle from anywhere.

7. Single Customer Experience
And customer experiences are critical, even for the Internet of Things. That’s true with BMw. APIs have turned into an ecosystem around IoT to build some great customer experiences. If you take an API First approach, the APIs you use for something like your car, or maybe charging stations, can be reused. BMW drivers can open up a map of amsterdam and see which charging stations are free. That’s a mashup from APIs from each of the charging station vendors, including Essent, another API management customer. They can map out how to get to the charging station within reach of their charge. They can then walk around and watch how much time they have left to charge. And they can get information from other APIs as part of that experience. Agence French Press, another customer, feeds batch-based feeds as real-time feeds into BMW cars using APIs.

8. Netflix has shown the way… Reactions Adrian Cockcroft received.
“You guys are crazy! Can’t believe it”
-2009
“What Netflix is doing won’t work”
-2010
“It only works for Unicorns like Netflix”
-2011
Adrian from Battery Ventures (formerly Netflix)
“We’d like to do that, but can’t”
-2012

9. Enterprise IT Adoption Cycle
- Simon Wardley

10. A mandate for change!

11. Digital Business in API Terminology A Simple, Stateless Message
{“API”:“First”}
{“API”:”Microservices”}
{“Microservices”:“Change”}

12. Digital Business in API Terminology A Simple, Stateless Message
{“API”:“First”}
{“API”:”Microservices”}
{“Microservices”:“Change”}

13. APIs Must be Useful
"The value of a well-designed object is when it has such a rich set of affordances that the people who use it can do things with it that the designer never imagined.”
Donald Norman

14. What is API First? Involved in most new projects
B2B
Mobile
Cloud
IoT
Social
Big Data
Lead with APIs by default

15. What is API First? The API is the Contract The API is the Product
What does it mean to be API First?
I’ll make a claim … over the next few years most of your integration projects will require APIs. According to Gartner 2/3 of your new integration will be either across or completely outside the firewall. 2/3 will be driven by businesses more than IT. It’s being driven by all the demand for mobile, cloud, big data, social, and new integration with partners.
For me, API First means leading with APIs in these projects. Because if you don’t, you won’t be able to reuse the APIs across other projects. And you need to get started on APIs now.
Now, Accenture had an interesting point about API First, which is why I included their slide here. APIs are a project. In SOA you knew all the endpoints. They were apps. But with APIs, you don’t know who’s going to consume the APIs. Anyone could across different projects. SO you need to design it to be easily consumable, self discoverable and documented. It’s a product. And how you define the API is your contract. Once “customers” start using it, it’s fixed. So being API First also means thinking this way about integration and APIs.

16. Making API First Work
NAB is also great example of how companies launch new digital business initiatives. They were one of the earlier innovators who built out the maturity model that eventually became what Accenture uses in their practices. They laid out a roadmap where they defined their core private APIs, how those mapped to public APIs, and since started to put in place their governance processes.
Then they found some pretty innovative mobile apps on top of it as part of their multi-channel banking initiative, like Flik, which replaces purchase orders with QR codes that get sent via a mobile device. To pay, you scan the QR code on your device. This came out of hackathons. It came out of ideas from the outside world. That‘s what we mean by living in the API Economy. That you provide APIs, consume other APIs from the outside world, and you or others create some great new customer experiences.

17. Digital Business in API Terminology A Simple, Stateless Message
{“API”:“First”}
{“API”:”Microservices”}
{“Microservices”:“Change”}

18. Introducing Microservices
“…the microservice architectural style.. ..is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. …”
Martin Fowler

19. APIs SOA/ESB API First vs SOA API Management The API is the contract
…And the product
“This is what I need…”
“Here is what I have to offer…”
WSDL is the Contract
Backend App is the Product
That’s not to say that SOA and APIs don’t fit together. Most of the time you have to make them work together. But you do need to understand the difference.
When you’re creating APIs you need to create what the customer wants out of what you have, including SOA. So there’s an outer API, a public API that is that contract. On the other hand you have internal services and backend systems. By themselves, existing Web services might be enough. But somehow you need to have this magic in the middle that lets you change functionality fast without impacting the public API. And that’s partly what API management does.

20. From SOA to API First
:et me give you an example. National Australia Bank started with SOA and existing services. They built three layers. The first was security. The second was a layer of outer APIs with business logic. This was the contract. But underneath there’s this layer of “inner APIs”, or private APIs. Some people call these microservices. People are still getting used to the word. It basically means small services. They broke down the logic to be small enough, and divided enough that they could change only a few of these services at a time and deploy the changes REALLY FAST to support dev ops, which was about being agile.
Then there’s the translation between some of these inner and outer APIs. The layer in the middle is often called service virtualization.
So API First is one thing you need. The other is to live and breathe the API Economy

21. Digital Business in API Terminology A Simple, Stateless Message
{“API”:“First”}
{“API”:”Microservices”}
{“Microservices”:“Change”}

22. Microservices Focus on Change
Public APIs:
Better Customer Experience
SOA:
Better Apps + Integration
API Management
The API is the contract
…And the product
“This is what I need…”
“Here is what I have to offer…”
WSDL is the Contract
Backend App is the Product
That’s not to say that SOA and APIs don’t fit together. Most of the time you have to make them work together. But you do need to understand the difference.
When you’re creating APIs you need to create what the customer wants out of what you have, including SOA. So there’s an outer API, a public API that is that contract. On the other hand you have internal services and backend systems. By themselves, existing Web services might be enough. But somehow you need to have this magic in the middle that lets you change functionality fast without impacting the public API. And that’s partly what API management does.
Microservices: Improved Developer Experience

23. Legacy Enterprise Applications
Web Client
Backend Server
Data Storage
Mobile Client
Taking a step back
Other Clients
Other Clients

24. The Backend Was Still Monolithic
Tightly coupled
Monolithic scaling
Backend Server
NOT sure we want to cover this…

25. SOA brought separation, but little empowerment
Course grained, reusable, more scalable services
Coupled through orchestration
Still common servers, DBs, data
Service
Service
Backend Server
SOA defined a set of affordances – but they are not easily understood.
The data is still coupled and monolithic. The services are still coupled.
Service
Service

26. Microservices brings developers
Why SOA?
Break the monolith
Integrate legacy apps
Scale & Reuse
Why Microservices?
A platform for the business
Agility
Not tied to servers, tools, DBs
Backend Server
Service
Service
SOA brought services, but little empowerment
Separable elements of functionality become services
Scale & reuse services as needed
Ensure architectural (API management) consistency
API contract: common way to discover, learn, test, promote APIs
Governance: lifecycle management, runtime (policy) management
Service
Service

27. Build it, Run it, Own it SOA Services are seen as projects
The team moves on when the scope of that project is delivered
Microservices and their APIs must be managed as products
Product team owns their service from conception to retirement
In a SOA world you already knew what you were building for. Today you need a platform that can support apps & integration we don’t have requirements for yet.
SOA was the answer to IT integration. API Management is about improving the customer experience

28. Public APIs: True Loose Coupling “Smart endpoints, dumb pipes”
Simple and stateless (RESTful)
Little coupling to a process (unlike Web services)
Designed outside-in based on how it’s consumed (product)
Bullet proof
Built-in error handling/checking
Designed from the outside in (product)
Very slowly changing, insulate from underlying change
Self described
Standard web API documentation (e.g. Swagger)
Easy to use repository (search, etc.)
Self testing during learning process
All reuse configured not coded
Security, identity, composition, policy/SLA, auditing, analytics
SOA was the answer to IT integration. API Management is about improving the customer experience

29. Microservices (Private APIs): Agility
Platform agnostic
Support servers, tools, languages, DBMSs of choice
Constant change (daily)
Bounded code/products (microservices and APIs)
Bounded, independent teams owning “products”
Dev Ops approach from development to operations
Lightweight communication across containers
Automated testing, deployment
Self service (versus governance)
Self service, delegated ownership
Governance processes tailored for self service
Delegated control over “configurable” attributes

30. Design Security Assuming it’s Public
Threat protection (e.g. OWASP top 10)
Identity management (AAA, Oauth 2.0, Mediation)
Don’t assume internal or private access
Auditability, compliance
The Real Firewall
Backend Server
Service
Service
Microservices
Service
Service

31. Trust, Visibility Policies/SLAs The Real Firewall Backend Server
Service
Service
Microservices
Service
Service

32. Key Takeaways {“API”:“First”} {“API”:”Microservices”}
{“Microservices”:“Change”}
Getting Started
Security
Public APIs
Microservices

33. Q & A

34. Obrigado! Microservices under the microscope
Microservices under the microscope: how an API First strategy is helping businesses become truly digital
Web APIs are the new de facto approach to architecture integration for all innovative digital business applications across cloud, mobile, B2B, big data or Internet of Things (IoT) technologies. For many of these projects, enterprise architecture and service delivery is adapting from an "inside-out" model towards a microservices and API First approach, which offers greater flexibility and agility around core IT services. In this session we investigate the promise of microservices, and consider how they will work in real enterprises with existing applications, complex SOA environments and strict organizational or governance structures.
Thanks,
QCon – São Paulo
#APIFirst
@rdmeyersf
March 24, 2015