JavaOne 2015 Notes

Pretty amazing perk having an event with Elton John, Beck, and including food, drinks, carnival entertainment, and coach shuttle transport.

Derek Ashmore

Solid presentation.  Not the depth of info as the “Building MS” presentation, but some valuable nuggets.

Yet-again another demonstration over the fuzzy nature of MS’s...

The one extra additional heuristic that is not necessary novel, but at least highlighted here is “Not dependent on execution context”.

To me, another way of saying that is - “MS’s should be Stateless”.

That makes a lot of sense.

I will add some comentary, but here is the slideshare...

http://www.slideshare.net/derekashmore/writing-microservices-in-java-java-one20151028

Another point he makes that is an ideal, but hard in practice...

Ideally each MS should have it’s own data-store (if needed).

ie. MS’s should be share-none.

Benefits

forced modular boundaries

no platform lockin (each service has the flexibility to go it’s own way).

possible to manage larger number of developers and independent teams.   So there is less communication overhead (easier to scale up dev).

Boundary Sanity Check

mission statement in one sentence in biz terms.

context independent (stateless)

warning: spending time analyzing call flow between MS’s.

Design for Failure Patterns

fail fast.

retry  (old-style)

circuit breaker (stop sending to service if failure count threshold is met).

dispatch via msg  (msg can be queued even when destination is down).

service call mediator  (error handling is factored out into a mediator).

circuit breaker - AKA Hysterix (threashold of errors to trip circuit, timeout before restarting attempts)

Deployment

embedded containers (typically Jetty)

exe jar- sprint boot, dropwizzard

Docker - standardizes the process deployment and env (jvm versions, environment,...)

Correlation ID's

having a transaction ID being threaded though all nested Service calls.

provides context for service calls.

can track using http header (api metadata).

Daniel Bryant

This was the most content dense and pragmatic talk i seen so far.

Pure firehose.  No step-by-step formula, but lots of resources and advice.

It would be impossible for me to post all the info, but click here for the slide-deck...

Tons of great tool suggestions and advice - must read.

What are MS’s?

Yet-Another definition.  This definition makes a lot of sense, especially the “in your head” heuristic.

This is not the first presentation to reference DDD term concepts, in this the idea that a MS is within a Bounded Context.  

I would certainly think you would never have a MS larger than a BC, but personally that may be a bit coarse?  BC’s are often an entire monolithic app.

eg. “an ecommerce app”, “inventory mgt”, “crm app”, etc...

After attended a few talks, i would suggest “no smaller than an Aggregate Root (transaction boundary)”, but no larger than a “Bounded Context”.

But what do i know?-)

After the talk we chatted, and made the point that distributed services were all the rage when J2EE was born, then an anti-distributed backlash swung in the other direction during the IoC days.  Now we are back to suggesting distributed.

Daniel was all over that, and said that he’s not surprised if he does a future JavaOne presentation preaching Monoliths under a different label:-)

We both agreed that it really comes down to the usecase, company, culture, team, etc...

What is right for Netfix, does not imply what is right for anyone else.

Look who i bumped into during brunch time?-)

Greg, thanks for hanging out with me and chatting.  

Not sure how this made it into JavaOne since this is a pure browser tech, but i was happy to attend.

I’m always in awe how the browser has been able to so successfully evolve from a collaborative standards body (W3C).  The technology is amazing.

One of their many evolving standards is Web Components.  It does not get much attention, but it deserves to.  IMO it’s a leap in capability.

In a nutshell Web Components enhances web pages with a UI Module system.

Sounds boring, but it’s major.

I will talk high-level, but here are details and inspiration...

https://developer.mozilla.org/en-US/docs/Web/Web_Components

http://webcomponents.org/

https://customelements.io/

Background

Webpages are increasing including complex UX components.  The code is often a huge amount of complex CSS/JS and HTML tag scaffolding.  Hugely nested collections of <divs> that have no real semantic connection with the UX.

Tags are intended to be semantic, css is for styling, and js for interaction - right?  But that is not really the case with UX components today.

And today’s components have no insulation from each other.

A web page is one big global namespace.  No isolation.  There is no way to guarantee that unrelated component css/js will not conflict.  Hope for the best.

But no more!

Web Components allow you to create new dom Modules.

Custom semantic tags!  

Instead of having 100′s of lines of <div>, <p>, <li>, ....

...all can be replaced by a new element you come up with that is the meaning of what you are trying to represent.

