Modern distributed applications are built as a suite of microservices. In this blog we discuss the characteristics of microservices. We will also compare microservices to its predecessors like SOA and monolithic applications. We point out the benefits and downsides of a microservices architecture.
Let us start with a little bit of history and go back to late 90s or early 2000's. Web applications were monolithic. A single web container would serve the entire application. Even worse, a single web container would serve multiple applications. Not only was this not scalable, it was a development and maintenance nightmare. A single bug could bring multiple applications down. And there was an ownership issue. You had multiple teams/developers contributing code. When there was a bug, the ownership was not clear and bugs would bounce around among developers.
Around mid 2000's the new buzz word was service oriented architecture SOA. This was promoted by large web application server companies. See my blog on SOA written in 2010. SOA encouraged number of good design philosophies such as interface based programming, loosely coupled applications, asynchronous interaction. REST, XML,JSON and messaging platforms enabled SOA. SOA was a big improvement, but the tools and deployment technologies were still heavyweight.
The microservices architecture is the next step in evolution further improving the ideas from SOA.
Many dismiss microservices as another buzz word. But having developed real world applications using tools listed in section 3.0, I see real value and benefit in this architecture.
The main idea around microservices is that large complex systems are easier to build, maintain and scale using independently built and owned smaller services that work together.
Each microservice is a modular fine grained application providing a specific service. Let us say you have an application that has a UI , authentication, Apis for customer info, Apis for uploading documents, Apis for analytics. You may have a microservice for the UI, a microservice for customer apis, a document upload microservice, an analytics microservice.
A microservice is fully functional.
A microservice performs one specific business or IT function.
The development of the microservice can be done independently.
A microservice runs as its own process.
A microservice communicates using common protocols such as REST/Http.
A microservice offers services via its Apis. It can communicate with other microservices using their APIs.
A microservice is deployable to production independently.
When your application has multiple microservices, each could be developed in a different or the most suitable programming language or framework suited for that service.
A microservice should scale horizontally by just running more instances of the microservice.
Testing, bug fixing, performance tuning etc on the microservice should happen independently without affecting other microservices.
The above listed characteristics make it easier to build large complex systems.
A number of newer frameworks have made building microservices easier.
For Java programmers, Dropwizard and SpringBoot are very useful frameworks for building microservices. The old way was monolithic application servers like websphere, weblogic , jboss etc. Dropwizard and SpringBoot turn the table by embedding the web server within your java application. Development is much easier as you are developing a plain java application with a main method. The entire microservice is packaged in one jar and can be run with the java -jar command. For additional information, please read my blog comparing Dropwizard to Tomcat. For Javascript, python and other languages there are similar frameworks.
To start with microservices, a framework as mentioned above is all you need. Once you have developed and use several microservices, the following platforms may be useful.
Docker is a containerization technology that makes it easier to manage production deployments. This is of interest for a dev-ops person who has to roll out services to production.
Kubernetes is platform for automation, deployment and scaling of containerized applications.
For smaller business and smaller applications, the overhead of many microservices could be a problem. If your infrastructure is one or two $20 per month VMs on AWS (or other cloud providers) you will not have enough memory/cpu/disk for multiple microservices.
The increased network communication is a cost.
Each microservice is its own process. The remote calls have a serialization/deserialization cost.
Microservices are a logical next step in the evolution of the development of complex applications.
They are a best practice. But they are not a silver bullet that solve every problem.
1.0 Introduction
Let us start with a little bit of history and go back to late 90s or early 2000's. Web applications were monolithic. A single web container would serve the entire application. Even worse, a single web container would serve multiple applications. Not only was this not scalable, it was a development and maintenance nightmare. A single bug could bring multiple applications down. And there was an ownership issue. You had multiple teams/developers contributing code. When there was a bug, the ownership was not clear and bugs would bounce around among developers.
Around mid 2000's the new buzz word was service oriented architecture SOA. This was promoted by large web application server companies. See my blog on SOA written in 2010. SOA encouraged number of good design philosophies such as interface based programming, loosely coupled applications, asynchronous interaction. REST, XML,JSON and messaging platforms enabled SOA. SOA was a big improvement, but the tools and deployment technologies were still heavyweight.
The microservices architecture is the next step in evolution further improving the ideas from SOA.
Many dismiss microservices as another buzz word. But having developed real world applications using tools listed in section 3.0, I see real value and benefit in this architecture.
2.0 Description
The main idea around microservices is that large complex systems are easier to build, maintain and scale using independently built and owned smaller services that work together.
Each microservice is a modular fine grained application providing a specific service. Let us say you have an application that has a UI , authentication, Apis for customer info, Apis for uploading documents, Apis for analytics. You may have a microservice for the UI, a microservice for customer apis, a document upload microservice, an analytics microservice.
A microservice is fully functional.
A microservice performs one specific business or IT function.
The development of the microservice can be done independently.
A microservice runs as its own process.
A microservice communicates using common protocols such as REST/Http.
A microservice offers services via its Apis. It can communicate with other microservices using their APIs.
A microservice is deployable to production independently.
When your application has multiple microservices, each could be developed in a different or the most suitable programming language or framework suited for that service.
A microservice should scale horizontally by just running more instances of the microservice.
Testing, bug fixing, performance tuning etc on the microservice should happen independently without affecting other microservices.
The above listed characteristics make it easier to build large complex systems.
3.0 Enabling Technologies
A number of newer frameworks have made building microservices easier.
For Java programmers, Dropwizard and SpringBoot are very useful frameworks for building microservices. The old way was monolithic application servers like websphere, weblogic , jboss etc. Dropwizard and SpringBoot turn the table by embedding the web server within your java application. Development is much easier as you are developing a plain java application with a main method. The entire microservice is packaged in one jar and can be run with the java -jar command. For additional information, please read my blog comparing Dropwizard to Tomcat. For Javascript, python and other languages there are similar frameworks.
To start with microservices, a framework as mentioned above is all you need. Once you have developed and use several microservices, the following platforms may be useful.
Docker is a containerization technology that makes it easier to manage production deployments. This is of interest for a dev-ops person who has to roll out services to production.
Kubernetes is platform for automation, deployment and scaling of containerized applications.
4.0 Disadvantages
For smaller business and smaller applications, the overhead of many microservices could be a problem. If your infrastructure is one or two $20 per month VMs on AWS (or other cloud providers) you will not have enough memory/cpu/disk for multiple microservices.
The increased network communication is a cost.
Each microservice is its own process. The remote calls have a serialization/deserialization cost.
5.0 Conclusion
They are a best practice. But they are not a silver bullet that solve every problem.
