
Google and IBM announce Istio – easily secure and manage microservices - ajessup
https://developer.ibm.com/dwblog/2017/istio/
======
tyingq
Interesting, but there's currently a lot of overlap between competing things
that want to inject themselves between service consumers and service
producers.

There's API gateway products (Apigee, Kong, etc). Load balancers and proxies
of various types. Caching and CDN products. More niche stuff like bot
blocking, and this attempt to bundle control and statistics.

It would be nice if some sort of standard pattern emerged, where something was
the main orchestrator. At the moment, you can end up with suboptimal stuff.
Like a CDN that routes to a cloud API gateway that then routes to a (not
geographically close) load balancer, that then hits the actual service.

I'm surprised that Cloudflare, Akamai, and the like haven't offered all of
these things at the edge. Some things are service to service, but a fair
amount is client to service...putting this stuff closer would help.

~~~
fierro
Regarding API gateway products, Apigee will actually work with Istio

[https://apigee.com/about/blog/digital-
business/simplifying-m...](https://apigee.com/about/blog/digital-
business/simplifying-microservices-management)

~~~
tyingq
That's an example of the breakage though. Apigee's cloud runs in only 2
specific AWS regions. So once you tie all these pieces together, you end up
with a long path, with some functionality that should be closer to the end
user.

~~~
gregbrail
Apigee's cloud runs in a lot more than two AWS regions today, not to mention
GCP regions, and the whole product can be installed in your own datacenter. We
also offer a "micro gateway" that lets the proxy component run anywhere and
communicate with the rest of Apigee via an API. We'll be taking this hybrid
mode further and the Istio integration is one of the things that will take
advantage of that hybrid model.

(I work for the Apigee part of Google.)

~~~
AmIFirstToThink
>the whole product can be installed in your own datacenter

Could you please provide a link to documentation/articles that showcase this
use case... on-premise installation of Apigee?