Want to create a “mini shopping cart” that is consistently used across your site?  

Go ahead and create a new html element call <mini-cart>, or whatever else you want to call it.

Custom elements must have at least on dash in the name.

That element can be defined similar to the old-style implementation, but all the scaffolding elements are hidden inside the implementation of the <mini-cart>.

The implementation can be defined using a JS API (DOM methods).

This is the “Custom Element” part of the spec.

Rather than using the core JS api, a declarative definition can be created using another part of the spec - “HTML Templates”.

Templates are very similar to JSP Tag Libraries, but pure browser.

Also similar to JSP, is the ability to compose HTML.  For JSP we have parameterized <includes>.

For that usecase in HTML there is the “HTML Imports” part of the Web Component Spec.

And finally, the final magic-sauce piece of the Spec is “Shadow DOM”.

The Shadow DOM is use to implement the contained elements of the Custom Element.

Think of the Shadow DOM as being a disconnected sub-webpage.  Any JS and CSS applied to the Shadow DOM will be isolated from the parent webpage.

At the same time the Shadow DOM can declare controlled exports of css/js that effect the parent page.  Just how i would hope an DOM Module would behave.

Also, as you would hope, you can compose Web Components, so more complex Web Component can made up of a collection of more simple Web Components.  

And those Collaborating Components (Modules) can be independently developed with inconsistent implementation frameworks.

I will believe it when i see it, but i theory a WC could be implemented with jquery and composed of a WC implemented with Angular and another WC implemented with ReactJS.

Stunning!  (if lives up to promise)

Atlassian

This presentation was given by an Atlassian developer.

A great endorsement of Web Components is the fact that Atlassian uses Web Components to some degree in every one of their (many and amazing) web applications.

Browser Support

It will take time to get browsers fully compliant, but Chrome already is fully compliant and FireFox is very close.  Safari and IE lag, but their roadmap includes full support.Until full support is available, a polyfill can be used.

The  reference implementation polyfill google’s Polymer (44kb).

Atlassian has also opensourced a polyfill lib that is focused just on the Custom Element piece of the spec - skate.js (5kb).

Atlassian User Interface (AUI)

Atlassian also has opensourced the WebComponents they are using for their products - who knew and how cool!?!

https://docs.atlassian.com/aui/latest/

Accessibility is a big requirement Atlassian has committed to. 

One big benefit of the AUI for Atlassian has been the encapsulation of accessibility boilerplate.

And this is an example of a general benefit, that Web Components allow the UX designers/developers to consistently apply their design, which is applied by developers.  And hidden implement changes can be made that ripple consistently through the app.

AUI is used not only internally to apply consistent UX, but it is also required by 3′rd part component development to extend the consistency to partner development.

Marcel Offermans

This was a shorter presentation (hour), which was a nice change.

Good set of demos with no gremlins striking.

Still have no definitive definition of MS.  I think the pragmatists think of them as just yet-another service that is well designed and has a process boundary.

But even the process boundary stuff does not look hard-n-fast, since this presentation talk about the reality of small IoT environments that will normally require all services to be co-located in a single device runtime.

Modularity

Nothing new here, but Modularity mentioned as being important, not only in the context of MS, but good design.

Org Structure

This point was worth the talk, and i think is a great usecase for MS.

Conways Law:

"Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure."

Wow, that’s cool.  Particularly since the law stated generally, not just for software systems.  

Given this reality, then it would be worth considering having micorservice design and boundaries mirror the development org structure?  

Or if that is completely unreasonable, then maybe the org structure should be changed to reflect a better software design structure?-)

Sure enough if you google “conways law microservices” there are many articles floating around on this topic.

Case Study: Entertainment System

A sample product that ran through the rest of the talk was an Entertainment system.

It modeled a Dashboard that could have an arbitrary collection of Applications plugged into it.

OSGI

Here is where things turned not as cool for me, but once i embraced it, then i was glad to take the detour.

It turns out that everything following was implemented in the context of OSGI.

Not that i’m not a fan of OSGI, but i felt it was not fair that the title of the talk not include OSGI since it was such a heavy part of the talk.

But once i got over that, it became an opportunity to see some cool things from the world of OSGI.

If it was not for Jigswaw creating OSGI uncertainty, i would persue it more deeply. 

OSGI has some flaw that only the VM can solve (Jigsaw).  But it is battle tested and proven for almost a decade and has quite a mature ecosystem of tools.

