How We Improved Our API Response Time by 95%(blog.maxcdn.com)
blog.maxcdn.com
How We Improved Our API Response Time by 95%
http://blog.maxcdn.com/improved-api-response-time-95/?comments=1
1 comments
Hi - there was a comment put in from the blog: "Weird, you built two prototypes but you have based your decision on theory. Any benchmark of the two prototypes which could show that your decision was the right one ?"
Hey there! Answered on our blog, but also wanted to post our response here as well:
Hi Matt! Great question. There was prototype code in both GO and Node.JS. The code written in GO was not fully tested in a "production" environment because we made our decision on quite a few factors early on.
GO is fantastic as faster development cycles and performing CPU-bound operations. However, there are places where GO just isn't the right choice for this particular scenario.
We use GO in various parts of our infrastructure where the piece is small and meant to process lots of information. However, provisioning zones is not so much a CPU-bound operation but an external operation bound operation. We have to wait for nginx to do various operations before control comes back to us. We're not crunching numbers, we're writing to the data storage for our provisioning information. This type of operation is further bound to external factors.
GO is also a language that doesn't have massive adoptability yet. There's a lot of 3rd party vendors where we use their technology and rely on their SDK's to interact. Many of those vendors may not have written a GOlang library. Sure, there's bindings to other languages; however, this is a small hoop to jump through. Is our provisioning dependent on such libraries right now? Not so much. However, you have to keep an eye on the long-term future.
We also isolate our backend systems at various levels and have them communicate via REST API's. You can certainly write solutions in GO to have a REST frontend; however, it's not the ideal case for GO, in our opinion. There's a fair bit more scaffolding to put in place which means more code to maintain. There are some some great libraries out there for this (check out https://github.com/ant0ine/go-... however, we have to compare the amount of code we need to write to support the environment we run in, versus the amount of code that focuses on the core problem we are trying to solve.
Also, it's pretty difficult to find GO rock star engineers to hire. We have a couple amazing ones here in our team and we only hire the best. By the way, if you ARE A GO rock star, we want to talk to you. Reach out to me.
So, what we really wanted to find was a replacement language that is quick to develop, does well with asynchronous operations, which are external operations and I/O bound, and is easy to maintain with our existing engineering team as well as future members.
When deciding what platform or language to use to solve a customer facing problem, you sometimes can't make the decision on numbers alone. In the end, node.js has the right balance of features to give us the ability to rapidly develop solutions that are I/O bound and has the support and maintainability to ensure we can keep developing the best customer solution possible for this specific use case.
Hi Matt! Great question. There was prototype code in both GO and Node.JS. The code written in GO was not fully tested in a "production" environment because we made our decision on quite a few factors early on.
GO is fantastic as faster development cycles and performing CPU-bound operations. However, there are places where GO just isn't the right choice for this particular scenario.
We use GO in various parts of our infrastructure where the piece is small and meant to process lots of information. However, provisioning zones is not so much a CPU-bound operation but an external operation bound operation. We have to wait for nginx to do various operations before control comes back to us. We're not crunching numbers, we're writing to the data storage for our provisioning information. This type of operation is further bound to external factors.
GO is also a language that doesn't have massive adoptability yet. There's a lot of 3rd party vendors where we use their technology and rely on their SDK's to interact. Many of those vendors may not have written a GOlang library. Sure, there's bindings to other languages; however, this is a small hoop to jump through. Is our provisioning dependent on such libraries right now? Not so much. However, you have to keep an eye on the long-term future.
We also isolate our backend systems at various levels and have them communicate via REST API's. You can certainly write solutions in GO to have a REST frontend; however, it's not the ideal case for GO, in our opinion. There's a fair bit more scaffolding to put in place which means more code to maintain. There are some some great libraries out there for this (check out https://github.com/ant0ine/go-... however, we have to compare the amount of code we need to write to support the environment we run in, versus the amount of code that focuses on the core problem we are trying to solve.
Also, it's pretty difficult to find GO rock star engineers to hire. We have a couple amazing ones here in our team and we only hire the best. By the way, if you ARE A GO rock star, we want to talk to you. Reach out to me.
So, what we really wanted to find was a replacement language that is quick to develop, does well with asynchronous operations, which are external operations and I/O bound, and is easy to maintain with our existing engineering team as well as future members.
When deciding what platform or language to use to solve a customer facing problem, you sometimes can't make the decision on numbers alone. In the end, node.js has the right balance of features to give us the ability to rapidly develop solutions that are I/O bound and has the support and maintainability to ensure we can keep developing the best customer solution possible for this specific use case.