Google and IBM announce Istio – easily secure and manage microservices

One of the benefits of microservices is the ability to trivially deploy many versions to improve performance and uptime.

You should be using service discovery and deploying multiple instances.

If you adopt micro-services in earnest, a challenge you face is how to ensure that the right set of services can communicate (and only communicate with) the right other set of services. In a large organization, it's not unrealistic to have hundreds of services, and not all of them are fully trusted (some may be run by vendors, etc).

What's more, these things are being constantly deployed to a wide variety of environments. Some may be on cloud VMs (or a dynamically scaled cluster of VMs), some on bare metal, some in orchestrators like Kubernetes. Some will run on networks that the organization maintains, some may be maintained by a DC or cloud provider.

Historically the answer to securing this communication has been to use L3 network segmentation with strict rules to decide who can send packets to who. But, particularly in an increasingly heterogenous and dynamic environment it's very difficult to do this reliably and quickly. Networks are also a pretty crude authorization system - it implies that just because you can reach an endpoint that you are authorized to use it, which isn't necessarily true in practice. Some of the other benefits of Istio - like system-wide circuit breaking and flow control are also difficult to do purely at the network layer.

If you're interested in this, I'd encourage you to check out https://spiffe.io/about which has some more detailed thoughts on the limitations of the L3 micro-segmentation approach and how it can be solved.

Possibly. However, tooling and code generation can help.

If the smarts is just a state machine, and the rules are abstracted at the right level, it would not be that hard to support.

"Thick" smartpoints can save on operating cost (infrastructure, personnel, complexity, level of expertise) when your system is "simple enough"

At massive scale, from an economies of scale (all things considered), it may make better sense to go with "Thin" smart endpoints.

The migration between the 2 models is where the art of the design comes in play :) It's an art because it is a decision process involving many players with conflicting and competing goals, decisions, time frames, motivations etc.

It's often not just a "technical" decision

> Really interested to hear user feedback from today's #istio announcement and where it will have the biggest impact.

Okay: I immediately deeply, profoundly, bitterly hate and despise your announcement and for just one, really simple, dirt simple, but totally unforgivable reason: What the heck is a "microservice"? You never said.

That word, microservice, is not in a standard English dictionary, so you are writing undefined jargon, gibberish, junk and not English. You are insulting me and even worse yourself.

Instead, write English. Get rid of the undefined jargon.

Got it?

This was a difficult lesson?

> the biggest impact

Until you learn to communicate at, say, the late elementary grade school level, e.g., learn to write English, the impact promises to be minimal.

Resiliency: Centralized proxies can suffer from shared failure domain issues (especially when large number of configs, etc., are deployed).

Performance: Side-loaded proxies tend to perform better, in part because they deal with a subset of config.

Our choice of sidecar deployment was informed by on our (Google, Lyft) experiences with both centralized and sidecar models. However, that being said, Istio is not predicated on per-pod deployment.