Some of the tools that were used:

Eclipse, Gradle

Apache Felix (very large OSGI framework)

Amdatu  (OS project with an impressive array of tools for modular OSGI development)

BND for Eclipse (popular utility tool for OSGI dev).

Apache ACE (an impressive looking framework to manage OSGI artifacts and automated deployments). 

The demo included an OSGI component that provides very cool shell for an app.  He used the shell to control the components.

He used JaxRS to implement REST API endpoints.  But did not use REST for intra-MS communication.

He used OSGI Remote Services for MS communication (an OSGI remoting extension).

So the OSGI container hosted the OSGI MS’s.

He used an OSGI registry to dynamically wire MS’s together.

For example: 

The Dashboard is listening for Application Registry changes, then plug and play depending on events.

He demonstrated Apache ACE to automate the deployment of OSGI modules to target machines.  It also acts as an artifact repository (similar to Maven), with versioned components.

IoT

The IoT discussion was just jammed in the end of the talk.

IoTIPv6 for identity.

talk about device Sessors.

Communication: Bluetooth, ZigBee, WiFi.

Need to deal with a not-always-on.

In many cases the device must be autonomous.

deployment

All MS on the same device.

Resource constrained.

Updates done over limited connections.

He did make the point that IoT MS’s are often all co-located on the same device, but there is still value in having strong MS-like module boundaries (which OSGI provides).

Atlassian sponsored hang-out right next to the Hotel.  

How cool is that!

Alexander Buckley

Good job on the presentation.  

“Layers” did not get communicated as well as hoped.

Module have been in the works for years (a decade?).

They are hugely important for organizing in the large, but they are complex to retrofit into Java, which is the cause of the recurring delays.

But it sounds as though Modules are official for Java9.

Will be impact.   Should not be, but potentially could be breaking impact.

JSR 376 - targeted for Java SE 9

Similar to class level access (public, private), but at a more coarse-grained Module level.

Packages are members of modules.

Class-public does not imply Module-public.

module-info.java is a new special file that declares a module and all it’s dependencies and exports.  The file is compiled specially (the file name dash is not normally a legal class name character), into a standard Java class with special responsibilities.

eg.

module <name> {   export <one-or-more-packages>, require <one-or-more-modules> }

Currently some frameworks have attempted to encapsulate packages using Classloader isolation.

But that technique is not practical for JDK classes.

Class objects are also not isolated by classloaders.

Classloaders cannot create isolation at compile-time.

Problem:

If an interface of module is “exported”, but the interface includes a class that is “required”, then we seem to need both?

In that case you can “requires public <package-name>”.

This same pattern can be use if a module exports a package, but later refactors a package outside of itself.  Now the newly refactored Module no longer contains the package, so it must “requires public” the package that was carved off.

An important point is that Module semantics are enforced by compiler, VM, and Core Reflection.  There is no way around it (except i think to pass typeless Objects between Modules, but once you cast/call anything, then Module checks will be enforced).

UnnamedModule (UNM)

Any legacy classes that are not part of a Module (ie. classes in the old classpath) will be added to the UnnamedModule.

Named modules can not call the UnnamedModule.

Automatic Modules (AM)

Automatic Modules are UNM that are placed in a new "modulepath" (yet-another-classpath).

AM and UNM automatically export everything.

Modules can call anything in an AM.

This is where backwards compatibility constraints create lots of extra complexity and the appearance of hack.

Layers

A Layer is a graph of modules that map to a class loader.

Layers wrap up coherent sets of modules that interact with loaders.

Layers must be acyclic (no cycles).

Export “X” can only exist only once in a Layer.  ie. a Module can not depend on 2 Modules that both Export “X”.

Nice quote give...

"excessive dependencies are bad, but cyclic dependencies are very bad"

I didn’t catch a good explanation of the purpose of Layers?

I believe they are the bridge from Modules to classloaders.

Module -> Module graph -> Layer -> classloader

They also enforce consistency rules.

I’m a half-hour early for Jigsaw, and already a huge lineup of geeks.  

I was planning on leaving the Oracle Party early enough to make the Lambda talk, but had too much fun!

Very nice Customer Appreciation event hosted by Oracle for McKesson.

Lots of nice food, drinks, chat.

Dan Heidinga

Presentation had a good technical level and pace.

Showing this applied to static usecases was excellent.

What is it?

invokeDynamic is a relatively new Java 7 feature to support dynamic method calls.

