|
Architectural Principles In Basic Stages
1) When I began learning OOP principles way back in 1993 there was a focus on :
reuse via inheritance
2) As OOP principles gained traction many companies, developers and researchers discovered the problems with this and a new idea arose :
prefer composition over inheritance
3) Next people began to discover that constructing small services which provide one distinct solution were a good idea. SOA was the buzz-phrase we heard. Of course, there was much truth in there.
4) Now, we are hearing a lot about Microservices. It's another progresssion.
Ideas and Buzz-Phrases
Of course all of these ideas get buzzed by people who don't really even know what they're talking about and then people at the fringes just think, Quote: "Oh, it's another Architect-induced cycle of info-BS."
However, each of these things has contained a core of knowledge that has tried to help us all take another step toward better practices -- to turn software dev from magic/art to science/engineering.
Sometimes: Layers of BS
But a lot of the good stuff does get covered up in layers of BS by uninformed devs.
Must Read: So Many Great Ideas
The reason I'm writing about this is because I've just completed the intro and chapter 1 of a absolutely fantastic book on Microservices where the extremely talented author has summarized all of this and then succinctly and clearly exposes the truth about them as a next logical step in this progression. You must read this.
The Tao of Microservices by Richard Rodger - Manning publishers[^]
So Difficult To Get New Ideas
It is often so difficult to get new ideas. It is so rare to find someone who illuminates things so clearly. This author does a great job of providing the architectural overview but also explaining in detail exactly how microservices can solve certain problems.
It's always cool to find new resources like this, especially when they illuminate buzz-phrases that we all hear about.
|
|
|
|
|
Seems interesting, thanks for sharing it here, adding it to my read list 
|
|
|
|
|
It really is a great read. I am always happy to find new authors who :
1. open up new ideas / concepts in new ways so I think new thoughts
2. get to the point quickly
3. describe how the technology really works, succinctly
4. give me an idea where architectural principles fit together into the bigger puzzle
|
|
|
|
|
I agree with you on that, the book should be to the point, no long stories should be there, i would love to have the list of books from you which you think should be read as a Computer Science professional and Software Developer.
|
|
|
|
|
Thanks that's a very nice compliment that you are interested in what I've read.
I will try to get a list going and share it.
Some of the books I've enjoyed are so old like Programming Windows 3.1 by Charles Petzold. That book was just so well written and was like having a mentor sit with you and teach you programming. Of course, now it is not relevant at all.
Petzold did write another book which I talk about a lot because it is so expansive about computing it is a great one for computer science understanding: Code: The Hidden Language of Computer Hardware and Software (Developer Best Practices) [^]
Oh, of course the Bob Martin book on SOLID is also quite good:
Agile Principles, Patterns, and Practices in C#[^]
|
|
|
|
|
My pleasure, that would be great to have that list, i will be waiting for that
|
|
|
|
|
raddevus wrote: to turn software dev from magic/art to science/engineering.
It'll never happen. Software development is accessible to the masses, even children. Science and engineering requires a level of formality that programmers try to avoid at all cost, and therefore ignores the cost, and then we companies / OS projects that fling tools/frameworks at us that market their tools as making programming easy, as in, Pink Floyd cue here, "we don't need no education" (reference to Brisingr's post below.)
Would you hire a college dropout (being one myself) to build a bridge? No. But we hire junior developers with no experience in the tools, languages, or formal programming practices to code things that require performance, usability, stability, security, and maintainability, with little or no mentoring or oversight.
Latest Article - Code Review - What You Can Learn From a Single Line of Code
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
modified 21-Jan-18 17:40pm.
|
|
|
|
|
Marc Clifton wrote: It'll never happen.
A little bit of a negative view, but I do agree that it won't really happen as an entire movement.
It does, however, happen in individuals and those individuals write the best software.
That's also why the book is so interesting because the writer addresses this exact idea and the idea of moving it more toward science/engineering and away from art/magic.
Here's the author explaining that exact point. I think you'll find it interesting.
The Tao of Microservices Software development is an art. It isn’t predictable enough to be engineering. It isn’t rigorous enough to be science. We’re artists—and that’s not a good thing. We find it hard to work in teams, we find it hard to deliver on deadlines, and we find it hard to focus on practical results. Anyone can claim to be a software developer; opening a text editor is no more difficult than picking up a paint brush. A small number of painters are 10 times better than others. A small number of coders also are 10 times better than others. But most of us are working on bad instincts.
Unlike art, software has to work. It has business problems to solve, users to serve, and content to deliver. We have a thousand opinions among ourselves about how to do things correctly, yet many software projects are delivered late and over budget. Much software, especially that produced by large companies, offers users a terrible experience. We have a self-important belief in our work, as artists, that isn’t connected to the reality of our systematic failure. We need to admit we have a problem, understand the nature of that problem, and use science and engineering to solve the problem.
|
|
|
|
|
raddevus wrote: It does, however, happen in individuals and those individuals write the best software.
Quite true. I guess that gives me some hope. 
BTW, I'll be checking out the book - thanks for the recommendation!
Latest Article - Code Review - What You Can Learn From a Single Line of Code
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
This is the drumbeat that Robert Martin has been beating for ages. I thought his takeaway on the VW emissions scandal was extremely insightful, and did highlight his premise that Software Engineering is not a proper profession and really needs to be.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
raddevus wrote: Now, we are hearing a lot about Microservices.
I have been using micro-services since 2012. I think I started hearing about the idea since 2010.
OOP is good for certain scenarios. Not all development warrants OOP, and that is alright. Don't feel bad if you are not using OOP for everything - it is not suited for "everything", and does not make you a bad software engineer if you do not use it for everything.
Micro-services and WebAPIs are where it is at now - IMHO.
Keep these OOD principles in mind when developing, and use it as a guideline only:
1. SOLID (object-oriented design) - Wikipedia[^]
|
|
|
|
|
I don't see an incompatibility between OOP and Microservices. I code my Microservice interfaces as a collection of repositories, and they play perfectly nicely in an event-driven OOP system.
I do exactly the same thing on the other side: I write a microservice as I would a DAL repository, generally with a Model-Projection flavor, which is pretty fundamental OOP.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: I don't see an incompatibility between OOP and Microservices.
Exactly. And really everything you said is exactly what the author of The Tao of Microservices is saying.
That's why I found it interesting. OOP has led to microservices which is maybe just a pattern built on OOP principles. I think the progression of software design in this is very interesting.
|
|
|
|
|
Well, to be fair, a well-formed microservice is just a data source, and should be able to play nicely with any sort of design paradigm (though Functional would be the other logical approach).
I prefer to think of it as de-duplication of effort through an abstraction layer. The lovely thing about abstraction layers is that you can take an asymmetrical approach on either side of one.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I would be interested in how cobbling together microservices as components within an application accounts for:
1 - the additional time required for external calls to a microsoervice versus calls to in-process components/libraries.
2 - interruption in network communication (network goes down, some IT guy changes firewall and router ports, loss of Internet access, etc.) when trying to connect to microservices versus no network connections when using in-process components/libraries.
It seems to me that performance and reliability are issues that can be negatively affected by microservices that do not come into play when using traditional local libraries that get linked in.
I would think someone saw this early on and those concerns are already addressed.
Thanks
|
|
|
|
|
Those are great questions and are actually addressed in book.
One of the things the challenges/problems that implementing microservices creates is the proliferation of numerous running processes in production and the challenge managing it.
That can be seen as a problem.
However, the author explains that what it does is forces the issue of creating a system / process for managing production processes since a person (or persons) cannot actually manage the great many processes manually.
This is all about trade-offs. The network / latency issues are solved quite well with systems used in microservices such as akka.net.
|
|
|
|
|
10,000 hours ...
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
As to the original question, my suspicion has long been; mostly students desperately searching for subjects for their masters' thesis and/or PhD dissertation. All too often, they then get so focused on it, it becomes the universal tool in their mind.
What's interesting is looking at a piece of software that was developed over a long period of time and you can often identify when parts were written by what fads the software followed (or the devs had to follow because of third party software.)
|
|
|
|
|
Joe Woodbury wrote: looking at a piece of software that was developed over a long period of time and you can often identify when parts were written by what fads the software followed (or the devs had to follow because of third party software.)
Very good point.
I'm almost completed the 2nd chapter of The Tao of Microservices and the author is saying the same thing.
This book is absolutely amazing because the author is actually attacking a lot of recent absolutes like Agile, (mindless) Unit Testing, strong-typing (which sounds weird but makes sense when you consider that if you change a type that two services depend upon then you cause a real problem).
The book is so cool, because the author is talking about all these problems that have attempted to be solved by methodologies and trends but which haven't really been solved.
His main point is "move toward simplicity". That move toward simplicity will cause you to have to manage somethings using specialized tools but that is good because that is what the specialized tools are for and the move to simplicity will make people not mind actually looking at your code.
I can't wait for others to read this book and discuss it.
|
|
|
|
|
Warning to MVC web devs using bootstrap v3:
Starting sometime this weekend (it didn't happen on Thursday), it looks like bootstrap 4 will be installed if you run update-package in the NuGet console. If you're knee-deep in a site that uses v3, and you don't want to deal with the accompanying refactoring that will be required, add the following attribute to your bootstrap line in packages.config:
allowedVersions="[3,4)"
The bootstrap4 installer froze when it was trying to install something called popper, and an admittedly halfhearted google search resulted in no resolution. Fortunately, the site I was working on is fairly small (but deeply vested in bootstrap v3), so just restarting from scratch wasn't a too-terrible solution.
I felt this was significant enough to post this in the lounge because it will have a severe impact on your code.
I now return you to your regularly scheduled anarchy.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Ugh. One of the several reasons I don't use NuGet and a) compile the source myself or b) just grab the files for the version that I'll be using.
(Step b sometimes requires setting up a dummy project with NuGet and then copying the DLL's over to my real project.)
Latest Article - Code Review - What You Can Learn From a Single Line of Code
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
New Info:
I discovered that if you want to upgrade to Bootstrap4, you must first install popper separately. At that point, the upgrade to BS4 will proceed normally. The same warnings regarding major refactoring (because the MVC5 templates are BS3-specific) is still in effect. For instance, the NavBar does not show up when you start a new MVC5 app and update the packages.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I love how the new versions of really good frameworks are getting progressively worse by adding all this bloat.
I don't think that required sarcasm tags, should have been obvious from the source.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Well, it looks like BS4 might actually be better than BS3, but without an accompanying template MVC change, it's pointless to upgrade to BS4 in any MVC5 app because all of the templates generate BS3 code. Of course, you could create your own upgraded MVC5 templates, but what a pain.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I'll take a look at it, as I generally use a SPA with microservices rather than the MS-baked MVC framework, but the tendency of these things to just keep growing in terms of tool-chain and libraries is highly off-putting. This is exactly the reason I moved away from Angular; well that and the threat of a new version every 6 months.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
