Micro services is great and many company comes and talk about it on how it is used for scaling team, product etc
Microservices has dark side also and as a programmer you should know about it before going on ride.
In this post i will share some of the myths/dark side about micro services
- We needs lots of micro services
Before you create any new micro services think about distributed computing because most of the micro services are remote process. First define what “micro” means in problem context it could be lines of code , features or deployment etc
- Naming micro services will be easy
Computer science has only 2 complex problem and one of them is “naming”, very soon you will run out of options when you have 100s of them.
- Non functional requirement can be done later
Suddenly non function requirement like ( latency, throughput, security, reliability etc) becomes very important from day one.
- Polyglot programming/persistence or something poly…
Software engineer likes to try latest cutting edge tool so they get carried away by this myth that we can use any language or any framework or any persistence.
Think about skills and maintenance overhead required for poly…. thing that is added, if you have more than 2/3 things then it is not going to fit in head and you have to be on pager duty.
- Monitoring is easy
This is one of the most ignored fact about micro services and come as afterthought.
For simple investigation you have to login to many machines , looks in logs , make sure you get the timing right on server etc.
Without proper monitoring tools you can’t do this, you need ELK or DataDog type of things.
- Read and writes are easy
This thing also get ignored now you are in distributed transaction world and it is not good place to be in and to handle this you need eventual consistent system or non available system.
- Everything is secure
Now one service is talking to another services using API, so you need good auth system to make sure your system is secure. If you work in financial system then you will be spending more time in answering security related questions.
- My service will be always up
That will never happen no matter how good programmer or infra you have, service will go down and now you are in Middleware land(Kafka,ActiveMq,ZeroMQ etc) to handle this , so that request can be queued while service was not available.
- I can add break point to debug it
This is just not possible because now you are in remote process and don’t know how many micro services are involved in single request.
- Testing will be same
Testing is never same as monolithic, you need better automated test to get out of testing hell.
- No code duplication
As you add more services, code sharing becomes hard because any change in some common code required good testing and to avoid that many team start code duplication.
- JSON over HTTP
This is one of the biggest myth that all micro services must have Json over Http and it is user facing.
This has resulted in explosion of REST based API for every micro services and is the reason of why many system are slow because they used text based protocol with no type information.
One thing you want to take away from anti pattern of micro services is that rethink that do you really need Json/REST for every service or you can use other optimized protocol and encoding.
- Versioning is my grandfather job
Since most of the micro services are remote process , so you have to come with request/response spec and have to manage version for backward compatibility.
- Team communication remains same.
This is like hidden elephant in room with more services more team communication is required to keep them posted about what is current version, where it is running , what is broken etc.
You can have more silos because no one knows about whole system
- Your product is of google/facebook/netflix scale
This is like buy lottery ticket that you are never going to win.
If you can’t write decent modular monolithic then don’t try micro services because it is all about getting correct coupling and cohesion. Modules should be loosely coupled and high cohesive.
No free lunch with micro services and if you get it wrong then you will be paying premium price :-)
| Published on Java Code Geeks with permission by Ashkrit Sharma, partner at our JCG program. See the original article here: When microservices becomes darkservices Opinions expressed by Java Code Geeks contributors are their own. |
JSON over HTTP.
As regards this point. what other protocol would you suggest?
One big myth is that all micro services is consumed by java script client.
If you have a service that is not consumed by js then you get option to choose protocol and encoding .
You can use non http protocols and non json encoding( SBE, protobuffer,thrift or your own)