Microservices are just the new EJB. Those of us who know better will only increase abstraction when necessary.
Monoliths Are the Future
251–260 of 567 posts
Re: Monoliths Are the Future
#252I think the underlying point, as expressed by the author, is that trendy new architecture patterns will never be a panacea for bad engineering, though that's often how they're implicitly sold as ideas.
It is actually sold as a way to fix bad engineering? I've literally never heard that before. I think almost everyone knows that microservices are hard. On the other hand they are often sold as a way to increase developer velocity. And I do sometimes wonder if that is the case (based on personal experience).
We did a massive rewrite of a 7 year old giant code base to microservices gradually over a couple years. One of the only few positives that we gained from it was that when we crashed we didn't bring down everything at once. The biggest negative was that we ended up with an extremely noisy event bus that made backups and diagnosing out of sync issues very problematic.
Re: Monoliths Are the Future
#253Earlier quoted context omitted.
> you create unmaintainable spaghetti that can't ever change without breaking things you can't easily surface. How does creating a tangle of microservices (effectively distributed objects) really solve the problem?
Microservices provide an abstraction. That is kind of the point. If you feel like the data yours service operates on would be better off stored in a redis database instead of an RDBMS, you can rewrite your persistence layer, test and roll out the new version of the service. As long as your APIs do not change, nobody cares how you produce responses to requests. In a monolith, this would be a nightmare. You don't have…
Seems to me you are talking about a database access layer instead of microservices.
My understanding of microservices is a bunch of loosely connected services that can be changed with minimal impact to the others
Problem with the ideal is in reality this never works as complexity grows the spaghetti code moves to spaghetti infrastructure ( Done a network map of a large k8s / istio deployment lately ? )
Re: Monoliths Are the Future
#254Earlier quoted context omitted.
> you do not simply go and poke your reporting fingers into individual service databases Side point: This is a needlessly hostile and unprofessional way to refer to a colleague. Remember that you and the reporting/analytics people at your company are working towards the same goals (the company's business goals). You are collaborators, not combatants. You can express your same point by saying something like "The habit…
This is an incredible overreaction to an entirely innocuous comment.
I've noticed reporting/analytics people going extinct around my workplace as micro services make monitoring easier. There might be some pent up hostility towards the technology side
Re: Monoliths Are the Future
#255I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…
This is what gave rise to data lakes. The typical data lake maturity model I see in enterprise is: 1. Pay a ton of money to Microsoft for Azure Data Lake, Power BI, etc. 2. Spend 12 months building ETLs from all your microservices to feed a torrent of raw data to your lake. 3. Start to think about what KPIs you want to measure. 4. Sign up for a free Google Analytics account and use that instead.
> Spend 12 months building ETLs
Okay, sounds reasonable enough for a complex enterprise.
> to feed a torrent of raw data to your lake
Well, there's the problem. Why is it taking a year to export data in its raw, natural state? The entire point of a data lake is that there is no transformation of the data. There's no need to verify the data is accurate. There's no need to make sure it's performant. It's just data exported from one system to another. If the file sizes, or record counts match, you're in good shape.
If it's taking a year to simply copy raw data from one system to another, the enterprise has deeper problems than architecture.
Re: Monoliths Are the Future
#256I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…
Build a reporting database that maintains a copy of data from other data stores. Simple enough. Surely you wouldn't run analytics directly on your prod serving database, and risk a bad query taking down your whole system?
I'd probably reach for setting up a read replica (trivial) before completely overhauling my architecture.
Re: Monoliths Are the Future
#257What is old is new again. I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One company I worked with tried to move our entire monolith application, which was well architected and worked fine, over to a microservices-based architecture and the result was an unstable, complex mess. Sometimes, if it's not broke, don't try to "fix" it. I can say th…
I am fine with that, I miss the simplicity of PHP and Delphi sometimes.
Re: Monoliths Are the Future
#258Earlier quoted context omitted.
What/where do you run this mythical one-analyst pipeline, though? Is that in cloud services too? Airflow? Kubeflow? Apache Beam? It sounds like you're just pushing the problem around.
AWS data pipelines and AWS lambda. It's cloud services the whole way down. https://aws.amazon.com/datapipeline/
I saved a company 20k a month by creating a job server in AWS. Lambda isnt cheap when you start using it hard
Re: Monoliths Are the Future
#259Earlier quoted context omitted.
> Quite the self-fulfilling prophecy there. Microservices require your organization to have an engineering culture. I would be afraid of introducing them at, say, Home Depot where (I've heard) your average programmer doesn't even write tests. If you have engineering talent within a small multiplicative factor of Google (say 0.5), then you can pull off Microservices at your org. Edit: I'm being downvoted, but I don't…
I think you're being downvoted because you're implying monoliths don't require an engineering culture and that microservices are a silver bullet in getting systems built correctly. I've seen good and bad in each approach. It's certainly possible to enforce good SOCs and proper boundaries in monorepos, and also possible to plough a system into the ground with microservices. They're all just tools in your toolbox and b…
[deleted]
Re: Monoliths Are the Future
#260Earlier quoted context omitted.
> It can be done wrong, but when executed correctly [...] Quite the self-fulfilling prophecy there. > Yes, it's easier to get your data, but in the long run [...] Systems can and should be evolved and adapted over time. E.g. deploying components of the monolith as separate services. You can't easily predict what the requirements for your software going to be in say 10 years. And depending on the stage a company is, e…
> Quite the self-fulfilling prophecy there. Microservices require your organization to have an engineering culture. I would be afraid of introducing them at, say, Home Depot where (I've heard) your average programmer doesn't even write tests. If you have engineering talent within a small multiplicative factor of Google (say 0.5), then you can pull off Microservices at your org. Edit: I'm being downvoted, but I don't…
You’d be surprised how sophisticated Home Depot is. They switched their monolith to microservices using Spinnaker and even contributed back to Spinnaker.