If you see an airplane that flies you might conclude airplanes are a good transportation pattern. But if you see there's a boat, that promises to fly, and you see that people taped a lot of helicopters onto it to make it fly, then probably you would conclude that boats are bad at flying.
Message Brokers are the airplanes. Even if you can't understand how they work you will see that many companies use them who really rely on distributed systems working, eg telephone companies, banks, trading companies.
Service Meshes try to solve a problem that K8s was meant to solve in the first place. So K8s is the boat and Service Mesh is the attached helicopter. By itself it might be a good idea to use it, but the way things are taped together right now it's just an anti-pattern.
If you don't have a pointy-haired boss forcing you to use it, then it's probably better to avoid the whole thing.
I'd rather see how far the development around k8s-less pods with podman will go and take care of the distributed architecture of my systems myself.
These layers of abstraction are nice but they seem to ignore the fact you still have to manage the systems underneath and the networking around it.
At some point folks need to realize they arent google and they really dont need to abstract the development layer because they dont have a team of google SRE to manage what their pods / containers / mesh runs on
This is a strange answer. A message broker is not in the same category as Istio. Istio is for effecting policy changes (regarding security, traffic routing, monitoring, etc) without updating your code. Which is especially useful if your code is a bunch of diverse microservices.
The reason to use a tool is to make a task simpler or take a task out of your hands in most cases but the rare edge case. For instance grep makes it easier to go to a file to find a certain line.
If you need to know networking, storage, microservice architecture yourself you don't need any tools.
In k8s you need to know all this, and on top you need to know k8s to achieve the same thing. And then you either need to write k8s plugins or also additionally know all the k8s plugins and wether any of them will actually solve the problem you have.
No, it's not hard. Like most topics in software engineering there are 50+ years of pretty successful development, backed by science, backed by software from the 70s, backed by all seniority levels of engineers.
The problem nowadays is that people don't want to learn the proven stuff. People want to learn the new hip framework. Learning Kubernetes and React.js is much more fun than learning how actual routing in TCP/IP works, right?
The problem is that something can only be hip for 1-5 years. But really stable complex systems like a distributed network can only be developed in a time frame of 5-10 years. Therefore most of the hip stuff is unfinished or already flawed in its basic architecture. And usually if you switch from one hip stuff to another, you get the same McDonalds software menues, just with differently flavored ketchup and marketing.
So if you feel something is hard it might be because you are not dealing with the actual problem. For instance you might think about doing Kafka, and that's fine. But be aware that email is shipping more messages than Kafka and its doing it longer than Kafka.
If you don't know your topology it might be star or mesh. But it's still a topology or a mix of multiple topologies.
And if you develop a distributed system you really need to think about how your network should be structured. Then if you know which topology fits your use case you can go and figure out the way this topology works and what the drawbacks are. Star networks (like k8s) for instance are easy to setup but have a clear bottle neck in the center. A Bus (like Kafka) is like a street. It works fine until it is full, and there are sadly some activity patterns were an overloaded Bus will cascade and the overload is visible even weeks later (although you have reduced the traffic already), if you don't reset it completely from time to time.
It's not magic. You can look all of it up on wikipedia if you know the keywords. Also there is not a single "good" solution. It depends always on how well the rest of your system integrates with the pros and cons of your topology choice. And if you use multiple topologies in parallel you have a complexity overhead at some point, which is why working in big corps is usually so slow.
> The problem nowadays is that people don't want to learn the proven stuff. People want to learn the new hip framework. Learning Kubernetes and React.js is much more fun than learning how actual routing in TCP/IP works, right?
That's an awfully short-sighted comparison.
There are far more job offers for deploying and managing systems with kubernetes and to develop front-ends with React than there are for developing TCP/IP infrastructure. It's fun to earn a living and enjoy the priviledges of having a high salary, and the odds you get that by studying solved problems that nowadays just work are not that high.
If my livelyhood depends on doing bullshit then of course I will also do bullshit. But that doesn't stop me from applying for other jobs or from creating random HN accounts and complain about it. ;-)
I also found it's not bad everywhere though. If you treat the smart people around you well here and there you will get some opportunity to actually change something.
So what I also try to do is getting people out of the mindset that they are actually doing something reasonable when they do this bullshit circus to pay the rent. It's possible when you are really frustrated to spend a few hours here and there to learn the actual stuff instead of the new hip stuff. And over time you will thereby be able to solve more and more problems with actual solutions.
An example from my own life: At one point I really learned about Ansible, Chef, Puppet etc. Then I learned about actual configurations, improved my knowledge of ssh, bash-scripting etc, and in the end I wrote bash scripts that replaced all the Ansible I had used. The results where more flexible, the error messages more readable (thanks to set -x you were able to see what actually went wrong), it was a lot less than 1000 lines of code, and it was a lot of fun to do some actual problem solving for a change.
I'm not sure what can be done nowadays. In the past you would say, format disks and go back to a backup before the threatening event happened. But nowadays all our stuff is in the cloud and you can only go back to the state from 10 minutes ago, and all our disks are flash drives that you can't fully format as an end user. Maybe you can just accept that some virusses will always be there and act accordingly.
Would be nice to have a tool that everyone on the planet could use to run against those backups and find a common source of the infections, along with an idea of when it was found in the wild.
What about Wechat? There are lots of seemingly pretty girls trying to voice or video call these days. Either I'm suddenly rich in their eyes or there's something fishy going on.
Name a chat app and I can provide a link or comment from someone saying the same thing about pretty scam girls. Facebook, Whatspp, Gmail, Kik, Snapchat, Instagram, and even BBSes, AOL, IRC etc...
What I saw on FB is automatic replies from bots. What I know from Skype are african boys who try to earn their next beer in an internet cafe by acting they would be a girl. I can confirm it's all not that.
In fact it is actually mutliple things, depending on the situation. I think the people Ian is talking about really exist. But I don't think it applies to health care. In health care it's actually a cost saving effort by politicians not unskilled providers trying to hide their lack of knowledge, i.e. reason (5) not reason (1). Therefore educating them or the public is also not an helpful action. More reasonable would be to try to figure out the cause of lack of funds and how to counter it, or if there is no way back to help people along the way, e.g. by writing an article about how to find and read research papers oneself as a previous user of a social health care system.
If you don't believe it or don't understand what I mean, read on:
1) In software dev "Product Owners" who have no idea of their job (or simply see that nothing happens and therefore have better things to do in their life than focus all their energy on their job) say that to have some kind of goal to work towards. True. That's probably also where Ian got this idea from. In this situation it's not unreasonable to do that because if he can't even act like he would have a goal he could not stay in that leadership position.
2) Users also really want control when they can't trust the actual service provider. And that doesn't just mean incompetent providers. It also means providers with goals that compete with the users. E.g. many countries now try to figure out how they can do nextgen_after_4g without Huawei, because they fear the political goals that might stand behind Huawei. In this situation it's also not unreasonable to want control.
3) A third reason is people who know the user's situation better than the user (e.g. IT security experts) and who want to help the users. In that case they will basically do the reason (2) fight for the users without much help from the users. It's a naive but admirable position to take. Not unreasonable.
4) Some people act like they would do reason (3) but actually just try to play games with the users on the user's cost. Anti-Vaxxers are such a group of people. Or the nationalist political grups we saw rise up a few years ago. They take an existing fear of uneducated users, escalate that to unreasonable sizes and then act like they would offer some help in exchange for money or votes.
5) Politicians and highest level corp leaders will say "users want control" when they have an area where they were providing a service in the past that the user come to expect, but for political or market reasons they can't provide that for much longer. So they act like someone else would want it. If they stand there in front of the camera in their $5000 suit, $200 hair cut, and their $3000 wrist watch nobody would believe them if they would simply say "all right guys, there is no more money for that service, let's pull our belts tighter". The only practical alternative I've seen is what the new Pope is doing. But that really needs a fanatic who can live an asketic life style which simply is not for most people. If most people can choose between a $5000 suit and a $2 self-knitted, itching rope then most people would choose option 1. So either you need to put one of a very small number of people in a leadership position and defend them there (which will cost you a lot as well), or you need to accept that "users want control" is the strategy the existing leadership is driving.
Imo the best approach is to think about how to deal with reality instead of hoping or fighting for a reality that can't exist. But I can even see the reasons for why one rather dies dreaming than live in reality. ;-)
Why would someone even say something like this? There are multiple models of how pricing works. Models at their core are incorrect because they simplify a complex thing to something that can be used for predictions. They are good models when they help your predict correctly and they are bad models if they can't help you make predictions. But all are "wrong" on purpose.
Therefore there must be different models because people want to predict different things. And of course neither of them is how things really work.
"this is not how X works" doesn't need to be said, because yes that's the idea of using models. Otherwise you wouldn't use models.
"this is not how it works in principle" assumes that there is no model that would claim previously said statement. And since you can create unlimited amounts of models of course you can very often construct a model where the statement works.
I suggest instead of claiming such a thing it might be more interesting to think about how such a model would help more or less to predict things.
PS: I believe The Intelligent Investor or how that book was called and a social model called Communism are both promoting models that connect use-value to price-value. So it's not even far fetched. It's a very common thesis for discussing pricing of investments.
Message Brokers are the airplanes. Even if you can't understand how they work you will see that many companies use them who really rely on distributed systems working, eg telephone companies, banks, trading companies.
Service Meshes try to solve a problem that K8s was meant to solve in the first place. So K8s is the boat and Service Mesh is the attached helicopter. By itself it might be a good idea to use it, but the way things are taped together right now it's just an anti-pattern.
If you don't have a pointy-haired boss forcing you to use it, then it's probably better to avoid the whole thing.
I'd rather see how far the development around k8s-less pods with podman will go and take care of the distributed architecture of my systems myself.