Microservices, APIs, and the Autonomous Web (transcript)

It’s good to be here, I am so happy to be returning to QCon in Sao Paulo. I love coming to Brazil, I was just in Sao Paulo last month to visit with some customers, and I always have a great experience. So I’m very happy to be here and I’m happy to see so many people here today. So I travel a lot and this is the best way to find out where I am. So this is how you find me on Twitter, and LinkedIn, and GitHub. And I traveled last year I think it was 40 weeks I was traveling, this year I’m trying to cut it back, maybe 35.

So I have a hard time remembering where I have been, so I need your help just for one moment, I need evidence that I have actually been here today. So maybe if we can all just say hello, hola, very good, okay, now I’m done.

Okay, so as I say I’m very happy to be here, I work in a group called API Academy. It’s a very unusual group, we have six people scattered around the northern hemisphere that travel all through the world. And we speak, and we listen to customers, and we share our knowledge, and we do this in lots of different ways, and one of the ways we do it is through publishing. So this is our website and the most recent book our group published is about "Securing Microservice APIs," it’s a free book. So if you visit the website you can download this free e-Book.

Another project that we worked on two years ago was releasing this "Microservice Architecture" book with O’Reilly. And also CA does sponsor a free download, so you can also download this book, this is about 150 page book. We are currently working one on API management, which we hope we will release by the end of the year. So this is a big way that we collect information from customers and then share that with the public, and that’s really our mission.

So that’s really what I’d like to do with you today, I’d like to share with you what we’ve been seeing over the last few years, and how we think we see something on the horizon. It’s something new, it’s something different, a big challenge, and a huge opportunity. So I wanna talk about a few things, I wanna talk about programming the network. Most of us here have been taught to program a machine, one machine, we have languages, and tools and all these other things that are geared toward testing and running everything on one machine. The problem we have facing us is that what we need to do is program the entire network.

We need to be able to use every part of the network, every machine on the network no matter where it is, and engage it dynamically, so this is a much different problem. Now on the machine front and on the local network front, inside companies we see lots of work on microservice, to try to make some of this better and related things. We also see lots of work on APIs in order to make those microservices available in lots of places, maybe on different networks using different protocols, maybe even in different formats than original.

What we see now more than anything else is the beginning of creating autonomy on the network, creating services that can actually make decisions for themselves. And I’m not talking about artificial intelligence, but literally talking about a component that when it starts, can dynamically enlist all of its dependencies, doesn’t have to know them ahead of time. They could move, they could have changed, and can actually work on a goal to solve a problem that only that machine knows, that none of the other services understand.

Most of us today we write APIs and services and client applications just for one company, this is my Salesforce API, this is my SAP API, this is my own company’s API. The big challenge is being able to enlist all of those APIs in one solution known to one machine. And I think that’s the next big thing that we’re seeing, we’re seeing people start to deal with this problem of how do I access other people’s APIs? And we’ve seen them in various ways. And in fact, before I start on this idea that we’re seeing, I wanna just remind us a little bit about how powerful this idea of the web and the internet has become.

So in the year 2000, almost 20 years ago, lots of things were going on. The Game Boy was big, right, very big. This was my phone in the year 2000, this was the first GSM enabled phone, it came out in 2000. And then there was this man. Who knows this man? Roy Fielding, both the hero and the enemy of all of us. So he has this notion to start talking about the way the World Wide Web portion of the internet works.

And he talks about it in this cooperative independent way, he talks about independent deployment, see that sounds familiar. He talks about independent components that operate on their own, and that can be changed while they’re running without disturbing the rest of the system. And he talks about inserting intermediaries to mediate between various servers without anyone ever knowing. And he talks about generalizing the interface and scaling. All the things that we talk about now all the time, this was almost 20 years ago. In fact, the very first paper he wrote on REST was in 1998.

There was another person for which 2000 was a big year, this is a person who had a really cushy, comfortable job at Oracle earning lots of money. He’d been at Oracle for almost 15 years, and he had a great future ahead of him, but he left Oracle to work on a rather sketchy, rather unsure project with three or four of his friends. He wanted to automate things, he wanted to make it easier for people in his line of work at the time which was selling, he was selling computers, he wanted to make it easier for them.

