I've now started a new job as a System Integrator, but I actually code Java the most.
So I thought a should ramble a bit about Microservices.
Pieces of a Microservice architecture:
Communication-technique
One of the big PROs with microservices is that they can be language independent. This however creates a demand for a language independent way to communicate.Rest:
One of the most common ways right now is to make REST-services. Most languages have a httpclient-library to call services, usually urls built by Strings. For load-balancing you might need a services orchestration application, maybe Consul/Eureka/Zookeeper.
AMQP:
Another way is to use a message technique like AMQP. The AMQP-servers (Brokers) are very stable and have great clustering abilities. AMQP is a network protocol, which has it's perks. This way has less support but has almost automatic load-balancing (if several clients listen to one broker the use a round-robin strategy for messages). Request-respond actions can be a bit tricky (usually a queue for the request and then listen to a respond-queue).
Summary:
What do these have in common? They are stateless. This means you have to plan it in that way. Microservices demands a lot of modular thinking.
Data Persistance:
How about databases? How do we save data?The important question is, how consistent must the data be?
One idea is to have a polyglot solution and have a datasource in every service which connects to eachother. Maybe MongoDB's sharding?
Another is to connect to a classic cluster of 2 or more databases.
Just be sure to not lock yourself in, don't forget that the individual microservices usually talk to the datasource, they need to be able to talk to them.
Another aspect is should the different services actually use any of the same data? If yes, then communication between teams (that code the services) needs to be top notch.
So preferably the answer is No.
Is DevOps a prequest for Microservices?
Microservice architecture has gotten a fresh start with the agile way of developing. And these small services are developed fast and change fast. There has to be a way to quickly deploy a new version of a service.Many automation-tools have come together to solve the "pipeline", jenkins, go.cd, etc.
This is where Docker has made a good impact. If the service can be contained in a single container (or 2 if data is needed), it can move from development to test to production very easy.
But do we have time to teach a ops-guy how to administrate your service if it changes rapidly? If we need to scarp it and change the whole application-stack for another.
The developers are the experts, if they can administrate the service even in production, they have all the power to update, change and migrate the service.
So even if DevOps technically isn't a prequest for Microservices, it makes for a more agile way of developing.
Should I do Microservices?
The big question is SHOULD you do microservices?Todays development is moving more to the modular architecture.
Which is a step towards microservices. But microservices are not a hail-mary solution. They come with a price, complexity. You need orchestration and communication-layer and a way to deploy all the services. They will probably take more performance too.
So what do we gain? Scalability and the option to quickly change parts of it.
Good modularity can also help against spaghetti code.
So my 2 cents if you should do microservices:
If you KNOW that you need to scale big some day or will aquire more functionality then microservices might be for you.
If your only doing a website, then microservices might only be unncecessary complex.
I will do a small Microservice project and put it on Github for a more concrete example, to show what I'm talking about. But it is not this day.
Happy Coding!
