Raphael

Sure, yeah. So let̵;s start with my who am I. So I̵;m a platform architect at RightScale. RightScale is a crowd-management platform. I̵;ve been working there for almost eight years. When I started, the whole product was basically a single-raise app, and the platform has grown a lot since then. The last I counted there were about 52 different services running in production, running on about a thousand VM. So I̵;ve designed, developed and debugged a lot of them.

Part of going from this single-raise app to all those distributed services, we felt a lot of pain in having to design API’s the right way. What I mean by that is being able to come up with APIs that are consistent and have standards that are enforceable, so that we can come up and say, “Yep, that API looks good. It follows all standards and we’d be able to integrate that service with the rest of the fleet.”

As you probably know, once an API is alive it’s almost impossible to change it. Once you have customers that start using it or once your internal services rely on it, then that API is gonna be there forever. So it is very important that you spend the time designing it properly.

When we looked at what was available to do that, there just wasn’t much. There were a few tools here and there, but nothing that we felt would be enough for us. So we ended up creating a at the time [unintelligible 00:02:53.10] in Ruby called Praxis, that basically allowed you to write the design code and then the framework would leverage the design in runtime.

Going fast forward, RightScale kind of shifted towards Go, and I thought it will be good to see if we could do something [unintelligible 00:03:12.25] in Go. To be honest, I wasn’t sure initially that will be possible. We played around with a few things, and it took me about a year really to come up with something that started to look like it may work. There two big a-ha moments in that kind of research phase. One was the realization that code generation was the perfect approach for achieving the goal of keeping the design and implementation separate. We were making sure that the design is directly enforced.

[00:03:51.14] The second realization was that the design should be written in a DSL, so that the language used to describe the API used the right terms. You want to talk about resources, actions, responses, requests, and you don’t want to have to deal with programming language artifacts, so that DSL will have to be a Go DSL obviously, so that it could be understood right away, and also so that it’s still possible to use the legal language when it’s needed.

Fast forward a year and a half, I have to say that the result turned out a lot better than I thought it would be, and I think the credit goes to the Go language. The Go language provides a very simple and powerful mechanism to create the DSL. It also has as very good code analysis support, which is essential and a very good code generation package, the template package in particular.

So all of that put together, I think, we end up today with something that is actually very interesting, and we have started using extensively here at RightScale.



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here