So he and his friends started this tiny, little company called Salesforce. Of course, it didn’t look like that in 2000, it looked like this in 2000. Just sign up for an online Salesforce automation, this was a crazy idea. He basically said we’re gonna get rid of installing software in the year 2000. The first solution that leverages the internet, he thought of how we could start using the internet in a unique way. And in fact, Salesforce is really recognized now as one of the first software as a service company, they’ve been at it for almost 20 years.

They were one of the first to monetize APIs, one of the first to charge per transaction APIs and make millions upon millions, upon millions of dollars. They’re still seen today, as a powerful force, as a matter of fact, they’re valued at more than $90 billion in just a matter of less than 20 years. That’s pretty amazing and they’re built on this notion of APIs.

I’m gonna jump ahead a little bit to the year 2006, that was another important year because in 2006, an open source project was launched called the Mule Server. And Mule Server wanted to take Salesforce one step better. Here’s Ross Mason, he was one of the founders of MuleSoft, they wanted to provide integration software, connection software to connect lots of other APIs. Now a lot of people had done this before, what was unique about MuleSoft is they wanted to do it on an open source platform on the web itself, not inside a company.

Jump ahead 10 years, they opened an IPO, they raised lots of money, they raised up to $200 million, they’re estimated to be worth $3 billion in the first year, this was just 1 year ago. And what happened just last month? They created this idea of a platform as a service, they have this notion that they are not just the software but they’re the platform on which the software runs, and for that Salesforce buys them. Salesforce buys them for $6 billion.

That’s a lot of money for MuleSoft, they’re not buying the revenue of MuleSoft, they’re buying something else. What are they buying? What does Salesforce see in offering 20 times the value of this company to purchase it? And what I think they see is the power to monetize not just their APIs, but all of our APIs, the next big step.

Now I haven’t talked to Marc Benioff or Ross Mason about any of this, so what I’m telling you is what I imagine what I think is on the horizon. I don’t know this for a fact, but this is something that we’re seeing our customers talk about as well, how do we deal with other people’s APIs? And I think Salesforce maybe on to something. I think they’re onto the notion of the possibility of programming the network. Now I’m not sure if this will work, there have been other companies that have tried to do this, but I don’t think anybody as large or as experienced as Salesforce has tried it.

I love this quote from Pat Helland, Pat Helland worked at Microsoft, and then he worked at Amazon, and now he works at Salesforce. And he says, "There’s no simultaneity at a distance, the network is a problem." Physics halfway around the globe, latency, all these things, we’re not gonna beat that problem. The smart companies make the network their superpower, they figure out how to use the power of the network rather than ignore it, and pretend like it doesn’t exist.

So much of our software has always taught us we should just pretend that it’s just a function, that it’s just executing locally, but then it turns out nothing runs well, everything’s got high latency. One small thing breaks, the whole thing breaks. The people who understand programming the network have gone beyond trying to treat it like a machine and treat it like its own.

So let’s talk a little bit about programming the network, we actually have all the bits and pieces to start programming the entire network if we would just pay attention. So we can send data, we can establish a network of machines, and we can create solutions that run on that network like Salesforce, and SAP, and Oracle and all these other things.

One of the cornerstones of the network is this thing called TCP/IP. TCP/IP is the thing that we sort of ignore that we don’t really care about, UDP is another big one. But it’s the notion that what we’re trying to do is deliver packets from one place to another. And there are some really amazing things built into the TCP/IP protocol, and that includes the idea that if the packet doesn’t get there, I’ll send it again. And even more importantly, it was built on the notion that if I receive a packet, and it’s not quite right, if I can still figure out what it was supposed to be, I’ll use that rather than reject it.

This is a key principle that underlies all of our network, and that is I wanna be generous in what I accept because if I rejected everything that was not quite what I understood, I would reject most of the traffic that I receive. And then we couldn’t build the internet the way we built it today. Instead, I’m gonna be generous in what I receive and strict in what I send. I make sure I do my best to send a proper packet, my best to send it correctly so that nobody has to work extra hard.

