You should always start with domain specific microservices. Those “microservices” shouldn’t be out of process services necessarily. They can just as easily be in process “domain services” in a monolith that are only accessed via an interface where each module is treated as a black box.
Microservices Are Something You Grow Into, Not Begin With
61–70 of 159 posts
Re: Microservices Are Something You Grow Into, Not Begin With
#62Earlier 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.
Your job is whatever you agreed to when accepting that job.
Some companies require managers to aid in the technical development of employees, some don't. Some provide a lot of latitude in how that's done, some don't.
Re: Microservices Are Something You Grow Into, Not Begin With
#63Most 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'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
Re: Microservices Are Something You Grow Into, Not Begin With
#64Interesting 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?
Author here.
Keep in mind Shopify does scale horizontally in terms of servers. They are just scaling a monolithic application.
Those 600k shop owners results in Shopify's platform handling over 80,000 requests per second according to stats that are publicly available[0].
It's one of the largest scale Rails apps in production.
Re: Microservices Are Something You Grow Into, Not Begin With
#65I 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…
In theory, translating an interface-based monolith to a SOA should be straightforward - drop-in some replacement classes for your services and you're good to go.
In practice, it's not as simple as that. Serialization across service boundaries requires a bit of thought - invoking a method via a local call stack can accidentally cause a blowout on an SOA service buffer. Network timeouts suddenly become a thing. Latency might be an issue.
Of course, these aren't critical obstacles, and I agree that the architecture should look very similar, no matter whether it's a monolith or microservice. But designing one from the ground up would look a bit different.
Re: Microservices Are Something You Grow Into, Not Begin With
#66Earlier quoted context omitted.
Indeed. It just replaces internal calls between services of your monolith with flaky and slower network calls.
This can sometimes be worthwhile in a corporate environment even if technically it makes things harder, because it solves a major political / communication problem. However, for the expense of dealing with the complications of an additional network boundary to worthwhile, some of the following must hold: * You need architect who has an overview of the whole system creates abstractions that make sense and puts the API…
"Although the evidence is sparse, I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team."
Re: Microservices Are Something You Grow Into, Not Begin With
#67Most 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…
Microservices are a cult, but SOA is Amazon's conerstone. Most services are the right size to fit a team (so, not micro) and implement separation of concerns. Random link: https://www.zdnet.com/article/soa-done-right-the-amazon-stra...
Some Amazon teams have multiple services of varying sizes. What Amazon and similar companies get right is by (generally) insisting on good engineering/business/regulatory reasons for splitting out services.
Re: Microservices Are Something You Grow Into, Not Begin With
#68Earlier quoted context omitted.
Just like you have tests between monolith modules you can have integration tests between microservices
The more layers you are testing, the slower and harder it is to write tests and the feedback loop is way longer also.
Depends how you do it. Having a sane communication model/interface between the services allows you to test it in two ways:
1) You test the internal structure with unit tests
2) You test changes to the API contract with E2E tests
Both are fairly straightforward once you set it up properly.
Same goes for the monolith, assuming you do your work on following somethink like the SOLID principle, it is easy to test piece by piece. The only thing here is that the interface contracts are internal to the codebase vs external to other codebases. (You might argue the last point actually forces you to write a more coherent API contract in both situations)
Re: Microservices Are Something You Grow Into, Not Begin With
#69Most 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'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"?
Re: Microservices Are Something You Grow Into, Not Begin With
#70I 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…
It's a form of https://en.wikipedia.org/wiki/Zero_one_infinity_rule; by starting with two, you're already at "infinity", and it's easier to go from there than it is to transition from 0-1 or from 1-infinity.