Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2018 (Copenhagen), 14 Nov 2015

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: A Brokerless REST Interface for gRPC Services - Roman Zimine, Turbonomic

Description

Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)

A Brokerless REST Interface for gRPC Services - Roman Zimine, Turbonomic (Intermediate Skill Level)

gRPC is gaining traction due to its cross-platform, schema-driven interface design, efficiency, and use of HTTP/2. However, transitioning from REST to gRPC has some pain points due to missing alternatives for commonly-used tools. Sending free-form JSON over cURL does not work. There is no integration with Swagger/OpenAPI. Polished alternatives to GUIs like Postman or Swagger UI don't exist. Providing a REST interface over the gRPC services can solve these problems. We present a brokerless solution, using a Protobuf compiler plugin to generate a library of RESTful controllers with Swagger/OpenAPI documentation. This allows each microservice to expose both a REST and gRPC interface with no extra effort.

About Roman
Roman Zimine is a software engineer at Turbonomic building a distributed, service-oriented containerize system for workload automation in hybrid cloud environments.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Hello, my name is Roman I'm from turbine omec and I'm gonna be talking about well broke a list. Rest interface for JRPG services have a bit of a cough. So you may hear that throughout the presentation just bear with me. So the agenda is a little bit long. But each point is it's pretty quick, I'm, basically just gonna go over. You know how we got to the point where we needed to come up with this solution and and then what we did as a quick, spoiler alert.

A

What we did was we wrote a protobuf compiler plugin and like a little mini framework for them to generate spring web rest controllers that we inject into the application.

B

A

If that makes 100% sense, then you know, then you may not have a lot more surprises in this presentation, but then I'll just go into more detail about why we have to do it and how it works so before I get into the actual work that we did. I'll just spend a few minutes talking about who we are, and we I mean turbo nomic.

A

Basically we're you know a company that automates your workloads in a hybrid cloud environment which basically means you know you have your applications running on your VMs or on containers or in any other technology, and we basically match the demand of the application to the supply of the infrastructure.

A

That's kind of the the the marketing spin on things and I'll just quickly go over what that actually looks like in practice. So suppose you know this this cloud here is your your hybrid cloud environment and in this environment you have a vSphere instance, so vCenter a bunch of hosts and the hosts have VMs. You also have an AWS account and you have some VMs running in there, and occasionally you want to move VMs from vSphere over to AWS.

A

You want to resize them as the demands of your you know, applications change and you want to size them down later and you want to know you know when you need more hosts or when you can power off some hosts or when you know, when it's more cost efficient to use the AWS environment or the vSphere environment, and doing that all by hand is like a giant headache, because you know you have to manually connect to vSphere on AWS tweak, a bunch of controls and it in a large-scale environment.

A

That's just really difficult for a single person or even a group of people to do well.

A

What we do is we have an application that you deploy inside your environment and the application does that for you, so it connects to vSphere connects to AWS, connects to all the other types of platforms, and then it basically manages it for you and of course you know there should be an arrow over here, because we have like a UI and API and you can talk to it, but really the vision is that it'll manage your and optimize your data center.

A

So you know you might think that sounds like a neat idea and some other people thought so too. So we got some customers and, as we got bigger customers, we had to deal with larger environments in that application. As you see over here, we have you know this little application here and it it used to be a single Java.

A

You know Tomcat thing, and you know that worked well for, let's say 10,000 entities, but when we want to go from 10,000 entities to you know 50,000 entities to a hundred thousand entities, it proved to not be quite good enough and we're thinking you know. Well, what can we do to have greater scalability and what we decided to do was you know, independently scalable containerized components, also kind of known as micro services. So this is what our microservices architecture ended up.

A

Looking like, so you over here on the left side, you have your vSphere and your AWS again, and you know those are just logical boxes containing the whole environment and inside we have a component I'm talking about logical component. You know the mediation component, which connects to those well to all the platforms that we support using they're externally available api's, and it combines the various data models into a single abstraction, that kind of fits the whole environment.

A

That abstraction then goes out to all these other components that have their own functionality. So, for example, you know we help the analysis engine and that's the one that drives you know. I was talking about matching supply to demand, that's the one that drives all those and tells you what actions you need to take to you.

B

A

Improve the health of your environment, then you have history, which you know, keeps stats and that's everything you have policy which you can use to define certain policies like, for example, these two VMs should always be in the same cluster or you know things like that, and then those components will, you know, be accessible via an external API which includes a UI component and the user that we talked about earlier is over there making you.

B

A

Making rest calls or clicking around in the UI and that's kind of how the whole thing works and there's more components. You know down here, but even with this many you, you can see. There's a lot of there's a lot of green arrows and all the green arrows are some form of communications. So, in the first iteration of this architecture we had two types of communication.

A

The first type was pub/sub with protobuf I mean you're in a JRPG talk, so I assume you know what protobuf is, but basically it's a like binary serialization, you know messaging format, publicly, Google and so on, and then there's we had synchronous calls with Java interfaces hiding spring rest. Yes, we are a Java shop. So all our code is in Java, as will you.

B

A