Actually more than a feature, it’s a very rare inclusion of a new bytecode.

I’m a fan of dynamic languages, so i have followed invokeDymanic as an interested observer.

It’s a compiler/tool developer concern, not really used directly by developers, but it’s a very cool VM capability that is worth being familiar with.

Problem: How to efficiently dynamically link?

Old solution is some form of Call-Site-Caching.  

This is where the implementing dynamic language resolves the method at call-time, then caches the method.  

The next time around, the context of the call still needs to be examined.  If the context has not changed, then the cached method is still valid and can be called directly.

This machinery is complex and still slow, and is re-invented by each language implementer.

The VM is unaware of what is being attempted, so can not optimize, and often the generated code is complex enough that the Java optimizer is further disabled.

JSR292 - InvokeDynamic

JSR292 was created to solve the problem of dynamic linkage and typing.

Cases where non-Java language semantics are not consistent with Java.

non-Object based.

use of metaclasses.

use of multiple dispatch.

What the invokeDynamic bycode does

Bootstrap is called with the full context of the first call of a method (includes caller, method name, descriptor, other data).

You can implement Bootstrap to interpret this context however you like.  You must finally return a CallSite object.

The CallSite object holds on to the target method.

The invokeDynamic instruction is bound to the resulting CallSite instance forever.

CallSite includes hints of the stability of the target method (”constant” will never change, “volatile” can change ever call,...)

These characteristics make dynamic calls very flexible and allow the VM to apply very good optimization.

In the case of “constant” CallSites, the performance will match static method calls (after warmup).

Switchpoint is the ability to externally invalidate callsites.

invokeDynamic can be use to implement sematics beyond just simple method calls.

lazy constants.

new semantics.

new bytecode prototyping.

The question was asked (which is a good one)...

What is a dynamic language anyway?

The speakers made the point it is not black/white, that there really is a spectrum, and there are many dimensions.

compile time vs. runtime.

typing, dispatch (static in Java)

binding, loading (dynamic in Java)

Most interesting was the point that Lamdas have been implemented within Java (a supposedly static language) using InvokeDynamic.

Couple of big benefits.

This allow runtime-based optimizations to be applied.

** It allows a new language feature not to require VM internal implementation.  This is normal Java lib code.  So it keeps the core VM smaller and more simple.

Another example that may be coming in Java9 is a String concat optimization.

eg.

String concat = a + "|" + b + "|";

This form of code is very inefficient, but used a lot.

The compiler can use invokeDynamic to generate a callSite that is passed the entire list of concatenations, which can then be optimized (at runtime).

The prototype of Java10 parameterized types over Value Types is also using InvokeDynamic.  

Jose Paumard

Talk was very light on fluff.  Dove straight into dense code.

Normally would enjoy a steep dive, but this was pretty hairy.

Would have been nice to have some more foundational discussion, but i there will be more talks that will likely help fill gaps (hopefully).

Streams are arguably the most significant addition to Java8.  

The API is mostly functional, and designed to be written in a fluent style (nice), where chains of calls create a pipeline of stream data processing.

One of the key design goals is to make the API inherently parallelizable.

By default processing is on a single thread, but with a single parallel() call, you automatically have the pipeline spread across available cores.  Very cool.

list.stream().parallel()    // ! now running in parallel.

Conclusions

This is a long post, so i will start with my thoughts regarding a contract of Java Streams vs. RxJava.

Opinion: All this Streaming/Reactive shiznitz is awesome.  IMHO it is going to take a few years (decade?) for most devs to feel fluent with these patterns and way to expressing algorithms.  But the reward is immense power.

Java Streams

JStreams is strictly pull-base.

Single threaded by default, but can be easily processed in parallel on request.

Parallel work is on the Consuming side, by splitting up the incoming stream to be work by many Consuming threads.

Without a lot of experience here, Java Streams feels like a lightweight approach to processing local data.  Imagine you can a bucket of data and you needed to sift through and analyze it.  This seems to be a great scenario for Java Streams, which perform work single or mult-threaded.

It seems to have excellent performance characteristics for processing a collection of raw data.

RxJava

RxJava is pull (Cold) and (mostly) push-base (HOT).

Scheduler defines the threading policy, which is on the Producer side.

Work is parallel when there are many Sources (many source threads).

On the other hand, RxJava seems particularly well suited when you are not simply in control of a bucket of data.

If the problem looks more like an independent stream of events coming from autonomous Actors, then it smells like a RxJava (Reactive) problem.

