71–80 of 159 posts
Earlier quoted context omitted.
I've experienced 2 through 5 first-hand when I joined a startup It was shocking for me to witness critical technical decisions being made within a couple of minutes _research_ i.e. reading a blog post
"Move fast and expect broken things"?
I 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…
I work in defense, where software systems tend to stay in service for a very long time... It is very, very hard to keep a monolith from turning into a big ball of mud after it's handed off to O&M. Very often a different company will be awarded the contract to maintain a system you developed (and it may change hands more than once), and they will strive to do the absolute minimum possible to keep the software functioning until it is retired (which is always at least 10 years longer than anyone planned).
I 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.
Earlier 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.
And when some new tech comes up then the business hires shiny new people because the people working for them haven't "kept up".
Most 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 organ…
The mistake is when people think a buzzword is the new best practice without doing real analysis.
Earlier 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.
So, you have to strike a balance between getting stuff done and taking care of your people in terms of professional development and growth.
It's ok, most organizations fail at it. The "90% of everything is crap" rule applies to managers as well.
Most 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…
It really is true that huge monolith legacy systems might prevent dev teams focused on product growth from even being capable of doing their jobs, let alone meeting aggressive deadlines.
It doesn’t always mean microservices or heavy re-architecture is the right choice, but sometimes it absolutely is.
The places where I’ve seen the most value to pivoting away from existing monoliths often have benefited a lot from microservices.
I was part of a group that split a huge tangled mess of search engine and image processing services in a monorepo into separate smaller web services, and by further separating them into distinct repos per project, we could migrate things to new versions, convert some legacy Java services into Python to take advantage of machine learning tools that fundamentally do not exist in jvm languages, all in more careful, isolated ways that monorepo tooling just simply doesn’t support, and lots of other things that would not have been possible if we tried to steadily change portions while preserving their co-integration in a single large project that attempted to support modularization in ways that were simply just bad.
Your language seems to betray the fact that you personally associate the entire concept of microservices with being intrinsically dogmatic.
Typically only dogmatic people feel that way, in my experience. But either way, there’s nothing inherently dogmatic about a microservices approach.
Interesting that the article mentions Shopify supporting over 600,000 users with a Rails monolith. At my day job, one of the justifications for us adopting microservices is that we want to horizontally scale. We have fewer than 8,000 users. Hubris, eh?
Most 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 sounds sanctimonious and rife with the exact same inexperience and overly brittle purist attitudes you are criticizing. It really is true that huge monolith legacy systems might prevent dev teams focused on product growth from even being capable of doing their jobs, let alone meeting aggressive deadlines. It doesn’t always mean microservices or heavy re-architecture is the right choice, but sometimes it absolute…
»In the end, it's absolutely the case that a movement to microservices is something that should be evolutionary, and in direct need to technical requirements.«
I would argue that what you did is exactly that. Perhaps with the caveat that it should have been done earlier.
I'm not reading tha parent arguing that one should stick with a monorepo/monolith until the end of time, but rather providing a few thoughts around what might cause a push in applying microservices incorrectly.
Most 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…
And are very often right about it. Delivering monoliths can require such amount of bureaucracy and needless coordination that it slows everything down. I've seen it.
> Inexperienced developers proposing microservices because they think it sounds much more fun than working on the system as it is currently designed.
It doesn't matter who proposes something, if its good idea, do it. And in my experience it is indeed more fun (in addition to other benefits).
> Technology does not solve these problems.
Using microservices is a matter of organisation, it has nothing to do with technology. It is non-technical solution for non-technical problem. Any effect it may have on a technology is secondary to main goal.
> In the end, it's absolutely the case that a movement to microservices is something that should be evolutionary
Nothing you said before contradicts that.
> and in direct need to technical requirements
How people are organized is not a technical requirement.
> For nearly every company out there, a horizontally-scaled monolith will be much simpler to maintain and extend than some web of services,
To maintain, yes. To develop, often not.