4 ms·

Code ownership, stewardship, or free-for-all?

44 points by spallas 5y ago

Cthulhu_ 5y ago
A step back maybe, but that's a lot of different technologies and skillsets required for a small amount of people. One thing to always keep in mind is the 'choose boring technology' mantra; prefer using existing technology (e.g. languages, API technologies, front-end libraries) over adding new ones. Every new tech adds complexity, or another node in a graph. Also, avoid microservices. That is, don't build microservices to start off with, because you're most likely making the wrong abstraction, and you're adding a ton of overhead (inter-service communication, logging, tracing, envirionment setup, etc). Splitting off services is fine as long as you can bring a strong argument in favor of it (e.g. performance, if one aspect of your application is hit 10-100x as hard). But in practice, in most applications, you don't need microservices. You will need scalable services, but those don't have to be 'micro' per se. Also don't get hung up on the 'micro' in the name, size should never be a reason to break up a monolith.
- lbriner 5y ago
  I think you are repeating a strawman argument against microservices that doesn't always hold. Microservices are about domains of logic and form nice clear boundaries. They don't necessarily need inter-service comms or much by way of environment setup/maintenance. We have an email microservice that was split up that way because the email logic was spread out everywhere and called from multiple apps. A microservice was a good way to encapsulate all of the email logic into a single place with a clean interface. We can make all sorts of centralised changes without affecting any of the apps. We can also scale it out as the amount of email we need to send increases.
  - kortilla 5y ago
    Email just sounds like a regular service. Separate SMTP servers where you encapsulate all of your logic of email dispatch frequency, retries, etc has been pretty standard for a long time. > encapsulate all of the email logic into a single place with a clean interface You can encapsulate and put stuff behind an interface with libraries too. This is not the value proposition of microservices.
  - Chris2048 5y ago
    Parent said: don't build microservices to start off with and you describe: because the email logic was spread out everywhere and called from multiple apps so it doesn't sound like a counterpoint to me - you didn't start off with the email service, and only split it off after it was already established across multiple entities. Plus, you added a bunch of justifications for this, i.e you could "bring a strong argument in favor of it" - so where is the strawman in your examples?
- marcosdumay 5y ago
  > e.g. performance, if one aspect of your application is hit 10-100x as hard I'm not sure this one is a good argument for microservices. Having 100 copies of a microservice isn't any easier than having 110 copies of a monolith. Any kind of competent code division is done because the divided interface is simpler than what you'll get without the division. So, go with the sibling here, and divide your code only if you have a very enticing interface that will be good to isolate and reuse. Doing high-level architecture decision because of operational details is almost guaranteed to lead you into disaster. You can do a few of them ever, so if you do it, it's better be one of your main differentials.
  - nijave 5y ago
    It's cheaper when you reduce resource requirements. If you're loading a bunch of code in memory you don't end up using, you're wasting memory. Depending on how modular your code is, you may end up loading other external dependencies that don't get used (like initializing database connections). Likewise, for containers, you can usually make the container image smaller reducing data transfer, reducing Docker pull time, reducing host IOPs to unpack the image. A lot of those problems can be optimized around, but sometimes it's quite a bit of work if you're already on a platform or framework that makes assumptions If you're not deploying or scaling often and you have other mitigations like lazy loading to reduce memory, there may be no advantage.
nfrankel 5y ago
>As a simple example, imagine a small team of, say, 6 developers: > >The team has created and now supports a mobile app, an Alexa skill, three separate web apps, fifteen microservices, and a partridge in a pear tree. If a team of 6 developers created 15 microservices, I'm afraid that they don't understand the pros nor the cons of microservices and they should be fired instantly.
- frockington1 5y ago
  Too be fair I did the same thing 2 years ago and I'm sure I'm not the only one. Drank to much microservice koolaid and ended up with 12 services. Consolidated it down to 7 once initial micro high wore off
  - deleted 5y ago
    [deleted]
- Chris2048 5y ago
  Counterpoint: anyone who suggests the number of microservices should correlate to the number of developers should be fired instantly.
  - marcosdumay 5y ago
    Wait, what? Are you suggesting that the number of developers does not place a maximum cap on the complexity of your infrastructure? Because if what you are saying is that nobody should ever get near that cap, so it should be theoretical only, that still supports a correlation.
    - natpalmer1776 5y ago
      Six full time developers who wrote 15 microservices that each do one thing well should not be fired. The burden of microservices lies in the underlying infrastructure required to host them. So, assuming we have a competent infrastructure engineer, devops engineer, security engineer, site-reliability engineer, and a handful of other hats being done well... your six developers can write and maintain far more than 15 microservices assuming that each service has a clearly defined single-objective scope. Because infrastructure complexity <> Software development complexity.
