Two extremely hot IT topics right now are APIs and Microservices. Unfortunately, too many people think this is one topic – i.e. they are the same thing. This is not correct. There are several misconceptions about APIs and Microservices, and throwing in Services (from Service Oriented Architecture - SOA) the confusion gets worse. So, I thought I would try to take a very simple view at positioning these.
Common Misconceptions and Why
Misconception
|
Why do people think this?
|
Microservices are just more fine-grained (web) services
| The naming of microservices and services basically implies this |
| APIs are microservices (and vice versa) | APIs and microservices are frequently used together with one representing the other (more later), so they are often treated as one item |
| APIs and Services are the same – API is just a new name for a Service | Both an API and a Service are frequently implemented as REST or SOAP, so since the technology used in the implementation is the same, they must be the same. |
If you understand that these are misconceptions, then you can stop reading now.
Definitions
In writing the following definitions, I am going to stay away from technology. Instead I will use the purpose or principles that drive the use of the item. Technology changes frequently and can mislead as to
why or where you should use a capability, but if you use the purpose to guide you then positioning becomes easier.
- API – Should be correctly referenced as a “Business API”. See “What is an API? and What is the API Economy?” for a more complete discussion. Summarizing: “Business APIs are simple to understand interfaces focused on business recognizable assets – a product, an order, a customer, etc. Business APIs are focused on self-service consumption of the asset, simplicity, security, analytics, and speed to deliver”. APIs should be fine grained and focused on what the target consumer of the API wants. If different consumers want different views of the asset, it is okay to have more than one API, each providing a specific view of the asset. APIs should not contain true business logic, since they are frequently deployed in the DMZ (in a gateway). There may be some transformation and routing logic included. The API will call the business logic or data assets either inside the enterprise Systems of Record and/or combine this with other calls inside or outside the enterprise to provide the desired result to the consumer.
- Service – perhaps one of the most overused words in all of IT. In this case I am referencing Service in the SOA sense. The purpose of a service is reuse and connectivity. A service is also an interface, representing an asset in the enterprise (hence confusion). But, in this case the purpose is to provide a single complete view of the asset. Typically, a service has a provider view. The “customer” service can provide any information about customers, “account” service about accounts, etc. Having a single view of the asset rather than have each project create their own definition removes duplication of information and out of sync issues. It also reduces costs since projects do not need to reinvest in creating the asset definition. Because of the completeness of the asset description by a service, this led to more complex coarse-grained interfaces that could meet many purposes.
- Microservice – a microservice contains business logic (i.e. code). It is not an interface, so clearly not identical to an API or Service as described above. Using microservices implies a micro component architectural style for creating applications. Instead of creating one large monolithic application that contains all the application parts in a single “package”, the purpose of microservices is to break the application into component parts, each providing a particular capability that together implement the functionality desired in the application. This approach increases agility, scalability, and improves DevOps. There are multiple definitions of microservices (here and here), which again causes some confusion and leads people to call many things microservices. Stick to the definition by purpose is my advice.
RelationshipsThe picture below shows a monolithic application (left) which perhaps is being rewritten using a microservice architectural approach (right). Instead of a single silo component, the new version of the application is composed of three microservices.
The original silo component application may have been represented by a single SOA service. That service has 4 APIs, each providing views that consumers want from the service/application. In the Microservice application note that we can still have the same 4 API views into the application. Since the API views are consumer oriented, the structure of the back-end application does not determine the number of APIs.
Not all microservices need to be exposed through APIs. The following picture shows a microservice application. In some cases, there is an API exposed while in other cases other forms of application integration may be used to call the microservices directly.
Individual microservice components should focus on their component functionality and not be burdened with the complexities of API exposure beyond the microservices application boundary. Exposure to a consumer (if desired) should be delegated to a separate capability (i.e. API Management) to enable consumption of the microservice functionality. API management components allow for control of the consumption of the microservice component assets:
API Gateway:
- Decoupling/routing
- Traffic management
- Security
- Translation
API Manager:
- Plan/product design
- Access management design
- Policy administration
API Analytics:
- API usage
- Account (consumer) usage
Developer portal:
- API discovery
- Self-subscription/administration
Between the terminology, history, and technologies, there is frequent confusion across APIs, Microservices, and Services. I hope this simplified perspective helps position these terms and their usage. Many thanks to Kim Clark (@KimClarkKJC) for his prior work in this area.
To understand more about IBM’s thoughts on the API Economy visit the IBM
API Economy website. IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs. You can find more information about IBM API Connect at the
API Connect website. And you can also experience a
trial version of API Connect.
If you have questions, please let me know. Connect with me through comments here or via twitter
@Arglick to continue the discussion.
#APIConnect#APIeconomy#APIEconomy#APImanagement#APIscience#APIstrategy#APIvsservice#api_strategy#APIConnect#apimgt#apis#architecture#experienceAPIs#ibm#ibmapimgt#Microservices#MicroservicesArchitecture#service#soa#TechnicalStrategy#think_apis