Microservices Part 1 – Introduction
“In short, the micro service 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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” From Martin Fowler article
So, we have some idea what micro services architecture style is, but let’s go deeper..
I’ve used microservices with different clients in my professional life, from Google to Electronic Arts, but not always is the best approach. Some years ago I had to create a backend for eBay in 2 months, I was the backend technical leader and my team initially was 2 developers and me. In that kind of situations microservices doesn’t fit, we have to keep focused on helping the client to achieve goals. I used a monolithic architecture based on spring boot. But let’s talk about a little bit of this approach to understanding how it works and when should be used and when shouldn’t.
When use microservices as an architectural approach we will face some good things and no so good things and depends on the project complexity you will love this approach or in the other extreme, you will suffer it a lot. Some good things are listed follow.
Flexible Design, ready for new features
I think the most important advantage of the microservices is the design flexibility. This able us to rewrite parts of our architecture without rewrite all the application. This is because the minimal coupling between layers. Theoretically speaking seems to be very easy.. is not in the practice, but the effort is less than rewrite a layer completely.
Small responsibilities = small code
Because micro-services are “micro”, they do just a small task. To have minimalistic tasks and responsibilities has a big advantage.. less code! and obviously fewer maintenance tasks, independent lifecycle, less documentation, etc.
Easy to Scale
To have a small piece of code with just one minimalistic responsibility enable to us scale just one small component of the architecture. Suppose we have a CDN service and in a promotion of our website, a lot of users start to upload photos. The CDN service will scale from few instances to several and back to few when users slow down the CDN uses.
Easy to Deploy
Ehh.. more or less from my perspective. Yes, a minimalistic piece of code is easy to deploy. If we use spring boot, dropwizard, node.js + express, or any other similar technology you can start or stop an application easily. In few words, you start an application in a node, container, or virtual machine and that’s it, the process can listen a port, responds requests, etc. But you must monitor and control several applications.. without a correct tool, it can be a mess.
As your application is composed of multiple minimalistic services, if some of them go down only some features from your application will go down, not the entire application. You can restart some services without affect all the system. Suppose we have several services A instances, and 4 of them started to delay the responses.. you can restart that 4 instances and all the system continue working, even if we have load balancers and circuit breakers we can restart these without any impact.
New Challenges coming
Microservices doesn’t fit all problems, it helps but also is coming with some other complexity. We can highlight some complex stuff to deal with as follow.
Communication service to service
In the micro-services approach we will have a lot of pieces of code running out there, and obviously, we have to communicate them to create the whole system. Inter-service communication could be seen as overhead and yes it is but is the price of decoupling things. We will cover the most common options:
We can use HTTP to expose micro-services API in order to share a service with another one. Why HTTP? because is the de facto standard. It means that almost all frameworks and languages have a HTTP client and in micro-services approach the plurality is important. Do not reinvent the wheel, just use the standards and you can mix different languages in the same project easily.
Using Messaging Queues
For massive processing, we should use a message queue mechanism. This mechanism provides different advantages like retries, persistence, monitoring and more. Some queues implementations like Kafka of RabbitMQ has a lot of connectors and libraries for many languages. This option is to long-running workers and obviously, you can use a simple mechanism and improve it later.
Usually micro-services scale horizontally automatically, it means them can be started and stopped randomly. In order to do the inter-service communication, they have to know where to find a service instance ready for requests. The response to this issue is a kinda catalog with services published and unpublished into it, so any service can request another service to this catalog and then work directly with it. So the catalog must balance the load, has a timeout mechanism, monitoring, and more. This catalog is called service discovery and it MUST be consistent, highly available and distributed. Basically, the service discovery is another service where all the services register itself when starts and can ask for a service using a namespace or any identifier.
We have another thing that rise up when we use microservices.. like circuit breakers, several load balancers, service monitoring, dashboards, routers and more.
If you don’t live in a cave without internet, is highly probable that you are hearing about microservices for everywhere, almost all of us speak, write, learn and teach about microservices, but let’s say something important now, micro-services are not new (actually are very old) and are not the answer for everything. When to use it depends on the system requirements mainly scalability, project budget, and team knowledge. Innovate is great! but be smart on this.. don’t use things because another company uses, think about current requirements, maintainability, time to market, etcetera.
There is a lot more to write about this approach, but as we detailed in the very beginning of this article, this is an introduction and we will cover more concepts, advantages, and difficulties in next articles. Next article we start to write some code to see micro-services in action. Stay tuned.