This needs a "(2015)" adding to the title.
Agreed, was reading through this and before I checked the date - all I could think was "I know I've read this before - did someone just republish this as their own?"
“It's The Future”
491–500 of 536 posts
Re: “It's The Future”
#492Re: “It's The Future”
#493"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
What was the benefit you envisioned?
We were looking to break up our monolithic rails app into micro-services so devs could iterate and develop faster. We also thought that the application as a whole would become more failure resistant. Unfortunately, inter-dependancies among the services themselves meant that the failure-resistance didn't pan out as we thought.
Re: “It's The Future”
#494"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
> Also, the team spent too much time debating standards etc. IMHO. You need a lead with a clear vision that drives the effort. Too many leads will create chaos.
We did have a lead with a vision, and part of the vision was standards for each service (for example, file structure in Go). I can see the rationale behind it; a new dev can onboard very quickly on to a new service. But in hindsight, maybe it wasn't thought out enough.
Re: “It's The Future”
#495"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
> Also, the team spent too much time debating standards etc. IMHO. You need a lead with a clear vision that drives the effort. Too many leads will create chaos.
[deleted]
Re: “It's The Future”
#496"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
was it a complete rewrite? I don't think thats the right way to transition. Why didn't you try to separate the features one-by-one from the monolith? That would give more immediate feedback and real problems to work on instead of the possibility to get stuck on the holy architecture debate.
No it wasn't a complete rewrite. We started by separating out the most mission critical components. Maybe that's where we went wrong; the most mission critical components were quite large and unwieldy to split out all at once. There was also the overhead of keeping the newly separated out component and the monolithic app in sync.
Re: “It's The Future”
#497The article perfectly summarizes my frustration and sentiment. These days I hear these buzzwords all time. I work as a consultant for an enterprise product and most people whom I meet they somehow catch these buzzwords and blurt it out in front of everyone during meetings and discussions to either showoff that they know technology and things that are in the market these days(also latest iphone, apple news, tesla, spa…
Micro-services are the current-year deity of the cargo-cult that is Silicon Valley. Unlike the natives, however, who simply wasted some time building extraneous fake runways, in the Valley people are royally screwing up their own core architecture. I'm old enough to find this more humorous than frustrating.
I think micro services only came into existence because SOA was such a disaster, everyone confused SOA architectures with web services. These ended up being n-tier apps with a web service RPC (or several) in the middle just to add some unnecessary serialization and network transfer bottlenecks.
So far I've seen micro services repeat this trend almost exactly.
Re: “It's The Future”
#498Earlier quoted context omitted.
> Any positive experiences with micro-services here? Yep. We already had a feature flag system, a minimal monitoring system, and a robust alerting system in place. Microservices make our deployments much more granular. No longer do we have to roll back perfectly good changes because of bugs in unrelated parts of the codebase. Before, we had to have involved conversations about deployments, and there were many things…
That sounds more like your team doesn't know how to use git beyond nothing more than an SVN replacement.
My experience is that most devs don't even know how to use SVN correctly. I just had a conversation with someone waiting for me to finish something before they could branch. The idea that I could merge my change into their branch afterwards didn't occur to them.
Re: “It's The Future”
#499"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…
> You take your monolithic app and you split it into like 12 services. The non-web world has been doing this with message queueing for about 15 years. Maybe more.
Don't be so quick to assume micros services involve message queuing. For most it seems to just be an elaborate RPC mechanism (unfortunately).
Re: “It's The Future”
#500Earlier quoted context omitted.
Micro-services are the current-year deity of the cargo-cult that is Silicon Valley. Unlike the natives, however, who simply wasted some time building extraneous fake runways, in the Valley people are royally screwing up their own core architecture. I'm old enough to find this more humorous than frustrating.
I think micro services only came into existence because SOA was such a disaster, everyone confused SOA architectures with web services. These ended up being n-tier apps with a web service RPC (or several) in the middle just to add some unnecessary serialization and network transfer bottlenecks. So far I've seen micro services repeat this trend almost exactly.
Microservices take all the SOA problems and turn them up to eleven, as far as I can tell. It intertwines decomposition of your system (sometimes good) with network communication (rarely good) and additional ops management (never good).
Yanking out the major chucks of independent functionality into separate deployable services makes sense at a large enough scale and for large enough, independent enough components. But you would only do so out of necessity, not as an initial architecture.
And yet here we are.