Actors in the sense that there are many sources, in their own thread(s), all generating data independently, at their own rate, and possibly time dependent.

That is not a good scenario for Java Streams, but looks to be a natural fit for JavaRx.

eg.

There is a bunch of REST Services (or even better WebSocket Services) that are generating data you need to consume and join in parallel.  

RxJava could be used to Observe all of those independent Services.

Java Stream

In a nutshell a Java Stream is an Object that connects to a source of data.

Sources of Data can come in many forms.

Collection source

Files can be the source of Streams (Files.lines() -> Stream<String>).

Regex source

Stream does not hold data (it’s the infrastructure for pipelining).

Primary usecase is map/filter/reduce.

Can generate Optionals, which wrap values that can be empty.

Another key property, is that the pipeline (such as map/reduce) is processed in a single pass without intermediate data structures.

Wow, that’s strong.

Code referenced some Java8 syntax that was new to me, particular method refererences.

eg. Person::getAge

There is a little more to it, than just a straight method reference, but that is the easy way to think of them.  Here is more discussion.

http://stackoverflow.com/a/22245383

Collectors

Collectors aggregate and do stream analysis.  The classic Collector is the “groupingBy” collector, which takes a predicate and puts each element of the stream into a different bucket (results in map).

Here are some more examples right out of the Java doc.

https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collectors.html

Since primitives are not first-class objects (maybe Java10 value types will change this?), specialized Streams are created for each primitive type.

eg.

String.chars() -> IntStream

flatMap() is commonly used.  If the stream contains collections, then you can think of flatMap() as “flattening” those collections and adding the individual members back into the Stream.  The Javadoc has a good example.

https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#flatMap-java.util.function.Function-

It is worth repeating - streams avoids the need to create intermediate data structures to analyze collections.

Custom Streams

Maybe typical types have Streaming support built into the standard lib.  But what if you want something outside the JDK to be Stream-able?

The core implementing class is common to all Streamable types.

That is “ReferencePipeline”, which does not need to be extended.

To create a new Streamable type you must implement...

...drum roll.....

Spliterator!!!

I think the name derives from a combination of Split (partitioning) and Iterator (traversing) responsibilities, as well as an attempt to generate a cool sounding name.

The Split is the sauce that allow the pipeline to split the stream into parallel pieces.

There is not too many implementation requirements, but the was looking pretty funky.  This is maybe the most straightforward slide... 

He presented some specialized Spliterators...

ZippingSplitetor is a builder for creating Spliterator that joins Streams.

WeavingSpliterator is used to round-robin source from a set of source streams.

Reactive Streams RxJava (Netflix).

OK, now he jumped in RxJava.

He made the point that it is not a replacement of Streams/Collections.

It is an implementation of the Reactor pattern, which first appeared in C#, but has been ported to many languages, including Java.

One big difference with with JStreams - RxJava is time-series.  It can generate events independent of whether anyone is consuming.

Observable

The Observable class is the central implementation class.

It’s a beast at > 10k of code in a single class.  

An Observable generates generator, pushes objects.

Observer

Observer is an interface that Subscribes and consumes events (pubsub).

So an Observable (source) pushes to a subscribing Observer.

Contrast that with Streams, which pulls from a source.

eg. 

observable.subscribe(observer);

And here is an example of an Observable that generates Timer events.

Observable.timer( ...);   // generates events.

Schedulers

Observables run in the context of a Scheduler.

A Scheduler supplies a pool of threads (and presumably implements a Scheduling policy).

WARNING:  Jose gave a heads-up that Schedulers are a bit of a leaky-abstraction.  Different types of Observables have different underlying Schedulers, which in practice you often need to be aware of.  And a peek under the implementation hood is needed to understand those Scheduler semantics.

Observables can be combined with Operators.  Some examples...

The funky sounding Ambiguous operator, amb(), takes the first stream that provides data.

zip(), takes one element from each stream and emits one.

combineLatest, concat, merge, etc...

Cold Observable

Generates events only when being Observed (pull-based).

The behavior of Cold Observers sounds similar to JStreams? 

Hot Observable

Generates events independent of an Observer (push-based).

What if try to subscribe many Observers, and the time taken causes some Subscribes to lose events (race condition)?

You can try to cache a window of events > cache(<count>).

Better solution in this case is to use ConnectableObservable, which can batch the subscription of a collection of Observers into a single atomic Subscription.

Logging

