What are MicroServices?

Hi, I am Malathi Boggavarapu working at Volvo Group and i live in Gothenburg, Sweden. I have been working on Java since several years and had vast experience and knowledge across various technologies. So now let's jump start to learn what actually MicroServices are.

I want to introduce you to the big picture of MicroServices. I am here to present MicroServices at high level, explain you what it is, what it does and more important thing is to help you in understanding if MicroServices are suited for your project or company. This is not a technical course and you won't see any code here. This introduction course can be useful if you code Java, .NET, RUBY, NODE.js or any other platform that allows you to build MicroServices. This course help you discovering MicroServices so that you can quickly decide to use them or not.

First of all i will introduce MicroServices. During this introduction i compare MicroService architecture with Monolithic architecture and explain how the software development life cycle might be effected by the choice of one or the other approach. I will wrap up with some pros and cons of MicroServices so you know whether you can use them in your organization or not.

Now i will talk a bit about Software development lifecycle which is followed by all the IT companies while developing the software independent to the application architecture.

Software Developement Lifecycle

No matter if you follow Waterfall or Agile model, Software development has a certain lifecycle which turns Project into Product. This project involves engineers to Design, Develop, Deploy and Execute this Product in production. MicroServices have an impact on this development lifecycle. They have an impact on the technology. 

Let's focus on typical Agile software development lifecycle. During the Analysis phase, we gather the requirements. During the first Sprint, this is the foundation of the application that defines the minimal requirements to get the application off the ground. Then comes the Plan and Design phase where we plan the Sprint to make sure that we can meet the requirements in the given timeline as well as pulling the design elements from the requirements. And the Development phase is the longest. This is where we go into Action and develop all that was planned. This goes hand-in-hand with testing phase. Testing is vast topic as as it includes Unit Testing, Integration Testing, UI testing, Performance and Stress testing. At the end of this Sprint we release all the plan features into the production. Now the product is alive and that's when the customer starts using the application. But now it needs to be monitored. This is the important phase as it will give us a feedback how our customers use the application. Based on the results we can build the requirements for the next iteration. And ofcourse in the long run we have to maintain the application. During this development life cycle, several different people are involved. Users and Business analysts will gather the requirements and write down the stories for the given sprint. Developers, Web designers and architects will design and develop the software. Project managers will coordinate the project and make sure to synchronize everyone so that target can be reached. Once running in the production the Operational team is responsible for monitoring, dealing with security and making sure the software is Up and running 24/7. An organisation will typically have several of these projects. Bigger ones, smaller ones, crucial ones running 24/7. Each project is mostly independent. Some might have used waterfall approach and some Agile. Some projects can take few weeks to build or else few years. Some will succeed some will fail. The succeeding project will turn into software and finally each software will get deployed. Some of them are deployed on servers or VM's or they will be deployed directly on cloud. This is the quick overview of what most IT companies do when building software. MicroServices are also pieces of software and roughly follow the same development lifecycle with slight changes. Let's see MicroServices and the impact that they have in this lifecycle.

What are MicroServices?

The term MicroServices describes the software development style that has grown from recent trends. It is the set of practices meant to increase the speed and efficiency of developing and managing the software solutions that scale. These set of practices is technology agnostic meaning that there is not one single technology or programming  language to build MicroServices. Infact you can build MicroServices roughly with all programming languages. It's more about applying certain number of principles and architectural patterns that finally create MicroService architecture. 

Ok, now let's focus on the word itself. The word MicroServices made of Micro and Services. You could ask how big is the MicroService? There is no universal measure defining the ideal size of MicroService. Each MicroService is supposed to do one thing and do it well. So the Micro refers to the scope of service functionality, not the lines of code. MicroService is a service build around a specific business capability which can be independently deployed. We call it as Bounded context. So to build a large enterprise application, we have to identify the sub-domains of our main business domain and build each sub-domain as a MicroService.

For example an e-commerce application has a large domain. But when you think of it, you can divide into several small sub-domains such as User management, Catalog, Invoicing and so on. 

Now the word Service. The Service is an independently deployable component of bounded scope that supports interoperability through message based communication.

Now that you know what MicroServices are. Let's go back to our development lifecycle. The way we have been developing software is basically one project results in one product, one application which is one piece of software. The bigger the project, the longer is the lifecycle. It might take from few months or years to go from gathering the requirements to actually release it into production. The bigger the project the bigger the teams as you need more people to design, more people to develop and more people to test. Let's call this big piece of software a Monolithic for now.

Now if you manage to split this monolithic into smaller MicroServices then you can concentrate on something smaller. The development lifecycle is still the same with same different phases as it has to go through. But the smaller project iterates faster from requirements to development to releasing it into production. Smaller project also means smaller teams. Instead of having several teams located in different offices, each working on their own tasks and not communicating much with other teams, you can have a single one working closely together. Microservices will force you to be more agile. It will have users, developers, the operational team, the QA team all together working on the same product. But ofcourse if you have sub-divided the application in smaller pieces, that means you will endup with several projects living in parallel. Because they are small they all benefit from having small teams, faster development lifecycle and getting into production onetime. Each MicroService lives independently but they all rely on each other. Being small in terms of business functionalities means that you need to interact with all the microservices so they can all together achieve the task of your application. They all get deployed in production at their own pace on premise or on cloud living side by side with all the microservices.

