Hands-On Microservices with C#

Designing a real-worl, enterprise-grade microservice ecosystem with the efficiency of C# 7

Matt R. Cole

• Verlag: Packt Publishing
• Jahr: 2018
• ISBN:
  9781789533767
• Auflage: 1
• Thema: Informatique
• Thema: Programmation en C#

Build enterprise-grade microservice ecosystems with intensive case studies using C#

Key Features

• Learn to build message-based microservices
• Packed with case studies to explain the intricacies of large-scale microservices
• Build scalable, modular, and robust architectures with C#

Book Description

C# is a powerful language when it comes to building applications and software architecture using rich libraries and tools such as.NET.

This book will harness the strength of C# in developing microservices architectures and applications.

This book shows developers how to develop an enterprise-grade, event-driven, asynchronous, message-based microservice framework using C#, .NET, and various open source tools. We will discuss how to send and receive messages, how to design many types of microservice that are truly usable in a corporate environment. We will also dissect each case and explain the code, best practices, pros and cons, and more.

Through our journey, we will use many open source tools, and create file monitors, a machine learning microservice, a quantitative financial microservice that can handle bonds and credit default swaps, a deployment microservice to show you how to better manage your deployments, and memory, health status, and other microservices. By the end of this book, you will have a complete microservice ecosystem you can place into production or customize in no time.

What you will learn

• Explore different open source tools within the context of designing microservices
• Learn to provide insulation to exception-prone function calls
• Build common messages used between microservices for communication
• Learn to create a microservice using our base class and interface
• Design a quantitative financial machine microservice
• Learn to design a microservice that is capable of using Blockchain technology

Who this book is for

C# developers, software architects, and professionals who want to master the art of designing the microservice architecture that is scalable based on environment. Developers should have a basic understanding of.NET application development using C# and Visual Studio

Let's Talk Microservices, Messages, and Tools

Microservices are all the rage. They are talked about everywhere, and it seems like everyone wants them nowadays. There are probably as many implementations of them as there are words in this paragraph, and we'll add yet another one into the mix. But this comes from several implementations and years of experience developing enterprise grade microservice ecosystems for big clients. Now, I'm letting you in on the same techniques and best practices I've been using in the real world. And thus, you have the logic behind this book. I'm going to show you how to develop a powerful, flexible, and scalable microservice ecosystem, and hopefully along the way spark ideas for you to go off on your own endeavors and create even more. And we're not talking about some skimpy little web page or a single service; I've packed this book full of more microservices than you can shake a stick at, and I am sure your ideas will take shape and you will enhance this ecosystem to meet your needs.

In this chapter, we will cover:

• What a microservice is
• What a microservice architecture is
• Pros and cons of a microservice
• Installing and an overview of Topshelf
• Installing and an overview of RabbitMQ
• Installing and an overview of EasyNetQ
• Installing and an overview of Autofac
• Installing and an overview of Quartz
• Installing and an overview of Noda Time

What is a microservice?

Ok, let's just go ahead and get this one out of the way. Let's start this book off by talking a bit about exactly what a microservice is, to us at least. Let's start with a simplistic visual diagram of what we're going to accomplish in this book. This diagram says it all, and if this looks too confusing, this might be a good place to stop reading!

Let's next agree to define a microservice as an independently deployable and developable, small, modular service that addresses a specific and unique business process or problem, and communicates via a lightweight event-based, asynchronous, message-based architecture. A lot of words in that one I know, but I promise by this end of the book that the approach will make perfect sense to you. Basically, what we are talking about here is the Messages central component in the previous diagram.

I know that some of you might be asking yourselves, what's the difference between a service and a microservice? That is one very good question. Lord knows I've had some very heated discussions from non-believers over the years, and no doubt you might as well. So, let's talk a bit about what a Service-Oriented Architecture (SOA) is.

Service-Oriented Architecture

The SOA is a software design paradigm where services are the central focus. For the purposes of discussion and clarity, let's define a service as a discrete unit of functionality that can be accessed remotely and acted upon independently. The characteristics of a service in terms of a SOA are:

• It represents a specific business function or purpose (hopefully)
• It is self-contained
• It can and should function as a black box
• It may also be comprised of other associated services
• There is a hard and dedicated contract for each service (usually)

Some folks like to consider a microservice nothing more than a more formalized and refined version of an SOA. Perhaps in some ways, that could be the case. Many people believe that the SOA just never really formalized, and microservices are the missing formality. And although I am sure an argument could be made for that being true, microservices are usually designed differently, with a response-actor paradigm, and they usually use smaller or siloed databases (when permissible), and smaller and faster messaging protocols versus things like a giant Enterprise Service Bus (ESB).

Let's take a moment and talk about the microservice architecture itself.

Microservice architecture

Just as there is no one set definition for a microservice, there is also not one set architecture. What we will do is make a list of some of the characteristics that we view a microservice architecture to have. That list would then look something like this:

• Each microservice can be deployed, developed, maintained, and then redeployed independently.
• Each microservice focuses on a specific business purpose and goal and is non-monolithic.
• Each microservice receives requests, processes them, and then may or may not send a response.
• Microservices practice decentralized governance and in some cases, when permissible, decentralized data management.
• Perhaps most importantly, at least in my mind anyways, I always design a microservice around failure. In fact, they are designed to fail. By following this paradigm, you will always be able to handle failures gracefully and not allow one failing microservice to negatively impact the entire ecosystem. By negatively impact, I mean a state where all other microservices are throwing exceptions due to the one errant microservice. Every microservice needs to be able to gracefully handle not being able to complete its task.
• Finally, let's stay flexible and state that our microservice architecture is free to remain fluid and evolutionary.
• No microservice talks directly to another microservice. Communication is always done in the form of messages.

With all that in mind, we've now created our definition of a microservice and its architecture and characteristics. Feel free to adjust these as you or your situation sees fit. Remember, as C# developers we don't always have the luxury, save truly greenfield projects, to dictate all the terms. Do the best you can with the room you have to operate within. As an example, chances are you will have to work with the corporate database and their rules rather than a small siloed database as described earlier. It's still a microservice, so go for it!

Pros and cons

Let's run down some pros and cons of a microservice architecture.

Pros

Here are a few of the positive points of a microservice architecture:

• They give developers the freedom to independently architect, develop, and deploy services
• Microservices can be developed in different languages if permitted
• Easier integration and deployment than traditional monolithic applications and services
• Microservices are organized around specific business capabilities
• When change is required, only the specific microservice needs to be changed and redeployed
• Enhanced fault isolation
• They are easier to scale
• Integration to external services is made easier

Cons

Here are a few negatives when considering a microservice architecture. Please keep in mind that negative does not equal bad, just information that may affect your decision:

• Testing can be more involved
• Duplication of effort and code can occur more often
• Product management could become more complicated
• Developers may have more work when it comes to communications infrastructure
• Memory consumption may increase

Case study

Let's take a look at someone who took a monolithic ...