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

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

Digital Business Changes Everything

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

Digital Business has no Speed Limit

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.

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.

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

Enterprise IT Adoption Cycle http://blog.gardeviance.org/2012/07/adoption-cycles.html - Simon Wardley

A mandate for change!

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

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

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

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

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.

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.

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

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 http://martinfowler.com/articles/microservices.html

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Q & A

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 #API @axway March 24, 2015