Microsoft Launches Two New Open Source Projects for Developers -- OAM and Dapr (betanews.com) 34
Continuing its embracing of open source, Microsoft has today announced two new open source projects. From a report: The first is Open Application Model (OAM), a new standard for developing and operating applications on Kubernetes and other platforms. The second project is Dapr (Distributed Application Runtime), designed to make it easier to build microservice applications. Microsoft says that both OAM and Dapr "help developers remove barriers when building applications for cloud and edge." Microsoft has worked on OAM with Alibaba, and the aim is to simplify the development and deployment of applications. The company explains that: "OAM is a specification for describing applications so that the application description is separated from the details of how the application is deployed onto and managed by the infrastructure. This separation of concerns is helpful for multiple reasons." The second open source project is Dapr, which Microsoft describes as "an open source, portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge."
Lol. Like I'm gonna code for free FOR Microsoft. (Score:1, Troll)
Sorry, coding for the competition. Your history should have gotten you a death sentence. Die in a fire, ya cunts!
Re: (Score:2)
Die in a fire, ya cunts!
Or as I like to say, "Die of cancer in a fire." That makes it a tad more vicious.
Die by slit throat while getting fucked in the ass by a rusty pipe.
FTFY -- if your going for vicious
Re: (Score:2)
I used to work with a librarian who to made comments about want to stake certain students covered in honey to ant hills until they begged for death ... he was a nice guy actually.
Not this again (Score:1)
"The second project is Dapr (Distributed Application Runtime), designed to make it easier to build microservice applications"
Microservices? Not this shit again...
Not this again-under the influence. (Score:2)
Of course. Why should it go away because YOU don't like it?
Re: (Score:2)
Of course. Why should it go away because YOU don't like it?
Well, it should go away because I don't like it. Everything I don't like should go away. Is that such an unreasonable position?
Re: (Score:2)
it's not unreasonable, but it does kinda make you sound like a whiny cry-baby.
Re: (Score:2)
No, it makes him sound like he's seen this crap before.
----
"I could build this application so that this would be a function call or I could make this a remote call to a service."
Now which one is going to be faster and less likely to fail? Let's use the other one!
Re: (Score:2)
Considering said server could be in someone's homelab, as much as in a remote cloud, the latter is just as viable.
Re: (Score:3)
Christ, it's getting to the point that we'll have to swipe a credit card just to boot a computer.
Re: (Score:1)
Sometimes you have reboot the credit card also, they use chips now. It's e-turtles all the way down.
Re: (Score:1)
For some reason the theory sounds much better than the practice. I get most reuse from understanding the domain better, not by making everything a service or generic component by default. It can create a lot of wasted overhead and interface micromanagement busywork if the actual reuse rate turns out not to be frequent enough.
We all wan
Re: (Score:2)
I've been on more than a few projects that went the microservices route. Or tried to.
The unlucky ones, IMHO, were the ones that actually got their clown-cars full of microservices running. Those poor fuckers were left having to live with the application in one way or another for the next several years.
The lucky ones either failed right away or realized that the whole microservice masturbation dance didn't really solve problems, it just broke them up into lots and lots of smaller, tightly-coupled problems. (
Let others be the guinea pig [Re:Not this again] (Score:1)
If it's hard to know if one is doing it right, then it's often better to let other orgs learn and document the "algorithm" for when to use what so one is dealing with a clear road-tested recipe rather than an esoteric art.
Re: (Score:2)
if you really have components in your system that are tightly-coupled and you are using microservices then you're using the wrong tool for the job.
Tightly-coupled, loosely-coupled, attached with a leash made of woven gold, I don't care- the whole microservices thing was sold to devs as an elaborate practical joke as far as I can see.
Sometimes a tool isn't right for any job, and that describes the microservice paradigm. It was a great idea that turned out to be a crappy idea.
Magic Legos Redux [Re:Not this again] (Score:1)
XML "web services" were a big buzzword back in the early 2000's and made similar promises about modularity, reuse, and plug-and-play gluing of services to get instant apps in a Lego-like way.
But the reality turned out different and they became kind of a niche for specialized needs. Stored Procedures, FTP'd files, and simple web pages that returned CSV using query-by
Re: (Score:2)
It's very clear why you had a poor experience and that's because you were doing it wrong and then blaming the tool/paradigm for your failure.
No, I just watched from the sidelines and shook my head as things went predictably downhill. I wasn't actively involved or I would have pushed the devs away from microservices.
Microservices are pointless bullshit for 99% of the stuff they're used for.
Re: (Score:1)
Coupled-ness is often hard to define and measure. If you have a clear-cut algorithm-like recipe for measuring coupled-ness and the need for microservices, I'd looooove to see them. Bring on the precision, I'm tired of cult-like vagueness in IT fads.
Re: (Score:1)
I didn't say it was "always" bad. If I implied that, I apologize. The implication was that if you modularize your systems into microservices, you will almost automatically get more reuse. That is wrong: there is no automatic.
A similar implication was made about OOP back in the day: that if you make everything an object or class, then you will automatically get "reuse". That turned out to be mostly wrong, and many created spaghetti objects as a result of trying. OOP is mostly about cleaner packaging of stat
Re: (Score:1)
If your teams align with the "components", I could agree. But if you force teams to fit the technology and the new team structure goes against the grain of the organization, you could be in for a disaster. Seen it happen. Conway's Law again.
They are not magic modular reuse abstraction Legos by themselves: they have to fit in the organizational structure.
Re: (Score:2)
It's not the word 'microservices' I object to, it's the word 'runtime'.
This sounds like Java and .NET all over again, and we all know how open those are.
If I want MicroService (Score:3)
Tips for Forex Trading Beginners (Score:1)