Introduction to Microservices & a BONUS
Audio : Listen to This Blog.
Microservices is a trending term right now, along with Internet of Things (IoT), Containerization and others.
Microservices architecture based on the micro service pattern have gained quite some popularity in recent years. Netflix, Amazon, and Spotify are some of the larger and more interesting players moving towards this type of pattern. Let’s explore why.
What is Microservices architecture?
Paraphrasing Martin Fowlers in his article about Microservices, “microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API”. Although he’s making a reference to HTTP APIs, it’s not the only mechanism to communicate services, but it’s becoming the most used due to the growing popularity of the web services.
In other words.
“Microservices are small, independent processes that communicate with each other to form complex applications which utilize language-agnostic APIs. These services are small building blocks, highly decoupled and focused on doing a small task.”
“Microservices is an approach to application architecture and development wherein an application is built in smaller, separate pieces. Each service is developed, tested and deployed independently.”
It means each service performs a business feature and inside this service you can organize the code as you desire. You can think in a service as an independent application which is able to run alone and has value by itself.
“Smart endpoints and dumb pipes” — with that sentence microservice community tries to summarize how the application should be structured in terms of communication. The smart part of the application should reside in the services (endpoints) and communication should be done as simple as possible, using REST APIs or message queues, such as RabbitMQ or ZeroMQ. In fact, message queues is the second most used approach for communicating services, especially those ones that run long-time operations or are not high priority. For instance, if a service needs to communicate with another one that just sends emails, message queues are a nice choice.
Advantages of using microservices
This is probably one of the biggest advantages of the microservices architecture. As your application grows it’s easy to plug-in new services with new business capabilities. As most of the software applications are business-driven and market changes so fast you will end up loving this advantage.
Every time you start an application you have to decide in which language you’ll build it. Sometimes you choose one depending on your skills and sometimes depending on the best choice for the application in question. As time goes on and your application grows you end up having to stick to the selected programming language and related technologies you chose. Then you realize that some new features will perform better in another language/framework. Or even worst, that technology doesn’t have a library to use with your programming language. Here is where microservices can help a lot. As every service is a decoupled and independent application you can use a different language/technology for each one, depending on your needs. So, for instance, your application is written in PHP and you want to integrate a chat using Node.js.
Multiple Database Types
Similarly as described before, you can have different types of database in your application. For instance, let’s say your application uses MySQL to handle most of the relational data but for a chat you may prefer to use a NoSql database such as MongoDB.
Ease of deployment
As I said before, a microservice is an independent application and, as such, it can be deployed independently. It means that every time you need to change a service it’s not necessary to re-deploy the entire application.
As a decoupled and distributed system, when some of the services fails (and it will do) just a feature of your application will fail, but the application will be still usable. Moreover, you can have a service monitoring the rest of the services and if one of them fails it will reboot the service.
Easy to Scale
This is one of the issues microservices attempt to solve. Because functionality is separated into different “component”, each component can be scaled up or down independently, without affecting the rest of the system.
Okay, now you know what microservices architecture is. But at Mobinius what are we building with this architecture and what are our next big steps to achieve our organisations mission and vision statement will be in my next blog post.
- http://martinfowler.com/articles/microservices.html (James Lewis and Martin Fowler blog post about Microservices)
- http://samnewman.io/blog/2015/04/07/microservices-for-greenfield/(Sam Newman article about using Microservices from the beginning of a greenfield project)
- https://www.nginx.com/blog/introduction-to-microservices/(Introduction to Microservices | NGINX)