Summary

Micro everything - The important characteristic of MicroServices is that it should be Micro. Even though there is no universal measure, they should be small in terms of Team, Code,Test and Business requirements.

MicroServices are autonomously developed and independently deployable. Each Microservice is deployed in its own way and it's own pace. And because MicroServices should interact with each other they exchange messages between them.

Basically the focus of MicroServices is to solve the initial problem of systems that are too big. Smaller teams, easier to manage, quicker to develop and test and more agile.

Monolithic Vs Microservice Architecture

Building a Monolithic application

Let's start by designing an e-commerce web application the monolith way. Let's imagine to build an e-commerce application that sells product, create purchase orders, checks the availability of product from supplier, generates invoices and ships the goods to the customer. We will first model the application. Our customers need a user profile with an address where we can deliver the products. The user puts an order which basically is a list of products he wants to buy. A product belongs to a category for example A book, A CD and can be described as media. Think a PDF file for book and MP3 file for CD. Once an order is created, the application need to contact the Supplier and creates an invoice for customers so he can pay. All this info will be stored in database. We need a UI made of few screens. I am sure you have seen this kind of architecture before. We have a frontend that hooks to a backend. We have a backend that is deployed as a Single monolithic application with its own single database. Being responsive its single UI supports variety of different devices including Desktop, Mobile or Tablets. The application might also expose API's for third parties to consume. You can even run multiple instances of applications behind Load balancers to increase scale and improve availability. We have been using this kind of architecture and it works and has proven to be efficient. See the below picture for clear understanding.

So why shall we care about MicroServices??

Pros of Monolith application

1) They are simple to develop. The technical stack is limited to few frameworks, languages and              databases. 

2) The code can fit into IDE and can easily be built. 

3) They are simple to test. Ofcourse you still have to mock with few external services when doing           integration tests. But most of your tests, test a single piece of software. 

4) Monoliths are also simple to deploy. We simply need to deploy final artifact on runtime, configure      a few properties and that's it. 

5) They also simple to scale. You just run multiple instances of same application behind load                   balancer. 

But what if we want to add more functionalities to our e-commerce application? Once the application becomes large and the team grows in size, the monolithic approach has number of drawbacks. 

Cons of Monolith application

1) The bigger the application is the harder for new team member to become more productive. 

2) You need extra teams to handle the size of growing monolith. Once the application reach certain s      size, it is necessary to divide big organization into teams to focus on specific functional areas. For      example the team just developing the UI, another one for the backend, another one for testing, for      deploying. The problem with Monolithic application is that it prevents teams working                          independently and the teams must be coordinated. 

3) The code of the application will get harder to understand and modify. As a result development            typically slows down followed by quality of code.

4) You won't be able to easily take advantage of emerging technologies but instead abide to long               term  commitment to a technology stack. 

5) What if a small part of application needs a database? You all need to change lot of code just for          that. You will end up scaling application for bad reasons. If you need more CPU to handle all the        invoices at certain times such as Christmas or New year, you need to scale entire application, not        just the invoices. 

6) The web container hosting the application will be overloaded. The larger the application, the               longer the container will take to startup and the more resources it will consume. The database             contain all the data and might become huge which will have impact on the application                         performance.

Building MicroServices

Let's start with building our e-commerce application in MicroService way.

We need to define an architecture that structures an application as a set of loosely coupled colloborating services. For that we can define services corresponding to Domain driven design sub-domains. A domain here our e-commerce application consisting of multiple sub-domains. Each sub-domain corresponds to different part of business. So if you notice carefully at our domain model, we can sub divide into 3 sub-domains. The user sub-domain deals with user authentication, its profile, its address. Then you can see the whole piece processing purchase orders, invoices with flat rates and discounts. Finally we have entire sub-domain related to Products and the suppliers selling this products. See below picture.

Now we have a problem. We have dependencies between these sub-domains. They should be totally independent. Domain Driven Design gives us set of techniques and patterns to help us designing our models. One technique is duplicating the entities that depend on each other. See the below picture to illustrate this.

For example here, we duplicate the User. As separate entities we can even specialize them. In User domain, the user can have profile with Social media. In Order domain the User can have information about payment such as credit card. Same for the Product that is duplicated in both the domains Order and Product. Each sub-domain is responsible for processing its end data. It should have its own database. Infact sharing database is discouraged in MicroService world.

So that's all for this course. Hope it is helpful. In the next section we will dig into further concepts of MicroServices. Please post your comments and make the session live and interactive.

Happy Learning!!