41–50 of 159 posts
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?
There's trade-off's. They are using a fairly complex CI while with micro-services you release each service individually. It's hard to turn a monolith architecture into a architecture with micro-services. So it all depends on what works best for you. The idea with micro-services is that with a much smaller service - development is faster and cheaper, you can for example rewrite the entire service, use different softwa…
Come on. The system is as large and as complex as will be necessary. Separating components with network calls doesn't make them any less interdependent.
Don't start out with a DI framework, use poor man's DI (ie 'passing stuff in').
Don't start out with microservices, use (poor man's) DI, ban all public static/global variables, and segregate code into separate processes with public 'interfaces' (but don't use actual interfaces until you actually need them! 1 interface per class is an antipattern!). These can all run in an async process pool you build, which can monitor bottlenecks when you get to that point. You can then (years later) easily break an internal service into a microservice when the trade off makes sense.
I'm obviously static typing/oop focused, but there's a version of this which applies to any paradigm.
Most 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…
Does IT fail sometimes? Sure. But more often than not projects go sideways at the leadership / team (i.e., all stakeholders, not just IT) level. Blaming IT is a convenient narrative.
people jump into this because of shit processes like agile which push for incremental and iterative development processes instead of thinking things through properly. usully just to be able to have easy deliverables and easy reporting to upper management about the epic progress that is made. all the while product quality usually is degraded to a point where customers will start to feel it badly. always the same dumb…
I agree that microservices is the new "must have" technology but actually it isn't a great deal different from a monolith. The monolith can have separation between services and still requires interfaces to work between them. As others have said, microservices bring a lot of baggage that you might never have seen before (i.e. big learning curve) and the myth of isolated changes is just that, a myth. Unless it is some…
I personally don't like the word "microservices" since it implies that services have to be micro. For the last few years I have worked on service oriented systems where the individual components are sometimes pretty big - one could say almost monolithic :).
Splitting a monolith into separate services exacts an operational price. Engineers should be honest in assessing whether it's worth it. Sometimes it is, sometimes it isn't.
Interesting 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?
At one extreme, you have applications that need horizontal scaling from day one (Scientific computing). At the other, a monolith serving 10^6 users from a single app instance.
I grew out of microservices because it felt like I was doing the same boilerplate REST service over and over. So I made a modular REST API service that could load plugins. The plugins can contain anything from simple endpoints to database schemas with sqlalchemy. All this is loaded into the main app at runtime. So the main app can handle authentication against LDAP for example while all the various deployed microserv…
So a Python version of a J2EE app server?
Interesting 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?
The load per user can be widely different in different application. We don't have a great measure for that, one cound use a combination of requests per user per day, and the sum of CPU-seconds used to serve them. The sum of CPU-seconds should contain the periodic (e.g. cron-like, not directly request-answering) tasks too. At one extreme, you have applications that need horizontal scaling from day one (Scientific comp…
For context: the product at my day job does something likely at an equivalent level of complexity to Shopify. It's just another SaaS business that handles payments, invoicing, etc. If anything, Shopify is more complex.