6 ms·
I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are: 1. Independent releases 2. Easier for on-
by seperman 7y ago
I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are:
1. Independent releases
2. Easier for on-boarding new engineers
3. Scale micro-services independently
The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search is so much faster after the breakout!".
- drbojingle 7y agoHow many engineers do you have and what's your growth in manpower like?
- ryan_j_naughton 7y agoOur entire product, engineering, data science, design org is around 80-90. Engineering is about 50-65% of that. But search/merchandising is a small fraction of the team. We have 2 dedicated backend engineers on the search team. We are growing rapidly. We are aiming to double the size of the eng org in the next 8 months.
- drbojingle 7y agoCool, thanks for sharing. So is your micro-service architecture you described in your article for the 2 engineers or the 40? Asking because 40+ doubling to 80+ seems like a great fit for Micro-services, but 2 people, eh, not so much, IMO.
- gitgud 7y agoMicroservices are almost completely opposed to agile development. They require a strong architecture before implementation and are much harder to reconfigure regardless of versioning. The running system is also hard to manage.
- seperman 7y agoNot sure if I agree with you regarding the agile part. If each team owns their "micro-service", then they can have their own "sprints".
- budabudimir 7y agoWhat is the difference between each team owning a microservice and owning a part of the monolith? There is common release process, but with proper infra in place, that shouldn't be a problem.
- seperman 7y agoI was just disagreeing with "Microservices are almost completely opposed to agile development". You can be agile in both monolith architecture and micro-services. I don't see why microservices can be opposed to agile.
- sheeshkebab 7y agoIt all comes down to coordination and regression, which are quite complex in monoliths. Suppose you'd like to push code change to production for your monolith - how do you know that someone else's change 1) is ready to to production together with yours 2) does not affect your module. Typically these can't be answered easily - and so release process is converted to manual testing and scheduled (and often slow) releases.
- gitgud 7y agoYes in very large systems that's true. But in the other systems, there's huge overheads which restrict systems from changing. - Multiple execution environments - Complexity in communication between services - Managing the versioning of each service and it's dependent services. Although services are easily to scale and change independently, they are hard to reconfigure globally, which means the application as a whole is hard to change...
- seperman 7y ago
- simplify 7y agoHow is it easier to on-board new engineers? You mentioned but did not explain this point.
- fouc 7y agoEasier to on-board in the sense of limiting what new engineers can see, only giving them smaller pieces of access. Otherwise it's probably the opposite, takes a lot longer for new engineers to understand the full system. Perhaps even reduces the bus factor, since less people understand all the moving parts.
- seperman 7y agoExactly. I could not have explained it better than you.
- accnumnplus1 7y agoThat can be done with libraries.
- seperman 7y agoWe do use libraries as much as possible. However we avoid putting business logic into libraries.