First published on MSDN on Jul 16, 2018
Today is a big day for Service Fabric! First, we're excited to announce the public preview of Azure Service Fabric Mesh, the fully-managed Service Fabric hosted environment where you can deploy containerized Service Fabric applications without any infrastructure or VMs to manage. You can read more about that
announcement on the Azure blog.
We're also excited to announce the 6.3 release of the Service Fabric runtime along with tooling and SDK updates. Many of the new innovations and features in Service Fabric Mesh are actually built into the core Service Fabric runtime. This ensures that the applications you build are portable across any environment that runs Service Fabric. The different Service Fabric environments are your local machine, on-premise clusters, Azure clusters, and Service Fabric Mesh. So in addition to the usual bug fixes and performance improvements, with the 6.3 release you can now start exploring some of these exciting new features.
A simpler way to build applications
This release is the starting point of a new way to build Service Fabric applications that's simpler and more portable than ever before. Dubbed
Service Fabric Mesh Applications
, this new way of building applications for Service Fabric is based on the concept of individually-deployable
resources
where you specify your application and service definition, and any additional components or infrastructure pieces that are used by your applications and services, such as networks, volumes, and secrets.
A resource describes how something should run. For example, a service resource describes the name of one or more container images to run, how many copies of the image to run, environment variables, CPU and memory allocation, and references to other resources, like networks and volumes.
Many of the Service Fabric concepts you're familiar with today still exist when deploying resources. For example, applications are still groups of services that are deployed and upgraded together, and services are still made up of code packages, which are groups of containers that are always placed and activated together. However, a number of things have been drastically simplified. Here is just a taste of some of the things that'll make Service Fabric a friendlier place to run your applications.
Unified application development
Service Fabric applications described by resources are drastically simpler than before, because a service resource
only
describes how to run container images. Rather than having to decide up front if your service should be a Guest Executable, Guest Container, Reliable Service, or Reliable Actor and getting a slightly different experience with each one, you can now use any language or framework you want and get a consistent experience. We feel it's particularly important for polyglot teams that use multiple different languages to all feel right at home on Service Fabric.
Composition over inheritance
Of course, the Service Fabric platform has a lot to offer beyond just running some containers, and so Service Fabric APIs will still be available for your applications to get the most out of the advanced distributed systems Service Fabric has to offer. But instead of having to write Service Fabric-specific applications, you'll be able to write applications any way you want, including using existing frameworks like ASP.NET Core or Spring, and simply import Service Fabric libraries to get access to Reliable Collections and Service Fabric APIs.
Types and instances
Service Fabric has a concept of provisioning service
types
, similar to defining a class in an object-oriented language, and then programmatically creating
instances
from those provisioned types, like instantiating an object from a class. This is particularly useful when your services are not packaged inside containers, as you need a way to safely provision and version your application binaries. Service resources are much simpler as they only describe container images, and so the
type
concept no longer exists in the resource model. Instead, the service resource declaratively describes how to run an instance of your service in a simple YAML or JSON format. This allows you to easily reuse and automate the deployment of service instances and skips the provisioning step altogether.
Manifests will live on
The Application Manifest and Service Manifest XML format you're used to isn't going anywhere and will continue to be supported. This is the "native" Service Fabric format, and so we're referring to applications written this way as
Service Fabric Native Applications
. This is where you get access to all the low-level power of the platform, with complete control and flexibility over your application and cluster. However, because of the amount of control offered at this level, Service Fabric Native Applications will not be supported in the Service Fabric Mesh environment.
What's next
This release lays down the foundation for applications based on resources. This release includes an HTTP API that allows you to create, update, and delete resources anywhere Service Fabric runs. Over the next few releases, we will be introducing support for more types of resources in Service Fabric clusters, as well as a complete development and management experience with CLI, PowerShell, Visual Studio 2017, and Visual Studio Code. Lastly, we understand that with a release such as this, terminology and support questions are plenty. Therefore, to get an overview of the new terminology and the support for tooling and programming models in the different environments, please visit the
Service Fabric Mesh terminology
documentation.
And last but not least, the full release notes with a complete list of bug fixes and changes for the 6.3 runtime are available here:
Microsoft-Azure-Service-Fabric-Release-Notes-SDK-3.2-Runtime-6.3.
Useful Links
All the best,
The Service Fabric Team
