<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Service-Fabric on Cloudinthealps</title><link>https://cloudinthealps.mandin.net/tags/service-fabric/</link><description>Recent content in Service-Fabric on Cloudinthealps</description><generator>Hugo</generator><language>fr-FR</language><lastBuildDate>Wed, 15 Feb 2017 00:00:00 +0000</lastBuildDate><atom:link href="https://cloudinthealps.mandin.net/tags/service-fabric/index.xml" rel="self" type="application/rss+xml"/><item><title>Containers, Azure and Service Fabric</title><link>https://cloudinthealps.mandin.net/posts/containers-azure-and-service-fabric/</link><pubDate>Wed, 15 Feb 2017 00:00:00 +0000</pubDate><guid>https://cloudinthealps.mandin.net/posts/containers-azure-and-service-fabric/</guid><description>&lt;p&gt;Today I will try to gather some explanations about containers, how they are implemented or used on Azure, and how
this all relates to micro-services and Azure Service Fabric.
First let&amp;rsquo;s share some basic knowledge and definitions.
Containers in a nutshell
To make a very long story short, a container is a higher level virtual machine. You just pack your application and its
dependencies in it, and let it run.
The good thing about those is that you do not have to pack the whole underlying OS in there. This gives us lightweight
packages, which could be around 50MB for a web server for example. Originally, containers were designed to be
stateless. You were supposed to keep permanent data out of those, and be able to spin out as many instances of your
applications to run in parallel, without having to bother about data.
This is not completely true about most deployments. Today many containers are used as lightweight virtual machines, to
run multiple identical services, each with its instance.
For example, if you need a monitoring poller for each new customer you have, you might package this in a container and
run one instance for each client, where you just have to configure the specifics for this client. It&amp;rsquo;s simple, modular and
quick. The stateless versus stateful containers is a long standing one, see [link to statefull vs stateless]
Orchestration
Just like in virtualization, the case is mostly not about the container technology and limits, but rather about the tools to
orchestrate that. Vmware vCenter versus Microsoft SCVMM anyone?
You may run containers manually above Linux or Windows, with some limitations, but the point is not to have a single
OS instance running several services. The point is to have a framework where you can integrate that container and
instantiate it without having to tinker with all the details : high-availability, load-balancing, registration into a
catalog/registry etc. The video below is very good at explaining that :
The Illustrated Children&amp;rsquo;s Guide to Kubernetes&lt;/p&gt;</description></item></channel></rss>