We remain concerned about business logic and process orchestration implemented in middleware, especially where it requires expert skills and tooling while creating single points of scaling and control. Vendors in the highly competitive API gateway market are continuing this trend by adding features through which they attempt to differentiate their products. This results in overambitious API gateway products whose functionality — on top of what is essentially a reverse proxy — encourages designs that continue to be difficult to test and deploy. API gateways do provide utility in dealing with some specific concerns — such as authentication and rate limiting — but any domain smarts should live in applications or services.
We remain concerned about business logic and process orchestration implemented in middleware, especially where it requires expert skills and tooling while creating single points of scaling and control. Vendors in the highly competitive API gateway market are continuing this trend by adding features through which they attempt to differentiate their products. This results in overambitious API gateway products whose functionality — on top of what is essentially a reverse proxy — encourages designs that continue to be difficult to test and deploy. API gateways do provide utility in dealing with some specific concerns — such as authentication and rate limiting — but any domain smarts should live in applications or services.
One of our regular complaints is about business smarts implemented in middleware, resulting in transport software with ambitions to run critical application logic. Vendors in the highly competitive API gateway market continue to add features that differentiate their products. This results in overambitious API gateway products whose functionality—on top of what is essentially a reverse proxy—encourages designs that are difficult to test and deploy. API gateways can provide utility in dealing with some generic concerns—for example, authentication and rate-limiting—but any domain smarts such as data transformation or rule processing should live in applications or services where they can be controlled by product teams working closely with the domains they support.
One of our regular complaints is about business smarts implemented in middleware, resulting in transport software with ambitions to run critical application logic. Vendors in the highly competitive API gateway market continue to add features that differentiate their products. This results in overambitious API gateway products whose functionality—on top of what is essentially a reverse proxy—encourages designs that are difficult to test and deploy. API gateways can provide utility in dealing with some generic concerns—for example, authentication and rate-limiting—but any domain smarts such as data transformation or rule processing should live in applications or services where they can be controlled by product teams working closely with the domains they support.
One of our common complaints is the pushing of business smarts into middleware, resulting in application servers and enterprise service buses with ambitions to run critical application logic. These require complex programming in environments not well suited to the purpose. We're seeing a worrying re-emergence of this disease with overambitious API Gateway products. API Gateways can provide utility in dealing with some generic concerns - for example, authentication and rate-limiting - but any domain smarts such as data transformation or rule processing should live in applications or services where they can be controlled by product teams working closely with the domains they support.