In fact, this idea is called the robustness principle, be conservative in what you send and liberal in what you accept. Jon Postel who is really the shepherd of a lot of the initial internet standards wrote this into the TCP/IP specification. "Be conservative in what you send, and liberal in what you accept." Those of us who use schema to accept a message are breaking this principle because if I use the schema and say, "I’m sorry, those aren’t in the order that I was expecting, I’m gonna throw it away." I will throw away most of the traffic. Instead, if I use schema on the way out to make sure that that packet is built correctly, that’s the robustness principle.

So this notion of accepting things and working with them as best I can before I throw them away is a key element in programming the network. And it’s a challenge for a lot of the companies that I work with because they want everything to be perfect the first time, it’s never perfect the first time. And instead they reject things and then they have meetings, and they have lots of reviews before they can release anything because they wanna make sure it’s all perfect. That’s not how life works and that’s not how you scale on the network.

Now, another system that’s really been important in the last 30 years is this thing of HTTP. HTTP is what’s called an application level protocol, not like TCP/IP which is a data level protocol. One of the amazing things about HTTP is it actually tells you ahead of time which statements are read statements, and which ones are write statements, right? Get is read, post, put, delete, patch, those are write statements and they have different rules.

As a matter of fact, most of them are idempotent rules, that means that I can repeat the thing over and over and get the same result, get is idempotent. Put is idempotent, delete is idempotent, I can repeat it, but I can’t repeat post. Post is not idempotent, if I do post twice I’m likely to add two things to the system, charge your account twice, if I do put twice, I’m only gonna charge your account once.

There are very few protocols that have this power, there’s power to actually tell me what’s safely repeated even when I’m writing data. Many of my customers ignore this power, use for instance soap, which only runs over one function on HTTP, post, which is not safely repeated, and not cacheable. They actually make things worse. What’s another practice today that does the exact same thing that is built to use only post to do everything and ignore caches, and ignore repeatability? GraphQL.

Let’s make sure we don’t make the same mistakes and ignore one of the more powerful features of HTTP. The internet was built on this notion of understanding just how dangerous things are. When you think about a machine, a computer, or a bot, how is the bot gonna figure out if it needs to repost if it doesn’t get a response? It’s gonna be very hard. But a bot could easily put a second time. So we have the seeds of autonomy built into this protocol, there are lots of other features of HTTP, we won’t get a chance to talk about now.

"It was designed for distributed collaborative information systems based on hypermedia," according to Tim Berners-Lee. Notice it’s not designed to solve a particular problem, it’s designed to solve a class of problems. Right? So we can build all sorts of solutions and in fact, we have, we started from simple forms, and forums and comments 15 years ago, to now we’re actually running entire email systems and my presentation system, and everything else is being run using HTTP, that’s a powerful, powerful protocol.

So one more big part of this HTTP is based on sending messages back and forth over the same four or five functions. Everyone on the planet uses get, put, post and delete and they can build any software they want. They don’t need a special function name, they can do it with just these four or five or six. That’s pretty amazing.

The last thing that we learned in this process of programming on the network is the languages that we use to program in. We don’t use JavaScript to program the network, we use HTML to program the network. We use JavaScript as polyfill for all the things that HTML doesn’t do or that other browsers don’t do. Right? Like tabs, suggest, all these other things that it doesn’t do. HTML is the language of the web, and HTML is declarative, not imperative, it describes the entire problem, and the entire solution all at one time and lets someone deal with it. Somebody renders it, and then we can have humans interact with it or the machines.

HTML is incredibly powerful because HTML has changed 6 or 7 times in the last 20 years, and we can still run all of it. The very first HTML page written in 1998 still works today on every browser even though we’ve changed HTML time and time again. We don’t even know anymore if we’re getting an HTML 4, an HTML 5, XHTML, we don’t even know when we look in browsers anymore because that problem’s been solved. In fact for HTML, and HTTP, and TCP/IP, all of them have changed over the last 25 or 30 years and nothing’s broken.

We’ve known for more than a quarter of a century how to improve software time and time again without breaking anybody, yet most of the companies I work with don’t do this. Instead, they break their customers, they break their apps, they break their clients repeatedly.

