In general I would agree, but since you mentioned "never" I have to interject ; )
In this visualization, I was immediately able to pick out clusters around "i", "Apple", "touch" and so on .. and the interactivity helps me to quickly filter and explore. So, I think that for an exploratory tasks, a force-directed graph helps.
The training we had to do with our sound team dropped significantly, as we could load useful presets, do some preparatory work at home before the service etc. It was a great example for what a real "digital transformation" looks like ;)
I have no idea which side of the bed HN woke up today, but the comments here disparaging Martin Fowler's body of work really trouble me.
I really enjoy Martin's (and more recently his collaborators') blog posts on various trends. More often than not, they distill key concerns and references into a quickly readable summary. His books on software patterns collect a breadth of problem/solution pairs that have now been baked into so many frameworks that you probably don't even realise you are benefiting from them.
If you are totally new to Martin Fowler's books and writing, I would urge you to not brush them aside because of some snide comments on HN. There's a wealth of material that can surely enrich your thinking.
To get to the next level and scale of bigger programs, you need to leverage the tons of work information visualization researchers have done.
I always point people to Prof. Tamara Munzner's work[1][2] that allows you to skip over all the dead ends that people have tried over the decades and gives you a "thinking framework" on how to design visualizations.
[2] really interesting. A shame the preview only covers the table of contents. There’s a search feature, but you are not allowed to see the search results :-/
I spent quite a while with SOA, but I find Kubernetes a little different.
To me, SOA is more about the implementation-- especially the old WSDL-driven part.
But Kubernetes is more about infrastructure. The applications are written in different styles and different languages. K8S is more like a platform than anything else, to me.
> The S was meant to be service as in windows service but it was co-opted to be service as in web service.
That assertion makes no sense as SOA is a software architecture approach and the communication between services has no impact on the system's architecture.
Communication between services has a huge impact on system architecture. A web service is an RPC mechanism, whether it's SOAP, REST, CORBA or whatever, it's nothing new and didn't need a new name. SOA was supposed to be message driven, usually through an ESB or something similar, MSMQ was popular at the time.
Yeah. The basic idea is fine. (Don't write huge monolithic software blobs!) But the term was effectively coopted to be about a lot of specific heavyweight proprietary software and the heavyweight specs associated with them.
I'm not disagreeing but the reason SOA is more complex is that it does a whole lot more than "REST" microservices. It encompasses standardized protocols for transactions, faults, asynchronous services, auth, and more, in addition to payload typing and state. Such QoS dimensions aren't either considered in naive "REST" services at all, or at least not in upfront design (because waterfall sucks right?). Hence they're implemented for each service in an ad-hoc fashion, if at all. Implementing ad-hoc security in Docker containers (a technology proud of cutting ties with established ways of keeping eg OpenSSL lib up-to-date) in the "REST architectural style" (appealing to junior devs) and without transactions sure sounds like calling for trouble and acrueing technical debt like there's no tomorrow.
And also not disagreeing. While not an expert (thankfully!), it was very prescriptive and theoretically suited to the development styles of the time. As you suggest, microservices is more ad hoc and puts a greater burden on good architectural and operations practices which are more informally enforced.
But, net net, I put SOA in the same general bucket as ITIL and other associated practices of the time. They meant well but for most purposes they involved too much process and were ultimately too tied to big vendors trying to sell stuff.
> I'm not disagreeing but the reason SOA is more complex is that it does a whole lot more than "REST" microservices. It encompasses standardized protocols for transactions, faults, asynchronous services, auth, and more, in addition to payload typing and state.
"REST" microservices also do that, but they aren't bound to quasi-proprietary protocols and tooling.
How does "REST" handle coordinated transaction rollback/compensation over multiple heterogenous service calls? How is SOAP, XML, WS-*, AMQP proprietary?
> How does "REST" handle coordinated transaction rollback/compensation over multiple heterogenous service calls?
By "REST" I assume you're referring to non-SOA distributed systems which might happen to use REST or RPC-over-HTTP interfaces, and not the architecture style.
Assuming that, "REST" handles all those features by integrating services that support coordinated transaction rollback/compensation over multiple heterogenous service calls.
> How is SOAP, XML, WS-*, AMQP proprietary?
If you read what I said you'll notice that I explicitly said "quasi-proprietary protocols and tooling".
It's time for the pendulum to swing back I guess ;)
The article give iOS 7 the credit for ushering in the 'flat' design trends ... But I remember the Windows Phone 7-8 'Metro' (later renamed to Modern) design language as the key influence. It blew away people with the attention to typography and proportional grid-based layouts.
I think you're right. But, in a reversal of roles, Microsoft did the design well and Apple's copy was a poor, souless wannabe IMO. They sucked any semblance of "joy" (for lack of a better word) out of the Metro ideas and iOS.
I disagree. Microsoft just took typographic design principles that have been extant for decades and which were already commonplace in print and web design and applied them wholesale to UI design.
There are situations where this makes perfect sense, but it was hardly a sensible approach to UI design on the whole. Metro was widely criticized for making it more difficult for users to be productive, which I would argue is the primary concern of any desktop operating system. And indeed, Microsoft quickly moved beyond Metro in favor of Fluent, a design language that is much more in keeping with Apple’s current design language than it is with Metro.
Metro, despite being relatively popular with UI designers and developers, totally flopped with users, who did not find joy in using it at all. With Metro, Microsoft attempted to cut out UI chrome in favor of content. The idea being that removing chrome would make room for content. Instead, they ended up treating content as chrome, leaving substantially less room for actual content. Microsoft failed to meet their own design goals for Metro. And what’s worst, they seemingly failed to recognize that they had failed for quite some time.
Apple’s human interface design guidelines for iOS, while far from perfect, are a much truer realization of the design principles that Microsoft set out to implement with Metro. Rather than treating content as chrome, chrome is reduced to its most basic elements, retaining its ability to inform the user as to its function, while minimally detracting from content.
Design is not fashion, fashion is fashion. Otherwise, every market and product/service segment has its own "fashion", but that doesn't make them "is fashion". (Startups are fashion, engineering is fashion, education is fashion, technology is fashion etc.)
> "the web is still clinging on to monolithic backends — with their high costs, slower speeds, and huge surface area for attacks"
Hmm .. I've observed that microservice architectures often end up having large deployment footprint, higher usage of the network and a larger surface area for attacks since the "edge" is orchestrating more of functionality..
Does investing in Netlify really warrant such BS bingo? It's a really neat product in its own right.
No. UWP is windows phone 10 only. However on practice the core code had not changed massively. UWP also won't work on Windows 8 or 8.1. I have a moderately successful win 8 app which I'm updating to UWP. It's taking forever though. I keep rewriting and refactoring as i learn better ways to do things. I need a kick up the ass to get launched
It's a fantastic item for the browser toolbox, and i agree with Amea that the "hallmark of success" has been achieved by this technology