I. Introduction
I guess a lot of people probably have a question like “What is Microservice?”, Or “Why is it now Microservice but not from the old days, from the day I started learning?” code? “. And basically every time I hear about a Microsoft service, people get a very vague feeling. And I have spent a lot of time to learn about it, and also fortunate to try with a few microservice systems so I would like to have a bit of sharing, so everyone can understand more about Microservice Architecture.
II. Background
To be precise about the context of Microservice or history, etc., it must be quite confusing, and difficult to remember, so I will explain in the most understandable way so that everyone can grasp the most basic way, with the keyword to help you can further research on your own. Now that we have heard about Microservice, what architecture were we using before? That is Monolith . So what is Monolith? Google translate means monolithic =))))) detach, you see the phrase “mono” – it means single (like a single speaker (mono) – double speaker is (stereo)). From that, we can understand roughly that everything we will build on a system, single codebase, all will be compile and deploy simultaneously.
III. So why is Monolith now obsolete?
The first is the development of the Internet, which has started to rekindle the microservice since 2004, but not so prominent. But in recent years, with the explosion of technology with smartphones, Wifi, etc., leading to more and more access to technology services, more technology businesses have appeared to meet the demand. current needs. Instead of just small systems, with news sites, information, and traffic and interaction are not too large, now are social networking services, fintech, development that requires growing faster and faster to meet the growing demand from users. Therefore, the disadvantages and disadvantages of Monolith began to appear.
IV. Cons of Monolith
1. Application Scaling:
With the exponential growth of service companies, their demand for software expansion is also increasing. For example, Facebook initially had a user base of Harvard students but now with the strong growth, they need to expand the system to be able to handle a lot more users. So scaling is an extremely important thing for today’s applications, and that’s something that monolithic applications cannot do.
2. Development Velocity:
At the moment, all companies want to develop features in the fastest way. However, in a large and complex system, adding a feature will be very slow, especially with Monolithic Application. Applying new technology is difficult because the whole application must change. So many monolithic applications often depend on old and outdated technology, leading to changes that will take time and money. And with the current characteristics of small and medium-sized companies, mostly start-ups, constantly changing the spec to suit the needs of the market will make it difficult for Monolithic Application to meet demand.
3. Development Scaling:
Companies often expect their products or businesses to be developed in parallel to minimize development time, but with a monolithic system, even if there are many more developers, it is still impossible to solve. The problem is because when processing code, logic, or infrastructure will involve other parts of the code, it can sometimes lead to waiting for each other, conflict, etc. In addition, with Monolithic systems, it is difficult for the new developers to join the project or the young graduates to grasp such a large and complex system.
4. Release Cycle:
The release time for a large Monolithic system is usually about 6 months excluding the delay due to a number of different factors. Currently, the release time greatly affects the competitive factors of companies. For example, big e-commerce apps like Lazada or Tiki have a lot of events for September 9, October 10, November 11 or December 12. If the development team still uses the Monolithic structure, can it guarantee release features in a short period of time?
5. Modularization:
The components are closely linked, leading to unwanted side effects like changing one component affects another component. The entire application needs to be redeployed for any changes. It is not easy to understand the project because the modules are closely related. A small issue can kill an entire application.
IV. Microservice Architecture
In recent times, a lot of new technologies have been released and have greatly influenced software development such as Cloud Computing, Containerization (Docker, Kubernetes), DevOps. Along with that is the appearance of many new programming languages, such as Golang, Rust, Swift along with the convenience and ease of use like languages such as JavaScript, Python. Some changes on the Software Development model, Waterfall software development model have almost been removed and replaced by the method of rapid, iterative and incremental software development: Agile software development. Computer hardware is getting cheaper, faster and the development of Multi-Core CPU, GPU. New database changes such as NoQuery and New Query have emerged and become a trend.
To address these issues, along with the advantages of Cloud Computing, Containerization, DevOps, modern Programming languages, and the need for modern software development (fast development, horizontal scaling), a Software Architecture Style was developed. developed from 2012: Microservice Architecture. So, what exactly is microservice architecture? There are many definitions of Microservice Architecture and below are my own definitions of it
The microservice architecture is about splitting the system into smaller units that can be independently deployed and communicated through a fairly simple way, with a new language that is fast, light, and together, complete the business in the fastest way. and the best.
The microservice architecture also uses the same technique ( Divide and conquer ) to solve the complexity in systems, and it is similar to the Monolithic architectrure where complex systems are divided into multiple Microservices with the ability to communicate. via external interfaces. The main difference between Modular Monolithich and Microservice Architecture is that every Microservice can be independently deployed, while with Modular Monolithich, modules must be deployed simultaneously. You can understand it in a simple way through the image below 
The monolithic application is a single unit (tightly coupled) like a cube in rubik. Modular applications are similar to Rubik’s, which consist of a lot of small modules, but these modules cannot be separated and must be deployed simultaneously. Microservice is like Lego pieces, we can easily split and reassemble them to form a big block. So we can deploy each service separately, then connect them together, will not reduce the impact on the current system.
V. Advantages of Microservice
1. Application Scaling:
Firstly, microservices are mostly stateless (to understand more about stateful and stateless) and if you use Docker, Kubernetes or Infrastructures, Microservices can be horizontal Scaling in just a few seconds. In fact, the high horizontal Scaling has been used in many large companies such as Netflix, Spotify, Uber, and Google to move from Monolithic architecture to Microservice to ensure the growth of their business. . Second, it will distribute and optimize the system better, for example if a microservice such as intensive processing of machine language, CPU, it is advisable to use specific languages that are optimal for operation. with CPU such as (C / C ++, Rust), or with microservice implementations of logic, or the server will be optimized in programming languages to be easily changed, easy to work for developers (Java, PHP, Ruby on Rails).
2. Development Speed:
Microservice is usually quite small in size (several hundred to several thousand). Due to the size, adding new features in the microservice is often faster.
3. Development Scaling:
Microservices are autonomous and can be independently developed. Therefore, scaling (development, expansion) will be better for developers / teams who can work in environments that are less affected by other environments. The simple understanding is to divide and conquer, so it will be easier to expand. Therefore, companies can easily hire more developers and can scale. Similarly, due to their size, and specificity, developers will be able to capture and integrate faster with the project and with the code. Because this is simply a small part of the architecture to handle, rather than having to understand a very big and messy system like Monolithic.
4. Release Cycle:
Personally, one of the best features of Microservice Architecture is that every microservice can be independently deployed. Since then, the Software Release Cycle in Microservice Applications will be smaller, simpler with CI / CD, and can be released by day / week, something that Monolithic can hardly do.
5. Modernization:
With the rapid development of technology, technological change is a continuous thing, so with microservice it is easier to develop new technology on a new module and then later. that just connecting to it will be a lot easier than before. For Monolithic, this can sometimes be extremely difficult, because the system processing, logic, coding are closely related, sometimes changes are not possible, leading to business or costly costs. and time to rebuild an entirely new system.
BECAUSE. The disadvantages of Microservice
Like everything in life there are two sides to it and so does Microservice Architecture. Microservice solves many of the problems that businesses are facing, resolving the disadvantages that Monolithic is facing, but it is not necessarily a universal key for all systems, and is not always Using Microservice is good as standard, but sometimes we need to balance and find the architecture that best suits it. I have a little time to read about some articles about it such as “Building Microservices”, “Goodbye Microservices: From 100s of problem children to 1 superstar” or “The Death of Microservice Madness in 2018” where the authors Having mentioned the shortcomings that microservice is having and we need to know especially before moving from Monolithic to Microservice. Here are some disadvantages that we have distilled:
1. Design Complexity:
Monolithic architecture gives us a “One size fits for all” type of solution for business applications. For example, if your Web application has thousands of lines of code, Monolithic Architecture will give you quite similar solutions. (Enterprise Java or Ruby on Rails or PHP). But with Microservice Architecture, there will be many solutions (possible solutions) to solve your problems depending on the specific business, customer needs, etc. Therefore, if we apply a solution The “non-standard” approach will lead to many problems (for example, simply buying a childish t-shirt for an adult or vice versa) that will have many business consequences (user experience, turnover v..v). Since then, the design microservice architecture requires a lot of carefulness and needs people who are experienced and highly specialized to understand the nature of their business and customers, which I personally think is not simple. , and not on day 1 and 2 we can design exactly. In contrast to Monolithic, sometimes the development of packages will come with dedicated support from the developers themselves and thus will reduce the initial difficulty in designing the system.
2. Distributed Systems Complexity:
The microservice is known as a distributed system and surely we have heard that it is quite confusing and headache (sometimes even unknown), and it is actually quite is complicated. I won’t say much about the distributed system but with it there are many difficulties that surely for those who do not have much experience will be difficult to solve and overcome.
3. Security:
Security in Software Systems is usually something that anyone can see but nobody wants to mention. Securing an application is hard, so securing a different set of microservice and countless distributed links is really something trivial.
4. Data Sharing and Data Consistency:
Ideally, each microservice should have its own Data Store. The downside is that Microservice needs to share data with each other to ensure the Business Goal. Data consistency is a challenge because identifying particular data with large data is not easy
VII Summary
This article seems to be understandable at first, but more and more abstract later, partly because the microservice topic itself will make people quite vague and a little hard to imagine. Not to mention some of his titles left to him, but simply because I do not know what kind of translation anymore. In the next article, I will list about more specific case studies so that everyone can see it less ambiguously. Thank you for reading and apologizing to me for the slightly confusing article