On Tue, 2015-10-06 at 15:07 -0400, Nick Sabalausky via Digitalmars-d wrote:
> 
[…]
> 
> Felt stupid for not being hip to this "microservices" thing you say,
> so
> just looked it up. But it sounds to me like it's basically just a
> buzz-driven rediscovery of the basic principles of proper
> encapsulation
> and Unix philosophy ("do one thing and do it well").

Yes there is an element of just using encapsulation and single purpose tool, but there is a lot of trying to do cluster computing well by keeping the components small and manageable. The downside is the potential communications complexity.

BTW microservices doesn't mean just Web services/applications per se (they are a subset), it is any protocol. The Web services/applications people conveniently forget there are protocols other than HTTP.

> (Kinda like how "cloud" sounds like a big fancy new revolution until
> you
> realize it's just the hip new word for "internet" or "hosted". Or
> "Facade design pattern" vs plain old "It's a thin wrapper".)

"Cloud" is really a destruction of personal computing in favour of re- centralization of all computing: put the computing power back in the hands of the people who want to control what you may or may not do with computers. Beyond this is gets political.

> Does that sound about accurate, or am I missing something?

I think you are missing some aspects of why there is sanity to what is happening, but you are not wrong that there is a lot of "buzz" and "hype", but that tends to go along with anything "trendy" and "hip". And there is a lot of reinventing the wheel because the hipsters create cool new stuff, but have failed to study the last 60 years of computing before doing so.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2015-10-07 at 07:15 +0000, extrawurst via Digitalmars-d wrote:
> […]
> 
> I have never used Go, but isn't what you describe exactly what vibe.d is doing using Fibers ?

As I understand it, vibe.d is a single threaded event-loop with fibres. In this sense it is equivalent in architecture to Node except that vibe.d allows for blocking fibres where Node required non-blocking approaches. Thus I would choose vibe.d over Node any day, except…

Go has a task pool (goroutines), but underneath is a thread pool not a single thread.  This means that multiple goroutines can be executing concurrently, that means in parallel (*). GPars has an approach similar to Go. Go is way more efficient though as it uses the kernel threads directly, GPars has to fight with the JVM threads.


(*) It is a pity that computing and the rest of the world have different meaning for concurrent and parallel, it leads to lots of wonderful confusion.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 2015-10-06 at 18:56 +0000, Dicebot via Digitalmars-d wrote:
> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
> > Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015.
> 
> What do you mean by microservice examples? It is infrastructure methodology, not specific code thing, any simple network service can be viewed as microservice.

At the Web services application level it is having a small framework for structuring the use of GET, POST, PUT, DELETE,… packets. Basically RESTful services.

At a non HTTP level I guess you can say all networking is microservices except that you want a protocol over TCP/IP or UDP/IP and shouldn't there be frameworks to assist building these things?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 7 October 2015 at 10:50:47 UTC, Russel Winder wrote:
>> What do you mean by microservice examples? It is infrastructure methodology, not specific code thing, any simple network service can be viewed as microservice.
>
> At the Web services application level it is having a small framework for structuring the use of GET, POST, PUT, DELETE,… packets. Basically RESTful services.

Even web microservices are not necessarily RESTful ones. Nick has correctly pointed out that there is a lot of spiritual similariy between concept of microservice and traditional UNIX way of designing small single-purpose command lines apps. It basically gets down to "do as few things as possible in one application (but do it good) and build a pipeline".

> At a non HTTP level I guess you can say all networking is microservices except that you want a protocol over TCP/IP or UDP/IP and shouldn't there be frameworks to assist building these things?

What utility would you expect from such framework?

