In August 2014 Cisco hosted a Meetup Group where Adrian Cockcroft presented on microservices. John Wetherill, of ActiveState, was there and subsequently managed to interview Adrian on the same topic for a multi-part blog series. John has started to publish this interview, with some highlights captured below.
John's first question was about polyglot development, which although often discussed as important to microservices, is not something John sees in reality.
For example Twitter’s microservices are mostly built using Scala, Hail-O (Europe’s answer to Uber) is all Go, and the Seneca microservices framework is all JavaScript. Pivotal themselves is touting Java/Spring as “The Language for Microservices,” and my understanding is that even Netflix has standardized on Java for its Java bindings.
Therefore, what John wanted to know was whether it was better to adopt polyglot when developing with microservices or to stick with a single language?
Adrian first pointed out that Netflix is in fact a polyglot environment, with some parts implemented in python, so how did they add this support to their platform?
[...] to support polyglot Netflix did a couple of things. One is that they open sourced a generic sidecar process called Prana written in Java which interfaces to the platform. They've built custom sidecars for memcached (a C application), Elasticsearch and Cassandra. [...] You put a sidecar on the instance, and the sidecar does the platform chatting and gathers data from whatever you're monitoring and sticks it in the standard monitoring tool.
Then he moves on to the reasons for adding polyglot, not just at Netflix, which essentially boils down to the fact that many companies simply have mixtures of languages being used. There may be a single dominant language for core services, with other languages providing access to them for domain specific reasons, such as being better suited for the problem at hand.
I was talking to group last week who started with Ruby, but now are mostly Node, but they do have a bit of Java in there too. So it isn't a single monoculture, but it is more difficult than people expect to maintain multiple languages.
John's next question was about how companies that don't necessarily have the resources or buy-in from management can adopt microservices as Netflix did?
Adrian started to answert his question by first recognising that things did not happen overnight at Netflix and there were no well defined patterns or templates for them to follow:
[...] we started figuring this out in 2008 and we were reading the core white papers by Google and Amazon and taking into account the things we learnt. So we made stuff up, and yes, there certainly were a lot of very experienced, very clever people on board. A bunch of us were over 50 so we've been around. It's not a bunch of young kids making stuff up and thinking we're the first people ever to have done it.
Over the last 7 years much has changed in the industry, with Cloud and DevOps adopted by many companies. Public and private Platform-as-a-Service are no longer new concepts and there are many different implementations that can be chosen by companies to help them. The pieces of the Netflix-like puzzle that were complex in 2008 are no longer that complex or have many other groups and companies working on them to share their experiences.
The other thing is I'm seeing a lot of big boring sounding companies who are well down the microservices path, much further than I thought. Watch the videos from DevOps Enterprise summit. It was a mind-blowing conference for me. [...] Nordstrom's was on stage, saying “OK we figured out how to optimize for speed instead of cost.” The department of Homeland Security talked about running chaos monkey on their production on the systems for processing Green Cards. We’re talking about your green card application, the immigration naturalization part of the US government running Chaos Monkey on their production systems! I almost fell off my chair.
Adrian goes on to talk about how other companies, such as Target and Macy's, were also talking about using microservices and how it had happened for them. They wanted to move faster in general and heard about DevOps, or someone had purchased one copy (or 23 in the case of Target) of Gene Kim's Phoenix Project. This causes them to try it out on small projects to see whether it really works for them.
And they measure and observe it, and they found they typically went from releasing once a quarter or once every six months to get a product release, to releasing a hundred times a quarter. They're seeing two orders of magnitude increase in release frequency which means the size of the chunk of work being released is a hundredth as big as it was before. The flow works because these units of work are small, easy to understand and easy to roll back. The number of production issues and outages they have is an order of magnitude less than it was before.
And as Adrian then mentions, the next obvious question for the Target's and Macy's is: what does it cost? Due to the fact that these companies are not spending as much on building things that they don't need, or buying machines that sit idle most of the time, Adrian summarises that the cost is about half of what they used to spend.
Turns out you actually can get more done with the same or less people, and you're delivering products to customers that they like better and you’re typically doing it faster than your previous teams could. So you're getting stuff done quicker, you’re using fewer engineer days to do the work and you're doing it more effectively using fewer machine days to roll it out and make it work. The whole system becomes more efficient with less waste which is the whole principle of agile.
We'll look at the next part of the interview once it appears and try to summarise it again here.