Presentation: Microservices: State of the Union

Location:

Duration

Duration: 
10:35am - 11:25am

Day of week:

Level:

Persona:

Key Takeaways

  • Hear from one of the Microservice thought leaders about the latest changes and movements in the space.
  • Understand some of the successes and failures of adopting Microservices.
  • Get a view of what’s next with Microservices and learn some of the techniques that have led to highly successful deployments.

Abstract

Adrian Cockcroft has been at the fore front of the MicroServices revolution and helped coin many of the patterns and techniques that define that space. He will address the current trends and successes in this domain in terms of companies who have adopted this style and how they currently fare. He will also share his insights from the ring side view he has gained by observing companies via his Venture based interactions.

As attendees you might be aware of many larger companies such as Netflix or Uber that have embraced Microservices, but are concerned if that is the right choice for you. Adrian's experience observing various companies go through this change will help you either pursue this journey with confidence or conversely stick to your Monolithic approach.

Note: This is a portion of a full podcast with Adrian Cockcroft. You can read the full show notes  and listen to the podcast on InfoQ.com. You can also subscribe to all future podcasts by following us on our RSS feeds on InfoQ, SoundCloud, or on iTunes.

Interview

Question: 
What is the state of the union with Microservices today?
Answer: 
I did a talk at DockerCon Europe around a year ago, and what I did there was try to set out all the different ways people were approaching Microservices at the time. I said: “This is the Netflix flavor approach,” “This the Twitter flavor.” One of the things I observed was that it seemed to depend on what your base language was where you ended up. If you were a bunch of Java developers, then you pretty much go “Well, there is this Spring Cloud thing that looks pretty helpful,” so you naturally end up in a fairly Netflix-y oriented environment because Spring Cloud plugs into the Netflix open source tooling. Netflix is largely a Java shop.
That’s one space. Then, if you are into Scala, there was Twitter that has done a lot of work in Scala and have open sourced tooling around that. It is a different flavor, and there are just some different base packages you would use for communication and tracking things. Then there is Go and Node. Those are the main other languages I think I picked up on. There are few Go based frameworks and some Node based frameworks. Most of these things were emerging a year ago.
I tried to create a little taxonomy (or a bunch of buckets). You need to pick a way to do communications, and you need to pick a discovery mechanism, a container model and all those kinds of things.
This was at that time the current state of the art. It was early playing around with the Docker related services and tooling. A year later, we’ve gone from a situation where a few years ago you had to invent this stuff yourself. Then a year ago, there were a bunch of nascent projects and brand new things you could play with. The situation now is there is too much to choose from and everyone is in analysis paralysis because they can’t decide which container scheduler they want to play with because there is a new one every week.
If you are coming from here, then this one makes sense. If you are coming here, this one makes sense. If you are focused largely on premise, you will probably come up with something different than if you are on a public cloud. Or if you are on a small scale, there are different optimizations from really large scale and things like that.
Question: 
Is the microservices architecture always the right approach for all companies or is there a time when it is the wrong approach?
Answer: 
It is usually wrong to start with it if you are building something simple, and you are a startup. You can build a Ruby on Rails system in an afternoon. It will be functional, and it will be reliable. You won’t have many features in an afternoon but it will be up and running. If you start designing a Microservices architecture first, you will be weeks in before you get the first thing up. You have got too many choices to make. So people typically start with something more like Ruby on Rails (or whatever, some variant like that) some packaged front-end with a single back-end.
Then at some point, you outgrow that. You have got too many developers, and they keep breaking each other’s code.The system starts falling over because you changed one piece of the system that broke everything else. So there is a point at which the team gets big enough. Typically, it’s not worth splitting up until you have a bit more than a handful of people. Your code should be in one monolithic place to start with because it doesn’t make sense to spread it out. But if you want MySQL, Redis, and NGINX (all those things), you just don’t go and hand compile those into one image. You generate a Docker Compose file and pull them from Docker Hub or something.
People generally have an architecture that is built out of a bunch of off-the-shelf Microservices. Then they have their code in one block in the middle talking to one database with one schema, and the problem is that, as it grows, there is a point at which you have to say: “You know what? I need a second database. I need a third database. I shouldn’t be mixing unrelated concerns in the same database and I need to split up some of the code that I am building into a separate system.” Now, how do you find these other systems and how do you distribute them?
Typically, when you get into scaling the team and needing to be more highly available, there’s where you need to get into Microservices, because you are building a distributed system at that point. Once you get to about 100 people, a monolith is pretty hard to run. It can be done but it is a very, very difficult thing for most organizations to efficiently build something that has got hundreds of changes going into each release. It is just too hard to work out what broke what.
Question: 
Have Microservices reached critical mass?
Answer: 
It’s not critical mass yet. There was a couple of Microservices conferences at the beginning of last year. There is one called microXchg in Berlin (which started off as a meet up) and it exploded into a 300-person conference. Everybody who is anybody in Microservices went to. That was the initial coming together for Microservices. We did that again this last February. Again, a relatively small conference with a very high proportion of the people that wrote the books on Microservices, and the people that are going around talking about it. We just got together to kind of swap ideas and see where we’ve got to.
What you saw last year was a software architecture conference discussion and a developer topic. What you are seeing this year is it’s moved up to the management chain. There is usually a management buzzword of the year, right? Like, have you done Big Data yet? Have you done Cloud yet? Have you done containers yet? So last year it was probably containers. There are a number of these buzzwords. But one of the standard ones last year was “Have you got a Docker strategy? Have you figured out how to do containers?” Then if you actually start doing Docker, that is all about Microservices. What you are seeing this year is people at management level talking about breaking up the monolith to go faster, and you are hearing Microservices thrown around by C-level execs.
It is a bit of a caricature but I am seeing discussions by people who aren’t in the software architecture space, where they are using the word. There is a reasonably broad understanding of what it means now. Although, it is still a bit nascent in terms of tooling in some respects. It’s getting more mature in terms of just general production use and people understanding it. So, it has sort of arrived.
The other thing that is coming up right now is serverless computing. Where you take Microservices down to individual events, fire up a service just to run that one event and then shut it down again. It is event driven. And that works pretty well for the back-end event flow business logic side of a lot of systems. That is the new hot topic in the architecture world: serverless. AWS Lambda is now being used in production. Google, Microsoft and IBM have all released direct clone/competitors to it for cloud use (and on premise). There are a few startups and frameworks, but it is still pretty early and issues to be solved. I don’t think there are many of the major monitoring tools that currently have any clue how to monitor serverless systems for example.

Speaker: Adrian Cockcroft

Tech Fellow @BatteryVentures best known for Microservice/Cloud Architectures @Netflix

Adrian Cockcroft has had a long career working at the leading edge of technology. He’s always been fascinated by what comes next, and he writes and speaks extensively on a range of subjects. At Battery, he advises the firm and its portfolio companies about technology issues and also assists with deal sourcing and due diligence. Before joining Battery, Adrian helped lead Netflix’s migration to a large scale, highly available public-cloud architecture and the open sourcing of the cloud-native NetflixOSS platform. Prior to that at Netflix he managed a team working on personalization algorithms and service-oriented refactoring. Adrian was a founding member of eBay Research Labs, developing advanced mobile applications and even building his own homebrew phone, years before iPhone and Android launched. As a distinguished engineer at Sun Microsystems he wrote the best-selling “Sun Performance and Tuning” book and was chief architect for High Performance Technical Computing. He graduated from The City University, London with a Bsc in Applied Physics and Electronics, and was named one of the top leaders in Cloud Computing in 2011 and 2012 by SearchCloudComputing magazine.

Find Adrian Cockcroft at

Tracks

Monday, 13 June

Tuesday, 14 June

Wednesday, 15 June