Microservices

Well, if you ever buy something from Ebay, you may know that Ebay is a very large website providing a lot of features for buying and selling things. It is also available on many platforms such as App Store (iOS), Google Play (Android), Microsoft Sotre (Windows), ChromeBook (Chrome OS)... So, did you ever wonder how that many of features could be easily and quickly developed to work seamlessly together on different platforms? If you did, you were thinking of "Microservices". Then...

What is Microservices Architecture?

The Microservices Architecture regards to a technique of software development, in which software components communicate with back-end services through a communication protocol via a network. The basic principles of Microservices is based on Service-oriented Architecture (SOA) with independent products, pieces of a product and technologies. A single service in a microservices-baed application is a discrete unit of functionalities that provides remote access for a client to accomplish some kinds of tasks on a certain feature of the application.

Let's look at Ebay for an example of payment-processing feature (PPF), since their application can run on many platforms, traditionally they have to implement a PPF for their iOS app using Swift, another PPF for their Android app using Java, another one again for their Windows app using .NET and so on if one day they launch their app on some brandnew platform. That's a nightmare but now with Microservices, they can develop only 1 payment-processing service using any technologies they prefer, then allow their app to communicate with the this service whenever it comes to processing a payment.

Microservices Architecture has the following properties:

• Component-based software: A whole large software can be divided into many smaller components with each one being responsible for a certain functionality. Each component is now considered a service, which can be independently designed, implemented, tested, deployed and maintenanced by separate teams of developers. This property brings to an important attribute of microservice, which is failure resistant. It means if a service becomes unavailable at a point, the other ones should still be functioning successfully and correctly.
• Request-based services: An individual service should only accomplish its own task without overlapping with the task of another service. It should accept a request which is sent to from a client, process the request then respond to client accordingly. If a service receives a request to retrieve all pending transactions records of a customer for instance, it should only return the requested data as required.
• Lifetime liability: In microservice, unlike traditional development approach where different teams focus on a specific functionality of the whole application, the responsibilities of each team now are developing a complete application basing on set of services and reliable for the application for its lifetime. For example in Ebay's case, a team which develops an Ebay app on Android will need to deliver a complete app and be continually responsible for its operation.
• Distributability: Each service in the microservices ussually manages its own database and should never touch the database of another service. The technologies used to develop a certain service are not necessarily used for the other services. This architecture is called the decentralized governance of services, which is favored by most of the software architects in designing the solutions for complex business logics.
• Evolutionary: Microservices allows for Continuous Integration and Continuous Delivery of software and, therefore, enables the developers to control and apply changes in the applications within a timely manner and without interupting the system's availability.

However, many first-time practisioners of microservices are mistaken it by some myths as the followings:

• "Micro means a little app": To correct this myth, "micro" should be understood as a small service that works together with the others to provide a full feature for an app. In microservices, a software is built from a set of losely coupled and highly modular components. This facilitates the process of development and maintaining the applications. By making components decoupled, existing features can be easily upgraded and new features can be added with no downtime.
• "Monolithic software can be converted to microservice with ease": While some software development businesses usually advertise this myth to their customers, it is almost a utopian. Remember the term "architecture"? It should be architected from the early days of designing the software and properly implemented to make all the services work together in the right way. Hence, bringing a legacy app into microservices is definitely not just about simple refactoring or rewritting the software. So, breaking a monolithic application into smaller parts is not microservices.
• "Microservices reduces business costs": Well, everything comes with a cost, so does microservices. The amount of money a business needs to spend on developing their software do not go any lower with microservices, but it will greatly aid the process of implementation and the long-term operation of the software.
• "Microservices provides better architecture and agility than monoliths": This is not always true. Microservices does not make the application easier, faster or cleaner to develop. Rather, it reduces the high level of coupling between many features into the smaller components, therefore somewhat reduces the length of a pice of codes. Also, it is not simpler for engineers. To design an application in microservices, an engineer needs to have certain exploits to all of the technologies that would be involved in the development, and has prior experienced in various kinds of software development. It is detrimental that microservices is incorrectly designed or over-complicated.

Pros and Cons of Microservices Architecture:

Pros

• A service can be developed by a small team very quickly
• Different services can be written in different programming languages
• The likeliness of bugs and errors in codes and logics is significantly reduced
• Offers the ability for Continuous Integration and Continuous Delivery
• Easier for new developers to get the codes, thus, allows for quick catchup and contribution
• Latest technologies can be applied easily. Third-party services, add-ons, plug-ins and libraries can be conveniently installed.
• If there is some changes or upgrades to the application, only the related microservices are modified then re-deployed, no need to bring the whole system down and then deploy the entire again

Cons

• Testing may become more difficult with the distributed deployment
• The large number of services may result in communiation congestions
• Higher level of complexity because developers have to mitigate failures in networking and messaging formats. As well, integration and management of the whole application may become complicated
• Independent teams of developers may result in duplications of services
• Developers have to possess sound knowledge and skills to manage the communication across distributed services and databases
• Required more proper communication and collaboration across different teams
• Increased in memory consumption