This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
This is the third post of a series. In the first post (WIN AN EBOOK - Hands-On Microservices with C# 8 and .NET Core 3) , Ed Price announced the survey*. And in the FlixOne Bookstore Journey, Gaurav explains the sample and scenario. (Click here to enter the contest.)
Gaurav and Ed just published a book on microservices in a .NET Core world. I did the tech review on the book so I've already had the pleasure of reading it :)
Reviewing a book gives you some insight into how much work is required for writing a book, and covering microservices is a topic you can write extensively about. My part in the book's making primarily required me to read a lot, which is less hard than writing it all. You face different challenges though - if a reader catches a glaringly obvious bug in the code they may very well complain "what kind of blind reviewer let this pass" so I had to put some effort into scrutinizing the text :) (If there are obvious bugs there still I will assume they were inserted after the pages passed my eyes.)
You should read all the chapters in order to get a feeling of the multiple facets required for being successful with microservices. But how do you get an actual real life feeling for it all (apart from the sample code)?
Some of the aspects with microservices are, let's be honest, in the theoretical department. Of course, this could be said about programming in general and dependent on what your role in it is as well. If you are the solution architect for a new platform that should be able to handle millions of users you will have different concerns than a developer trying to figure out why a given unit test is failing. Correspondingly it's hard to figure out the path when someone says "lets rebuild our web platform into a non-monolithic microservices based architecture".
How do you know if Service Fabric or Kubernetes is right for you? Should you implement the ambassador or sidecar pattern? And getting down to the nitty gritty - should you use Linux or Windows containers?
This book will obviously not be able to give you all the digested answers for what fits into your specific use case, but it should give you a background for reflecting upon some of these things.
Looping back to my own question on how to get a feel for this - is there any specific area to start with? As a consultant, my default answer is usually "it depends" (let's bill a couple of hours before getting to actual business right), but I'll provide an example (free of charge)...
"Oh great, like we haven't been able to hook up some REST HTTP conversations in recent years." I'm pretty sure most devs have been consuming APIs for a while now. But there could be things you haven't dug into yet. Take for instance the "ASP .NET Core Web Application" template in Visual Studio 2019. You have a couple different options (MVC, Razor Pages, etc.), but even if you tick off the box for Docker Support you essentially have something that tries to lead you to build a monolith.
I'm not saying it's bad code. It's actually great that you can have a basic "Hello World" type web app up in a couple of seconds. It's not a bad starting point for other things further down the line either.
So you start adapting the boilerplate to your needs, and then it strikes you that maybe you want to separate the backend (API) and the frontend (UI). This means that you should be thinking about something like what makes a good microservice. You probably want to split the API and the UI into different projects.
Ok, you run the Project Creation wizard again and have a separate API project. Are there more things to think about? Well, most API calls will be read-only, but there will be some write actions with complicated logic for validation before persisting. For the read-only part you should probably look into having a caching mechanism. Should you do separate services for reading and writing? What is the proper size of a microservice?
So now you have two microservices for the API. But how about accessing them? It would look sort of silly if you told the frontend guy that there are separate URLs for reading and writing. So maybe you need an API Gateway to put in front. Many APIs, possible multiple gateways - sounds like this will be quite the management task. Which is why we have API Management.
The book goes over the examples, which are available on the book's GitHub repo:
Let's call the backend sorted then and talk frontend. You need HTML/CSS/JS to do this, and doing autoscaling to fit different screen resolutions is easy enough. But you've been thinking that on mobile devices it might be even better to create a native app. You could wrap the regular web view, but you want to optimize data traffic. There are actions you just don't need to do on a mobile so you sort of feel like you need a separate API for the mobile app. Have you looked into the backends for frontends pattern?
Right, we have a number of APIs and a number of microservices. You get that this is where you suit up for Introducing Docker and deploy your services. Is this also the time to look into how you can wrangle all these services and look into Azure Service Fabric and Azure Kubernetes Service?
The above scenario reads more like a thought experiment than a recipe - I get that. Thing is it should be something you can start playing with without designing a fancy system first. You can mock both the reading and writing part of the API, and if you don't actually know how to build a mobile app you can fake that too. Not every buzzword I dropped was directly related to APIs, but you should be able to see how it is a lot to explore in that area. The terms in bold italics are ripped right from the Table of Contents for Gaurav and Ed's book.
Did I mention you can win a copy?
Here is the link to the survey* again.
* Please take a few minutes to complete our survey. Please ensure you are authorized to provide this information and not violating any company policies. Your responses will be kept confidential with restricted access. For more information, see the Microsoft Privacy Statement. If you have questions about this survey, please contact TechCommunity@microsoft.com.