So HTML is a standard markup for creating apps and pages, it was originally designed to create web pages and it’s great for that. It’s not very good for creating apps. Most of us have to fill it in with lots of JavaScript and CSS in order to get an app working. And that’s a challenge, it’s been a challenge for a while. There have been some people working on solving this problem, creating what amounts to the HTML of the application space. And their new declarative languages like HAL/S which is used by Amazon, Siren which is used by Google and Apigee, Collection+JSON, Uber, Mason, there are several other of these formats that are now designed specifically for solving the next big problem.

In fact, they’re all based on these three things we’ve talked about, so I wanna talk about them in a slightly different way. I wanna take the tech away and not talk about TCP, not talk about HTTP, or HTML. But I wanna talk about them in more general terms, what I call these levels of system design. Designing the functionality you want, the bits and pieces, the things that actually work. Designing the intentionality. What is the thing I’m trying to do? I’ve got all these bits and pieces, how do I plug them together? How do I actually do something?

And then finally, how do I make this autonomous? How do I create a space where other people that I’ve never met, other software, other servers, other machines, that have never interacted with me before can meet up, connect, bind, and actually solve a problem without human intervention? The good news is we have all of the tech we need for that, we just need to design it in, we just need to build it in.

So functionality, this is something that’s fit for purpose, practicality that works, and functionality for us is microservice. Microservice is the function, is the work that we need to do, in fact, most of the discussions around this space is the idea of making the services smaller so it’s easier to find the functionality you’re looking for, and easier to modify and change it without breaking everything else.

We say loosely coupled components in a resilient engineered system. And there are lots and lots of training lots, and lots of tools for designing loosely coupled components. Things like domain-driven design which has been around for about 10 years. There’s lots of things for creating resilient engineered systems like containers, and Kubernetes, and all these other things. These are all at this level of functionality, and they’re very powerful, but they only take it so far. They make it easier to make sure system’s up and running, easier to define a boundary, easier to deploy and release, easier to fix, easier to replace but that’s just at the functionality level.

I love Michael Nygard’s quote, "Bugs will happen. They cannot be eliminated. They must be survived instead." As a matter of fact, there’s a big space in the DevOps movement that talks about this idea of safety one and safety two in a system. Safety one in a system is to remove the bugs, take all the bad things out. You know, we can’t take all of them out, sometimes we have to stop. Safety two is to put enough code in the system to make sure that it survives the bugs, that people can’t abuse the code, that people can’t log in incorrectly, that buffer overflows don’t happen, that I can’t flood a service, that the service won’t do something it’s not supposed to do.

Safety two is how real life works, safety two is in our car. If somebody sells us a car, they cannot prevent us from getting into an accident. But we have lots of safety two around us, the car itself, the way it’s built, the brakes, the lane controls, the stop signs, the lights, all these other things, that’s all safety two. Many of my customers continue to try to build safety one systems, and they will never get very far because it doesn’t scale. We need to focus on building safety two systems, systems that survive.

There’s a great quote, I can’t remember who gave it to me, "Healthy systems continue to run even when they’re in failure mode." Netflix talks a lot about this, Google talks a lot about this, there’s lots of possibilities. I would encourage you to read Michael Nygard’s book, "Release It," he talks about a series of capabilities in there that many customers that I work with, and many companies like Netflix and others are implementing. I call them stability patterns. So you’ve heard of some of these, timeout, circuit breaker, bulkhead, steady state, fail fast, and handshaking. These are all principles for implementing a safety two type microservice.

Timeout basically means, look, I’ll give you so much time to respond, if you don’t, I’m just gonna ignore you, right? Don’t get caught in a system where you’re stuck. Circuit breaker is if you’re not responding, I’m gonna stop talking to you, I’m gonna give you a minute, I’m gonna start talking to somebody else instead, and then I’ll switch back. When the heat gets too hot, the circuit breaker flips, I go do something else and then I go back.

Bulkhead is basically the idea of a proxy in front of a series, right, a set of services that all are copies, if one goes down, you can still talk to the other ones. Steady state, it’s a big problem we have, right? So anybody writes a logging system, anybody writes data records to a disk, do we ever check to see if the disk is gonna run out someday? Often we get bugs and we’re like, "Oh, I never realized I left logging on, I ran out of disk space."

