What are Microservices?
Microservices take a traditional application design approach and break it into smaller and simpler pieces. Traditionally, programs are developed using a monolithic approach that results in it functioning as a single unit. When one part of it breaks or needs to be updated, it can take the whole application out of commission. As a monolithic program grows, it becomes increasingly difficult to maintain, as many co-dependent areas need to be addressed to update the program. Monolithic structures are a natural way of building things, and all tests run in a single program, but as cloud-based services grow, these structures become increasingly dated.
Microservices address this issue by creating a suite of small services that each have their own function and can communicate with other services. Each microservice is an independently deployable application that gets connected to others to deliver the desired functionality. When the microservices are connected, they can communicate with each other through requests and procedures. The advantage here is that changes can be made to a single service, allowing them to be replaced, fixed or upgraded without needing to address the entire application. In addition, since microservices are independent of each other, they can be written in any programming language that suits their function best, and even have their own database.
Building a program using microservices is like building with blocks. You need a variety of types to achieve your goal. One of the most useful aspects of microservices is that they can be implemented into existing programs to quickly add new functionality, eliminating the need to create an entirely new software program.
How do Microservices Work?
Picture a house. At its most basic level, a house is a shelter. There are many services and accommodations that make the house more comfortable to live in, but that doesn’t take away the fact that the house is a shelter. Microservices are like each appliance or utility that is in a house. Even if some of these appliances stop working, the house still serves its purpose and will continue functioning without them. Just like a house, some microservices are larger and more important to the overall function than others. Utilities of a house are a good example of this. Electricity is a vital part of a house, as many appliances rely on electricity to work. However, even if there is no electricity, the gas and water services still work, allowing the house to have heat and water still. Even when major service components are down, the house can still function.
Getting to the smaller microservices, you can compare them to appliances in a house. They do depend on a higher up service (like electricity) to run, but the house can still function without them. Take a dishwasher for example, if the dishwasher breaks, the house still functions as normal. The broken dishwasher doesn’t affect the structure of the house, and dishes can still be cleaned in the sink. The dishwasher can be replaced or fixed without disrupting the house as a whole. Similarly, the brand of the dishwasher does not matter to other appliances within the home. The refrigerator and dishwasher do not need to be made by the same company for them to function. This is the same with microservices in that the languages (dishwasher brand) can be whatever suits the component best. When a particular component needs maintenance (broken dishwasher), it can be addressed without disrupting the function of the program as a whole, and the operation can continue as normal.
Another example of microservices would be a website. When creating a website, there are endless options of how to design it and what features to have for the user. Regardless of what is selected, the website will still be a platform for a company to put information on. The options for different features can be called plugins. Plugins can be turned on and off, and have many different functions. For example, a developer can choose whether or not to add a plugin for a social network on the website. With or without the social plugin, the website will still give the visitors the information they need. The website may not need a social capability, so having one or not will not affect the website. This relates to microservices in that the plugins are independent of each other. They add to the overall website, but can be taken off without breaking the site. Some websites may not need to have a payment function like a vendor’s website would. Both websites still serve their purpose with or without this function. The developer of the website can choose to have this function or not, and the website will still serve its purpose of displaying information. Like microservices, the features of a website can be turned on and off without affecting the purpose of the website.