Christian Posta, a cloud-native architect, writes about microservices, Istio and service meshes, API gateways, and enterprise concerns with AI protocols like MCP.
Commenters value his microservices series, especially on data, and cite his Istio post as a case of a project moving back to a monolith. They also cite his MCP critique.
The choice of transport is just one, quite telling, aspect of this mess.
Could these commands be executed over websockets? Yes, they could. Will they? No, because the specification literally only defines two transports, and all of the clients only support those.
As with any hype, the authors drink their own coolaid, invent their own terminology, and ignore literally everything that came before them.
Even reading through explanations on the once again vibe-coded https://modelcontextprotocol.io/ you can't help to wonder why.
"tools" are nothing but RPC calls (that's why the base of this is JSON RPC)
"resources"? PHP could do an fopen on remote URLs in the 90s. It literally is just that: "Each resource is identified by a unique URI and can contain either text or binary data." You don't say.
"sampling"? It literally is just bi-directional communication. "servers request data from the client by sending commands". What a novel idea, must have a new name and marketing blurb about "powerful MCP feature, enabling sophisticated agentic behaviors while maintaining security and privacy."
As for auth, again, MCP doesn't have it, and expects you to just figure it out yourself. The entirety of the "spec" on it is just "MCP provides an Authorization framework for use with HTTP and your expected to conform to this spec". There's no spec. Edit: to be clear. At the point of writing all mentions of "MCP Auth Spec" on the internet link to…
Contour is not an API Gateway.
Disclaimer: I work for Solo.io
An API Gateway can do sophisticated edge security challenges (OIDC, Authz based on OPA, web app firewalling/WAF, etc) as well as things like message transformation, swagger/grpc detection, exposing APIs for self-service signup through a portal, etc. Gloo does all these things.
I've written in depth about this as well, specifically in terms of things like contour, Istio ingress gateway, consul's service mesh gateway, etc, etc
https://blog.christianposta.com/microservices/do-i-need-an-api-gateway-if-i-have-a-service-mesh/
Gloo resources:
https://docs.solo.io/gloo/latest/guides/dev_portal/
https://docs.solo.io/gloo/latest/guides/security/waf/
https://docs.solo.io/gloo/latest/guides/security/auth/oauth/google/
https://docs.solo.io/gloo/latest/guides/security/opa/
https://docs.solo.io/gloo/latest/installation/advanced_configuration/fds_mode/
https://docs.solo.io/gloo/latest/guides/traffic_management/request_processing/transformations/
Isn't one of the defining characteristic of Microservices to have a data persistence instance for each service (even at the cost of duplication)?
(I am basing myself on just a superficial interest for MS so I might be wrong - here is what I am talking about: http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/)
If this is correct, than no, Microservices are really not "just like SOA".
(If I am wrong, please correct me - I am here to learn).
You are making a lot of ageist remarks. There are plenty of Senior engineers making wrong decisions. For example the istio project moved from microservices to monolith - https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/ and none of those engineers are "junior engineers" by any means.
This should be on top of HN, really great series and something I will use to justify event-driven distributed architectures when I need to. Spot on!
By the way, check this part from the series: http://blog.christianposta.com/microservices/why-microservices-should-be-event-driven-autonomy-vs-authority/