On 4 August 2010 13:25, Alexander Johannesen <[email protected] > wrote:
> > > Yeeeehaw! > > > Steve Jones <[email protected] <jones.steveg%40gmail.com>> wrote: > > No I just want something beyond Google/Amazon/Yahoo. Just > > one or two traditional companies leveraging REST. > > National Library of Australia. Or a few others I can think of, but > you're going to say that these aren't traditional enough and / or real > companies and / or serious businesses or somesuch, aren't you? :) > Nope that would be a good one... reference would help. > > > >> I feel you're asking about that new fangled invention, the "car" or > >> whatever they call it, by looking in the barn for them. :) > > > > Nope, I'm being told that the flying car is really popular... but its > just all those regular cars on the road that I can see. > > No, no, no, you can't just go and change my allegory like that. > Uncouth. Actually, who told you REST is a flying car? You're > misinformed. > Well apparently it makes everything easier, is completely dynamic and so much better than everything else... but you just don't see it around very often... > > > > The reality is that the real challenge in computing is the one the > > enterprise faces, namely the people side of the problem is the real > > issue not the technology side. > > What a crack of nonsense. "The real challenge", eh? And only the > enterprise face this problem? I feel you're playing up something > terribly vague as something clear cut. > Nope. Its basic Mythical Man Month stuff. There are no technology silver bullets and the real effort remains in the thinking and communication parts of the problem. > > > > REST hasn't proven an ability to help there while WS-* (for all its many > faults) has. > > Hmm. What do you use as evidence that REST hasn't helped the "people > side of the problem" as opposed to WS-*? What does that even mean? > Big projects use WSDLs as a contract between different areas. These contracts are testable and able to be done upfront, this enables teams to work independently and thus increase their efficiencies. > > > >> I know that > >> until I really dug deep in REST I didn't see much advantage from SOAP > >> stuff, but after doing a few runs of massively distributed systems > >> something clicked. And perhaps there is a massive amounts of clicks > >> that needs to happen, lots of little epiphanies that is required for a > >> better adaption. > > > > But here in lies the problem. Most solutions don't require massively > distributed > > solutions to work well > > Are you sure about that? Because as soon as the pipeline is clogged > with too many connections, load-balancing, proxies and splitters are > exactly what implies a distribution of the problem. We're not going > into the future thinking the data dn the connections are going to be > lower, are we? Seriously, even in the mires of dogmatic enterprise > there is a huge push for better handling loads and volume, and the > answer to that isn't faster CPU's, but distribution. > Yup I'm sure about that because 99% of people in IT can't handle distributed systems problems. > > > > in fact massively distributed and "working well" in support are pretty > > much at opposite ends of the spectrum in most enterprises. > > Umm, this must be a unique viewpoint by the enterprises you serve. In > all other that I've been to, "working well" means just that it works > well, and if that includes distributed solutions, then that's what > they do. Why on earth would these two be at opposite ends? Didn't > Google teach you anything? > Yup they did, part of it is the quality of people they have in support which is stratospherically above every enterprise I've ever seen. The challenge in a lot of enterprises is "smart" solutions that hit support and become problem children. > > > > I've done massively distributed systems, and the quality of people > > you need in support is a legion ahead of where most organisations > > have support. > > Bah. Software and hardware are getting far easier with this all the > time. I recently had a distributed system put together by a flock of > abstract penguins. It's not that hard anymore, just a technical > procurement of skills. The real challenge is - as always! - in design, > which certainly doesn't only apply to distributed systems. > The challenges are indeed in design, and support. The biggest challenge in my job is always reducing complex problems down into simple chunks. > > > > This is the problem on technically focused "better mousetraps" they > > are missing the point that that technology isn't actually the problem its > > people, and in particular support, that are the real challenge. > > But if technology doesn't mean a thing, why are you looking for the > whole REST vs. WS-* dichotomy? I think I'm missing something here. > I'm saying that REST v WS-* has been a pointless debacle in the continuing drive of IT "professionals" to drive new technologies that fail to solve old problems. > > > >> The ESB is > >> *perfect* for the blame game, and satisfies a many managers at the > >> same time! :) > > > > Certainly there is a blame point, but the issue with REST isn't that it > > doesn't have a blame point its that it doesn't help CREATE the blame > > points. > > Ok, you're scaring me now. Why the hell would you *want* blame points? > Seriously? Why would I want to be clear where the actual problems were and have clearly defined borders against which people can be explicitly measured and tested? > Tech that reduces them should be the aim here, unless you want to > embrace middle-ware hell and middle-management bliss. > So favour a lack of clarity and continual finger pointing? > And also, what > on earth does it mean that REST don't help create blame points? > REST has a lack of standardised contractual approaches. > There > is no difference between our two contender in the amount of shit they > can create given the right idiot behind the wheel. > Actually REST can create bigger shit thanks to its dynamic contracts. > I was pointing out > the ESB trap, not the REST vs. WS-* battle; ESB is traditionally > steeped in WS-*, but that's just a side-effect. Like you said earlier, > the "real issue" is with how people are using these things, no? ESB > comes with contractual nonsense in terms of where blame should be put; > it shifts blame around rather than solving the problem. IMHO, of > course. > Whereas IMO and experience having that formalism (which is admittedly rare in ESB programmes) is actually the thing that makes the programmes successful and helps to deliver the value. Having a lack of control and enabling fluid change always results in finger pointing hell. > > > > The good thing about WS-* is that you create a contract and > > every bugger has to use it, people who don't are wrong. With > > dynamic interfaces you don't have that rigour and in an > > average enterprise this is death and complexity. > > What evidence do you present for ; > a) dynamic interfaces don't have contractual rigour > Errr the bit where they are dynamic and can change without informing the consumer via a standardised approach... How do I formally publish a REST interface to a consumer BEFORE the service is delivered and manage the change in semantic behaviour of the REST solution between multiple consumers and providers? > b) enterprises who dare dynamic interfaces end in death and complexity > I could, if NDAs didn't prevent me, name about eight companies off the top of my head where back in the old C days a really clever approach to code using dynamic interfaces (pointers to functions et al) really screwed up the code as it hit support. I myself made the mistake of creating a dynamic interface solution in CORBA in the mid-90s which required lots of funky coding and re-direction and created a really slick mechanism for deploying change without having to update the IDLs... I know for a fact that although it worked perfectly while I was there and reduced the development cycles it was dead 3 months after I left as it dropped into support and was (in the words of one individual) "too weird" for them to support > > > >> like the cost of maintaining several but similar layers of technology. > >> ESB vendors will slowly move to REST, and customers will slowly > >> follow, even if it takes another 10 years or so. > > > > Which means by my reckoning that REST will have put enterprise IT > > back by 15 years because it doesn't address the real problems that > > exist in enterprise IT, instead it seeks to solve a problem that isn't > there. > > Again, this is utter nonsense. What on earth is a "real" problem? > PEOPLE and more specifically how teams communicate and increase the separation between their areas and enable systems to be developed as independent entities which collaborate rather than as big blobs which are melded. This is the real problem with IT, particularly at scale, and has been for 30+ years. Approaches such as Design by Contract (late 80s, early 90s) demonstrated some progress in this and from experience the rigour of doing interface first delivery certainly helps on large scale programmes. > You > are probably thinking of something specific that fits your paradigm, > but I doubt very much that there is only one way to solve whatever > problem you're thinking of. Come on, there are no "real" problems as > opposed to other problems that aren't worthy of your attention, you > just have some specific solutions in mind to problems the rest of us > haven't been told of yet. > Maybe it is something specific to my way of viewing the world, and I look forwards to someone making my life easier by showing a better way of working in complex programmes. A new technology is highly unlikely to be that thing however if it continues to concentrate on the IT plumbing. > > "REST will put the enterprise back 15 years?" You aren't serious about > such a statement, are you? Seriously? Because, well, you know, it's > stupid. :) > Okay not back, just no progress. REST is good for website design but that is (IMO) not much of a challenge anyway, REST has not shown how it improves the situation beyond the website. > > > > The real problem of enterprise IT is how to get disparate > > teams working together and defining the clear boundaries between > > them that ensure they can work independently and test > > independently and control their area. > > So? (I mean, apart from this hardly being *the* real problem we all > have) Where in REST vs. WS-* (we should come up with a name for this) > does this even bring points to the SOAP side? Are you back to > contracts? I think several people in the past have pointed out that a) > REST lowers the need for contracts (depending on the job), and b) you > can still have them if you want (but you make them yourself). > Nope, people have said it but I've never actually seen how that works in practice. writing your own contractual approach is just a step backwards and does not aid in the collaboration between people and organisations. > All this > point is boiling down to is that no big standard of contractual REST > hasn't been made yet (but, there might be a reason for that, like the > actual need for it being low), and that I grant you, but that's not a > problem with REST, it's a problem with those who need and make big > standards to support themselves. > I Ahhhh I see. Or rather I 100% disagree. The reason that REST is avoiding things like contracts (IMO) and security architectures and definitions around more complex pieces which are required in enterprise computing is that they are actually hard things. Its much easier to say "oh its the web" and ignore the problems and come up with a personal half-baked solution that works for your project but no-where else. > > > >> Hmm, I can think of a handful of technologies that are technically > >> better than what ultimately became the success story. Success has > >> often *very* little to do with technical merits or the problem at > >> hand. Often it is pure luck and someone just friggin' did it first > >> that way, and it stuck. > > > > I can think of loads of better people solutions that failed due to > technical > > bigotry (Eiffel and Ada v C for instance). > > What's a "people solution"? And what do you mean by bigotry here? > "C is more efficient because it uses less characters" was a refrain I regularly was told about why C was "better" than Ada. This amazingly fails to recognise where the real challenges lie in IT. > > > > IT continues to miss the point (IMO) on where the real challenges are. > > Aren't you broadly assuming millions of people are all wrong, only you > are right? > Nope, I'm actually assuming that folks like Fred Brooks, Yourdon, De Marco et al remain pretty much as right now as they were when they wrote their top books in the 70s and 80s. > > > This is why companies like SAP make a fortune and people who code > > custom solutions don't get why. > > Huh? SAP is making a fortune because you *can* customize it (I've > never heard of anyone using it out of the box without modification), > Really? I have. Most of the time people customise SAP its because they can't change the way they think and shouldn't have bought a package in the first place. > so I don't understand your hint that SAP somehow hits the sweet-spot > (in fact I've customized SAP enough to know just how much it *isn't*). > Some companies make a fortune with custom solutions, some are open, > some have good ideas and poor tech, some have good tech but poor > ideas, some have cool names, some have excellent sales people, some > have bad technicians, some have open API's, others have the E-R > patented (or want to), some have locked down everything, and lots of > them are somewhere in the middle. And lots and lots and lots of people > in both camps understand perfectly well why SAP makes a mint and they > don't. > > > In other words, what you're saying here is just fluff. Lots of > companies are making lots of money by making shit, and others are > making lots of money by making gold. And we're *all* in IT. > We are indeed and there is lots of money floating around. Its just a shame that the quality of IT doesn't appear to have progressed much in the last 30 years. By continuing to focus on new plumbing approaches we create a slightly better wheel. This could be "fluff" but I doubt it. Steve > > Regards, > > > Alex > -- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > --- http://shelter.nu/blog/ ---------------------------------------------- > ------------------ http://www.google.com/profiles/alexander.johannesen --- > > >