~~~
akhimich
Here is what i found [http://docs.apigee.com/private-
cloud/latest/overview](http://docs.apigee.com/private-cloud/latest/overview)

(I work at Apigee)

------
syvanen
There seems to be also other companies involved:

Redhat: [https://blog.openshift.com/red-hat-istio-
launch/](https://blog.openshift.com/red-hat-istio-launch/)

Pivotal: [https://content.pivotal.io/blog/pivotal-and-istio-
advancing-...](https://content.pivotal.io/blog/pivotal-and-istio-advancing-
the-ecosystem-for-microservices-in-the-enterprise)

~~~
gcb0
and isn't the entire solution just packaging a proxy developed and open-
sourced by Lyft?

~~~
dougreid
Envoy is a big part of the solution, yes. But it isn't the only component. A
control plane layer, including an auth component and an adaptable policy
enforcement and telemetry collection component, is included as well.

More info is available in the overview doc here:
[https://istio.io/docs/concepts/what-is-
istio/overview.html](https://istio.io/docs/concepts/what-is-
istio/overview.html)

------
spullara
This may be the most important project in distributed computing in a long
time. It solves some fundamental problems that layer 3 networking has been
unable to tackle. Its initial integration with Kubernetes is great but long
term it could be the basis of all application level communication whether it
is deployed in a container orchestration system, VMs, bare metal or as an
enabler for Lambda (function) frameworks.

~~~
tmsam
What fundamental problems does it solve that layer 3 networking has been
unable to tackle? Not pushing back - just ignorant and want to learn!

~~~
ajessup
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](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.

------
socialjulio
Good Istio links; IBM post:
[https://developer.ibm.com/dwblog/2017/istio/?cm_mmc=dw-_-
soc...](https://developer.ibm.com/dwblog/2017/istio/?cm_mmc=dw-_-
social1705-_-hackernews-_-istio)

Project Calico Network Policy Engine:
[https://www.projectcalico.org/welcoming-istio-to-the-
kuberne...](https://www.projectcalico.org/welcoming-istio-to-the-kubernetes-
networking-community/)

WeaveWorks:
[https://www.weave.works/docs/tutorials/istio/istio/](https://www.weave.works/docs/tutorials/istio/istio/)

RedHat: [https://blog.openshift.com/red-hat-istio-
launch/](https://blog.openshift.com/red-hat-istio-launch/)

------
alpb
Google's announcement: [https://cloudplatform.googleblog.com/2017/05/istio-
modern-ap...](https://cloudplatform.googleblog.com/2017/05/istio-modern-
approach-to-developing-and.html)

Istio website: [https://istio.io/](https://istio.io/)

~~~
ajessup
The Istio blog post is excellent, and provides a lot more detail.
[https://istio.io/blog/istio-service-mesh-for-
microservices.h...](https://istio.io/blog/istio-service-mesh-for-
microservices.html)

------
einrealist
What happened to dumb pipes, smart endpoints? We do the same things again that
we did before with SOA, having hard-to-replace middleware / bus systems.

~~~
parasubvert
The REST architecture always included the possibility of gateways and proxies
in the end-to-end communication path to delegate shared responsibilities out
of the user agent or origin server. This balances the need for centralized
admin of some things and decentralized deployment of other things. Most
microservices systems, even if they're not using HTTP in favor of something
like gRPC, Kafka, or Rabbit, are taking a lot of WebArch lessons to heart in
how they manage their policies, routes, etc. balancing centralized management
over decentralized evolution.

The problem with SOA-in-practice was that everything flowed through a
monolithic ESB as both client and origin server, that needed to have
omniscient knowledge of every route, transformation, etc., and was often a
single administrative bottleneck, fault domain, etc. Some SOA frameworks had
service mesh patterns where you could deploy decentralized engines with your
services, but without cloud IaaS/PaaS circa 2006-2007, there was no way to
maintain/deploy/upgrade these policy agents without a heavy operational
burden.

In sum: CORBA, COM+ or SOAP/HTTP were about mostly-centralized approaches to
distributed services, REST was about extreme decentralized evolution over
decades, most are looking for something akin to a dial where they can have
something a bit more controlled than dozens of independent
gRPC/HTTP/Rabbit/Kafka producers-consumers but not stupid like the SOAP/HTTP
days.

Modern cloud native service mesh approaches like this Istio thing (NetflixOSS
Zuul+Eureka+Ribbon or Linkerd are alternatives) are just decentralized
gateways and proxies, possibly with a console/management appliance that makes
it easy to propagate changes out across a subset of your microservices. This
has the benefit of allowing you to default to decentralized freedom for your
various microservices but for areas where you want administrative control over
policy over a set of them , you don't have to go in and tweak 15 different
configs.

NetflixOSS really pioneered this pattern. Netflix managed to use things like
Cassandra and Zuul hot-deploy filters as the means to updated
routing/health/balancing configs across their fleet of microservices. There
are alternative ways to handle this of course - Hashicorp's Consul piggybacks
DNS and expects your client to figure things out via their REST API or DNS
queries. There are also things like RabbitMQ or a REST-polling mechanism to
propagate config changes perhaps, as not everyone wants Cassandra. New
frameworks like Istio or Linkerd are further alternatives. We're spoiled for
choice, better or worse..

~~~
rdli
Well said.

Besides Netflix, I'd put Twitter as an early pioneer, with their work on
Finagle. Both of these companies, for better or worse, took a library-centric
approach (Eureka/Hystrix/etc or the Finagle lib). This limited their
applicability to the JVM.

The sidecar model that AirBnb pioneered with SmartStack, later adopted by Yelp
and others was the cheapest way to get non-Java langs to have similar
resilience/observability semantics. And now given the popularity of polyglot
architectures, it's probably should be the default choice for companies
adopting microservices.

~~~
einrealist
Maybe a local proxy, deployed with the service, is a good answer to my
objections, rather than having a centralised approach. This can help in
polyglot environments, but remove any limitations a centralised solution would
impose. Something like Istio would be an agent a service connects to locally,
used for service discovery, complex routing or rate limiting. The
configuration is service specific. Load balancing is done by "dumb" proxies,
like in the old days.

~~~
spullara
Maybe you don't understand how Istio works. The Envoy proxy is locally
deployed as a sidecar next to each process. The centralization is entirely for
the control plane. The local proxy uses the centrally managed configuration
for making local decisions about routing.

------
Beldur
Google Cloud Platform Blog Post:
[https://cloudplatform.googleblog.com/2017/05/istio-modern-
ap...](https://cloudplatform.googleblog.com/2017/05/istio-modern-approach-to-
developing-and.html)

~~~
syvanen
There seems to be also other companies involved:

IBM:
[https://developer.ibm.com/dwblog/2017/istio/](https://developer.ibm.com/dwblog/2017/istio/)

Redhat: [https://blog.openshift.com/red-hat-istio-
launch/](https://blog.openshift.com/red-hat-istio-launch/)

Pivotal: [https://content.pivotal.io/blog/pivotal-and-istio-
advancing-...](https://content.pivotal.io/blog/pivotal-and-istio-advancing-
the-ecosystem-for-microservices-in-the-enterprise)

------
moondev
Great documentation and some really great tools included. I was able to get
the platform running in minikube really quickly. Interested to compare this to
linkerd.

~~~
vishvananda
My read of the documentation also indicates a large overlap with linkerd.
Hopefully one of the creators is around and can do a compare/contrast.

~~~
geodel
One important difference I see is istio works only with kubernetes/bluemix,
whereas linkerd has many more deployment options.

~~~
dougreid
The initial release for Istio is targeted at kubernetes. However, Istio is
designed to be easy to adapt to other environments. With community help, we
anticipate extending it to enable services across cloud foundry, VM, and
hybrid clouds. We hope to have major new releases every 3 months, including
adding new environments.

~~~
geodel
Thanks, This is interesting. Currently where I work, we have not started using
containers/schedulers etc. We simply use VMs for services. For now I simply
want to experiment with these new technologies.

------
misterbowfinger
Is this going to be a linkerd vs. istio thing? Like a Docker Swarm vs.
Kubernetes?

~~~
markbnj
I was just wondering the same thing, since we use linkerd in production to
handle thrift traffic to, from, and within our k8s clusters. But this
statement from the examples page put me off a little: "If you use GKE, please
ensure your cluster has at least 4 standard GKE nodes."

~~~
dougreid
That suggestion is based on the requirements of the underlying bookinfo sample
application and is not related to Istio itself.

Disclaimer: I work on Istio.

~~~
markbnj
Thanks for the clarification!

------
theprop
Why does Lyft need 10,000 microservices? They probably have less than 100,000
active cabs at any point in time?

~~~
pscarey
"spanning 10,000+ VMs handling 100+ microservices" ?

~~~
theprop
Sorry...thanks...let me clarify the question, why on earth does Lyft have
10,000 VMs??? They have less than 200,000 rides per day. That's a 1 VM to 20
rides per day ratio.

~~~
curiousDog
I guess they're building with future growth in mind. What if they decide to
expand to the rest of North America in the near future and have a sudden
spike?

~~~
kondro
Then you spin up more VMs when you do the expansion.

------
rexreed
Why aren't more people using MQ for inter-service messaging (something like
RabbitMQ) instead of HTTP?

~~~
ldemailly
MQ shines in async calls/event delivery. gRPC / http2 / websockets / thrift is
better for synchronous calls ?

~~~
devlolz
With the ISO/oasis standard AMQP you can actually do synchronous calls without
an intermediary. You also have 'direct' message routing capability with
components like apache qpid dispatch router.

I can't see a reason why one would use gRPC/thrift and then having to build
flow control, delivery guarantees and other messaging features yourself.

~~~
bpicolo
gRPC is built on http/2\. I imagine it supports flow control and delivery
guarantees already? It's just http/2 + protobuf

------
alnitak
Can someone ELI5 how is this relating to, and complementing, Kubernetes? What
does it do that Kube doesn't, and what does Kube do that Istio doesnt?

~~~
dougreid
Kubernetes supports a microservices architecture through the Service construct
and performs rudimentary L4 load balancing and more.

But it doesn’t help with higher-level problems, such as L7 metrics, rate
limiting and circuit breaking.

This is where Istio comes in.

Disclaimer: I work on Istio.

------
fierro
Regarding API management in the context of Istio:

[https://apigee.com/about/blog/digital-
business/simplifying-m...](https://apigee.com/about/blog/digital-
business/simplifying-microservices-management)

------
jrv
Nice to see that this comes with Prometheus and OpenTracing instrumentation!

------
rshriram
IBM's announcement:
[https://developer.ibm.com/dwblog/2017/istio/](https://developer.ibm.com/dwblog/2017/istio/)

------
garindra
Is the sidecar-container-within-a-pod the only deployment option on Kubernetes
currently? Is a daemonset deployment (like what Linkerd does) option currently
in the works?

~~~
kyessenov
We have been looking into a per-node deployment model from the beginning,
which is what daemonset is doing. Things get more complicated across the board
with the transparent traffic capture at the node network namespace level,
invasive installation requiring tight integration with k8s and reconciling
iptables rules, and a more complicated workload identity story. We have
started with the sidecar model, but are certainly interested in more
deployment options

------
graphememes
I'm curious what the benefit of side-loading proxies and load balancing versus
centralization provides?

~~~
zackbutcher
Check out [1] for an overview of the trade-offs.

Disclaimer: I work on Istio

1\. [https://groups.google.com/forum/m/#!msg/kubernetes-sig-
netwo...](https://groups.google.com/forum/m/#!msg/kubernetes-sig-
network/weni52UMrI8/TUQ8fN5-DwAJ)

~~~
graphememes
I'm not seeing any benefits though, there are a lot of assumptions and
emotional comments here not any hard evidence of it being a better solution.

There is actually a lack of it, there is only connotative evidence here in one
comment that refers to "hey look linkerd does this at scale" that sounds nice,
except that is not necessarily the point or the case.

How is having side-loaded proxies _better_ or more beneficial than having it
separate? It doesn't appear to be discussed or mentioned in this thread, all
of the arguments made for doing so are equally applicable to the separation of
the proxy.

~~~
kyessenov
Early in the design, we have looked at various modes of proxy deployment and
found that there are pros and cons for each. You are right that the sidecar
model is not always the optimal choice, it's a trade-off (see the referenced
document in the discussion). The sidecar is the least invasive approach with
respect to Kubernetes and was the focus for the initial release. We'd be happy
to hear arguments for a more centralized proxy model, and if needed invest
effort into making it happen.

------
misterbowfinger
[https://istio.io/docs/concepts/network-and-
auth/auth.html](https://istio.io/docs/concepts/network-and-auth/auth.html)

No option for OAuth2 or JWT? Maybe I'm not understanding the problem Istio
solves vs. Envoy

~~~
wenchenglu
Good question. The auth work for this release is mainly focusing on service-
to-service authentication. We are looking into adding OAuth2 and JWT support
for enduser auth in the future release.

Disclaimer: I work on Istio

~~~
misterbowfinger
Cool. Also - what does Istio use for persistence? I imagine it's gonna persist
the data for auth'ing stuff somewhere.

~~~
lookuptable
If you're referring to where the key/cert is persisted, it's currently
facilitated by Kubernetes' secrets and mounted into Envoy container

Disclaimer: I work on Istio

------
Yhippa
> Lyft developed the Envoy proxy to aid their microservices journey, which
> brought them from a monolithic app to a production system spanning 10,000+
> VMs handling 100+ microservices.

Are those numbers right? Wouldn't it be the other way around realistically?

~~~
threeseed
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.

------
gshulegaard
There is a lot to like about this move. Microservices and service mesh's are
certainly an interesting area right now...and this represents a big push from
some big players.

------
wwulfric
I know it's a higher architecture. But could anyone tell me the difference
between istio and springcloud/dubbo?

------
verst
In case anyone is interesting in using Azure Container Service with the
builtin Kubernetes orchestrator, I wrote an easy tutorial [1] for deploying
Istio.

[1]: [https://readon.ly/post/2017-05-25-deploy-istio-to-azure-
cont...](https://readon.ly/post/2017-05-25-deploy-istio-to-azure-container-
service/)

------
sheetal7
This is a great product! Kudos!

------
graycat
> 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.

~~~
graphememes
I'm not sure if you're trolling or genuinely don't understand, so I think I
can help you a little bit.

Microservices are services that are generally containerized and are easily
distributable through some form of a network to be easily replaceable parts.
These services are defined by a specification where they do a single task,
expose some endpoint or API and are composable with other microservices.

There is a need for these services to talk to each other, and to external
services and to do this they use some form of a meshing network. These
networks right now are done through container networks, such as the Docker
Overlay Network, the Kubernetes "POD" system, linkerd, serf, and a multitude
of other systems like istio. It is a space or area of concern, because there
is no singular approach to all these differing container services right now.
So all of them are vying to be the one that wins.

The issue that I find here is that you're looking in an English dictionary
while these are technical networking / operating system terminologies and that
dictionary will not help you in this namespace.

This page might help you a little more:
[https://en.wikipedia.org/wiki/Microservices](https://en.wikipedia.org/wiki/Microservices)

Also: Service being, a backend or software that performs some action based on
an input / output

~~~
graycat
Nice. Thanks. I'm perfectly serious -- obviously the OP didn't define
microservices -- you did. Good for you. Bad for the OP.

Okay, microservices look like what used to be called _agents_. For their
communications there have been various efforts at ways to define data
_objects_ , complete with a _registration hierarchy_ (that is, a case of
public naming) and an _inheritance hierarchy_ (roughly like some of
inheritance in some cases of object oriented software). So, we had _object
request brokers,_ CORBA or some such. And we had the ISO/OSI CMIS/CMIP where
ISO maybe abbreviates international standards organization, where OSI may
abbreviate something in French, where some international telecommunications
group, maybe part of the UN, was involved, and where CMIS abbreviated common
management information system, and CMIP, common management information
protocol, all mostly aimed at computer and network system monitoring and
management. The work was somehow close to some old Unix work with management
information base and ASN.1 -- abstract syntax notation version 1. Whew!

Okay, if there are to be lots of such microservices, as you nicely described,
then they will want to be able to communicate. So, maybe they will want to use
JSON (as I understand it, essentially just name-value pairs -- from Google,
JavaScript Object Notation and, thus, maybe more than just name-value pairs),
other _mark up_ languages,

[https://en.wikipedia.org/wiki/List_of_document_markup_langua...](https://en.wikipedia.org/wiki/List_of_document_markup_languages)

etc. But we'd have to suspect that there needs to be some common global
standards and data definitions.

Okay. Gee, in the past I went through a lot of that CMIS/CMIP, ASN.1, etc.
stuff, wrote some internal papers, wrote some software, etc. so was totally
torqued at _microservices_ without definitions. Right, maybe the hidden secret
is that we're supposed to retreat to Wikipedia for the undefined terms and
acronyms -- bummer.

But, I still wonder: How popular, pervasive, important, practical so far are
_microservices_? E.g., are they a lot like _agents_ for system monitoring and
management? Where are microservices getting to be important.

No, I'm not trolling. And with your description of microservices, we're making
progress here.

~~~
gegtik
There's some reading here
[https://hn.algolia.com/?query=microservice&sort=byPopularity...](https://hn.algolia.com/?query=microservice&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

~~~
graycat
Good. Maybe the OP should have given the reference.

My main interest here is not microservices but just to tell the HN and
computing community to be much more careful with undefined terminology and
acronyms.

Here we now have some good descriptions and references on _microservices_.
Good.

My main point is that articles on computing need to have, gee, call them
_links_ , to explain jargon and acronyms, to explain stuff not in an English
dictionary. The OP on microservices I am using just as an example.

To me, poor technical writing in computing and computer documentation has been
one of the worst obstacles to my startup -- darned near killed my startup --
and is a sore point.

~~~
gegtik
I guess my point is that microservices have been well trodden in this forum
context, I would not expect every article to require a basic primer explaining
every concept

------
fnbr
[Deleted]

~~~
jrmcgee
Well surprised or not, what you see in Istio is the result of contributions
from all 3 founding parties. My team on the IBM side did much of the work on
the Istio Manager and added capabilities in Envoy too, such as support for
zipkin tracing.

