This is not an example of "WHEN Not to do Microservices". It is a perfect demonstration of "HOW not to do Microservices".
The design of the Istio control plane is a dog's breakfast. And because they've screwed up royally with it, they're now loudly proclaiming that it's the fault of microservices and a sudden lurch to a monolith is now the way to go.
This is the kind of thing you can do with a version 0.x. You could get away with doing it with an "Istio 2", but a massive breaking change to an architecture is not OK to do on a version 1.5.
The Istio website gave no warning of this, there's no obvious roadmap published. I'm beginning to think the Istio team are a bunch of amateurs who like fiddling with new toys but don't really care that their software is being used in production environments.
Is Istio safe to use on production systems? As of this announcement, no.
One awesome thing about math is it is self organizing. Many topics are composed of many smaller topics. As an anecdote, we used to say people “actually learned” (high school) algebra in calculus 1 and trigonometry in calc 2/3. In those cases it was more that to solve those problems required using algebra and trig coherently.
So to learn those 1000 pages is to, to some extent, learn a core set of techniques across many different contexts. It compresses the required mental load. For the exceptions to that rule, well, you can skim over them and know enough about them to recognize their applications later.
Sure it does. If you really wanted to read and understand this book and dedicated time each day to understanding 3 pages worth of content, you could read the book in a year. Remembering 3 pages of content per day (especially in math where concepts build on each other) is really not hard.
> Remembering 3 pages of content per day (especially in math where concepts build on each other) is really not hard.
I disagree. Or rather, I think that's unsustainable. Any given three consecutive pages from Spivak's Calculus are probably doable on a daily basis. But is would be legitimately hard for most people to go through three pages of Rudin's Principles of Mathematical Analysis each day and consistently retain that information. Axler's Linear Algebra Done Right is very readable, but Halmos' Finite-Dimensional Vector Spaces will start getting just as dense as Rudin. These are difficult textbooks even when students are well-prepared for them with prerequisite courses. Terence Tao wrote two books to cover (with better exposition) what Rudin did in one. I think it would be pretty hard to read consistently three pages of Tao's Analysis I each day, before he even gets to limits.
I think you're underestimating the intellectual effort here. In my opinion, even if you're reading a math book targeted to your level, committing to reading and understanding three days of material each day would become exhausting. A typical semester is 15-16 weeks, with lectures 1 - 3 times a week, and most undergraduate courses do not actually work through the entirety of a 300 page textbook. Even at that slower pace it's not typical for most people to ace the course. If you read three pages a day and had a solid understanding of it, you'd be absolutely breezing through math courses.
In my experience students need to really step away from the material and let it percolate for a bit every so often in order to solidify their understanding. I really don't think you can partition the material into equal, bite-sized amounts each day. The learning progression doesn't tend to be that consistent or predictable.
If you assume that "run 200 miles" doesn't refer to a single run but rather to the capability of running 200 miles, the analogy works much better. If you stop training the ability to run 200 miles vanishes even more quickly than an equivalent feat of learning.
Be careful what you wish for. I have one. Go for dinner with them, they would charge you for the time spent eating the delicious dinner, and afterwards they would write you a letter stating the dinner was delicious. Together with a bill for the letter. Plus a surcharge for providing the "laugh at events of the day" service.
You're not a mug, you've an honest person treated badly by an incompetent company.
You would be a mug if you dealt with them again ;-)
Don't be surprised if you haven't heard the end of it. They might well lose the item and then attack you again. If that happens, do not waste any more time or money on them.
Have you kept a record of the courier delivery? Like a collection receipt?
If not, write them a letter, send by recorded delivery, and state that the item was collected and that this is the end of the matter.
They're almost certainly incompetent rather than malicious, so if there's another screw up you can refer them to the letter and then ignore any further correspondence.
£60 is a hell of a lot of money to buy nothing. He doesn't need to do any of that, just arrange to return the item and if Nintendo (or The Hut Group, which is sounds like) screw up the collection, it's their problem. Just keep records of all correspondence.
Don't be daft. Leave it up. As long as the article is truthful, what's the problem? Their appalling treatment of an honest customer should be exposed.
I do think you're totally overthinking this. They made the initial mistake, they need to correct it and at their expense.
They can't do anything to you. Make a "best effort" to return the item and no more. Keep a log of all your correspondence. Don't waste any more than a minimal amount of time on this, certainly don't take days off work etc to wait for couriers.
I already have taken the day off work, and the courier has now collected the Switch - so the hope at least is that I'm now done with it, albeit out-of-pocket.
Exactly this. If you're working on a system with any need of serialization (eg to/from JSon), or presentation on some kind of view tier, or storage in a database, then the frameworks make get/set pairs inevitable, even if you fight tooth and nail not to have them.
(Of course you could avoid the frameworks, but try telling your project managers that).
Behavior based object design, as well as being an endangered species, probably never existed very much in the first place.
I wonder if Java's popularity was partly due to people being able to appear to do OO whilst actually implementing "code acting on data" systems. You got the warm OO glow without the hard work of doing any behavior driven design.
This is correct. JavaBeans were a bad solution to a problem. It was Swing (or was it AWT then?) that needed it first, so that tool builders could allow widgets to have their properties customised. So the vile JavaBean conventions took hold.
I only quibble on the "mindlessly" part. I will never add a get/set in a class if it isn't needed. But invariably, in a Java project, some library somewhere insists that I have them. So eventually I find I've reluctantly added them.
Sometimes you can get away with leaving them private, sometimes not. It's a pain in the neck and like many things in Java, it should have been sorted out years ago.
The design of the Istio control plane is a dog's breakfast. And because they've screwed up royally with it, they're now loudly proclaiming that it's the fault of microservices and a sudden lurch to a monolith is now the way to go.
This is the kind of thing you can do with a version 0.x. You could get away with doing it with an "Istio 2", but a massive breaking change to an architecture is not OK to do on a version 1.5.
The Istio website gave no warning of this, there's no obvious roadmap published. I'm beginning to think the Istio team are a bunch of amateurs who like fiddling with new toys but don't really care that their software is being used in production environments.
Is Istio safe to use on production systems? As of this announcement, no.