41–48 of 48 posts
Writing new code is faster than understanding existing code. Different teams should have enough room to not step on each other toes. Soft boundaries tend to be overruled over time, because of human laziness.
Sure, if you start over you may we’ll get there faster but you’ll probably repeats some of the same mistakes all over again.
Writing new code is faster than understanding existing code. Different teams should have enough room to not step on each other toes. Soft boundaries tend to be overruled over time, because of human laziness.
I’m not so sure, I’d rather start from what is there, understand it and go from there. Sure, if you start over you may we’ll get there faster but you’ll probably repeats some of the same mistakes all over again.
I am a proponent of the disposable-code philosophy though: no system should be considered "off limits", and a healthy codebase should probably be completely rewritten every couple of years. It should just be done incrementally, in a modular way in most cases rather than throwing out the whole thing and starting again.
Why is microservices so much more popular right now than, say, distributed processing via the actor model? It feels like splitting things up with HTTP boundaries is a lot of work, less flexible and precludes a lot of re-use. Is it just because of advances in tooling lately like Kubernetes and docker?
HTTP makes sense from the standpoint that if you want to have a lot of flexibility over how and where your services are run, they can be addressed the same way whether they're running on one box in your living room or distributed across several data centers.
Earlier quoted context omitted.
Not sure if I agree with you regarding the agile part. If each team owns their "micro-service", then they can have their own "sprints".
What 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.
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.
Earlier quoted context omitted.
How many engineers do you have and what's your growth in manpower like?
Our 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.
Earlier quoted context omitted.
How is it easier to on-board new engineers? You mentioned but did not explain this point.
Easier 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.
Earlier quoted context omitted.
Easier 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.
That can be done with libraries.
Earlier quoted context omitted.
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…
Microservices 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.
But if those things are constantly in flux, it really isn't a good candidate for splitting into a microservice in the first place.