The demo and the sample is I'm gonna show later are also gonna, be on the other. So you know- and this is what that looked like you know, you have suppose you have an echo component, which you know just has some really simple functionality. You pass in a string and it returns the string, so we'd have an interface that looks something like this and the clients would create an instance or an implementing class of that interface and then on the component in the echo component.

A

You'd have the echo controller, and this is using all the spring annotations, like request, controller request, mapping all that stuff. This API operation here is swagger documentation. It's just annotations that'll provide that you can scan to generate documentation for your REST API and that'll become important in the next point. So you know that worked fine for our purposes, but it had a couple of problems and actually the biggest problem for us was that developers had to do a lot of work to get this. You know create this illusion of our pcs.

A

One of the reasons for that is because, as I mentioned earlier, we were using prototype messages for pub/sub, and then we had to create in between Java objects to kind of work with those prototype messages, because we wanted to have like a nice and documented REST API, and you know going protobuf over rest with the documentation and annotations and all that it was a. It was a big pain.

A

So, basically, every time you create a new interface, you have to, you know, create the relevant objects right, the to protobuf and from protobuf methods and add the you know going back to that illusion. Add the illusion of the you know the method and all the kind of plumbing to get that to work. It was a big pain and we're basically manually implementing a RPC layer. On top of on top of rest, there were you know there were libraries that we evaluated as far as helping us with that, and why should G?

A

Rpc was an alternative approach and then another thing was performance. Now, at the time that we made this decision to switch over to G, RPC performance and, namely speed. Wasn't really a big concern because our major data flows are going over the over pub/sub which which isn't really affected by this, but as we kind of progressed looking at some of the messages and the amount of data that goes between components now it like it's.

A

A good thing that we did is because doing getting the extra speed benefit you know is, is really nice so kind of. After evaluating a few things, we basically ended up trying to go for gr PC as the solution to our problems. You know this is what that echo service might look like in G, RPC I'm, not gonna, do like a long introduction, but just a quick refresher. So you know you have your service, it has an RPC which has a request message and returns a response message. The request message contains the string.

A

The response message contains a string and then.

B

A

Then, on the server you implement about that service, here is just no responding. The next response to the observer and completing a call and the client you create a stub and you use the stub to make a call almost like it's a local call, but not quite so that worked well and it didn't take.

A

We didn't take long to get started with, and you know teaching everyone how to use Jerry, PC and design Jerry PC services wasn't that bad, but we still ran into a particular problem and it kind of circled back to developer productivity again, because you know what happened over the time that we're using rest was we kind of got used to all the tooling that's available for rest, and you know not like the developers would use the rest calls using a curl, or you know, swagger, UI or postman to debug the containers to see you know what targets are defined, what actions are being recommended and so on?

A

And this this was just one GRP see. Well, gypsy, Java and Derby see a 1.0 was being released and there wasn't a lot of equivalent tools for to do that. In the GRP zero there was gr, PC gateway, which you may be familiar with, but it's basically it's a similar thing. It generates basically a proxy that you can kind of start up and then the proxy will. You can direct your HTTP request through the proxy and then it'll make er PC calls to your service.

A

But then, though, you know it required a proxy and it also required us to add. You know well added to our whole tool chain and it's a well, it's a bunch of go code and then getting it to build. Well, basically, we decided that it wasn't ideal and we would want something. That's more embedded into our application and our solution, you know spoiler alert again, is to create a proto buff compiler that would generate these controllers and that could well and then to embed. You know those generated controllers into our spring application context.

A

So and that would look something like this. So going back to our echo service, you know you have the echo request. You have the echo response, you know or you we went over that and then, after you kind of push it through this plugin, it would generate a much more convoluted, looking controller. Well, this is kind of an excerpt because it's it's a bunch of code, but you see here, you know it's echo and it returns the echo response and takes in an echo request.

A

This is the default version and you know and then well one one. Nobody thing is you know the documentation gets copied into this API operation as well, so that when you generate documentation for it, if you want to you'll, have that as well now, I'll just do a quick demo of of what that actually looks like exit this real, quick, okay, so.

B

A

It's the live demo, so we'll see how that works. So here uh I think I, don't know. If you can people see Oh. What does he mean a little bit you zoom in here I.

A

Don't know how does he mean hey? Sorry? Yes, so here you have like a simple, simple application. This is a slightly more fancy echo service. You know here, you can actually create echo objects which have which have this string as a content and that's just to illustrate some additional features, and you know it's pretty straightforward, there's a get, create, update and delete, and this is the implementation of that service. You know it's just backed by a hash map and all the you know, all the calls and I do what you what you expect. I did.

B

A

Error here, if you're trying to create one with an ID that already exists, it'll, throw an error, and then this is the application. It's a spring boot application. We create this G RPC server. Here we add echo service and this delicate here it's for the swagger documentation which what you'll see in a bit. So let me pull this over here as well. So then so we'll just build this real quick and then hopefully it works. Okay and then then we'll run it and after we run it, you can go to.

A

Go to the go to the swagger UI, which is just like a UI on top to the rest, api and.

B

A

