4 ms·

It depends on how you do it. We have 5 engineers and around 50 services and it’s much easier for us to maintain that than it was when it was monolith with a cou

by devjab 3y ago

It depends on how you do it. We have 5 engineers and around 50 services and it’s much easier for us to maintain that than it was when it was monolith with a couple of services on top. Though to understand why this is, you would have to know just how poorly our monolith was designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” and suddenly you end up with this huge spiderweb mess of a database that nobody knows who pulls what from because everyone has connected some sort of thing to it and now your monolith isn’t really a monolith because of it. Which isn’t how a monolith is supposed to work, but is somehow always how it ends up working anyway. I do agree though, that the “DevOps” space for “medium-non-software-development” IT departments in larger companies is just terrible. We ended up outsourcing it, sort of, so that our regular IT operations partner (the ones which also help with networking, storage, backups, security and so on) also handle the management part of our managed Kubernetes cluster. So that once something leaves the build pipeline, it’s theirs. Which was surprisingly cheap by the way. I do get where you’re coming from of course. If we had wanted to do it ourselves, we’d likely need to write “infrastructure as code” that was twice the size of the actual services we deploy.

jabradoodle 3y ago
> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith. More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually finally invest in fixing things. Perhaps your microservice rewrite goes well because you now know your domain after building the monolith, that is another option.
- devjab 3y ago
  With the microservice architecture it’s easier to lock things down. You can’t have someone outside of your team just give access to a dataset or similar because excel can’t get a connection directly into your DB. Which is an argument you could rightfully make for monoliths, except in my experience, someone always finds a sneaky way into the data on monoliths, but it’s too hard for them to do so with MicroServices. If you gave me total control over everything, I’d probably build a couple of monoliths with some shared modules. But every time the data is centralised, it always somehow ends up being a total mess. With MicroServices you’ll still end up with a total mess in parts of the organisation, but at least it’ll be in something like PowerBI or even your datawarehouse and not directly in your master data. Or to put it differently, for me MicroServices vs monoliths is all most completely an organisational question and not a technical one.
  - jabradoodle 3y ago
    It's not like microservices don't also give you chances to mess your data up. It's hard to do transactions across boundaries, you have to deal with eventual consistency, sometimes there is no single source of truth. I struggle to see how microservices fix this for people; having worked primarily with them for the past 6 years.
- shados 3y ago
  The thing with microservices is that shit doesn't have to infect everything. If someone in another team is clueless, they'll mess up their microservices but not anyone else's. If they are in a monolith, it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either). Unless it's a shared library, which is why good microservices architecture limit the shared surface as much as possible.
  - jabradoodle 3y ago
    > it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either This still happens with microservices though; people can still make terrible architecture decisions and standup terrible services you depend on.

by devjab 3y ago

jabradoodle 3y ago

> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith. More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually finally invest in fixing things. Perhaps your microservice rewrite goes well because you now know your domain after building the monolith, that is another option.

devjab 3y ago
With the microservice architecture it’s easier to lock things down. You can’t have someone outside of your team just give access to a dataset or similar because excel can’t get a connection directly into your DB. Which is an argument you could rightfully make for monoliths, except in my experience, someone always finds a sneaky way into the data on monoliths, but it’s too hard for them to do so with MicroServices. If you gave me total control over everything, I’d probably build a couple of monoliths with some shared modules. But every time the data is centralised, it always somehow ends up being a total mess. With MicroServices you’ll still end up with a total mess in parts of the organisation, but at least it’ll be in something like PowerBI or even your datawarehouse and not directly in your master data. Or to put it differently, for me MicroServices vs monoliths is all most completely an organisational question and not a technical one.
- jabradoodle 3y ago
  It's not like microservices don't also give you chances to mess your data up. It's hard to do transactions across boundaries, you have to deal with eventual consistency, sometimes there is no single source of truth. I struggle to see how microservices fix this for people; having worked primarily with them for the past 6 years.
shados 3y ago
The thing with microservices is that shit doesn't have to infect everything. If someone in another team is clueless, they'll mess up their microservices but not anyone else's. If they are in a monolith, it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either). Unless it's a shared library, which is why good microservices architecture limit the shared surface as much as possible.
- jabradoodle 3y ago
  > it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either This still happens with microservices though; people can still make terrible architecture decisions and standup terrible services you depend on.