Managing Micro-Services for your Company


  • What is good API Management?
  • How can API Management be employed to deliver micro-services at the rate of agile?

Analysts love to segregate our eco-system into epochs, such that every six months we observe a new craze around a buzzword. The buzzword of 2016, which has reigned into 2017 has been all about micro-services. For many reasons, this works pretty well for us developers because it really enforces the idea of implementing a service which does only one thing, and it does that one thing really well; enforcing the UNIX philosophy and mantra.

However, I really do want to take you back to 2002 and quickly fast forward through the various phases which the consultants sold concepts. First it was your application had to be “web first” with all the UI to be interacted via a web browser. Then Steve Jobs landed the smartphone revolution where, all of a sudden, the web browser became mobile first. As of late, thought leaders started to emphasis that we should be building API-first.

This API-first resonates well with our mission to build micro-services. It just seems natural, and you have to ask yourself why this is the case? Perhaps when we realize that our API’s is the supporting platform and not the sole product, and we realize that we need other developers outside of the immediate team to employ our platform - that is, the teams’ API - so that the platform, or the product, which the API supports could organically grow.

API First

Let’s go back to 2002. Amazon was a book-selling online retailer. Jeff Bezos understood that in order for his company, Amazon, to evolve and become a digital age company, he mandated the following orders to all his developers.

  1. All teams henceforth will expose their data and functionality through interfaces.

  2. Teams must communicate with each other through these interfaces.

  3. There should be no other form of inter-process communications allowed; no direct linking, no direct reads of another team’s data store, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

  4. All service interfaces, without exception, must be designed from the ground up to be externalized. That is to say the team must plan and design to expose the interface to developers to the outside world. No exceptions.

The last part, that is, to expose your API to the outside world must have been a seriously difficult pill to swallow as we still live in an age where network administrators want to hide everything underneath rocks called firewalls. Nevertheless, Jeff had the foresight to have the knowledge that API exposure actually provided platforms for developers external to the team exploit and grow the products independently to each individual team’s capacity.

Perhaps I could reframe it another way: an additional feature request for the product did not have to appear on the backlog of the team who owned the product. It just got used by another team developing their product.

There is no need to highlight Amazon’s success stories over the years since 2002; we all know it. But I do want to emphasis that Jeff saw the opportunity to organically grow his business without a large effort from from his own internal team members.

The Parallel: Micro-Services

If one has to go back to the mandate imposed by Jeff upon his teams, there is a lot of parallelism why we tend to build micro-services.

  1. Services should be able to expose all their data and functionality through interfaces.

  2. Micro-services have a contract which is advertised for consumers to utilize their API.

  3. Segregation and independence is strongly encouraged instead of building a huge monolithic application.

  4. … The fourth one is still scary proposition, exposing the API to the world, so let’s explore that a bit. But let’s look at some of the lessons learned by Amazon when adopting this mandate.

Lessons Learned by Amazon

There has been several lessons documented in the public by Amazon employees, and I am sure that some of these are quite obvious, but I would like to point out that almost every micro-service which is exposed will need to deal with these realities.

  1. Support and long term planning for service contracts are important.

  2. Security - every team becomes a potential Denial of Service (DOS) attack.

  3. Every team needs to ensure that they are able to perform within the constraints of their advertised Service Level Agreement (SLA).

  4. Monitoring and Quality Assurance. Monitoring and QA are interconnected, and tools reporting whether or not services are up and down are not good enough. Health metrics have multiple facets including average response times, the responses are correct, and that the solution is able to respond correctly to incoming requests.

  5. Discoverability. What API’s does my organization already have, and what can I reuse?

This naturally leads into an abstraction called API Management.

What is API Management?