On Tuesday, 6 October 2015 at 19:07:32 UTC, Nick Sabalausky wrote:
> Felt stupid for not being hip to this "microservices" thing you say, so just looked it up. But it sounds to me like it's basically just a buzz-driven rediscovery of the basic principles of proper encapsulation and Unix philosophy ("do one thing and do it well").
>
> (Kinda like how "cloud" sounds like a big fancy new revolution until you realize it's just the hip new word for "internet" or "hosted". Or "Facade design pattern" vs plain old "It's a thin wrapper".)
>
> Does that sound about accurate, or am I missing something?

Heh, funny you say that, since Russel's post just got me to look up the term too. :) I had encountered the term before, when I was talking to a dev shop about a project earlier this year, but figured it was exactly what it sounded like and didn't bother looking it up till now.  Looks like I was right.

Whatever hype may be involved, at least they're re-branding something _useful_, just be grateful for that. ;)

On Wednesday, 7 October 2015 at 10:39:07 UTC, Russel Winder wrote:
>> (Kinda like how "cloud" sounds like a big fancy new revolution until
>> you
>> realize it's just the hip new word for "internet" or "hosted". Or
>> "Facade design pattern" vs plain old "It's a thin wrapper".)
>
> "Cloud" is really a destruction of personal computing in favour of re- centralization of all computing: put the computing power back in the hands of the people who want to control what you may or may not do with computers. Beyond this is gets political.

I wouldn't go that far.  Users want to access their data from anywhere on their mobile devices, and given that those mobile devices can't store much, the cloud is just the most convenient place to put the data, now that 4G speeds are comparable to wired broadband from just a couple years ago (except for the much lower quotas on wireless, which only really limit you with video).

You could have made the same argument a couple decades ago, that PCs were a step back from workstations, because the old UNIX workstations came with compilers and a toolchain that let you build your own software whereas you had to go get the tools for your PC, ie they weren't bundled.  Some people make the same argument with the even more locked-down tablets today, where you can't even develop software using them.

But the truth is that most PC users weren't developing software or exerting much "control" over their desktops/laptops, and almost nobody wants to develop software or create on a mobile device.  They welcome more locked-down systems, because it lets them do the lighter tasks they actually want to get done much easier, without worrying about configuring the system just right, ie complexity, or viruses.

However, I do agree with you that the cloud is way overplayed, just for different reasons.  I think decentralized computing is going to take off instead, with a decentralized social network, like Diaspora except running peer-to-peer on your mobile devices, replacing centralized Facebook.  Cloud will merely be one of the nodes in that decentralized network, one where you offload heavy computing activity or data that you need from everywhere else, but not the center of mass that many treat it as today.

On Wednesday, 7 October 2015 at 10:48:02 UTC, Russel Winder wrote:
> On Wed, 2015-10-07 at 07:15 +0000, extrawurst via Digitalmars-d wrote:
>> […]
>> 
>> I have never used Go, but isn't what you describe exactly what vibe.d is doing using Fibers ?
>
> As I understand it, vibe.d is a single threaded event-loop with fibres. In this sense it is equivalent in architecture to Node except that vibe.d allows for blocking fibres where Node required non-blocking approaches. Thus I would choose vibe.d over Node any day, except…

vibe.d supports multiple threads and will schedule tasks on separate threads if asked to. Each of those threads will in turn have several fibres. The main difference from Go's runtime for me are twofold:

1. vibe.d is a library, goroutines are part of the library
2. vibe.d (like D itself) uses the actor model, go is (sort of, according to some) CSP

My "Go vs D vs C vs Erlang" MQTT shootout was based on a colleague claiming that Go would win because concurrency is its thing. I called his bluff since despite Go having a (AFAIK) very good scheduler, I didn't see how vibe.d wouldn't give me the same performance. I was right.

Atila

On Wednesday, 7 October 2015 at 17:31:12 UTC, Atila Neves wrote:
> My "Go vs D vs C vs Erlang" MQTT shootout was based on a colleague claiming that Go would win because concurrency is its thing. I called his bluff since despite Go having a (AFAIK) very good scheduler, I didn't see how vibe.d wouldn't give me the same performance. I was right.

Yes, Go is unlikely to have any throughput advantages compared to a systems level programming language.

Go's advantages:
- a more mature compiler
- robust runtime features
- lower latency GC
- infrastructure support
- simple syntactical constructs

I would consider Go-routines a convenience feature.

If C++17 does stackless coroutines right then it probably will surpass both Go and D in terms of memory locality, initialization performance and memory usage; and therefore throughput as well.

On Wednesday, 7 October 2015 at 19:58:55 UTC, Ola Fosheim Grøstad wrote:
> If C++17 does stackless coroutines right then it probably will surpass both Go and D in terms of memory locality, initialization performance and memory usage; and therefore throughput as well.

We might be able to reuse the existing delegate capture mechanism to create continuations.
Then await would "simply" rewrite the rest of the body as delegate, similar to how the foreach body can be transformed into a delegate.

There is some use-case for HPC code where stackless coroutines make a huge differences (used with a work stealing scheduler), for basic networking code it will only be a small difference.

On Wednesday, 7 October 2015 at 10:39:07 UTC, Russel Winder wrote:
> On Tue, 2015-10-06 at 15:07 -0400, Nick Sabalausky via
>> (Kinda like how "cloud" sounds like a big fancy new revolution until you realize it's just the hip new word for "internet" or "hosted".

Yes - technically it is nothing new perhaps.  But it's a commercial phenomenon, and so whilst the marketing hype is regrettable, if inevitable, it's the commercial aspects that are important here, much more than technical ones.

Big technological shifts (speaking about things viewed from a societal level, not from a practitioner's perspective) have two components - big relative price shift (which might be infinite in practical terms to a large fortune or from cheap to very cheap depending on the situation), and then the new activities and new ways of doing old things that become possible as a consequence of this price shift.  Business people take a long time to figure it out (see Brynjolfsson's work on organisational architecture), and that's why we have a period of hand-wringing between the new technology arriving and us seeing its broader benefits.  Solow, an expert on growth, observed in 1987 that "computers are everywhere but in the productivity statistics".  (My theory then was that people were too busy fiddling with fonts on their Macs to actually do any work!). A decade later, we had a different view of their influence.  Similarly we have people saying today "how many jobs has Twitter created?".  But it's not the people that Twitter directly employ, but those that benefit both from using it, and from the broader set of shifts of which Twitter is only the beginning.  Blyth Masters, for example, is doing some interesting work on exploring possibilities from using blockchain type technologies for wholesale finance.  There are some obvious problems there, but I wouldn't care to bet nothing interesting comes out of it.  But it's much bigger than that, even though I can only be aware of a part of it.

In any case, we have now inconceivable amounts of computing power on tap for very affordable prices and the tools to manage it.  When a little instance is 0.7 cents an hour, and a usable one is 1.5 cents and you can scale up and down as quickly as you like, many things become possible that weren't before.  The world is only slowly beginning to figure out what, judging by what I see in finance.

> "Cloud" is really a destruction of personal computing in favour of re- centralization of all computing: put the computing power back in the hands of the people who want to control what you may or may not do with computers. Beyond this is gets political.
>
>> Does that sound about accurate, or am I missing something?

Since I am foolish enough to run my own mail server, you can be sure that my sympathies are with you.  I think people are reckless - both individuals and corporations - in what they unthinkingly cede to companies that really have few incentives to act as one might wish.  It's one thing to be the customer, and quite another to be the product.  I saw Eric Schmidt speak some years back, and he really didn't give me a feeling that we have a similar idea about what evil means!

This being said, the world has always been broken in some respect, and we shouldn't let that stop us looking at the situation objectively even if one would wish in some respects things were other than they are.  The cloud may be centralising things for the individual, but at the corporate level it's less clear.  In particular, it's a classic case of the accounting being pretty clear that the economies of scale mean you should centralise IT infrastructure and it's management, but the practical experience of the people actually generating value within the enterprise often being rather different.  Things even in quite small firms of 150+ people start being more about internal bureaucratic logic and much less about ROI.  And the problem is that it's hard to make a convincing case for something that doesn't yet exist, and yet many big things have the tiniest beginnings.  So the current enterprise technology environment discourages those little experiments that drive real innovation, as well as getting in the way of larger projects.  The cloud, by commoditising compute, and making the price much more transparent then is a force for breaking down central structures that no longer serve their needs well.  When you can get whatever you need from Amazon today, waiting months and paying 10x more starts to seem a little stiff, and people start asking questions when before they had no choice but to grin and bear it.  Of course the questions about privacy and commercial confidentiality are there, but perhaps solutions are arriving, and business people need to be practical.  Even an overpriced internal cloud gives much more power to internal entrepreneurs than did the old way.

> I think you are missing some aspects of why there is sanity to what is happening, but you are not wrong that there is a lot of "buzz" and "hype", but that tends to go along with anything "trendy" and "hip". And there is a lot of reinventing the wheel because the hipsters create cool new stuff, but have failed to study the last 60 years of computing before doing so.

It may not be new, but it's new that it's so cheap and so easy.  (And when any idiot can, any idiot will... Which is mostly for the best, but not always)


Laeeth

On Wednesday, 7 October 2015 at 10:50:47 UTC, Russel Winder wrote:
> On Tue, 2015-10-06 at 18:56 +0000, Dicebot via Digitalmars-d wrote:
>> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
>> > Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015.
>> 
>> What do you mean by microservice examples? It is infrastructure methodology, not specific code thing, any simple network service can be viewed as microservice.
>
> At the Web services application level it is having a small framework for structuring the use of GET, POST, PUT, DELETE,… packets. Basically RESTful services.
>
> At a non HTTP level I guess you can say all networking is microservices except that you want a protocol over TCP/IP or UDP/IP and shouldn't there be frameworks to assist building these things?

Zeromq plus msgpack or the like (maybe cerealed!) gives you quite a lot.  I use nanomsg, which is still beta but nicer in some ways.  In any case it gives you survey, request/reply, bus, publish / subscribe patterns.  And it's very light and has decent throughput.  What kind of framework were you thinking of ?  (nanomsg doesn't do UDP, but I think zeromq does.  You can write your own protocol or pattern if the existing ones don't work for you, and sounds like that's work, but not much more than it needs to be).