Opening Announcements
Ryan Moore of Moore Creative Company lead us off with the meeting announcements which were mostly centered around DNN Summit. Being transparent, I did arrive a little late to the meeting and may have missed a few early announcements, but I can tell you that a good portion of the announcements were around the upcoming DNN Community Conference, DNN Summit.
DNN Summit
Cassidi Brickner of 10 Pound Gorilla briefly joined the meeting to provide information about the recently announced DNN Summit. DNN Summit replaces DNN Con and will be held in Denver on Jan 18 – 23, 2017.
If you want more information on the transition check out the informative blog on the transition from DNN Con to DNN Summit on the DNN Summit website.
Cassidi mentioned a lot of info, which can be found on the DNN Summit site, but specifically she mentioned that the prices on the skiing packages are currently being finalized and should be shared in the coming weeks. She also quoted “This is not your grandma’s tubing” when asked for more info about snow tubing!
Cassidi also reiterated that the speaker submission cutoff is September 16th! Submit your sessions now!
Micro-Services in Evoq
Joe Brinkman of DNN Corp joined the meeting as well and was our featured speaker. Somehow, he was able to get through our online heckling and give an informative presentation! Joe shared some neat info on the micro-services that DNN Corp is putting into the Evoq edition.
Joe shared a lot of info and I won’t be able to articulate it all here in text, but I will try to summarize. See the below video for the full take on micro-services.
Monolith Challenges
Joe started out with stating some issues that he referred to as “Monolith Challenges”. These challenges are ones that we are familiar with from working with DNN over the years. Things like the tight coupling of modules, the usage of API’s in way they weren’t intended to be used, finding issues in modules when a small change in an API was made. These issues affect things like scaling and deployment. Joe also gave the “single language” example where he described how DNN’s search feature is tied to Lucene.net, which is always a version or two behind the Java version of Lucene. Why not just use the Java version of Lucene? These are the kind of scenarios Joe illustrated when making the case for micro-services.
Building Micro-services
After making the case for micro-services Joe then went into some best practices for building micro-services plus spoke to some of the benefits. Some of those best practices were:
- Keep Services Small - Focus services on one task
- Messaging Enabled – Use traditional technologies to make sure they are API based
- Bounded Scope – Only have one reason for the service to change… focus on a single feature and that becomes the entire boundary of your micro-service
- Autonomous development – Find and use the right tools, regardless of their language. Let the micro-service do what is necessary
- Independently Deployed – The notion of being able to update a feature without the user having to install anything. This makes delivering enhancements, patches, etc. very easily. Clients don’t have to do an install or upgrade. Updates can be made in real time
- Decentralized – Having code in other locations can be beneficial if your architectures allows it. Though, sometimes you need centralized command in scenarios such as shared infrastructure
- Automated – Automate the entire deployment process. Independently deploy to any environment… push to dev/staging/prod
- Note – If you’re going to do this then this scenario requires good monitoring tools to detect failures during a push
- Also beneficial is that this allows for rolling it out to a small portion of customer base for testing “Rolling upgrade”
- Course-Grained API’s
- CRUD based API’s don’t do so well with micro-services
- Deal with data in batches going in and coming out
- Separate Data-Store per Service
- Services are not sharing DB tables
- Example, membership services solely responsible for managing users
- Other services can subscribe to events
- Deploy in containers
- Allows for deploying to Azure in a set configuration
- Services Should be Stateless
- This allows services to be called on or even destroyed as needed
- Netflix example, Chaos monkey, detects services with issues and kills them
To-Do List Example
Joe then showed his to-do list module that was built using a micro-service. He shared how there is an API endpoint and a UI endpoint and that they are using web pack to combine and minify resources. It was interesting to see how they turned the HTML view of a module into template that’s called in JavaScript.
Joe’s To-Do List micro-service was shown to us in the context of a DNN module, but then he turned around and showed the same functionality being delivered into a vanilla HTML file via an AJAX call using jQuery. It was neat to see. This brought on the notion of “Delivering a feature as a service”. At this point we went into some in-depth questions regarding the data access layer and API’s (see the video for that info)
David Poindexter & nvquicksite Updates
After Joe’s speech David Poindexter of nvisionative gave a brief update on the enhancements in the latest version of nvquicksite. In case you didn’t know there was a recent new release of nvquicksite. The new release provides a lot of usability improvements as David has reduced the number of clicks/steps necessary to get through the wizard. Also, David has implemented some basic stats to track usage of the installer. David welcomed more updates/requests/feedback from the community.
If you haven’t used nvquicksite yet, you definitely should. Go to nvquicksite.com to download the latest version.
Thanks again to our sponsor, JetBrains for sponsoring the group! We gave away some awesome JetBrains licenses last night!
Video Replay
See you next month!