Let's quickly define what we mean when we use the term microservice.

As the word already gives away, microservice consists of micro and service. Micro is smaller than small. A microservice by definition should be as small as possible. The other word, service, refers to the function of a microservice: it should do something for us. In this book—and in general—we call them microservices, the plural form of microservice. We do that because a microservice usually operates together with other microservices. A microservice application consists of multiple microservices working together and alongside each other.

Almost all major players, such as Google, Amazon, and Facebook, started out as so-called monolithic applications. What does that mean? In essence, a monolith is an application that operates as one large code base. Popular examples include WordPress, Joomla!, Magento, and Drupal; they typically run on one server for the frontend, PHP oftentimes. If you need to scale such an application, you would add more frontend servers that all do the same thing; they are replicas of each other.

While that would solve the demand issue, another problem exists as well: every time the web page is updated, by changing the source code, a single error could bring down the entire web page. The dominant web technologies for so-called monolith web applications used to be primarily PHP and some used to be Java and Perl. Wikipedia, Yahoo!, Facebook, and many others rely on PHP to this very day. Over time, additional scripting languages such as Python and Ruby entered the race. However, the following problem prevailed: changing source files could introduce bugs and bring down the entire site because every PHP file is usually somehow connected to the others. As the companies grew, they adopted another approach, which has proven to be much more reliable for continuous growth and maintainability. The approach, microservices, includes the idea that a web application does not consist of one big monolith anymore but is divided up into many independent services that work together.

The approach itself is not all that new; logistic companies had implemented such a strategy for their structures as well. But growing internet tech companies used this method to solve two of their main problems:

• Scalability: Individual services are much easier to scale than scaling the entire system.
• Maintainability: When changing or adjusting one service, it will not affect the other services, which creates a more solid and stable system overall.

Now, not only the general approach has changed but also the field of programming languages. While in early 2000 just a couple of languages were used for developing web applications, we have a lot more options such as Swift, Go, Python, and JavaScript that are available now.

For all of the intents and purposes of this book, let's use the following definition of microservices: a microservice is a small service that runs along with other services and builds the application together with the other services.

There is no actual official definition of what a microservice is and is not; however, the following rules generally apply to commonly used microservices:

• A small unit of a backend infrastructure
• Operating as independently as possible (meaning, no or little communication with other microservices)
• Performing a service (such as processing data or offering an API)
• Offering as little functionality as reasonable
• Operates with its own database

To conclude, a microservice is the smallest and most isolated unit possible of the business logic and is needed for the server application. Now, let's look at the cases when microservices are a great choice!