API Management software breaks down their various functions into three primary functions:

  1. Publisher Portal. This is where API owners publish their API’s to, and have various controls and policies which may be configured for the services. These features are designed to take the scary part out of publishing your API to the world. We will revisit the policies and controls available as abstracted concepts which the micro-service does not have to reimplement later.

  2. Developer Portal. This where your potential consumers will browse the various API’s available and subscribe to the products on offer by your API platform.

  3. Runtime implementation and policy enforcement. The abstraction layer where the publisher and developer portal meet.

In short, API Management allows publishers to implement the common abstraction pieces upon their API’s such as: service advertising, documentation, examples, access controls and service level agreements, analytics (who is using my API?), health analytics externalized (who watches the watchman?), and ability to create easier developer adoption.

But I can build these features directly into my Awesome Micro-Service!

I’m sure you can. However, just be prepared to multiply the effort in every deployment of your numerous micro-service. Not fun!

Furthermore, you probably will naturally tend to slowly move to creating an API Management service. If this is your competitive edge, then you are more than welcome to build one. However, there are a number of vendors who are heavily invested in this space who have smart people working on their API Manager 24/7.

Also, some may offer reasons why API Management is not for them. I’ve heard a lot of reasoning before, but here are the common ones.

  1. Current API Consumers are low. Never underestimate organic growth where the demand grows pretty quickly, it is hard to keep up. Automate your processes early.

  2. Your API is easy to understand already. Here is the shocker: not all customers’ developers are savvy. As a demonstration, let’s do a few acronym drops: RESTful, HATEOAS, CORS, and so forth. Having that “getting started in five minutes” guide will go a long way, and it would be wonderful if all your API’s are documented consistently.

  3. Access Control. Lock down who can subscribe to your API’s. Ok, that was easy. Now your executive team wants to introduce tiered plans where there are certain pro-rata limitations in place depending on the subscription level the client signed up for; that’s a little bit harder.

  4. Measuring our Partner’s API already has a dashboard. Do you really want to write a wrapper service just to monitor external API’s? Or maybe implement policies based on cost-based usage accounting to allocate the service costs proportionally to the various teams?

  5. Your API’s is designed for only one use case. No, it shouldn’t just be a backend for your mobile app. What if your boss want to plug an IoT device to it?

  6. Your company does not make its money by API exposure. Once again, your API is the mechanism as the platform to drive your product. An example is E-Bay exposing an API for adding stock to its catalogue. The money is not made on the listing of the stock; it’s made on the sale of the stock, therefore solving the chicken and the egg problem.

Are there any other Use Cases of API Management?

Yes, there is. There are two use cases off the top of my head and both of have one thing in common: the API Manager is not implemented on API’s owned by an internal team.

  1. Perhaps you want to interact with a SOAP service as a RESTful based service. API Manager can abstract that from you without any additional plumbing code.

  2. External service providers. How do you monitor their API health and analytics of their usage? Adoption waxes and wanes, and it super insightful to the business to determine whether their bean-counters are getting bang for their buck.

  3. Monetization of your API endpoints. You’ve solved the cross-cutting problem which occurs throughout your company, but how do you assign the cost centre of running the API to your consumers? Who pays the bills?

  4. Composability of new API endpoints. There may be multiple micro-services in your organization but new “app-specific” API’s could be composed on the API Manager than trying to compose a brand new project.

Conclusion

The primary purpose of my presentation of API Management is not to slant and demonstrate a particular vendors’ product. Instead, I really do hope that I have ignited some kind of intrigue to investigate the implementation of an API Manager. It doesn’t matter which product you choose, but the most important aspect of exposing your API’s external to the team is so the API is seen as the platform to organically scale your company’s product.

Consolidating all the API’s which the various micro-services exposes into a single portal for publishers and developers would allow API’s to be seen as first class platforms. API Management also allows batteries to be included when exposing the API Management endpoints to the externalized consumers.

API Management also implements various common use case and policies which means that the micro-services may be kept lean in implementation detail whilst the heavy-lifting details can be deferred to the API Management.

blog comments powered by Disqus