D for microservices

[Laeeth Isharc]

On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote:
> I just read the following two week-old comment on the ldc issue 
> tracker, when someone tried to run D on Alpine linux:
>
> "For now everything works(?) but I think the process could be 
> improved.. Would be really cool to have LDC easily building 
> alpine containers + static D binaries for microservice and 
> tooling development. I'm pretty tired of reading Go code :)"
> https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550
>
> It strikes me that microservices are a great way for new 
> programming languages like D to get tried and gain some uptake, 
> but that D might not be that easy to deploy to that scenario 
> yet.
>
> So this is a question for those deploying microservices, as I'm 
> not in that field, what can the D devs do to make it as easy as 
> possible to get D microservices up and running, make some 
> Docker and Alpine containers with ldc/dub/vibe.d preinstalled 
> publicly available?  What else, what kinds of libraries do you 
> normally use?
>
> This is a niche that D and all newer languages should target.  
> How do we do it?

We're going a bit in that direction, although it's a different 
thing in our kind of industry from a web company - we have fewer 
services and many fewer requests, but latency matters more for 
example.  I was thinking we might use Go for some services that 
integrate and monitor things, but we could also use D.

https://jobs.github.com/positions/8e98eac8-b504-11e7-9da8-0737a3dcef18

 From the comment:
"Would be really cool to have LDC easily building alpine 
containers + static D binaries"

How can we generate a static binary ?  I asked about this before, 
and the response was that it's a bad idea because of security 
vulns and so on.  True if you are running on a conventional Linux 
host.  But on the other hand, it's not that great if when the 
system phobos is upgraded all the D binaries break.  You can 
write a script using rdmd or dub scripting feature, but that 
doesn't work for more complex programs.

And on the other hand, for deployment, it's much easier to copy 
over one binary.  (In a sense it's funny that the question was 
asked in the context of containers, because containers are kind 
of an alternative to having a single binary).  When you're 
properly set-up of course it doesn't matter, but when you're 
moving towards that, a single binary is much easier.

I guess I can figure out the answer to this question easily 
enough, but I think giving people the option might help with 
adoption of D for micro services.  For example it's really just 
not that fun to make an AWS Lambda using D - being able to easily 
build a static binary would make the process much more pleasant.

I wrote this up a while back:
http://awslambda-d.readthedocs.io/en/latest/

"Since dmd links phobos dynamically on linux, and phobos/druntime 
aren't installed on the AWS lambda server, we will need to upload 
these to the servers and tell the application where to find them. 
(I should really have appended to LD_LIBRARY_PATH as I did with 
PATH).

Now one can follow the regular instructions for AWS Lambda: 
create a .zip file with the D binary, the JS file, and the 
following libraries (update version numbers as appropriate):

libcrypto.so.1.0.0
libphobos2.so.0.67
libevent-2.0.so.5
libssl.so.1.0.0
"

Alpine is nice - would be good to have this as a standard target 
in time.


Laeeth.