By now, all of us know Netflix and have used it. We should also know that because of the uptake in streaming services in general, traditional DVD rental services had to either adapt or face bankruptcy. Lovefilm, a more traditional DVD rental service was acquired by Amazon for £200m which became Lovefilm instant, a streaming service, and finally Amazon prime instant video. Blockbuster wasnt so adaptive….
Netflix themselves are the poster child for Amazon Web Services. To me, the fact that they’re running their platform on what’s essentially an outsourced datacenter isn’t massively interesting by itself. The reason they’re an interesting case is because of the way they were able to utilize public cloud to scale at an incredible rate. Within 6 years Netflix on the scene, Blockbuster was bankrupt.
Whats even more unusual is that in the spirit of open source, Netflix have completely shared their experiences, their content and their code. This use case video is an example. But why did they do this? Well it’s one of the ways that they show they’re a transformational company, which looks good to share holders, but it also brings in new talent, such as rock star developers who only want to work for the best companies. It also allows us to learn from their experiences and apply them to other areas of business.
So how did they do it? To achieve this feat, the developers at Netflix had to write code in a completely different way to any of its competition, which meant a transition in their culture (DevOps). Perhaps more importantly, it meant a transition into a new type of application architecture, known as micro services.
One of the benefits of cloud, both public and private is scalability. because of automated deployment capabilities, with an on-premise solution you are only limited by the capacity you have in your data center. With a public cloud, you are only restricted to the depth of your pocket to pay for capacity. This allows for almost unlimited flexibility to increase resources to meed demand. Maybe you’re a retail company who has huge demand once a year on Black Friday. Because of this, the constraints now fall to the application itself and how it can cope with this scale.
Designing for Failure
Developers are now thinking in a different way. In a DevOps culture, they actually care if the application fails. It’s now part of their remit to ensure the operation of the application in production. So how do you design for failure? For years we have been running highly available applications by running n+1 architectures, essentially duplicating the resources so that if the first fails, the service stays up. Imagine you have a small piece of code in your very large 3 tier application which contains a bug. This brings down one-third of your application. Bringing this back up can take time.
So what a micro services architecture does is to break the application up even more. Think about which are the services within application that absolutely cannot fail, and which can. You then have the ability to create a more intelligent resilience. In web scale applications, services can be spun up in containers for very short periods of time, only being run (and taking up resources) when required.
The image i’ve made below is a typical visualization of showing the major differences between the traditional “monolithic” architecture and the micro services architecture. As you can see the traditional architecture of an application is highly structured. Most of us are familiar with the 3 tier app. Web, App and DB. These are all dependant on each other and wrapped up into a single service. The major difference you can see on the right, with the micro services architecture is that there are a lot more components. An application, or multiple applications are consisted of multiple components, completely decoupled from each other. These services can run independently from each other. They essentially carry out a specific task with limited dependencies.
Adopting a DevOps culture isn’t required to design in micro services and vice versa, you don’t have to design in micro services when you’re DevOps. It does help though and now the two tend to go hand in hand. Because of much shorter release cycles, you can now more effectively decouple your application and release micro services more often.
A monolithic application is released into production every few months typically. The developers have done their tests and are confident, its been through testing and quality assurance, so next everyone gets into a war room and stays there until the application is running in production successfully. This is always a slightly scary time, and usually means ordering a lot of pizza and red bull. With a micro services architecture, you can release code into production much more frequently. As you’ve designed for failure, you can push it through and monitor the negligible effects, then push through something better, and so on. Amazon went on record in 2011 saying that they release code every 11 seconds on average. Every 11 seconds 4 years ago! With no more pizza releases, maybe Domino’s will be the next to go under to micro services?!