cosmiccatnap 5y ago
jillesvangurp 5y ago
A model that is common in open source but yet not in the corporate world is that of gatekeepers. It's essentially a form of strong code ownership combined with stewardship where a majority of contributions are not necessarily created by the owner/gatekeeper. Instead a gatekeeper works with a small group of others to accept, integrate, and coordinate change request from a larger group of people. Their job is to reject bad changes, and ensure integrity of the overall project is balanced with the needs and wants of those contributing code. For most contributors the repository they contribute to is read only. They have to fork it to even be able to modify it. Linux is the classical example of this. But many open source git projects work like this now. Commit access on an open source project is reserved for people in a gate keeper role. Usually these people are also contributing significant amounts of code. But the whole point of being open is that others can look at your code and modify it. And of course there is no obligation to merge those changes. You have to ask for those changes to be merged. And that request can be denied for all sorts of reasons. To get changes in, you have to negotiate with the gatekeeper and work by their rules. Somehow this model never really caught on in the corporate world. They'll use git of course and they do pull requests even. But it's quite common for all people to have commit rights and have just a soft rule that pull requests ought to be reviewed and merged by someone else. But most companies and teams end up cutting corners when they are under time pressure or when management throws its weight around. Once a pull request has work done on it, it just becomes hard to reject it without creating a lot of internal conflict. Unlike the open source community where you have to negotiate with the repository owners to get your change accepted, corporate gatekeepers, if they exist at all, typically lack the independence that e.g. Linus Torvalds would have to accept/reject changes. They'll bow to management pressures, arbitrary dead lines, etc. Gatekeepers like that are essential to large scale software open source projects. The short term interests of contributors are balanced with the long term interests of the software product. Companies seem to have a much harder time doing that. I think that especially large companies should be adopting this model.
- bluehatbrit 5y ago
  We had something similar to this in a previous job. It was a large organisation and each team owned their own components, they had merge access etc. If another team wanted to make a change they'd submit a pull request and the owning team would review it. That owning team would impose their own process and tooling on top of the standard stuff that was org wide. The big difference I suppose is that the team were the ones doing the majority of the work rather than purely gatekeeping. It did work very well on the whole though, especially as that team would then be responsible it in production.

44 points by spallas 5y ago

A step back maybe, but that's a lot of different technologies and skillsets required for a small amount of people. One thing to always keep in mind is the 'choose boring technology' mantra; prefer using existing technology (e.g. languages, API technologies, front-end libraries) over adding new ones. Every new tech adds complexity, or another node in a graph. Also, avoid microservices. That is, don't build microservices to start off with, because you're most likely making the wrong abstraction, and you're adding a ton of overhead (inter-service communication, logging, tracing, envirionment setup, etc). Splitting off services is fine as long as you can bring a strong argument in favor of it (e.g. performance, if one aspect of your application is hit 10-100x as hard). But in practice, in most applications, you don't need microservices. You will need scalable services, but those don't have to be 'micro' per se. Also don't get hung up on the 'micro' in the name, size should never be a reason to break up a monolith.

lbriner 5y ago
I think you are repeating a strawman argument against microservices that doesn't always hold. Microservices are about domains of logic and form nice clear boundaries. They don't necessarily need inter-service comms or much by way of environment setup/maintenance. We have an email microservice that was split up that way because the email logic was spread out everywhere and called from multiple apps. A microservice was a good way to encapsulate all of the email logic into a single place with a clean interface. We can make all sorts of centralised changes without affecting any of the apps. We can also scale it out as the amount of email we need to send increases.
- kortilla 5y ago
  Email just sounds like a regular service. Separate SMTP servers where you encapsulate all of your logic of email dispatch frequency, retries, etc has been pretty standard for a long time. > encapsulate all of the email logic into a single place with a clean interface You can encapsulate and put stuff behind an interface with libraries too. This is not the value proposition of microservices.
- Chris2048 5y ago
  Parent said: don't build microservices to start off with and you describe: because the email logic was spread out everywhere and called from multiple apps so it doesn't sound like a counterpoint to me - you didn't start off with the email service, and only split it off after it was already established across multiple entities. Plus, you added a bunch of justifications for this, i.e you could "bring a strong argument in favor of it" - so where is the strawman in your examples?
