{"id":6828,"date":"2015-05-06T20:18:52","date_gmt":"2015-05-06T20:18:52","guid":{"rendered":"https:\/\/itnigblog.live-website.com\/?p=6828"},"modified":"2020-06-11T13:20:21","modified_gmt":"2020-06-11T13:20:21","slug":"an-introduction-to-microservices","status":"publish","type":"post","link":"https:\/\/itnig.net\/blog\/an-introduction-to-microservices\/","title":{"rendered":"An introduction to Microservices"},"content":{"rendered":"

Lately has been a lot of debating and hype around Microservices. But what are microservices? Why is there that amount of noise around a term? Hope this introductory blog post can help you understand what is a microservice and introduce you into the topic.<\/p>\n

\n
\n
<\/canvas><\/div>\n<\/div>
Photo by\u00a0Glen\u00a0Carrie<\/a><\/figcaption><\/figure>\n

What are Microservices?<\/strong><\/h4>\n

Paraphrasing Martin Fowlers in his article about Microservices, \u201cmicroservice 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\u201d. Although he\u2019s making a reference to HTTP APIs, it\u2019s not the only mechanism to communicate services, but it\u2019s becoming the most used due to the growing popularity of the web services.<\/p>\n

It\u2019s pretty common to see people getting confused about libraries and microservices when reading about it for first time. Don\u2019t worry, it happened to all of us. They are different in that libraries are running in the same process than the main application, and they communicate using in-process function calls. Another common mistake is to confuse an architecture based on microservices with a modular architecture. While they are similar they\u2019re not exactly the same. It\u2019s true that microservices are implicitly modular but it\u2019s false that every modular architecture uses microservices. In fact, most of the modular applications are monolithic.<\/p>\n

As developers, sometimes we tend to organize our code around technical features, such as frontend, backend, helpers, libraries, etc. Microservices are organized around business capabilities and that\u2019s why it\u2019s often confused with modules of a modular application. 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.<\/p>\n

\u201cSmart endpoints and dumb pipes\u201d\u200a\u2014\u200awith 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.<\/p>\n

Pros and\u00a0cons<\/strong><\/h4>\n

Microservice term has been out there for years but lately, as web services grow, it\u2019s going to generate some hype around it. It\u2019s not the ultimate solution for all your application architectures, because of this you should be aware of the pros and cons.<\/p>\n

> Evolutionary Design<\/strong><\/p>\n

This is probably one of the biggest advantages of the microservices architecture. As your application grows it\u2019s 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.<\/p>\n

> Multiple Programming Languages<\/strong><\/p>\n

Every time you start an application you have to decide in which language you\u2019ll 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\u2019t 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 Ruby on Rails and you want to integrate a chat using Node.js.<\/p>\n

> Multiple Database Types<\/strong><\/p>\n

Similarly as described before, you can have different types of database in your application. For instance, let\u2019s say your application uses MySQL to handle most of the relational data but for a chat you may prefer to use a time series database such as InfluxDB. I\u2019m not a DB expert, don\u2019t take my word literally on which kind of DB is the best for a chat, it\u2019s just an example.<\/p>\n

> Independent Deployable Units<\/strong><\/p>\n

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\u2019s not necessary to re-deploy the entire application. It will make you feel more self confident when you\u2019re about to deploy.<\/p>\n

> System Resilience<\/strong><\/p>\n

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.<\/p>\n

> Easy to Scale<\/strong><\/p>\n

Imagine your application is allowing to upload images and apply effects over them. Some of these effects may consume a lot of memory and you don\u2019t want it to affect to the rest of the application. Using microservices you can easily add memory (or other resources) to the server\/process running this service. It\u2019s easy to scale resources depending on the service needs.<\/p>\n

> Deal with Too Many Services<\/strong><\/p>\n

When you\u2019re deciding in how many services you want to split your application it\u2019s easy to get crazy with the service boundaries and end up having lots of services you\u2019ll have to develop and maintain. It will be so easy to introduce unnecessary complexity into the system, and therefore errors. Be careful with that.<\/p>\n

> Code Duplication<\/strong><\/p>\n

The same way is nice to have the ability of using different programming languages, it\u2019s also very easy to have the same code in different languages. When it happens within the same language some people suggest to use this code as a library but then you\u2019ll be introducing coupling.<\/p>\n

> Testing<\/strong><\/p>\n

Testing is a pro and a con. While it\u2019s fairly easy to test a single service it can be a pain to test the whole system and its integration, since every time you want to test the entire application you have to configure and set every service up.<\/p>\n

> Asynchronicity<\/strong><\/p>\n

Asynchronous operations introduces complexity in its coordination and make it really difficult when you need synchronous or transactional operations.<\/p>\n

Many of these are not really a disadvantage but just a lack of tools for automating or monitoring. As a friend of mine says: \u201cWe need a tool!\u201d.<\/p>\n

Should I be using Microservices today?<\/strong><\/h4>\n

That\u2019s a great question I often heard. I would start by analyzing the application needs carefully. My advice is that it\u2019s better to start small and easy but without disregarding that your application can grow and you don\u2019t want to suffer it, but enjoy it. Be pragmatic not dogmatic. It\u2019s true that there are well known practices that will work for your application but don\u2019t be afraid to adapt them to your needs.<\/p>\n

A common approach that I also follow is to start the application monolithic but modular. After this, start separating these modules into services as you really need it. It will not be easy, as every in-process call you made you\u2019ll have to rewrite as a Remote Procedure Call, you\u2019ll need to mount a new server\/process with its own resources and configure them, but believe me, it will be easier than having to start with a tightly-coupled application.<\/p>\n

Form Follows\u00a0Function<\/strong><\/h4>\n

This title is an excerpt of a nice quote from Louis Sullivan:<\/p>\n

\u201cWhether it be the sweeping eagle in his flight, or the open apple-blossom, the toiling work- horse, the blithe swan, the branching oak, the winding stream at its base, the drifting clouds, over all the coursing sun, form ever follows function, and this is the law. Where function does not change, form does not change.\u201d\u200a\u2014\u200aLouis Sullivan<\/p>\n

***
\nby\u00a0Francisco M\u00e9ndez Vilas<\/strong>
\nFull Stack Developer at Redbooth<\/p>\n

References<\/strong><\/p>\n