Mulesoft and API Middleware for Cloud architectures

If you want to migrate many applications to AWS or the Cloud, you will need a Middleware platform to manage the APIs.  This middleware will decouple the client user from the back-end application and server resources.  Decoupling is mandatory to design best practices and isolate the end user from system changes, so you can migrate, upgrade or deploy new versions of your applications without disrupting business usage.  It is also forces you into Cloud-native application integration and provides a migration path from legacy to Cloud-friendly applications and code.

The leader in Cloud API and Middleware management is Mulesoft.  Mule provides a huge library of ready to use connectors, API designs and cloud management tools.  Mule is largely Java based so does not take a lot of training for most engineers to understand and use (perhaps one week).  Importantly, Mule forces you to delve into system and API design and properly construct not only your target operating model, but also the resources you wish to share or expose through an API.

(Above figure is from mulesoft.com)

With Mule we can have complex architectures. For example, I can have some business applications deployed in AWS, connecting back to on-premise legacy systems for certain calls or information needs.  The API accessed by the end-user will be in Mule and will call an exposed API on the application.  The end-user is directed to a secure connection via Mule, which handles the request and returns the desired resources to the end-user.  This ‘middleware’ decouples the server from the end-user with all the advantages that de-coupling offers.  This API layer is essential in the Cloud universe.

Importantly, Mulesoft has an excellent set of aids around API design, build and management.  The Mule API series can be accessed here.  As well there is an excellent book on APIs one should read written by Mule engineers, “Undisturbed REST, a guide to designing the perfect API”.  What I like about Mule is their deliberate approach to building a proper Middleware system.

For example the first step in the Mule series is ‘Why are you building an API?’.  Good question.

“Key questions to ask:

• Who is our target user for this API
• Which of our products/ services do we want them to be working with?
• What are THEIR use cases for integrating with our API?
• What technologies will they be using to integrate with our API?
• What other services will they want our APIto interact with?”

(Above figure is from mulesoft.com and shows a basic API flow in which an end-user accesses the Mule API to access an application which can be in the cloud or in-premise.  The user receives a security token, is allowed accessed to the resources specified by the API).

Once the aforementioned questions are answered, we can build out the functions of the API.  This ‘storyboard’ does not need to focus on HTTP commands or CRUD operations.  Instead it is high level.  For example, I might need to expose an API and set of functions so users can self-manage their own passwords.  I can write down the steps to do this in plain language and use UML notation or sequence diagrams to confirm my thinking about the process flow.

User manage profile -> change password -> check password meets rules -> change password -> database is updated -> email to user notification of change

This basic flow would be notated in UML.  The database password resource, in the above example, can now be exposed via an API.  But which API?  REST or Representational State Transfer is the most common type of API, but most APIs are not truly REST premised.  They usually follow some REST ideals and are mixed.  Hypermedia or rich media might be a constraint using pure REST.  Some APIs are JSON-RPC and others SOAP (Simple Object Access Protocol) based.  The last two are quite useful if your clients are using legacy systems based on SOAP libraries.  JSON-RPC is very easy to build and ties into RPC based systems.  Cloud Native code and apps should use REST.

You will only determine what type of APIs you need through an analysis and design process based on the real-world applications you are building and need to integrate with.

One of the main purposes of the API is to avoid ‘coupling’.  The API must be de-coupled from both the user (application or end-user) and the server resources, so that whenever there is a background change in our system, the API is not adversely affected.  API design is therefore very important.  It must be longer term in its thinking and construct and be extensible and not break backwards compatibility.  This is why good API design takes time and effort.

(Figure above is from mulesoft.com and shows AWS S3 bucket integrated with On-Premise and SaaS via an API in AWS)