There’s a great story, John Allspaw who works at Etsy, has this great exercise, he gets all of his engineers in a room together and he says, "If you could restart your system today, how long would it…and never touch it again, how long would it run before it crashes?" How many things do we do to make sure that humans are actually feeding this beast? We’ve gotta back up the logs, we’ve gotta move the thing, we’ve gotta restart the server every Thursday, so on and so forth. Creating a steady state will make it stronger.

Fail fast is even better, fail fast is the reverse of timeout. You asked me to compute a really complicated logarithmic equation, and you tell me you need it in 500 milliseconds. And I look at my history and I say, "You know what? It’s gonna take me 600 milliseconds." No. I don’t even waste the 500. I say no. Fail fast is a great way to make sure that you don’t get flooded with services, and that you can’t respond to. It’ll also make sure that you don’t get picked on by another service that keeps demanding more and more, you just say no.

And handshaking is this whole notion of making sure everyone’s up and running. In TCP/IP we have all these acknowledge, no acknowledge, send, and so on and so forth. On the web, on the network, what we use is health checks, we ping the endpoint every minute or every 5 minutes or every 10 minutes and we check the health of that system, always checking the health of that system. So Nygard’s stability patterns are a key to making this network work.

And then we have this idea of intentionality which is actually a philosophical term, this idea that I’m going to have a purpose and a deliberate thing that I need to do, that’s what APIs are for, APIS are a way to do a particular thing. We might have to enlist several bits of functionality in order to solve a problem like customer onboarding, or a process for approving a loan or something like that. We use APIs to create this space, APIs assemble all these pieces.

The biggest word in that application programming interface is actually interface, we’re designing the interface. We don’t need all the services to understand the interface we’re designing, we’ve been doing it on the front end for years, right? We understand it’s important to design a good interface, that’s the right buttons in the right place, that doesn’t make us angry, that doesn’t make it easy to make mistakes. We design interfaces for humans and we test them with humans.

That’s the same thing we have to do for machines, we have to design interfaces for machines, which are very different than humans. Machines can do repetitive tasks over and over and not get annoyed, humans get annoyed. Machines don’t have a long-term memory, machines can’t handle 17 steps and then submit once, and not make a mistake, that’s too hard, humans do that all the time. Instead, machines do lots of little things that all add up to finally being the one commit that we do, right?

So designing the interface is incredibly important because APIs are the thing that unlock the business value inside your company. They let you create new apps without having to build new services, identify new revenue streams from the data you collect and the way you use that data, maybe even initiate new businesses in countries where you can’t reach because that API can reach there. APIs are what actually make your company connectable to the rest of the world, and the quality of those APIs, the design of those APIs, it’s essential.

I love this quote from Donald Norman, Donald Norman is one of the founding fathers of human computer interaction. He has a great book called "The Design of Everyday Things." If you haven’t read it, I encourage you to read it. Here’s a quote from one of his lectures, "The sign of a well-designed object," you could say well-designed API, "is when people who use it can do things with it that the designer never imagined." Oh, I didn’t know you could do that, that’s a well-designed object, that’s HTTP, doing things that the designer hadn’t imagined.

Our APIs need to be not just solving one problem, but allowing people to stitch them together to solve problems we don’t know about. And they need to be able to do that without ever meeting us, without ever talking to us, without having a meeting before it’s released. That’s good API. APIs make interaction easy, and while APIs today are primarily focused on making human interaction easy, APIs for client apps, the future is making interaction easy for machines. So machine to machine interaction means machine to machine languages, machine to machine formats, machine to machine interaction flows that are not like humans at all.

I often talk about with my customers this notion of, you know, the Disney movie, Pet, do you know this idea? That you have a Disney movie and there’s a pet cat and she can open the refrigerator, and answer the phone, and walk along a skinny little rail and all these tricks, right, there’s seven or eight tricks. That’s not one cat, sorry, it’s seven cats. One cat does each trick, they all just look alike.

That’s the secret of the movie business, and that’s the secret of autonomous web, there isn’t just one client, there isn’t a client monolith, there are lots of little clients that do just one thing and one thing well and connect with lots of other clients that do things. Making interaction easy lets us string these together in a safe manner. So that leads us to this notion of autonomy, what we can do, what we have freedom from external influence, we have independence. How can we safely create independent services? And I’m telling you, you don’t need artificial intelligence for this.

