Earlier quoted context omitted.
They'll have to coin a less deragatory term than monolith first. Cohesive Apps? Macroservices?
Integrapp? I'll stick to coding maybe ...
> Integrapp
That's amazing in a horrible way. Got reminded of r/THI
SRE for single-tiered software applications
11–20 of 22 posts
Re: SRE for single-tiered software applications
#12This article signals to me that we may have reached ‘peak microservice’ and should now expect a flood of blog posts extolling the virtues of monoliths and lots of industry effort to combine microservices into self-contained monoliths.
They'll have to coin a less deragatory term than monolith first. Cohesive Apps? Macroservices?
Macroservices is a winner.
Re: SRE for single-tiered software applications
#13This article signals to me that we may have reached ‘peak microservice’ and should now expect a flood of blog posts extolling the virtues of monoliths and lots of industry effort to combine microservices into self-contained monoliths.
It’s a damped oscillator — opinions shift until a model that incorporates an understanding of both emerges.
I do genuinely believe a lot of things are like this in the software industry: especially as it is a relatively young industry. You put it very nicely, we are still in the process of oscillating around the optimum ways of doing things.
Re: SRE for single-tiered software applications
#14This article signals to me that we may have reached ‘peak microservice’ and should now expect a flood of blog posts extolling the virtues of monoliths and lots of industry effort to combine microservices into self-contained monoliths.
They'll have to coin a less deragatory term than monolith first. Cohesive Apps? Macroservices?
Macroservice ??? Oh lord !!!
Re: SRE for single-tiered software applications
#15This article signals to me that we may have reached ‘peak microservice’ and should now expect a flood of blog posts extolling the virtues of monoliths and lots of industry effort to combine microservices into self-contained monoliths.
I'm not so convinced. I'll assert that a service boundary can absolutely exist between two modules running within the same binary image. The distinction comes down to grading your application along a few axes: Ratio of deployable units to bounded contexts, ball of mud versus domain-driven design, release engineering maturity, and a few others that I may be missing. I'll further assert that "a monolith" is not the ant…
Interesting comment. By the way, Sam Newman's "Building Microservices" book now has a recently published follow-up (perhaps, a revamped version) called "Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith". I'm now starting to learn DDD and, based on my analysis of the content and excellent reviews, I have chosen "Patterns, Principles, and Practices of Domain-Driven Design" by Scott Millett and Nick Tune to be my initial guide through DDD jungle. :-)
Re: SRE for single-tiered software applications
#16Earlier quoted context omitted.
I'm not so convinced. I'll assert that a service boundary can absolutely exist between two modules running within the same binary image. The distinction comes down to grading your application along a few axes: Ratio of deployable units to bounded contexts, ball of mud versus domain-driven design, release engineering maturity, and a few others that I may be missing. I'll further assert that "a monolith" is not the ant…
Interesting comment. By the way, Sam Newman's "Building Microservices" book now has a recently published follow-up (perhaps, a revamped version) called "Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith". I'm now starting to learn DDD and, based on my analysis of the content and excellent reviews, I have chosen "Patterns, Principles, and Practices of Domain-Driven Design" by Scott Millett an…
I like the characterization of DDD as a jungle. There's certainly a lot of overgrowth in the process and patterns that can be bewildering and overwhelming at first.
I was actually unaware until just now that Newman had published another book! I'll have to give it and Millett and Tune both a look.
Best of luck with your DDD adventure!
Re: SRE for single-tiered software applications
#17Earlier quoted context omitted.
Interesting comment. By the way, Sam Newman's "Building Microservices" book now has a recently published follow-up (perhaps, a revamped version) called "Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith". I'm now starting to learn DDD and, based on my analysis of the content and excellent reviews, I have chosen "Patterns, Principles, and Practices of Domain-Driven Design" by Scott Millett an…
I like the characterization of DDD as a jungle. There's certainly a lot of overgrowth in the process and patterns that can be bewildering and overwhelming at first. I was actually unaware until just now that Newman had published another book! I'll have to give it and Millett and Tune both a look. Best of luck with your DDD adventure!
Thank you for kind wishes! Please let me know your opinion on these books, when you get a chance.
Re: SRE for single-tiered software applications
#18This article signals to me that we may have reached ‘peak microservice’ and should now expect a flood of blog posts extolling the virtues of monoliths and lots of industry effort to combine microservices into self-contained monoliths.
They'll have to coin a less deragatory term than monolith first. Cohesive Apps? Macroservices?
At risk of starting a debate on the true meaning of 2001 A Space Odyssey, I don’t think “monolith” is derogatory.
Re: SRE for single-tiered software applications
#19Earlier quoted context omitted.
They'll have to coin a less deragatory term than monolith first. Cohesive Apps? Macroservices?
At risk of starting a debate on the true meaning of 2001 A Space Odyssey, I don’t think “monolith” is derogatory.
Perhaps not originally. It has that context lately.
Re: SRE for single-tiered software applications
#20All well and good. Here's something that sounds totally crazy: the future of infrastructure and of software development is in self-programming/self-modifying systems driven by AI to meet a set of requirements. Not buzzword pitchdeck bingo, but systems that can figure out how to optimize, fix and add features to themselves. It's asking a whole lot to get there, but it's inevitable because the cost savings potential is…
For non standardized features, I doubt it will happen. I'm my experience, it all comes down to the details, and the details need to be expressed in a language without possible interpretation problems. Imo, most programming languages are already on that level, so there won't be any revolution here. Graphical programming might change how many people work. More standardized modules (blogging, authentication, e-commerce,…
It's possible that we could be replaced but it's hard to envision it would happen without a general AI.
Developments that are sophisticated, but fall short from truly replacing engineers, wouldn't have the predicted effect. Let's say a 20% improvement in the time it takes to produce software. Would anyone feel strongly, at this point, that this that would result in 20% of engineers being out of a job, or is it more likely we'd just produce 20% more software?