What are Microservices?

Over the course of several past years, the term “microservices” has been a dominant force in application development process. Combine it with the undisputed fact that almost all businesses of all niches cannot possibly compete – or even exist – without assistance from technology and Internet, almost every event and seminar out there will show you how to build an app for your company by utilizing microservices and present you with some examples of big brands in the market that have gained great success thanks to their own version of applications, software, and cloud computing.

Rapid development of cloud computing has made microservices possible, and probably in fact preferable among developers. Rather than trying to build an app in monolithic way, many developers have moved to microservices to simplify creation process, testing, launch, support, and maintenance. Before cloud computing, nearly all apps were built as monolith.

Microservices may also mean you have to learn to read micro-sized characters on your screen

Despite its popularity, there are relatively few attempts to explain what microservices actually are, especially in a language that the average John and Jane would understand. All the terminologies used in app developments sound cool and smart indeed such as software architecture, internet protocols, user interface, programming languages, and all sorts of jargons that only Sheldon Cooper likes to use. Therefore, it is about time that someone tries to explain what microservices really mean, but not in the way like a German examines a hybrid Porsche; let us try to understand it using the same language that our John and Jane use when they try too hard to sound sophisticated about a cup of coffee.

To understand what microservices are, first let us take a detour and go back to monolithic app. In simpleton language, a monolithic application is one built by someone in a basement with computers and peripherals worth hundreds of dollars accompanied by a leftover pizza from yesterday and half a glass of red bull because he does not like diet coke. It can be someone or a team, but the main point is that the application is built from scratch by one party. App development processes including but not limited to coding, testing, deployment, and troubleshooting are handled by a single party only.

On the other hand, an app built with microservices in mind is broken down into (too) many different parts; one team handles the coding, someone else is in charge of user interface, another takes care of payment portals, and so on. Let us say you want to create a music player app with your family. In this case, each member of the family tree handles different aspects of the app. For examples you are responsible for visual aspects, your step sister makes sure it plays various file formats, and your smart grandparents design the equalizers. Instead of doing all the works on separate room in the same house, you collaborate with each other from different places far away connected through cloud database.

Why Microservices are Preferable in Business Sense

At a glance, particularly from John’s and Jane’s points of view, microservices appear to merely overcomplicate an otherwise simpler work. From business and professional perspectives, however, such method can reduce the time and effort to build a fully functioning app. You can almost say that microservices allow for the creation of modular app with interchangeable parts. In the long run such application is easier to maintain for many reasons:

• Each developer maintains its independence. In some ways, this makes the entire people involved easier to assemble. You don’t have to spend time looking for professionals who know it all. What you need is a network of small teams; each is expert in a small aspect of the application.
• Every aspect of the app is loosely-coupled with others. When one aspect dies, another can still function.
• Much higher level of creativity thanks to decentralization of control.
• Small individual components are easier to manage, repair, and improve over time compared to one huge complex application scenario.

Every service of the app can fail at any time; with monolithic app, you must review all components to make sure everything else stays intact and there will be no problem (the app can still run, mostly) even when you address the issue with the hitching part. Since every team in the microservices has continuous monitoring, the whole app can still run and repaired simultaneously without noticeable issues from users’ perspective. You can almost say that microservices are indeed designed for failure.

Because with great responsibility comes great ridiculousness, each team must only be responsible for very small component of the app to allow for quick monitoring, troubleshoot, and update.