Learning microservices can be intimidating for any developer, but it's especially true for junior developers or frontend engineers with little exposure to how things work on the backend.
The most confusing aspect is that there is really no 100% standard textbook definition about what a microservice truly is.
In this video I'll try to quickly go over the what, why, and how of microservices so you can get a general understanding of the core principles of microservices and why they are so hyped in the tech world.
Even if you don't have any interest in working on backend programming it's a good idea to at least be exposed to these concepts
Summary of video:
What are microservices
They are a software architecture style that involves breaking an application down into individual pieces that are able to be deployed and developed independently from each other.
Benefits and Downsides
So why are companies using these things? Obviously there are some benefits to justify moving from the monolithic app style that has worked for a long time
- Faster development time - Teams can make their own decisions and for the most part don't need to coordinate new deployments with other teams
- Easier to onboard new hires - New engineers don't need to learn the entire application before contributing, they can start off working on a single microservice
- Scaling- Microservices can be scaled independently depending on traffic demands. Don't have to scale the entire monolith if a single chokepoint is slowing down the app
- Reliability - Because microservices are separated from each other, if a bug is deployed it can be isolated and rolled back without taking down other services
That's not to say microservices are perfect, there are plenty of tradeoffs that come with using microservices and monoliths are generally recommended for small apps and small companies until they start encountering problems with scaling.
- Complexity - A poorly designed microservice architecture can end up being worse than the average monolith
- Communication between microservices - Entire new set of problems created by the fact that microservices are broken up, they need some standard way of communicating with each other
Where to learn more
This was just a quick summary, I plan on doing more in depth tutorials on microservices so follow or subscribe if you are interested in that.
Until then here are some good resources if you are interested in learning more:
Top comments (8)
In my opinion the reality is a bit different.
Complexity is not the issue. Understanding the rules is. Hence, without proper understanding you can really mess it up
With the exception of scaling in the group, the rest are very subjective and really depends on many factors. It reminded those agile sales pitches.
In my opinion, their biggest benefits are
But I've almost never seen a properly done micro service landscape. I usually see the following
And as a result, when things become complicated you end up with a microservice only in code but in all other aspects including culture and ops, a distributed monolith.
In the video I do mention the aspect of being able to use the best tool for the job with microservices, forgot to add it to the summary
you're right about most microservices resulting in a mess, engineering discipline and having the right culture in place is probably the most important factor. In a crunch all the ideals will be thrown out the window to hit a deadline and tech debt begins to pile up
The most common root cause I encounter on this topic is that most people don't understand isolation. They tend to use different services as some sort of database over http/api or computational shared service. The fundamental requirements, that data is not shared is the most common root cause for the mess. And then all the rest follow. Sharing codebases, not versioning and in general everything that breaks isolation and all because as you say "ideals are thrown out of the window".
But we did the same hype word mess with agile, microservices and devops. Nothing wrong, quite the opposite, with each but somehow people in this industry read a couple of blog posts, don't bother to read a book and they make important decision without even half knowledge. Then you have all the companies that need sell each hype word. Anybody remember the "I'm looking to hire an agile developer" as if it is some sort of a skill? Then, after the mess, managers make conclutions that this is not good because of the internal mess.
We have to be the only industry which behaves like this. If civil engineering was like this nothing would be standing up. When I wrote a post about DEVOPS culture , i repeatedly mentioned don't read my post but read the book.
Great summary here!
Most annoying problem micro-services have introduced for projects I've worked on have been cpu time limits, de-duplication, getting new engineers to actually understand the big picture of the app without showing 8 repos and a flowchart that no one ever finishes properly because we're trying to push features. You can solve most of these problems today with frameworks like apigee mixed with proprietary or open source messaging buses such as gcp pub sub, rabbitmq. I think micro-services were bourne primarily out of scaling issues with multi billion user companies and then the adoption spread like a wildfire for a lot of developers. I have so much to say on this topic lol
100% right, vast majority of companies don't need microservices but lots of developers want to do what the big companies are doing. MIT has a distributed systems course where the professor himself says to do everything possible to avoid distributed systems for as long as possible.
Microservices are only used by big companies because they had no other choice, not because they thought it would be cool to make things complicated
Totally agreed, however I think there is a small caveat to this whole discussion. I definitely think that any compute should never live in the same instance as the database of the application, technically speaking that was really the birth of "serverless", because your instance would only spin up when the load balancing control plane would wake up the node and get the health statistics confirmation to send the payload. Adoption of kubernetes is pretty much universal at this point, mostly on the compute layer on modern enterprise applications. I dev with my friends all the time and whenever we're scaffolding a project out the microservice debate always comes up because if we do a good job we can run the small project all on free tier cloud tools. I'm thinking about writing a post on this, I've got a lot to say on it, I'll keep a lookout on your future articles, this was well done
Please go ahead and share your lessons with us. Thanks in advance!
definitely write some articles about it, we don't get enough of that type of content on Dev imo. I think people would be interested!