marcosdumay 5y ago
> e.g. performance, if one aspect of your application is hit 10-100x as hard I'm not sure this one is a good argument for microservices. Having 100 copies of a microservice isn't any easier than having 110 copies of a monolith. Any kind of competent code division is done because the divided interface is simpler than what you'll get without the division. So, go with the sibling here, and divide your code only if you have a very enticing interface that will be good to isolate and reuse. Doing high-level architecture decision because of operational details is almost guaranteed to lead you into disaster. You can do a few of them ever, so if you do it, it's better be one of your main differentials.
- nijave 5y ago
  It's cheaper when you reduce resource requirements. If you're loading a bunch of code in memory you don't end up using, you're wasting memory. Depending on how modular your code is, you may end up loading other external dependencies that don't get used (like initializing database connections). Likewise, for containers, you can usually make the container image smaller reducing data transfer, reducing Docker pull time, reducing host IOPs to unpack the image. A lot of those problems can be optimized around, but sometimes it's quite a bit of work if you're already on a platform or framework that makes assumptions If you're not deploying or scaling often and you have other mitigations like lazy loading to reduce memory, there may be no advantage.

nfrankel 5y ago

>As a simple example, imagine a small team of, say, 6 developers: > >The team has created and now supports a mobile app, an Alexa skill, three separate web apps, fifteen microservices, and a partridge in a pear tree. If a team of 6 developers created 15 microservices, I'm afraid that they don't understand the pros nor the cons of microservices and they should be fired instantly.

frockington1 5y ago
Too be fair I did the same thing 2 years ago and I'm sure I'm not the only one. Drank to much microservice koolaid and ended up with 12 services. Consolidated it down to 7 once initial micro high wore off
- deleted 5y ago
  [deleted]
Chris2048 5y ago
Counterpoint: anyone who suggests the number of microservices should correlate to the number of developers should be fired instantly.
- marcosdumay 5y ago
  Wait, what? Are you suggesting that the number of developers does not place a maximum cap on the complexity of your infrastructure? Because if what you are saying is that nobody should ever get near that cap, so it should be theoretical only, that still supports a correlation.
  - natpalmer1776 5y ago
    Six full time developers who wrote 15 microservices that each do one thing well should not be fired. The burden of microservices lies in the underlying infrastructure required to host them. So, assuming we have a competent infrastructure engineer, devops engineer, security engineer, site-reliability engineer, and a handful of other hats being done well... your six developers can write and maintain far more than 15 microservices assuming that each service has a clearly defined single-objective scope. Because infrastructure complexity <> Software development complexity.

cosmiccatnap 5y ago

jillesvangurp 5y ago

A model that is common in open source but yet not in the corporate world is that of gatekeepers. It's essentially a form of strong code ownership combined with stewardship where a majority of contributions are not necessarily created by the owner/gatekeeper. Instead a gatekeeper works with a small group of others to accept, integrate, and coordinate change request from a larger group of people. Their job is to reject bad changes, and ensure integrity of the overall project is balanced with the needs and wants of those contributing code. For most contributors the repository they contribute to is read only. They have to fork it to even be able to modify it. Linux is the classical example of this. But many open source git projects work like this now. Commit access on an open source project is reserved for people in a gate keeper role. Usually these people are also contributing significant amounts of code. But the whole point of being open is that others can look at your code and modify it. And of course there is no obligation to merge those changes. You have to ask for those changes to be merged. And that request can be denied for all sorts of reasons. To get changes in, you have to negotiate with the gatekeeper and work by their rules. Somehow this model never really caught on in the corporate world. They'll use git of course and they do pull requests even. But it's quite common for all people to have commit rights and have just a soft rule that pull requests ought to be reviewed and merged by someone else. But most companies and teams end up cutting corners when they are under time pressure or when management throws its weight around. Once a pull request has work done on it, it just becomes hard to reject it without creating a lot of internal conflict. Unlike the open source community where you have to negotiate with the repository owners to get your change accepted, corporate gatekeepers, if they exist at all, typically lack the independence that e.g. Linus Torvalds would have to accept/reject changes. They'll bow to management pressures, arbitrary dead lines, etc. Gatekeepers like that are essential to large scale software open source projects. The short term interests of contributors are balanced with the long term interests of the software product. Companies seem to have a much harder time doing that. I think that especially large companies should be adopting this model.

bluehatbrit 5y ago
We had something similar to this in a previous job. It was a large organisation and each team owned their own components, they had merge access etc. If another team wanted to make a change they'd submit a pull request and the owning team would review it. That owning team would impose their own process and tooling on top of the standard stuff that was org wide. The big difference I suppose is that the team were the ones doing the majority of the work rather than purely gatekeeping. It did work very well on the whole though, especially as that team would then be responsible it in production.