Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Welcome to our site

Take a moment to join our board

Sign in to follow this  
Omicron

[Nice Read] .NET Microservices. Architecture for Containerized .NET Applications

Recommended Posts

A nice read about microservices. Even though they mention .NET a lot, the content is still pretty relevant with other languages. 

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/index

Also, I uploaded the e-book as attachment as I am not sure about file storage on the server, I will provide you guys with a direct link to the download. (Which is also available on the overview page)

[Attachment].NET Microservices - Architecture for Containerized .NET Applications.pdf

Edited by Omicron
  • Like 1

Share this post


Link to post
Share on other sites

Funny that you bring up microservices using Microsoft's documents. I got the opportunity to spend last Wednesday at Microsoft to meet up with some Azure solution architects. We talked a lot about new Azure offerings and how they might benefit the company I work for, but also what Microsoft is trying to do in terms of cloud services. Microservice architectures using deployment services like Kubernetes or Service Fabric are fantastic, and offer a lot of promise, but don't apply to many use cases. The challenge of making multiple, independent microservices falls through to every layer of application development. If you can't separate your database into multiple for each microservice, that's a foreseeable issue. If you can't separate concerns without dependencies on each microservice, that's a problem. In a lot of the cases we went over, microservice architectures really only shine for a select few. Microsoft's big push right now is in providing a similar approach on much smaller scale using event driven / data driven micro-programs. Like, being able to write a Twitter bot that uses sentiment analysis and emails you when very negative, high profile tweets about your company go out using zero lines of code (Microsoft Logic Apps / Flow). Having that then interface with a serverless Azure Function that performs a small bit of work, and dumping large amounts of data into Cosmos DB that indexes everything and is built for multi-write and multi-read operations across multiple services. Having WebJobs that can fire when something's added to a queue or blob storage container (which replaces worker roles using WCF). Everything they do now seems to be more and more architected towards cloud solutions, rather than just cloud offerings for legacy/monolithic technologies. It's extremely interesting to see how they've progressed just this year. I know the company I'm currently working for wants to use microservices, and I'm totally for it. I finally feel like Microsoft is starting to find some ground again.

PS: As just a side note, I might have tried making a microservice architecture for Conquer Online. Although very interesting in having JSON-RPC via API like interfaces to each microservice, and a TCP gateway for handling connections, I didn't really see much of a benefit for Conquer Online. That being said, anything for Conquer Online beyond a two server system is a bit overkill. Fun to try though, especially when things can be so easily separated to handle different requests. Used Cosmos DB in the background, so I didn't bother separating data into individual databases. Doesn't matter too much when Chimera is essentially a microservice architecture already, just less granular without the naming services, routing, and service redundancy.

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, Spirited said:

Funny that you bring up microservices using Microsoft's documents. I got the opportunity to spend last Wednesday at Microsoft to meet up with some Azure solution architects. We talked a lot about new Azure offerings and how they might benefit the company I work for, but also what Microsoft is trying to do in terms of cloud services. Microservice architectures using deployment services like Kubernetes or Service Fabric are fantastic, and offer a lot of promise, but don't apply to many use cases. The challenge of making multiple, independent microservices falls through to every layer of application development. If you can't separate your database into multiple for each microservice, that's a foreseeable issue. If you can't separate concerns without dependencies on each microservice, that's a problem. In a lot of the cases we went over, microservice architectures really only shine for a select few. Microsoft's big push right now is in providing a similar approach on much smaller scale using event driven / data driven micro-programs. Like, being able to write a Twitter bot that uses sentiment analysis and emails you when very negative, high profile tweets about your company go out using zero lines of code (Microsoft Logic Apps / Flow). Having that then interface with a serverless Azure Function that performs a small bit of work, and dumping large amounts of data into Cosmos DB that indexes everything and is built for multi-write and multi-read operations across multiple services. Having WebJobs that can fire when something's added to a queue or blob storage container (which replaces worker roles using WCF). Everything they do now seems to be more and more architected towards cloud solutions, rather than just cloud offerings for legacy/monolithic technologies. It's extremely interesting to see how they've progressed just this year. I know the company I'm currently working for wants to use microservices, and I'm totally for it. I finally feel like Microsoft is starting to find some ground again.

PS: As just a side note, I might have tried making a microservice architecture for Conquer Online. Although very interesting in having JSON-RPC via API like interfaces to each microservice, and a TCP gateway for handling connections, I didn't really see much of a benefit for Conquer Online. That being said, anything for Conquer Online beyond a two server system is a bit overkill. Fun to try though, especially when things can be so easily separated to handle different requests. Used Cosmos DB in the background, so I didn't bother separating data into individual databases. Doesn't matter too much when Chimera is essentially a microservice architecture already, just less granular without the naming services, routing, and service redundancy.

What I have noticed that if you want to properly implement microservices, you shouldn't do it with a small project as it only adds complexity. 

Talking about complexity, I believe the biggest complexity is the communication between services. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

    • By Reiko
      So this is a pretty neat project I intermittently work on. This is a discord bot using the Discord.NET wrapper from RogueException. It makes use of the onion architecture and I tend to think while indeed a small project at this time, is the best showcase of my growth as a programmer and knowledge of OOP.
       
      One really neat feature I love to draw attention to is the command system. I sometimes get called out for overengineering the solution, but I highly disagree. One thing I've really bought into is the idea of future-proofing your application. Most discord bot command systems use hard-coded strings somewhere to dictate what command is being parsed. Something many programmers do is use a switch statement. This is fine, however I understood that as the needs for the discord server I administrate grow so will the scope of this project. I needed a more... automated solution. The idea came to me to use reflection for this so I could create/delete classes that were prefixed with the command and compiled at run time in order to be parsed and executed. Long night made short, I evolved from using Activator to compiling lambda expressions which displayed a HUGE performance increase (almost near raw hardcoded performance). This allowed me to have a solution where I don't need to manually maintain a switch block or refactor strings in the event commands change.
       
      Hope y'all dig it!
       
      https://github.com/reikotechnology/projekt-analytix
      Blog Writeup: https://reiko.tech/Blog/View/8
    • By Reiko
      So early this morning I did a live lesson on WPF that basically touched on design, MVVM, data-binding and commands. This video is definitely considered long, however my goal was not just to teach my viewers a certain way of doing it and leaving it at that, but to also go through other ways and why it's wrong. For example one thing I touch on is why the ideology that no code should exist in your code-behind is a good one.
       
      So here's the YouTube version of the lesson with the only edits being done to the start/end times. 😁
       
      C# - WPF Basics (In-Depth Lesson/Stream)
      Source as of current lesson: https://github.com/reikotechnology/chatty
    • By Omicron
      I have been working on an API which I will be using for:
      I got the base working and wanted to share it.
      The API is made in .NET Core 2.1 using Pomelo Entity Framework and FluentValidation 
      The project can be found on my Github: https://github.com/Sedatb23/EpochApi
       
×

Important Information

By using this site, you agree to our Terms of Use.