See, there's nothing there, because you know there's well. This is without any, without the plugin and and the problem that we were hitting at this point initially was okay. Well, now that we know that we have this, you know we know the services right and we can connect other content components to it. But you know what, if I want to see if echo five exists or what it is all there is no really easy way to do that. So.

A

Going back to I shut this down.

A

Check out the master branch see so here, you'll see this is actually completely unchanged. The application itself, the the service, is also unchanged. You'll see that oops.

A

It's hard to twist my neck: oh okay, you'll see that here we added some annotations to customize the way we'd want these routes to be presented. So you know the get echo would just be like yeah / echo, /id, create echo would be like a post and there's two alternate ways. One is to post the content to the sci-fi coast, life ID and another one is to just post the / echo, with with this crate echo request, which contains an ID and a Content and and so on. And another thing is we added.

A

We add this to the to the configuration of the protobuf maven plugin, which is what we use in java to generate on what to generate per buff out of the proto files, and this is the product and spring rest plugin. So now going back to here do a build should be fairly quick.

A

I'll run it again: okay, so now it's printing and now now you can see there is a co service controller here. So we can.

B

Go over here and we.

A

Can say: okay, well, let's try creating a new, ICO and we'll say content. Let's.

B

A

Hello and ID should be seven and let's try it out, so it returned successfully. The body of the response is this. So that means that if we do, if we can close this, you know if we do a get echo, you know yeah echo seven. We should get the same thing so yeah.

A

We we got this, that we just created and well I mean I can illustrate delete and all that I guess I'll do delete, but yeah then, after that, okay, we don't need it anymore, bye and then, if we so that's successful, it returned the same thing. And now, if we try this out, we'll see, there's.

B

A

Here well, by default it it doesn't throw an error right now. It just returns unsaid instance and then just as a thing with when we're talking about areas suppose I create, you know, create the thing with seven the first time it works the second time I created. It says: oh, it's an error, there's a duplicate ID, and that's because of that error that we defined earlier. So that's kind of that's kind of the gist of it. There's a the HTTP rule that we're using it's like the common Google annotation has.

B

A bunch more features.

A

But yeah I'm not going to demonstrate all of them here so.

A

Let's kind of take at the gist of the demo and now spend the next name, five minutes or so talking about how it works.

A

So the way it works is ma'am at the same way, any protobuf compiler works a compiler plug in the protobuf compiler. When you run it it will you pass it the list of plugins, which is what we're doing in that maven configuration there and then the compiler well right, serialize code generator requests proto's to standard in, and your plugin is responsible for reading those, and it looks something like this: there is a request.

A

It has one file, descriptor proto for each file and the way that our echo service would map to them as something like this. So the service would be. You know in the service, descriptive proto's. The messages would be in the met and descriptive proto's inside descriptor proto's. There is, you know, representations for fields and for methods and all that stuff. So we read that in and then for each file.

A

We can we parse the descriptors and we create Java objects out of them and then once we, you know in the Java objects, I mean there's just a snapshot from from the ID, but the Java objects. You know just contain some helper methods to get information about.

A

You know about the field, so, for example, the echo request would be represented by a message descriptor and then there would be a list of field descriptors that you can get from it and that's where you'd find a field descriptor for the echo field. So once we've parsed the descriptors into Java objects, we make calls through the specific generator to actually generate some code using those descriptors. So it's not actually an interface, but this is like the you know in brackets framework part of this that we have.

A

We actually have several plugins that use the same template.

A

You know we each plug-in just implements these methods and then you know the main framework kind of makes the calls into them. So you know generally message code service, code, enum code, you know the imports and all the other stuff and then once you've generated, you know well yeah, once you do that you're generating the code. So this is, you know going back to the service method. You know here we have response entity. This was echo request. This was echo. This was echo response and so on. So we just here is just using string templates.

A

You could do whatever you want essentially, and then we write a code, generator response to standard out, and that just looks like this, so you know there's a list of file and each file has you know a string and the string is just a code and the code gets written to the file, so yeah, that's kind of it. If you want to take a look at it to see how it works in detail, you can take a look at the common framework over here and rest plugin itself is over here. There's a you know.

A

We did implement this for mostly for ourselves for a QA department and there's, you know definitely a lot of work that could be done to make it 100%. You know production, ready and yeah. So if there's interest like I'm spending some time working in it and it would be cool if other people did as well- and you know if you want to learn more about us and what we do, we have a booth. So you can come talk to us there as well. So that's all and if anyone has any questions.

B

A

So the question is: how do we handle streaming? So this is where that part about you know it not. Being a hundred percent production quality comes in the way we do it right now. Is we just if you're? Let's say if your input is a client stream, then the the relevant rest input, which is be like a JSON array, and if your output is a service streams and it would be a JSON array of the response objects.

B

A

Don't know about Cloud endpoints also, the question was, if I know about Cloud endpoints and how it compares yeah. So I can answer that. If you can give me like a one sentence, summary I could.

B

A

hmm That's interesting, yeah I'll check that out. Yeah I don't want to make assumptions about what it is based on. Based on you know, our 2-minute talk, so oh yeah that sounds pretty cool.

A

All right well yeah! If, if you guys have more questions, you know we can talk after, but otherwise think we're I think we're good. Thank you.