Recap of Microservices for Java Architects Presentation CJUG

The award-winning software development partner recognized for innovative employee engagement measures

I had the pleasure of attending the Chicago Java Users Group (CJUG) for a presentation by Derek Ashmore. The topic was Microservices for Java Architects. Over a two year period, I was part of the implementation of a system that had similarities to the Microservice Architecture approach, so my intention for attending was to hear Dereks' opinions on the topic. I also hoped to have some of my open questions answered around the topic.
To start, if you are unfamiliar with Microservices, I recommend to check out Martin Fowler's article here:   
Overall, Derek did a great job of covering key Microservice Architecture concepts. I particularly liked his analogy of a stereo system for the structural concept of smart endpoints and dumb pipes. One of the drivers for Microservices is to address the concerns of a monolithic application. Derek addressed the monolith and then dove into a comparison of the monolithic architectural structure and the Microservice architectural structure. Next, Derek dove into design considerations and patterns. A few of the key patterns included Circuit Breakerand Retry. Derek covered how Microservices can be packaged, including a focus on Docker. He also covered several key cross-cutting concerns, including transactions, security and testing. Finally, Derek provided several considerations that are important when deciding to use Microservices for your architecture. 
During the follow on discussion we shared our collective experience on the following areas: 
1.  One of the key Microservice aspects I've researched is the need for DevOps, which Derek highlighted a bit following one of my questions. Microservices generally go hand in hand with lean engineering, which has the principle of releasing more frequently through a build-measure-learn cycle. Given this, it was his opinion that DevOps are really an important part of going with this architectural style. 
2.  Another key aspect was around team organization. It was Derek's opinion that the team should be organized differently around a Microservice structure. He provided some sizing considerations for a team as well. 
3.  The final aspect I got more information around was his opinions on security. I felt he went into a lot of good detail on how to address this concern. He also hit on an anti-pattern that I have seen several times in my research, which is exposing Microservices directly to the browser. 
Many thanks to Derek for this overview - the key opinions in his presentation confirmed what I have both in both my research and experience. He hit on the concepts of governance. He went into a lot of detail on database considerations, especially the concerns of two-phase commit in the approach. Overall, it was a very useful presentation in terms of content and I came away knowing more about Microservices than when I started.
If you are interested in learning more about Microservice architecture, here are some resources to check out: