Actually its less to learn than before, as long as you understand appx you're good. No msi, no installers :) An appx will install on containers, nano, server core and regular server. and this is true whether its a container, a vm or a physical machine.
Reverse forwarders you don't really need to know anything about, they just make sure old apps keep working with no changes
Service fabric is going to rock! the azure scenario is great of course but what's really exciting to me is the private cloud and also mixed cloud scenarios. if they deliver on what they initially promised you could have a single azure fabric consisting of an azure vm, a local vm and an aws vm, since service fabric is just something you install on a windows machine.
I really hope we'll hear more about service fabric soon, in server 2016 TP3 there is a mysterious "Service fabric" role for example. as i sometimes put my devops hat on i'm really curious about how you run these things yourself :)
Comparing to containers, i think they could be combined actually, you can probably run a service fabric node inside a container if you'd like, if for example the app isn't trusted. What service fabric gives you though is that automatic deployment, load balancing and failover, so its more high level than a straight up container
I think EF7 is going to be great but you should really consider calling it EF light or something, not EF7, its really no a representative name, its not an evolution of EF6 and EF6 will still be used alot after EF7 comes out.
EF light would be alot more cler and also not give the message that EF6 is not useful to anyone anymore
Just a follow up on the guid thing, i see the reasoning for having a key to identify a machine but my question was really if that key really had to be a guid or just any text (and now i know!) it's not a big deal, just a mild inconvenience when you're setting up a pull server configuration.
In the dsc MVAs you mention having the same config id on multiple machines and how in those cases the config id can be thought of as the "webserver" configuration for example. well i was thinking in those cases, why can't i just call it "webserver" then :)
Oh well, i'm in the process of writing my own pull server that will have some extra features where i can abstract that stuff away, witch i guess is the point. But it does make pull servers and "pure" dsc a little bit harder to get into :)
.net core is basically a cross platform version of .net, with a clr and a specific subset of libraries (and support for portable libraries)
With .net core you have an option to compile your code directly to native code, also compiling away all the stuff in .net your program isnt using and performing whole program optimization. that process is called .net native.
So .net core is a smaller portable version of .net and .net native is a technology to compile .net core programs to native code and also do a bunch of optimizations