What is meant by these terms?
From a definition of a service perspective:
In software development, a “service-centric” software application supposes to write code that gets exposed (typically over a network) via one of many interfaces.
These interfaces are the endpoints to business functionalities and regardless of the architectural pattern (SOA, Microservices), services tend to share the following attributes:
- are self-contained
- are “black boxes” to users of the service
- models a set of activities with specific inputs and outputs
Reduced complexity: in case lot of records are needed to serve a particular business or data requirement. Making multiple requests might suppose implementing processes or uses-cases more complex than they need to be.
Reduced risk: the classical (monolithic) development to serve data requirements might expose too much of the underlying data model.
Bottom line: SOA packages up functionality into endpoints, typically accessible at the enterprise level that is: easy to access for the business, reusable, can be used as building blocks for future applications.
APIs and relation to SOA
SOA is more B2B Business solutions layer where when business need to pass data back and forth between different types of medium, API‘s are built, and business rules are built around that.
SOA is an architectural methodology. It is a way of specifying separation of responsibility from a business oriented point of view into independent services, which communicate by a common API (often but not necessarily by publishing events to a bus).
In recent years, a culture shift takes place in businesses and organizations, especially in the public sector. Thus, there have been recent drivers to open access to data service, often through public APIs which are available online.
API definition: a source code-based specification intended to be used as an interface by software components to communicate with each other.
API = any way of communicating exposed by a software component.
SOA = a set of enterprise architectural design principles to solve scalability issues by splitting responsibility into services.
Microservices (architecture) – MSA
At a very high-level, microservices are an alternative way for architecting applications which offer a better way to decouple components within an application boundary.
Maybe if microservices were rebranded as microcomponents it‘d be easier to understand.
In an application that implements microservices, the application boundaries or interfaces are no different to that of a traditional monolith application, the key difference is what happens behind the application boundary.
Behind the service boundary, collections of independent microservices run in their own processes, all with their own individual set of APIs or web service endpoints that get exposed through the application boundary.
Microservice architecture is focused on multiple, independent, self-contained application-level services that are lightweight and have their own unique data model.
For CIOs / CTOs to make informed decisions:
In the followings, will present main attributes for each
My research above would have been not complete without to try find some API Management providers in Romania.
A reliable source I believe is Gartner (Magic Quadrant). Gartner report: https://www.gartner.com/en/documents/3970166/magic-quadrant-for-full-life-cycle-api-management (excerpt below).
I found 5 leaders (who have the ability to execute and they are also visionaries) and took all of them (in the order as they appear in the Gartner document) into my research to see if any Romanian customer can get some API services in Romania from these. I think it is important to have a local distributor or partner (for reasons relating to easier troubleshouting, local / on-premises customisation, etc)
Google Apigee: not found a partner in Romania for Apigee (see this – no “Romania” word in the results of that search and this – a provider taken also from the results of searches, but who has nothing in Romania, but is present in other countries in the region around Romania)
Software AG: not found a partner in Romania (they coordinate from Poland) – see this
Mulesoft – it seems they have a partner, but did not see a specific focus on API (at least from the main page displaying this partner’s services I could not retrieve details). Thus, see this – pointing to Softvision, but on mulesoft site the link “Partner’s site” points to this website whereby one could find no link/details about API services.
IBM: yes, they have IBM Romania and the specific page for API Management is https://www.ibm.com/ro-en/cloud/api-connect
Axway: yes, they have a Romanian partner (EasyDO) and the specific page is https://www.easydo247.com/products-axway
Final conclusions: I saw that the banks in Romania have already contracted some API Management services (for example, no.2 bank in Romania, BCR has something from Axway as per the link mentioned at previous paragraph – see at the bottom, where I found also BNP Paribas as their client).
I could imagine that IBM would have also offered to Romanian companies their API Connect product, but did not find on their website specific Romanian clients using API Connect. Maybe they keep that list confidential.
I know that for banks and fintechs the PSD2 directive (in force since December 2019) requires that banks have to expose their data through APIs for fintechs as consumers of data.
Anyway, if you run a Romanian company that has a complex IT architecture and want to go for digitisation in 2020, flexibility in creating new products in order to satisfy customer needs, you might want to consider gradually build new products having a services-based architecture, i.e. SOA, microservices. Therefore, implementing some APIs (if you did not do that already) and managing them is the way.
In pursuing the above-mentioned endeavour, if I am required to express an opinion, I would recommend to go with one of the leaders from the Gartner Magic Quadrant.