API Management

I was looking for an open-source API Management tool, as MuleSoft seems to be costing an arm and a leg - hope they change their model. It seems they are charging with the intention that all APIs are monetized, which is fundamentally wrong.

   During this research found a nice website which summarized on API Management features. 

Vendor access to Database - Not a Good Idea

Recently, I was queried on what would be the best way to retrieve data from a database within our enterprise, which is required by a vendor to consume. Basically, an external application looking to consume our data.
    As obviously, suggested to expose as API (REST/SOAP) or spew out a CSV/TXT/sth. file which will be consumed by the external vendor. It seems that none of the above could work for the vendor, without writing some customized code. With this stage set, I thought of enumerating why one shouldn't give access to their database to someone whom we aren't in control. Let's begin !

(1) Accessing data through a client application/DB Connectivity API (Eg. JDBC)
NO-NO:   Database patches/upgrades are normal and if we have to do any of those, we need to remind ourselves to check with the external vendor, whether it is all good, from their DB access API/client. This could have a roll-on effect on other databases installed in the same host. A very tight dependency, which DBAs will hate.
      Additionally, there is no assurance of how good the database connectivity life-cycle is. Personally seen external applications screwing up enterprise database, by not closing DB connections or utilizing a high DB processes, which in turn affect other applications performance. The very hard part is debugging the issue, when all that one knows an external application "ABC" is accessing our database.

(2) Giving access as a database view, to prevent any misadventures from external vendor.
NO-NO:  Consider a situation, where we would like to use the same DB view with some minor datatype or new field changes, we need to go to the vendor to check whether this is fine. If not, we will create another database view, very similar to the one used by the external vendor and the schema mess-up begins here.


(3) Vendor says, direct DB access is the only way
NO-NO:  This is where the principles of integration within organization kick-in. Deviating from it, means we are getting into the "spaghetti" world of integration, which may not be a nightmare tonight, but will happen for sure in the near future.

Can microservices simplify SQL queries?

I have seen very complex SQL queries embedded within code, esp. when they are across business applications boundaries. Eg. Finance, Billing, GIS SQL queries, working together to retrieve data of interest. Disparate systems making it to work as "one",
   Can microservices bring simplicity to that, as it is the very nature of it to implement them in a bounded specific domain-level context ?  It sounds logical to me that the answer is "YES"!
Again, someone for the love/hate of it can make a complex SQL or by the very nature of the complexity of the underlying data relationship. 

NoESB - A Marketing Gimmick ?!

Some API vendors are doing a peaceful web-oriented fighting with some ESB vendors. The core content is, ESB is not required or better don't use it if you want to improve your time to market and making the organizational software foundation agile.
   Well, well, all those arguments I see are related to cloud and new products/development. The interesting part is putting forward that API Gateway is a replacement for the ESB, where the API Gateway does the similar functionality to ESB. Now this argument itself debunks the theory of "NoESB", when you have subset of similar functionality in 2 different approaches.
   Did some more Googling and landed up at WSO2 site - a popular API vendor, not that I am fan of it. In SlideShare API-Centric Architecture  they have a clear point on that their API gateway is actually a full-blown ESB with some constraint and one has the choice to install the missing features to make it a ESB !
   ESB has their role as much as API, like for integrating in complex scenarios, file/ftp based and legacy application integrations. At the same time, I am a strong supporter on "smart ends and dumb pipes", which I have many times seen violated in BPEL processes. Business logic should be encapsulated in its domain and not be floated in a middleware. This is where the µservices principle stands attractive.
   It is a pity to see vendors(again!) playing their marketing games and continuing with the confusion era as much as it started with SOA. Beware is the only word, I say to myself !