This article was first published on Medium. You can take a look at it here
Microservices are becoming a very popular architecture design for appli...
For further actions, you may consider blocking this person and/or reporting abuse
Great description, I think you hit on all the right concepts. I'll add that there are a ton of situations where monoliths are still the right idea, and it's usually where you should start, regardless of where you want to end up. For all the benefits of microservices that you outlined, there is overhead you probably want to avoid early in a project.
Thanks Ben! You're completely right, microservices add overhead/complexity which is sometimes very unnecessary early on in a project. I've edited my post to reflect the disadvantages of microservices as well!
Good article. I'd like to add that before thinking about microservices, we should first think about basic decoupling. Is your front-end on a separate single page app? Is your database on a separate server? Also, is your existing monolith architecture configured in code (e.g. Puppet, Chef, Terraform)? How's your test coverage? These are the questions we should ask ourselves first before thinking about microservices.
I'd say no project should start as a microservices infrastructure, especially at the beginning you need a very good dev tempo and split your app in microservices almost always increases exponentially the complexity (and coste) of your project. Yes for microservices, but only with a quite big team and a mature app
There no theoretical difference between service over the network and API. Mostly the exchange format used tend to change. But carefully crafted API can be resiliant and backward compatible.
The amount of work to communicate with an API is several order of magnitude easier to code and faster to run. The last point mean that a whole set of programs where performance is a factor may not be able to benefit for some components to be spread over the network.
In particular services spread across farms and network can't afford to be too "chatty". The number of requests must be kept to a reasonable number and not slow down too much the overall process.
API on the contrary can be chatty. Hundred millions of calls literaly can be made in a second and the amount of data exchanged in a second can be in the gigabytes. If it fit the CPU cache, dozens gigabytes.
Services or micro services are tools. As you explained they are not silver bullet. On top of adding yet another level of complexity with exchange format, network errors, making deployment of a new feature spread accross many services much more complex, there are simply not a fit for all problems.
It may be easy to think you can always make smaller lighter services. But when you have already a few thousand ones, a typical cases in many big companies, the best solution to fight complexity isn't necessarilly to make them one or 2 level of magnitude smaller to have one or two level of magnitude more services. It is not easier to manage dozen or hundred thousand services than a few thousands. It may just make your network infrastructure explode and make it nearly impossible to understand how all theses micro services interreact.
Thanks for explaining difference between API and microservice. The detailed explanation about Microservice definitely cleared how Microservice can be a boon for business. Thank you for this small and useful guide for Microservice.
Nice balanced article. And Wahoowa! :)
Thank you for clarifying the difference between micro-services and API! great stuff!
any github links where one can start on developing with this paradigm
Are you able todo a follow up article on when to use which architecture?
Yes of course!
Thank you for sharing such informative content also sharing difference between API and micro services.
digitalinfoways.com/