D and microservices

[Mengu via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:07:32 UTC, Nick Sabalausky wrote:
> On 10/06/2015 01:54 PM, Russel Winder via Digitalmars-d wrote:
>> On Tue, 2015-10-06 at 16:21 +0000, Dejan Lekic 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.
>>>
>>> As far as I know, there is no implementation of microservices 
>>> as
>>> we see in the Java world. IMHO, D community should come up 
>>> with a
>>> good microservices architecture. As you pointed out, it could 
>>> be
>>> based on vibed.
>>
>> Pity, microservices is a very fashionable thing just now, and 
>> Go is wiping
>> the floor with Node and Java. Well that bit is opinion but… 
>> many people are
>> getting into all this non-blocking, event-driven, shared 
>> memory stuff and
>> boiling their brains, whereas the Go folk are doing blocking 
>> stuff using
>> dataflow which is much easier to program.
>>
>
> 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?

a half of it is the buzz and other half of is not. remember 
people talking about reactjs, go and rails being buzz? they were 
the same. we have built an online payment gateway and we are 
about to decouple our application and switch to microservices 
architecture. we have an api, a dashboard, a checkout page, 
mobile flow. we have to deal with accounting and reporting as 
well. and there is no way that this application will turn into a 
giant monolith. i don't want that. nobody wants that. it will 
become something we cannot handle.

another thing is whenever we do deployments we have to take down 
the whole application and go offline. i know there are other 
workarounds but when we only want to deploy mobile payments or 
the api, other functionalities should continue working and our 
customers should be able to pay.

nobody suggests starting with microservices architecture because 
you'll never know where things will lead you however when it 
becomes a giant the suggestion is to use microservices.

one other benefit of using this microservice is that you don't 
have to look for specific language programmers. you only need to 
hire good programmers as the only requirement  is to do one thing 
and and doing it well. the rest is about communication.