So I’ve been working for several years on a set of patterns for autonomous APIs, in fact, I think I gave one of the very first talks on these autonomous patterns here in Sao Paulo maybe two or three years ago. And we don’t have time to talk about all of them, there are some patents for design and principles. I wanna focus on the patterns for shared agreements. What happens is when I write software, when you write…like one server, and one client, it turns out they talk to each other, they actually flip roles now on the client, now on the server, now on the client.

They’re just interactions, they’re just interactions. And having shared agreements on these interactions is how we create this autonomy. So I wanna talk about four of those patterns that can give lots of autonomy and still maintain the safety two environment that we talked about earlier. The first one I call is use related. So it turns out there are lots of possible things to do, I can do like five things right now, the problem is listing five things every time is really wasteful. It’s like explaining to you every time I see you, "Hi, my name is Mike. These are all the things I know." It would take a lot of time because I’m really smart.

Instead what I’ll tell you is a few basic things. "Hi, I’m Mike. I’m from Kentucky," right? And if you want, you can say, "You know what?" You can also ask me other questions. And if you click on the related then it goes back and I’ll tell you all the possible things you can ask me. In other words, what I’m gonna do is give you the most common possibilities, the most common interaction steps at this point for clients that use the software, but if that’s not good enough, ask for all the related ones and I’ll see if you can find it.

This notion that we create bots that kind of like scurry around and figure out every possible angle, and follow every lead, they don’t do that, that is a waste of time. You do the most common things, the most efficient things, and if you don’t see that, then you ask for the rest. And in fact, if you ask for the rest long enough, that will become one of the more common things. So this use related pattern makes it possible for you to efficiently respond to customers, the clients, the apps, and also give them extra detail when they ask for it.

So services should return a related link that responds to all the possible actions, this is one of the patterns. So here’s a case where it says, you know what, there’s a couple of things here, self and approve, if you don’t like approve, you can go to related and get the whole list of things. Now maybe there’s more things, approve and cancel, and modify, and transfer, and review, and rush. Now maybe I’ll find the thing that I’m looking for. This is exactly how it works in real life, if you’re looking for something, you look in the obvious places first, and then you start looking in the not so obvious places. So that’s what it gives us a chance to do.

Now machines can look up the available affordances and opportunities, and we didn’t have to do anything. And writing this into the client is simple, it’s a simple one line statement, if you don’t find what you’re looking for, go here.

Now the big one is navigation, humans do this all the time, and we can make navigation easy for machines as well. We can allow machines to move forward and back and a list of things to do. Machines will do this all day long and not get bored because that’s all they do, that’s all they worry about. We can also offer things like cancel, and done, and restart, all these steps along the way that we can make standard in the way we interact with things.

So we can offer next and previous, and we can even offer things like cancel, and restart, and done. And we can teach our clients this order, once I’m in a next previous workflow, I have these other options available to me. I can supply you information from my memory, from my database, maybe on the bot that searches for Mike’s favorite shirt on the shopping website, that’s fine, I’ve got all the data I need. And I can go through this multi-step, and I can even change the list of steps dynamically or over time without breaking the client. So here we have a client that says, "Look, these are how you handle all of the steps, if you get to them, done, and cancel, and restart, and previous, and next, and all those things." And it’s relatively easy to write this kind of code.

Now the choice making about when you do something is another matter, but you can program that in just as well. What happens behind done, and cancel and restart, and all those other things can grow over time. Machines can now navigate a long series of steps safely, and those series of steps can even change over time and the machine can still work. I only need to know five or six possible things in order to get through this problem.

And that leads to another big one, partial submit. Partial submit is this idea that the server wants A, B, C and D, but I only supply A and B. So then the server says, "Okay, well, you’re almost there. Give me one more thing." Instead of rejecting the whole set, it says, "Give me the thing that’s missing," and machines are great at doing this. You can now partially fill in a form and keep submitting that form until it gets to the right place, or you wanna cancel, or you’re done, and you can teach a machine to do that. That even means that you can dynamically change the list of inputs over time and the machine will still work.

