Introduction to Microservices — The main philosophy
Let's talk about Microservices in this article. I've started to work with Microservices in 2017 and since I understood the importance about to apply this architecture in the companies I would like to start to share my knowledge with you. Let's start.
Probably you heard about the Pangea, when all the world was a continent unique around 300 million years ago and started to break and split. Normally, think about a Monolith like the Pangea 300 million years ago, and the Microservices like the world nowadays. In spite of the some difficult, to change the mind, once you learn the basic concepts about Microservices, it is going to be easy to use that every day in your job.
Think about Monolith, like the image bellow. It is one thing very hard to maintain, if you need to change something you can turn off all the system becoming unavailable. If you think about how many times you loose your night to work deploying a Monolith in production. Normally, you start a conference, ask the guy responsible about the load balancer to send all the request to one site and start to proceed with the deployment. Once you deploy, you need to verify that the application starts without error. In case you got an error, you need to rollback everything, manually.
We have amazing guys writing about the Microservices, like Martin Fowler in his blog https://www.martinfowler.com. Martin Fowler define Microservices:
“In short, the Microservices 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.”
Sam Newman define in his book, Building Microservices, like a "Small Autonomous services, that work together modelled around business domain".
Jon Eaves, from RealEstate.com.au, told once, that Microservices is something that could be rewritten in two weeks, a rule of thumb that makes sense for his particular context.
These are my favorite definitions about Microservices, like a tripod for give your first start in Microservices. Then, I have my own definition about Microservices here.
It is a small piece of business domain, (the sub-domain and bounded context) that is totally independent, and can be done by a Squad in Agile Environment, deployable anywhere in a private or public Cloud using IAAS, SAAS or PAAS using often the protocols such as Rest or gRPC in a continuous integration and continuous delivery.
Well, but what are these technologies? Looks like a letter soup, I do not understand Roan what are you talking about? Let's start for the most important concept that helped me a lot to understand how to break down Microservices. We need to thanks Eric Evans for this amazing concept, bringing the Domain-Driven Design for our life.
Ok, Domains, Subdomains and Bounded-Context, what the hell is that?
Domain — It is exactly the business, the core of the company, what it is the main business of the company. If you think about Amazon, for example, we could split the company in different companies, just to keep simple, Amazon sell services such as MarketPlace and Cloud services, and also, Amazon is a library selling books and e-commerce selling their own products such as Alexa, Kindle, etc. We could split in four domains, because they are different companies. Keep in mind that every domain has Subdomains.
Subdomain — Thinking about one of the Amazon's business explained before, selling products online (e-commerce). You have many areas responsible about listing the products for the customer, payment, renew stock, order, ship the products to the customer, etc… In this domain, we can say we have 5 subdomains such as Products Catalog, Orders, Logistics, Stock and Payments. Subdomain are small parts of the ecosystem that together define the Domain.
Bounded Context — this concept is responsible about the modelling and implementing transition to give the directing of the boundaries of some sub-domains. This is the most hard part to understand in the DDD concept, because it is not something concrete and might be many things such as a representation, a piece of code, library, any thing.
But, how works the communication of the Microservices? Who invented that? Rest or gRPC are the most common communication nowadays.
REST is acronym for REpresentational State Transfer. It is architectural style for distributed hypermedia systems and was first presented by Roy Fielding in 2000 in his famous dissertation.
Roy, defined to use each verb must being called using Http protocol like a Database action, like CRUD — Create, Read, Update and Delete concept.
HTTP POST — Must be called when you want to create something
HTTP GET — Must be called when you want to read something
HTTP PUT — Must be called when you are going to update something
HTTP DELETE — Must be called when you are going to delete something
Talking about gRPC is a open source high performance remote procedure call that use HTTP/2 developed by Google in 2015, that run anywhere and can make easily the communication between the two services. Bellow an example of protocol buffers, you can look at https://grpc.io/ and https://developers.google.com/protocol-buffers/
Person.proto
message Person {required string name = 1;required int32 id = 2;optional string email = 3;}
Main.class
Person john = Person.newBuilder().setId(1234).setName("John Doe").setEmail("jdoe@example.com").build();output = new FileOutputStream(args[0]);john.writeTo(output);
To start to work if Microservices I would say you must read and be aware of the links below:
12 Factor :
Microservices Pattern:
Cloud Native Computing Native:
Martin Fowler Blog:
See you in the next article. Thanks.
