This is an interesting read, and thanks for sharing. While keeping things monolithic is an efficient, worry-less and simple approach to architecting a product to maturity; what would you advise if it will take as much work or greater to break it down micro-services;
1. To continue anyways or
2. Find a mid-point in the life cycle to break things down or
3. Have a deep thought about the future of the project at the beginning (then decide)?
Microservices Are Something You Grow Into, Not Begin With
31–40 of 159 posts
Re: Microservices Are Something You Grow Into, Not Begin With
#32I agree that microservices is the new "must have" technology but actually it isn't a great deal different from a monolith. The monolith can have separation between services and still requires interfaces to work between them. As others have said, microservices bring a lot of baggage that you might never have seen before (i.e. big learning curve) and the myth of isolated changes is just that, a myth. Unless it is some…
Indeed. It just replaces internal calls between services of your monolith with flaky and slower network calls.
This is exactly how I view microservies (assuming that you know how to build a monolith in a modular way).
At the end of the day its only going to increase complexity.
Re: Microservices Are Something You Grow Into, Not Begin With
#33I think you can selective. We started with ~5 services all built fairly ad-hoc, splitting on sensible boundaries with the goal of never having a "mega" service. This means it has been reasonably easy over time to fully replace them on an individual basis with more mature systems without changing the API design. Now we're 3 years in with ~40 services and the approach has served us very well. Definitely agree you shoul…
> Definitely agree you shouldn't start with a ton of services, but I think you should definitely start with more than one. The jump from monolith to service-oriented thinking is a huge one.
I can't get my head around this.
Why should you start with more than one?
What is so different about "breaking your application into services" and "breaking your your application into appropriate modules / classes"?
If those need to scale then you should have an interface that you can expand to a micro-service.
As another poster said "It just replaces internal calls between services of your monolith with flaky and slower network calls. "
Re: Microservices Are Something You Grow Into, Not Begin With
#34Re: Microservices Are Something You Grow Into, Not Begin With
#35What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!
Not if you know how to architect one properly.
How is a small microservice with one purpose different from a class / module with one purpose?
Re: Microservices Are Something You Grow Into, Not Begin With
#36Earlier quoted context omitted.
> Sounds like resume-driven-development. Sure. That's one of the responsibilities of a team lead: to help team members to work and gradually build up their CVs. I want my team to experiment new stuff and learn while working. But I also want to limit the risk boundary. The whole reason why younger people are leaving dinosaur companies is that no one in management layer lets juniors experiment and fail. End of the day…
Nah, your job is to lead the team in the most effective direction in order to fulfil business objectives, not build resumes.
In that case you are going to find that you quickly lose your best devs. I'm not saying that resume building should be even within the top 5 priorities, but you will want to at least keep it in the back of your mind. It's a balancing act.
Otherwise the solution is to crunch-time people into oblivion and and quickly replace them when they burn out. Not exactly sustainable
Re: Microservices Are Something You Grow Into, Not Begin With
#37Bottom line is that it's all a case by case basis. However I'll always warn against slicing microservices too thin. Each slice is a moving part outside of the machine and therefore brings in additional risk. I recently refactored/rewrote a monolithic project into a few fairly chunky services. Each one is sliced by a broad context. The only reason I did it was because the monolithic app required separate physical deployments per client due to data sharing restrictions and the service model (I won't call it micro) allows sharing of the data I'm able (and should) share between them. Perhaps we need a name for the model in between monolithic and "micro"-services. Maybe Macro Services?
Re: Microservices Are Something You Grow Into, Not Begin With
#38Earlier quoted context omitted.
Sounds like resume-driven-development. I worked at a company with this disease before. The system was an abomination of vastly different technologies over the years stitched together loosely. Development was slowed substantially by having such a mess and the company couldn't move fast enough to compete so the startup died. Usually tech isn't the reason for a startup's death. In this case, it was.
> Sounds like resume-driven-development. Sure. That's one of the responsibilities of a team lead: to help team members to work and gradually build up their CVs. I want my team to experiment new stuff and learn while working. But I also want to limit the risk boundary. The whole reason why younger people are leaving dinosaur companies is that no one in management layer lets juniors experiment and fail. End of the day…
I'm pretty sure the reason "younger people" leave "dinosaur companies" is because they aren't happy. What causes that unhappiness is a wide spectrum. It could be poor team leads who let the young person's peers waste time while they carry the weight. It could be compensation at large companies is based on past performance rather than future potential growth. It could be because it sounds more impressive to a young person to say they worked at X new hotness tech company, etc.
Your job as team lead, however, is pretty clear. You lead a team to create value for your organization. Professional development is an obvious tool in that toolbox. Finding ways to limit or restrict exploratory development in order to reduce risk is another.
Re: Microservices Are Something You Grow Into, Not Begin With
#39Most of the time, I've found a push to microservices within an organization to be due to some combination of: 1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able t…
This is a great list. I've been reflecting on this drive for microservices in early stage companies for the last four years, and you hit all the major points.
One additional one I'll add is the marketing objectives of containerization and infrastructure companies.
And a good time to resurface Martin Fowler's Monolith First:
Re: Microservices Are Something You Grow Into, Not Begin With
#40Most of the time, I've found a push to microservices within an organization to be due to some combination of: 1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able t…
I don't believe it os reasonable to portray microservices as the result of incompetence and blame-shifting.
Microservices are actually a very basic and fundamental principle of software engineering: separation of concerns. If your system is extensive enough so that it covers multiple independent concerns and your team is large and already organized into teams focused on each concerns then it makes technical and organizational sense to divide the project into independent services.