Why does Lyft need 10,000 microservices? They probably have less than 100,000 active cabs at any point in time?
Google and IBM announce Istio – easily secure and manage microservices
91–100 of 123 posts
Re: Google and IBM announce Istio – easily secure and manage microservices
#92Why does Lyft need 10,000 microservices? They probably have less than 100,000 active cabs at any point in time?
"spanning 10,000+ VMs handling 100+ microservices" ?
Re: Google and IBM announce Istio – easily secure and manage microservices
#93Why does Lyft need 10,000 microservices? They probably have less than 100,000 active cabs at any point in time?
They don't have 10,000 microservices, they have
> a production system spanning 10,000+ VMs handling 100+ microservices.
Re: Google and IBM announce Istio – easily secure and manage microservices
#94Why does Lyft need 10,000 microservices? They probably have less than 100,000 active cabs at any point in time?
"spanning 10,000+ VMs handling 100+ microservices" ?
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.
Re: Google and IBM announce Istio – easily secure and manage microservices
#95Earlier quoted context omitted.
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...
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 beneficia…
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.
Re: Google and IBM announce Istio – easily secure and manage microservices
#96This 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.
I agree with your point about layer 3 networking being unable to easily tackle these problems. I question though, whther Istio is "all that".
Securing an endpoint without requiring changes within the endpoint has been done for some time - Whale Communications, which became Unified Access Gateway, F5 Big IP, IBM DataPower... They are called web application firewalls, and unless I'm missing something Istio is no more than that, but targeted at micro services.
Re: Google and IBM announce Istio – easily secure and manage microservices
#97Earlier quoted context omitted.
"spanning 10,000+ VMs handling 100+ microservices" ?
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.
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?
Re: Google and IBM announce Istio – easily secure and manage microservices
#98Earlier quoted context omitted.
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…
Thank you for your opinion and explanation. As long as proxies remain transparent to services, I see no problem. It becomes a problem, when proxies are getting smarter in terms of providing cross cutting features, like routing on payload level (not speaking of message headers) or do authentication and authorization on a per-resource level. That puts constraints on how services are built in this particular environment…
The commercial products in this space (Apigee, Layer 7, MuleSoft and the like) seem to have learned their lessons over the years, but we'll see. Things like Eureka require RESTful discovery protocols that aren't exactly standards, for example, and rely on well-written client libraries.
Re: Google and IBM announce Istio – easily secure and manage microservices
#99> 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 un…
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 f…
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...
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.
Re: Google and IBM announce Istio – easily secure and manage microservices
#100Is this going to be a linkerd vs. istio thing? Like a Docker Swarm vs. Kubernetes?
Spectators love a fight. Ultimately it's more about using the right tool for your situation.
Istio and Linkerd are both very young and the adoption will be with those that really need their unique features. Most companies, including startups, in my experience are using roll-your-own routing/traffic mgt via Consul , or using NetflixOSS' stuff today and probably through 2018. Enterprises are buying API Gateways and the like too - IBM API Connect, MuleSoft, Apigee Edge, etc.
As for K8S vs Swarm, I rarely see Swarm in the wild, really. From my vantage point, the battle has been Kubernetes vs. roll-your-own-Docker vs. Mesos in startups using the pure open source. For enterprises paying a vendor, it's been IBM Bluemix vs. Pivotal Cloud Foundry vs. OpenShift, as they've been making more money out of all these container vendors combined (I work for Pivotal) - probably around $300m+ annually across the vendors. Some just use their native cloud's platform, like AWS container engine, etc.
The main X-factor will be serverless frameworks eventually taking over, possibly rendering today's battles over runtimes somewhat moot.