Mike Hanrahan, Cofounder & CTO, Jet.Com
How ecommerce wunderkind Jet.com has fared using Azure for the last 18 months.
As one of the most awesome companies in the world (and as an Irish man, awesome is not a word I throw around willy-nilly) Jet. com had some pretty unique technology needs when starting up. I won't go into the details in this brief article, but suffice to say that Jet needed a platform to handle massive scale ($20b revenue by 2020) and we needed to build a huge amount of technology in a very compressed time frame (about 20 major pieces of software in about 15 months). I have written before on the reasons why we choose Azure (scale and tooling/services), but I haven't ever shared our actual experience with Azure.
"Azure wouldn't be Azure without a good dose of Microsoft middleware available as a service"
The basics of any cloud services are of course storage, network and compute and here Azure has proven to be more than solid for us. They have configurations available for pretty much any conceivable workload, from high compute, high bandwidth to massively scalable spinning disk storage to fast local access SSD. Of course Windows VMs are in abundance, but there is first class support for Linux as well (at Jet about 50% of our IAS machines are Linux). In fact, give that Jet’s platform is a blend of Linux and Windows, Azure’s commitment to both OSs made it really stand out among the competitors.
One thing to note here, and this is true of any cloud provider, is that the engineering teams really need to understand the detailed characteristics of the VMs they are working with. Although we hired a fantastic bunch of engineers at Jet who are well versed in building distributed systems, lack of deep understanding of the VMs caused us to unfairly make Azure a whipping boy for performance problems. It took us a while to really cut our teeth on building massively scalable systems on what is effectively commodity hardware, where you have to know how things like IOPs limits, network limits, network attached storage and more, to impact system behavior.
Azure wouldn't be Azure without a good dose of Microsoft middleware available as a service. The leader is of course SQL Azure, which is basically SQL Server as a service. Although early incarnations had considerable feature set divergence from SQL Server proper, the gap is narrowing quickly and we are quite happy at Jet to move a lot of our relational workloads over to SQL Azure. As I mentioned with the basics above, it took us a while to engineer around the fact that you can’t always just add more hardware, but in the longer run not having to run our own SQL Server machines is a huge win for us.
As you would expect, Azure has good support for most services and components that comprise a large scale system. Some of the key ones we rely on at Jet are:
Azure Redis: Does what it says on the tin. Just don’t try use it as a database. It’s a cache (a lesson we had to learn a couple of times!)
Azure Websites (aka Web Apps): Again, does what it says on the tin, but this time so much more. This is basically IIS and Kudu working together to host web sites. At Jet we run all our front-end Node.js web sites on this service along with a lot of our back end APIs. It has some really nice features that allow fast auto scaling, load balancing, multi data center operations (in combination with Azure Traffic manager), diagnostics, and continuous deployment from Git and other products.
Azure Service Bus: Like any good scalable system, at Jet we use a lot of message bus and queuing patterns in our platform (our whole platform is largely event based in fact). Service Bus and Azure Queues do the trick here very reliably.
One of the things that has taken us by surprise with Azure is the pace of innovation. In what is a very competitive space, where its likely only a couple of winners will remain standing in the next decade, Microsoft has clearly thrown off the shackles of a staid corporate behemoth and are innovating like a group of startup engineers with fire in their belly. We have seen countless new features, tools and services come online in the last 18 months and the 2016 roadmap looks just as exciting. This pace of innovation has definitely allowed Jet to take on some tech debt in some of our systems, comfortable in the knowledge that it will be paid down quite quickly when the requisite Azure service comes on stream.
The most cogent example of this is with respect to provisioning resources in Azure. When we first started Azure didn’t have the APIs, SDKs and templates to allow us to really define our topologies of services and resources in a declarative way. To create a truly idempotent set of scripts and definitions that represented our environment was impossible. At some point we always ended up having to back to the portal to tweak some feature or push a button. However, after a lot of work with the Azure team, within 12 months this problem had largely abated. We can now spin up pretty much anything we need in an “infrastructure as code” way.
Clearly I have only had room to scratch the surface of our experience with Azure, but on the whole I would said it was extremely positive. Although it took some work, we went from a few raised eyebrows in the early days to a good appreciation of what the platform can really do some 12 months later.