So here’s an example. So here is that dangerous post and I supply the inputs, and if I get needed inputs back, if I get a, "Hey I need some more inputs," then I go ahead and generate the form with the inputs as well as a series of actions, and then I can respond. And I can do this over, and over, and over again until I get to where I want. Now I can interact in small parts, I don’t always have to be perfect and I can actually learn over time what I need to supply.

Finally, there’s this last one, state watch, this is a tricky one, it’s basically this idea of signal, sign, and symbol. Signal is the data, sign is what the data is supposed to represent, like this value of minus one may represent the temperature inside a refrigerator unit. And symbol is the meaning of what minus one is, if minus one is too cold for the vegetables, that’s the symbol. It symbolizes that I need to do something.

Signal, sign, and symbol, we deal with these every day but getting a machine to think this way is not something that people commonly do. Typically what we need to do is we need to allow machines to say, look, I’m paying attention to this temp variable Z, which is the actual temperature inside the refrigerator, please always respond…all your responses tell me what that temperature is. Now the service doesn’t need to know what I’m going to do, how I’m gonna treat that whether I’m gonna treat it as a signal, sign, or symbol, it just needs to supply that to me.

That means that I can create a smarter and smarter client over time without rebuilding the refrigerator, or changing anything of its software. Now what I can do is create watch values, I can say I would like you to send me this information back and I’ll decide what to do. I’ll decide when to turn up the temperature, and when to turn down the temperature, when to tell my human handler that something has gone way wrong, I think somebody left the door open. I can decide that myself, I don’t need a service to do that for me. Clients are now actively participating in solving the problem rather than just dumb followers that just follow the links they were told, or do what they were programmed to do five years ago.

So now we have this case where I say, look, I’m gonna send this change of data that changes the sensor by increasing it, and I want you to state watch me both the sensors and the temp 13 device because that’s the one I’m interested in. So I get the information back about these devices. Now machines can set their own goals, now machines have autonomy by combining things like the use related that lets machines decide if they don’t get information enough. By using things like navigation which makes it possible for machines to go from step to step without having to restart.

By using partial submit to allow them to interact on a step by step basis, and then finally letting them set the variables, letting them decide what’s done, we add a great deal of autonomy without even starting with machine learning. And machine learning just makes it all better. We can do this today and add machine learning to the results to improve the interactions even more.

And that leads to this last element, what we really need to do is figure out not just how to do this, but how to do this without losing money, and in fact by making money, by monetizing APIs, by monetizing the future of interaction. So the big talk in business today, this is from "The Wall Street Journal" is that APIs and all the technology around it, microservices, and DevOps and all those other things, have moved from just an IT issue, a back office issue, a money-saving issue, to actually being the engine of commerce.

Salesforce wouldn’t exist if it wasn’t for APIs, that is their business. It’s not an add-on, it’s not how they make things run smoothly in the backend, it’s how they actually make their business run. Twilio, and Etsy, and all these other sites that only exist online have no brick and mortar, that is their business, their business is APIs. Even Amazon, they can make more money from the API side, from the processing side, than they do in the sales side, from the book side. The books was just a way to get enough capital going so they could pay for rebuilding the entire set of infrastructure.

So business is incredibly important, when it comes to APIs and services most of my customers think it looks like this, they look at every machine in their company, every server, every client, and they wanna control that space, and they wanna monetize that space. And if anything what they wanna do is build enough APIs so they can face that business outwards so that other people can use their APIs for their business. That’s a great strategy but it’s actually a strategy that has limits.

And the big problem is that all you can do is focus on who you can control and what you can control. You create APIs for your business but not for anybody else’s, and then people build apps for your business and not anybody else’s. And then you collect customers and you profit from that, as long as you’re in business, and as long as they’re using your API, and as long as you’re using clients that know your APIs, you’re okay. But you’re an isolated system, you’re an island standing alone.

In fact, most companies today are focused on monetizing their own APIs, which is a fine strategy, it’s a good strategy. Many of my customers haven’t figured out yet how to do this. But the thing is people are already working on the next big thing. They’re already getting past this, they don’t think about that set of network computers inside their company, they think about this. This is a snapshot of all of the connections of Wikipedia to various servers and server firms around the world, this is just a one time shot. In fact, the network is gigantic, and the network changes every single day.