materialize()  mapping can be used to log all events.

More Operators

selection methods, reductions, collections

repeating, and retry patterns for error handling.

joins

time sampling, observe durations between events, delay events, timeouts, etc...

What if a Hot Observable is too fast for the Observer?

Backpressure

Backpressure is the concept of Flow Control when the speed of the source events do not match the consumer.

This sounds very similar to the old producer/consumer pattern, particularly Pipes, where you would setup threads, a buffer, and use thread-waiting when the buffer was either full or empty.

Cold Observables handle this by being pull-based (except in a multicast stream setup).

Java Streams naturally handles backpressure by being Pull-based.

Ways to slow down data

Observer signals Observable when it's ready for more data (pull-based).

strategies on the Observing side

buffering

skipping

windowing

throttle (sample events).

debounce

Connecting Streams to Rx?

Iterators are a bridge (patterns for both directions).

Not trivial to implement.

Only works with Cold Observables.

Demo Benchmark

Shakespeare plays Scrabble

Usecase for performance test:

Set of all words used by Shakespeare and ways to compose and score each in scrabble.

This demo made it pretty clear that Jose favored Java Streams, since the usecase is not a good one for JavaRx.

A JavaRx fan made a point of loudly protesting the demo was bogus.

WAR JavaRx!!!

Rx solution is a more complex for this usecase.

Java8 can easily go parallel, but not Rx in this case.

JMH

For the performance measuring JMH was used for benchmarking.  Apparently a standard tool for JVM micro-bench performance measurement.

The number of events processed...

JStream (non-parallel) => 29k

JStream (parallel) => 253k

RxJava => 7k

Java9

Apparently java.util.concurrent is being enhanced to also add Reactive.

Hey if Microservices are all the rage, then Nanoservices must be the bomb - right?-)

Nano

I give full props to the main speaker Adam Bien (German dude), for generating very effective presentation-bait via the term Nano, which created a crowd-size much larger than would have likely attended otherwise.

I wonder how big the crowd would have been if the talk title was PicoServices?-)

Even more humorous was how dubious he was of the whole Microservice trend (right after getting us jazzed about Nanoservices).

If Adam was more honest he would have called the talk Micro-Shmicro - hehe.

To be fair he was not anti-microservices, more so anti-buzz.  

He also sounded veteran, battle-scarred, pragmatic, and believed in using a tool only if necessary.

JavaEE

As the talk suggests, he seems to be a javaEE evangelist.

A lagit benefit of javaEE he pointed out, that i have never given much thought to, is dependency management.

All (most) EE projects only ever need to depend on the “javaee-api” POM, and then be free of managing a slew of 3′rd party dependencies, upgrading dependencies, managing conflicts, etc...   The platform takes care of all that for you.

Microservices

For Adam, microservices do not have much meaning.  They seem to be a natural consequence to good app structure for him.

Many of the heuristics he suggested rang true for me.

He believes service boundaries should be deferred as long as possible, since it takes time to mature the business logic and design of an app.

The first microservice should be the app stripped of everything except core business logic (the domain model in DDD-speak).  All other infrastructure can be in one-or-more frontend apps.

Only if the “domain model” service is too large, only then think about splitting into multiple physical microservices.

A single transaction boundary should never span multiple services.

In DDD this would mean that a microservice should never be smaller than a single Aggregate Root (transaction boundary).

This makes sense since you want to avoid the need for distributed transactions.

He believed that DTO’s only have value if they do not mirror an Entity (he argued (reasonably) that the case where DTO’s == Entity structure adds no value).

He believed that for the most part, the frontend UI app should be responsible for orchestrating microservices.  

Which i assume means he is discouraging MS’s having dependencies on other MS’s?

He preached no sharing of resources, jars, etc... between microservices.  The value was in their physical separation and loose coupling.

One war per appserver (an extension of no sharing).

The following opinion was interesting.

The benefit and tradeoff of microservices:

The possibility of faster project delivery via physical decomposition and scaling up of large numbers of developers....

...but at the cost of more complexity and budget.

Distributed services have performance cost and complexity cost.

Docker

He dove into Docker with only minutes left in the talk (there were lots of Nanoservice questions that got in the way).

He showed what looked to be a potentially cool design pattern with layered Docker configurations.  An inheritance structure where the top layers are abstract, starting with stable infrastructure, then subclassing to progressively more unstable layers.

The bottom layers were environment, then finally the business application (single jar/war).