Micro-service vs. Legacy Seen in the Case of Netflix

Why are those IT companies now abandoning  the legacy environment and opting for the micro-service environment?

Since several years ago, many IT companies have been switching to the micro-service architecture based environment and thus providing services accordingly.

Main examples are those companies we are familiar with such as Netflix, Amazon, Google, Twitter, Coupang, 11st street, Baemin and so on.

Now, let’s go back to the original question. Why are these companies switching to the micro-service environment?

If you want an answer to this question, you must first consider the legacy environment.

Basic web service builds applications and distributes them to the WAS(Web Application Server). It is an up-time system consistently operating with the configuration of high availability (HA).

Monolithic architecture (legacy) supports speedy and easy development and distribution and there is no problem in the early phase, but as increasingly more users join the service, it becomes a totally different story. There will be more business logics and new functions will be added, thus the application size tends to increase further.

The problem is that as the application with an increased size causes various side effects such as higher code repetitiveness, complexity and combinations, thus as a result, there will be less freedom in build or distribution or repair and maintenance, and also, the entire service can go down due to a single, small code defect.

If service failures occur, then companies will obviously lose trusts from customers as well as financial losses, so their reputation and achievements can be threatened.

​Then, maybe, I can ask these questions.

1. Shouldn’t we be able to normally use the rest of service except for the service with the problems?

2. Is it possible to first separate the service with troubles and then quickly restore it later?

Well, maybe. However, if you look closely at those companies that found their own answers to this question, you can be sure of what the solution is.

Then, we should maybe look at the micro-service that those leading IT companies are adopting. The solution can be found if we are able to independently manage the business service on a small scale.

Now, let’s discuss Amazon and Netflix. Amazon has been preparing the micro-service for 20 years and Netflix has transformed into micro-service as it faced the limitation of monolithic architecture.

The following is an email that Jeff Bezos, the CEO of Amazon sent to employees in 2002.

All teams will henceforth expose their data and functionality through service interfaces.

Teams must communicate with each other through these interfaces.

There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.

All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

Anyone who doesn’t do this will be fired.

Thank you; have a nice day!

<Jeff Bezos email in 2002>

In the above email, 1) through 5) contain the MSA concepts. Surprisingly, in a very remote past, 20 years ago, they were already talking about the micro-service when they were in the era of monolithic service.

The internal platform implemented this way became the backbone of Amazon cloud that we are very well familiar with as the Amazon web service (AWS) was released in 2006.

Now, let’s talk about why Netflix abandoned the monolithic architecture and switched to the cloud service and the MSA environment.

Just like other IT companies, Netflix was initially using the monolithic service based on data center and relational DB.

As increasingly more users are subscribed, the service performance began to lag, then they chose to do a scale-up to improve the performance capacity. But, in 2007, as serious trouble occurred in the DB, the application in service was interrupted, and DVD delivery was delayed for 3 days.

As a result of this accident, Netflix realized the limitation of scale-up and began to transfer its business to AWS cloud that can facilitate a scale-out for more reliable service. In addition, they introduced the MSA architecture to facilitate easy and speedy distribution of application.

With 8 years of hard works, Netflix completed a migration from the data center to the cloud and thus began to enjoy various advantages as a result.

For example, there were an 8 fold increase in the number of users for streaming service compared to 2008 and about 1,000 times increase in the amount of viewed materials for 8 years, thus indicating very active service use by members.

Of course, it is not really a case of black and white to say “micro service is always good.” 

Surely , there are some disadvantages of the micro-service, and there are some considerations to be made when introducing them, but we can understand why leading IT companies are abandoning the legacy environment and switching to cloud and MSA as seen with the case of Netflix.

Here is the summary of advantages and disadvantages as well as characteristics of MSA(Micro Service Architecture) transitions.

Of course, it is not really a case of black and white to say “micro service is always good.” 

​MSA characteristics

• Small service size and independent process operation
• HTTP RestAPI used for mutual calls
• Business function oriented implementation
• Automated distribution machine for distribution works
• Minimal central focused management
• Can use programming languages and data storage technologies suitable for the service.

MSA advantages

• It is an independent service, so it can support a speedy recovery without affecting other service when trouble occurs.
• Service size is small, so it is possible to only scale out necessary service for efficient expansions.
• Improved service speed and productivity compared to monolithic.
• Fast and frequent distribution. (DevOps and Agile software development method used)
• New technology application and library version upgrade with easiness.
• Can use the development language and DB optimized for the service.

MSA disadvantages

• Inter-service calls made through communication, so there can be network transmission overheads.
• Distributed transaction processing technologies are required.
• Can use different technology in each service, so there are more of required technologies.
• Different data saving technology used for each service, so data redundancy should be allowed.
• Lots of distribution and release as the service count goes up, so we must automate every task.
• High level of team maturity required to manage the MSA.

Considerations for introducing MSA

• Is the current service adequate for MSA?
• Is fast and frequent distribution needed?
• Is it performance sensitive service?
• Is the service having distributed transactions?
• Can we allow data redundancy?
• Is there a team of skilled persons to manage the MSA service?

Now, let’s talk about the performance monitoring service that can be used to monitor MSA and micro-service.

Then, how is the Jennifer performance monitoring solution available in the C platform?

The biggest thing about micro-service is that the HTTP Rest API  is used for mutual communication. If there exists the optimal language that can process the service, then there are no restrictions on the development language such as Java, PHP, .NET, Python and so on, and each of independent service communicates with other service to generate massive transactions. Due to the characteristics of micro-service, general APM is hard to monitor.

Jennifer supports the four platforms such as Java, PHP, .NET and Python and it is optimized with the expandable architecture design for clouds or large scale transaction environments, and use of independently developed file DB and WAS load minimization technology can facilitate real time monitoring of performance and transaction data.

Its advantages include being able to quickly find the problematic service through agents and find a solution and take a glance at the interaction of services. It is also great to be able to perform real time tracking of every transaction processed in the micro-service and container (AWS, Docker and K&S).

In addition, it is possible to track specific micro-services with performance delays without affecting every business transaction processed on the micro service base. It is also worthwhile to note that you can use Jennifer’s SFR (Stack Fight Recorder) function to analyze the fundamental cause of performance issues in every platform.

So far, we have discussed the key functions of Jennifer.

We can say, Jennifer ① can perform real time monitoring of applications and analyze the transaction data and ② predict troubles in order to maintain the optimal condition.

I am sure you all know that Jennifer is the number one must have product in Korea with the largest market share in the Korean APM market. For further detailed functions of Jennifer, check the following C platform.

This article was written by Jinhwan Lee of CPlatform,
a partner of JenniferSoft.