And the network adds more machines and takes away machines, and adds functionality and takes away functionality every day. This is where the APIs need to live, not inside the company but on the network. When you focus on the network you have to focus on an open system, a system where you focus on what you can offer, not what you can control, because you can control nothing. It’s just like the traffic we talked about earlier, I sell you a car, I can’t keep you from crashing. I offer you an API, I can’t keep you from doing what you wanna do with it. But I can protect my API, and I can protect my users and my data, something we’ve been terrible at over the last 10 years.

I can create APIs that express my business intentionality, the things that we’re trying to help you do, like Salesforce is trying to help people do, automating the sales process. But then you can use them for whatever you wanna do, you can build other things with them. You build apps that have their own autonomy, that solve their own set of problems, not just your problems. Clayton Christensen has this great line, he wrote a book, "The Innovator’s Dilemma," and he said, "People are not interested in your product, they’re interested in their problem."

My problem is I wanna hang a picture on a wall, if I have to I’ll buy your drill but I don’t really care about drills, I care about my picture. If I can hang my picture some other way I will. When you understand your customers' problems, you build things differently, you give customers the autonomy to solve their own problems and maybe solve problems with the tools that you’ve given them in ways that you hadn’t imagined.

So focusing on what you can offer, not what you can control, using APIs to express your intention, your purpose rather than just your solution. And building apps that have autonomy, so that they can integrate with lots and lots of other intentional services offered by others, that’s the next big deal. The companies that are focused on this, are gonna monetize other people’s APIs, they’re gonna go beyond theirs to other people’s APIs. And that’s what I think Salesforce is doing, I think Salesforce is focusing on how to monetize other people’s APIs, and they wanna use the MuleSoft platform to do it.

So we may be looking at, just as Salesforce represented that first big step in monetizing APIs, we may be looking at that next big step in monetizing other APIs. I’m not really sure yet, there are lots of pitfalls to this, this is not the first time this has been tried. There are companies even today that try to be the proxy for everyone else’s APIs, and they haven’t figured out how to scale it. They’re actually building a giant closed system rather than an open system.

But the people here, the people in this room, you have the power to build an open version of this, just like Tim Berners-Lee built an open version of the web. Just like Tim made it possible for anyone anywhere to publish anything without asking for permission on a server using any software that could actually talk to HTTP and HTML, we can do the same thing here. It doesn’t have to be one company, it doesn’t have to be one product, it’s not gonna be solved by Docker, it’s not gonna be solved by Kubernetes, it’s not gonna be solved by Google, or Facebook. It’s gonna be solved by people, it’s gonna be solved by us, in a way that makes everyone more successful.

So focus on programming the network. What can you do today to make sure that the work you’re doing works on an open network? Build microservices for functionality and focus on safety two. Focus on surviving the problems and the bugs. If you wanna look at a company that spends a lot of time on this, look at Chaos Monkey with Netflix, that’s all they do is worry about safety two, how can we survive things that go wrong.

Create APIs for your intentionality, make interaction easy, make interaction easy for machines, not just humans. Use the formats and the processes and the patterns that machines like. Apply patterns for autonomy, start to create patterns in your services that other apps can take advantage of, where they can start anywhere, where they can end anywhere, where they can set the tone, they can decide when it’s time to start and stop.

Eventually, that means you can aim to monetize other people’s APIs because that means you can start to connect to their APIs following the same kinds of rules. You can create solutions that no one else thought of, you can even connect dynamically. If one service is down that’s a shopping cart service, you can use another shopping cart service. You don’t have to use just that one, you don’t have to hard code your dependencies to other services.

There’s lots and lots of opportunity ahead of us, and I’d like to leave with one more quote from Tim Berners-Lee. He says, "The web I envisioned has not yet been seen and the future is so much bigger than the past." Our future is so much bigger than the last 25 years, we’ve got a huge set of opportunities ahead of us, and we’re just starting the next step. And I hope this gives you some ideas, gives you some encouragement, and how you can start to contribute to that next big thing. Thank you very much, thanks.