Cesar De la Torre

With ML.NET and related NuGet packages for TensorFlow you can currently do the following:

Run/score a pre-trained TensorFlow model: In ML.NET you can load a frozen TensorFlow model .pb file (also called “frozen graph def” which is essentially a serialized graph_def protocol buffer written to disk) and make predictions with it from C# for scenarios like image classification,

As a developer or software architect, you are focused on the application lifecycle – building, maintaining, and continuously updating the end-user business application, as illustrated in the simplified image below:

When you infuse AI (such as an ML.NET model) into your application,

Today, coinciding with //BUILD 2019/ conference, we’re thrilled by launching ML.NET 1.0 release!
You can read the official ML.NET 1.0 release announcement Blog Post here and get started at the ML.NET site here.
In this blog post I’m providing quite a few additional technical details along with my personal vision that you might find interesting,

Context
——
UPDATE on May 13th 2019: The recommended way to deploy/run an ML.NET model into ASP.NET Core web apps or WebAPI services is by using the ‘Microsoft.Extensions.ML’ Integration package. Read about it in this tutorial:
– Deploy an ML.NET model in an ASP.NET Core Web API
The tutorial above uses optimized code based on an .NET Core Integration Package comparable to integration packages targeting Entity Framework,

We’re currently evolving the .NET microservices guidance and eShopOnContainers reference application. One of the most important topics is about the API Gateway pattern, why it is interesting for many microservice-based applications but also, how you can implement it in a .NET Core based microservice application with a deployment based on Docker containers.

Las arquitecturas basadas en Microservicios están emergiendo actualmente como opciones apropiadas para aplicaciones distribuidas de misión crítica.
En una arquitectura basada en microservicios, la aplicación se construye basada en una colección de servicios que deben ser desarrollados, probados, versionados y desplegados en producción,

Background tasks and scheduled jobs are something you might need to implement, eventually, in a microservice based application or in any kind of application. The difference when using a microservices architecture is that you can implement a single microservice process/container for hosting these background tasks so you can scale it down/up as you need or you can even make sure that it runs a single instance of that microservice process/container.

************************** NOTE ************************
This blog post is a replica of the same blog post I just published at the official Microsoft .NET Blog, here:
https://blogs.msdn.microsoft.com/dotnet/2017/11/01/modernize-existing-net-apps-with-windows-containers-and-azure/
********************************************************
As part of the series of posts announced at this initial blog post (.NET Application Architecture Guidance) that explores each of the architecture areas currently covered by our team, 

Explore DDD 2017 is a brand-new Domain-Driven Design (DDD)-centric conference, September 19-22 2017 at the Grand Hyatt hotel, in downtown Denver, Colorado, USA.

I’m not directly related to this conference, but I wanted to provide some support/awareness because this type of quality events is fundamental for the development and software architecture community.

The microservices architecture is emerging as an important approach for distributed mission-critical applications. In a microservice-based architecture, the application is built on a collection of services that can be developed, tested, deployed, and versioned independently. In addition, enterprises are increasingly realizing cost savings,