MuleSoft: how do we program the Internet of Things?

The Computer Weekly Developer Network hosts a brief Q&A with founder of integration platform company MuleSoft, Ross Mason.

MuleSoft provides the Anypoint Platform of integration products that tie together SaaS apps and on-premises applications… or work connecting any application and/or data source or API, whether in the cloud or on-premise.


CWDN: With more sensors collecting information about people and activities, how do we move on from here?

Developers in the IoT space need to think very differently about scale, reliability, security and dealing with many more connected consumers. Our traditional architectures need a rethink.

IoT brings in a new era for edge computing and developers working on IoT projects have to think about more layers to enable 100,000s or millions of sensors to exchange information with the back end systems and also with each other. One layer emerging is termed the Fog.

Unlike the cloud the fog layer is concerned with connecting the sensors to backend or cloud systems. The Fog layer is essentially a collection hubs that sensors connect to that can be managed remotely but also have enough smarts to communicate with each other.

CWDN: What’s involved and how much ‘heavy lifting’ is needed at the developer architecture end of the API spectrum?

Generally, because IoT type architectures are new for most people there is a lot of heavy lifting around device management, data management, architecture and connectivity to other systems.

APIs are typically used to a) provide an interface to hub devices that sensors or smaller devices connect to or b) to provide access to the server side where developers can access data and maybe control some aspect of the devices either directly or through a hub.

Building APIs has gotten a lot easier with open languages to express APIs such as RAML and web-based tooling like MuleSoft’s API platform (disclaimer I founded MuleSoft) to enable developers, architects and product managers to take a design first approach to APIs.

These tools allow you to create repeatable patterns – traits of an APIs – and re-use them in all of your API implementations. This saves time, reduces usability problems and solves the major issue of creating consistent APIs across teams.

CWDN: Highlight the advantage of creating APIs on the fly / seeing the outcomes in real-time whilst designing the API – can you explain why this is important for developers?

This point about API-first design is important. It introduces the concept of APX (Application Programming eXperience) to API development, (which is borrowed from User interface design).

It changes the way APIs are built today. It puts the focus squarely on the consumer of the API rather than the more technical aspects of building APIs. Most enterprise APIs are coded directly and then the code is annotated to describe the API interface (i.e. Java’s JAX-RS). This is fraught with problems since the bit that the end consumer sees is slapped on as the code is written and there is no real design process to create an API around the requirements of the consumers.

A real example of this (who I can’t name) is a company that has a mobile team and API services team. When the mobile team needed a new search API, the spec’d it on paper and gave it to the API team who took it away and then spent 2 months creating this new API.

When the new APIs was available it wasn’t what the mobile team needed. Partly it was the fault of the mobile team not specifying everything properly. And part was the fault of the API team that made assumptions and misinterpreted some requirements. Now wouldn’t it have been better is they could have created the API by simply defining it with a simple language like RAML in a couple of hours collaboratively.

What if they could then quickly mock out the service so the mobile team can actually get a feel for it?

And then once they agreed on a design, they could lock it down and the API team could invest the time in building it while mobile team could build their application against the agreed mock API. Introducing the design phase up front and using tools like MuleSoft’s Anypoint Platform for APIs allows teams to work together in this way and focus on building APIs that are designed with the user experience first.

CWDN: Will we be able to turn websites in their entirety into API channels?

Its possible but the tools are so good and easy for creating websites and there are so many developers that have those skills that we’ll keep doing a mix of traditional and API-driven web sites. New companies are already thinking API- first or Mobile-first for everything, so the shift away from traditional 3-tier web sites is gradually happening. Note that APIs strategies in the enterprise are being driven by mobile, not web sites.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.