In my last piece, I discussed how MSPs need to start moving to a microservices architecture to embrace the rise of the composite app, created by pulling together microservices from across a hybrid private/public platform. The issue with such an approach is in that facile statement of “pulling together microservices.” It sounds easy, but it can be incredibly difficult.
For example, take an MSP that goes through a lot of trouble in creating its own set of microservices. They play very well together with interactions being facilitated, due to sets of application programming interfaces (APIs) that the MSP has enabled. The problem is that these APIs are proprietary.
If a customer gets all their services from the one MSP, they are fine. The hosted microservices can be pulled together and operated in a way that still supports the customer’s needs and the MSP may still have a happy customer.
However, most customers are not looking to put all their eggs in one basket. There will come a point where the customer will be looking at the greener grass of some other microservice hosted on a different platform.
Maybe you want to try and create stickiness through holding them over the barrel of proprietary APIs? It has never worked in the past – those who create stickiness through making it hard for a customer to exercise flexibility may well find that the customer leaves completely. It’s better to have a customer that is still paying you some subscriptions than one that is a new profit line for a competitor.
Open APIs are key
Databases should support representational state transfer (REST) APIs, enabling standardised access and manipulation of data in a known and secure manner.
At the application level itself, most enterprise systems will already have reasonably well documented APIs. However, large public clouds have been saturating the market with what some perceive as proprietary APIs. As these APIs have taken root, they become de facto standards, as opposed to the industry-agreed de jure standards.
A prime example here is AWS S3. If you want your storage platform to adhere to an accepted, well-used standard, then S3 is the one to go for. AWS has a massive market in storage, and most storage vendors have been forced to accept that S3 is a dominant force in the market and provide S3 APIs in their systems.
Compare the sort of services that you are offering and look at what the nearest equivalents are from the big public cloud vendors. For example, if Google Cloud Platform has something similar, then check what APIs Google uses and use those for your microservice.
Why should you do this?
You will already have a nascent market already sitting on the Google cloud: using open APIs, you make it easier for them to jump off the Google platform and onto yours. Yes, the opposite is also true: if your microservice isn’t up to scratch, then your customers can go to Google. However, the idea is that you are offering something over and beyond what someone could get from a Google Cloud Platform (AWS, Microsoft Azure, IBM Softlayer, etc).
As part of this value-add service, why not look at offering API management to your customers? Using software such as MuleSoft, Apigee, Tibco Mashery, or NGINX, the whole lifecycle of APIs can be managed. Through the creation of a suitable API itself, through secure publishing, management, and control of who uses the APIs, the capacity to throttle back any traffic that is stressing a specific API, and the secure locking and end-of-lifting of old APIs that should no longer be used.
Most API management systems are multi- and cross-platform: again, a value-add offering to your customers. Not only can the customer manage the APIs they are using against your microservice offerings, but they can include any microservices, services, or full application APIs they are using from their own platform. Also, they can generally include third-party platforms – including the big public clouds.
With the right API management tools in place, you can then start to offer migration services to bring the customer more onto your platform. Alternatively, you can offer the capability to be a trusted aggregator where third party microservices are identified and offered by your company to be more easily integrated and utilised within a composite application.
The future will be shaped from how well any organisation can make use of microservices: as an MSP, now is the time to prepare your own platform to make the right offer to prospective and existing customers.
Photo: Gorodenkoff / Shutterstock
