Skip to main content

API management design patterns for Digital Transformation

Digital Transformation (DT) has become the buzz word in the tech industry these days. The meaning of DT can be interpreted in different ways at different places. But simply it is the digitization of your business assets with the increased usage of technology. If that definition is not simple enough, you can think of an example like moving your physical file/folder based documents to computers and make them accessible instantly rather than browsing through 1000s of files stacked in your office. In a large enterprise, this will go to the levels where every asset in the business (from people to vehicles to securtiy cameras) becomes a digital asset and instantly reachable as well as authorized.

Once you have your assets in digitized format, it is quintissential to expose that digital information to various systems (internal as well as external) through properly managed interfaces. Application Programming Interface (API) s are the de facto standard of exposing your business functionalities to internal and external consumers. It is evident that your DT story will not be completed without having a proper API management platform in place.

Microservices Architecture (MSA) has evovled from being a theory in the Martin Fowler’s website to a go-to technology to implement REST services for your organization when achieving the DT. Most of the developers in the enterprise are moving towards MSA when writing business logic to implement back end core services. But in reality, there are so many other systems which are coming as Commercial Off The Shelf (COTS) offerrings which does not fit into microservices landscape natively.

With these basic requirements and unavoidable circustances within your organization’s IT eco system, how are you going to implement an efficient API management strategy? This will be the burning problem in most enterprises and I will touching up on possible solution patterns to address this problem.

API management for green field MSA

If your organization is just a startup and you don’t want to use high cost COTS software in your IT eco system, you can start off the things with full MSA. These kind of organizations are called as green field eco systems where you have the complete control of what needs to be developed and how those services are going to be developed. Once you have your back end core services written as microservices, you can decide on exposing them as APIs through proper API management platform.

Pattern 1 - Central API manager to manage all your micro services

As depicted in the below figure, this design pattern can be applied for a green field MSA where microservices discovery, authentication and management can be delegated to the central API management layer. There is a message broker for asynchronous inter-service communication.
MSA central API gateway.png
Figure 1: Central API management in a green field MSA

Pattern 2 - Service mesh pattern with side car (micro gateway)

This pattern also applies to a green field MSA where all the back end systems are implemented as microservices. But this pattern can also be applied for scenarios where you have both microservices as well as monolithic (COTS) applications with slight modifications.

MSA micro API gateway (Service mesh architecture).png
Figure 2: API management with service mesh and side car (micro gateway)

API management for practical enterprise architcture

As mentioned at the beginning of this post, most of the real world enterprises use COTS software as well as various cloud services to fullfill their day to day business requirements. In such an environment, if you are implementing a MSA, you need to accept that existing systems are there to stay for a long time and MSA should be able to live along with those systems.

Pattern 3: API management for modern hybrid eco system

This design pattern is mostly suited for enterprises which has COTS systems as well as MSA. This pattern is easy to implement and has been identified as the common pattern to apply on hybrid microservices eco system.

Modern enterprise central API gateway with ESB.png
Figure 3: API management for modern enterprise

The same pattern can be applied for any enterprise which do not have any micro services but only traditional monolithic applications as back end services. In such scenarios, micro services will be replaced by monolithic web applications.

Comments

  1. This is really a very good article. Thanks for taking the time to discuss with us, I feel happy about learning this topic. keep sharing your information regularly for my future reference.
    WhatsApp API

    ReplyDelete
  2. Personal program system organization identity

    ReplyDelete
  3. Nice blog. Integrate text messaging into your own application, website or CRM with the Msgclub Bulk SMS API.

    ReplyDelete
  4. Thank you for sharing this information API. Looking forward to read more.
    Best API Web Development Services

    ReplyDelete
  5. Your blog article is outstanding; it is informative; in fact, I write on a variety of issues, including app development technology. Please

    read and give your thoughts on content related to mobile

    app development company
    for businesses.

    ReplyDelete
  6. Thanks for delivering a good stuff, Explanation is good, Nice Article.
    Best Mulesoft Training
    Mulesoft Online Training in Hyderabad

    ReplyDelete
  7. Great article thank you for sharing the valuable information with us.
    Best Digital Transformation Services.

    ReplyDelete

Post a Comment

Popular posts from this blog

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte

Understanding Threads created in WSO2 ESB

WSO2 ESB is an asynchronous high performing messaging engine which uses Java NIO technology for its internal implementations. You can find more information about the implementation details about the WSO2 ESB’s high performing http transport known as Pass-Through Transport (PTT) from the links given below. [1] http://soatutorials.blogspot.com/2015/05/understanding-wso2-esb-pass-through.html [2] http://wso2.com/library/articles/2013/12/demystifying-wso2-esb-pass-through-transport-part-i/ From this tutorial, I am going to discuss about various threads created when you start the ESB and start processing requests with that. This would help you to troubleshoot critical ESB server issues with the usage of a thread dump. You can monitor the threads created by using a monitoring tool like Jconsole or java mission control (java 1.7.40 upwards). Given below is a list of important threads and their stack traces from an active ESB server.  PassThroughHTTPSSender ( 1 Thread )

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p