The Story of Why We Migrate to gRPC and How We Go About It

The Story of Why We Migrate to gRPC and How We Go About It - Matthias Grüter, Spotify

CNCF [Cloud Native Computing Foundation]

День тому

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
The Story of Why We Migrate to gRPC and How We Go About It - Matthias Grüter, Spotify
At Spotify, we have historically built services based on our own proprietary messaging protocol and framework. Last year we finally kicked off the daunting multi-year task of migrating everything to gRPC. Migrating over 1000 services to gRPC poses interesting challenges, many of them are not only technical in nature: they boil down to questions of engineering culture and leadership at scale: How do you get 200 autonomous engineering teams to align on something as fundamental and cross-cutting as a new RPC framework? How do you roll-out gRPC at scale whit minimal disruption to both the organization and to the end-user? This presentation will address these questions alongside more technical discussions of advanced gRPC concepts such as interceptors, deadlines, and effective schema management and how they are essential in large distributed systems.
sched.co/MPY3

КОМЕНТАРІ: 14

@yoloswaggins2161 4 роки тому

Why didn't they open source hermes so an ecosystem could grow around it?

@yoloswaggins2161 4 роки тому

@@kennguyen9931 I don't think this is very plausible. No coder at spotify would hard-code credentials into their code if that code would ever be checked into a repo. Beyond that even if they did it's a problem that's so easily solved that I doubt it would be a blocking issue for long.

@willinton06 3 роки тому

Yolo Swaggins you’ll be surprised at things engineers do when they feel safe

@lordmushroom723 2 роки тому

@@kennguyen9931 lmao troll

@k42p3r 4 роки тому

Interesting story. It sounds like a great technology for Spotify to try out due to the drawbacks of Hermes and their need for high performance. That said, I don’t see gRPC as a competitor to existing REST APIs since they IMO have a higher level of compatability and are easier to work with. I’m looking forward to see how this hot technology will evolve the next few years.

@jimmiedoe1114 4 роки тому

ukposts.info/have/v-deo/ip-JiJWJop1prXU.html

@timzeynalov3537 2 роки тому

so loooowww

@markcuello5 Рік тому

HELP

@jkuang 2 роки тому

Every time when we finally reach a CLEAN API SPEC LIKE REST, some stupid people would come up with something else claiming "it could solve some problems for you." Complicated API SPEC is the reason that plagued us for decades. Keep the API SPEC simple. Save yourself YET ANOTHER TRIP back to memory lane of complication!

@JosueAdeLima 2 роки тому

Well... nothing is perfect, and also is how technology works, I use gRPC every day at work and It save us a lot of problems by the use of strong types. With a large setup of micro services you'll find errors with REST API's.

@jkuang 2 роки тому

@@JosueAdeLima I heard this kind of talks many times over the years. At the end of the day, it gets so complicated and we just abandon and move forward with REST. And someone will hold onto this fringe solution "that promised to solve your problems" and suffer silently for the rest of their career at the job. Repeat the same tragic story all the time, always have a rosy beginning and always ends up in a dark room silently suffering for as long as the application is running.

@JosueAdeLima 2 роки тому

@@jkuang Well I don't think you should suffer from your job, or stay on dark rooms, It's just a job. On the other hand is really bad to see one solution as the only one valid. REST serve its purpose, gRPC serves another one, being flexible is what makes this industry so great! Don't get in love with technologies or your code :-), get in love with the Money.

@johanw2267 Рік тому

Well programmers love to solve problems. So every tech you use is an iteration of an older tech in order so solve problems from the previous version. Does graphQL need to exist? It evolved from REST and some find it better, some do not. That is just how it goes in this industry. If things work you do not need to change it, but obviously for Spotify they hit a roadblock with their DIY solution and had to change. Use the right tool for the job.

@jkuang Рік тому

@@johanw2267 In many ways, people came up with something with the vague pretend that they are solving some edge case problems. But it is just yet another attempt to re-invent and feel relevant. I think invention is really needed to clearly solve a real problem but sooner or later you will realize that in most cases, they just highlight "some" problems that could have be solved with an existing CLEAN SOLUTION, and chose to come up with something else.