Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
posted by martyb on Friday March 16 2018, @01:07PM   Printer-friendly
from the Come-on-into-the-azure-waters dept.

On 14 March 2018, Microsoft announced that it was open sourcing its Azure Service Fabric.

The Azure Service Fabric is a distributed application platform which aids in deploying microservices, highly available applications and containers on the Azure cloud (someone else's, in this case, Microsoft, servers) platform.

The announcement (via a blog post from the Microsoft Service Fabric Team) states:

At this point we have the Service Fabric repo up on GitHub with Linux build and test tools, which means you can clone the repo, build Service Fabric for Linux, run basic tests, open issues, and submit pull requests. We're working hard to get the Windows build environment migrated over as well, along with a complete CI environment.

[...] For now, you can compile and test Service Fabric for Linux, everything from the low-level clustering and federation layers all the way up to process and container activation. We are also opening it up for contributions, albeit at a limited pace as we work on moving everything out into the open.

The github repo main page gives current status on the open sourcing process:

Quick look at our current status

  • Service Fabric build tools for Linux
  • Basic tests for Linux builds available
  • Container image with build tools available to run builds

Currently in progress

  • Build tools for Windows
  • Improve dependency consumption process
  • Automated CI environment
  • Migrate complete test infrastructure

Clearly this is an attempt by Microsoft to engage developers in using/developing applications/containers/microservices for the Azure cloud. From the standpoint of getting more folks involved in development of the platform, It's probably not a bad idea for them as they attempt to increase market share.

It still remains to be seen how receptive Microsoft will be to feature additions and bug fixes and whether or not they will allow non-MS blessed changes to actually run on Azure.

So what's the upside (if any) here for Soylentils?

Does this action by Microsoft make those of you who use (and/or consider using) other cloud (AWS/Google/etc.) platforms for PaaS, containers, microservices, etc. more interested in using the Azure platform?

Are there any advantages to this over tools available from other cloud providers? Is Microsoft just playing catch up?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Saturday March 17 2018, @11:53PM (1 child)

    by Anonymous Coward on Saturday March 17 2018, @11:53PM (#654278)

    In the announcement, Microsoft call this software their "secret sauce for large scale distributed applications." They've released it under a permissive license. They say that it's already in use "outside of Microsoft," which I take to mean outside of the Azure service. Couldn't any cloud service provider now adopt Azure Service Fabric? Then when someone creates a new cloud application, even if they intend to have that other provider host it initially, they might design it to use Azure Service Fabric, so they would have the option of readily moving it to Azure if that became advantageous. Microsoft isn't the biggest CSP, Amazon Web Services is. Enabling users to move freely between providers could be in Microsoft's interest: it has more customers to gain than it has to lose.

    Microsoft isn't just a CSP: it sells the Windows operating system too. Google Compute Engine didn't initially offer Windows (it does now). By releasing Azure Service Fabric, Microsoft disincentivizes the development of competing frameworks in which Windows is excluded or is an afterthought. So long as Microsoft guides the development of Azure Service Fabric, I expect Windows to have first-class support. If Azure Service Fabric is forked, the fork will start out having support for Windows.

  • (Score: 2) by NotSanguine on Sunday March 18 2018, @01:00AM

    In the announcement, Microsoft call this software their "secret sauce for large scale distributed applications." They've released it under a permissive license. They say that it's already in use "outside of Microsoft," which I take to mean outside of the Azure service. Couldn't any cloud service provider now adopt Azure Service Fabric? Then when someone creates a new cloud application, even if they intend to have that other provider host it initially, they might design it to use Azure Service Fabric, so they would have the option of readily moving it to Azure if that became advantageous. Microsoft isn't the biggest CSP, Amazon Web Services is. Enabling users to move freely between providers could be in Microsoft's interest: it has more customers to gain than it has to lose.

    Microsoft isn't just a CSP: it sells the Windows operating system too. Google Compute Engine didn't initially offer Windows (it does now). By releasing Azure Service Fabric, Microsoft disincentivizes the development of competing frameworks in which Windows is excluded or is an afterthought. So long as Microsoft guides the development of Azure Service Fabric, I expect Windows to have first-class support. If Azure Service Fabric is forked, the fork will start out having support for Windows.

    Interesting points. Which touch upon a couple of things I was curious about. I don't use cloud instances (I did get a free one from Amazon last year to do some external testing on a new firewall I'd installed) and have no use for application services or containerized stuff on other people's servers as I do that internally.

    I haven't delved too deeply into what's available, but IIUC, there are pieces (especially WRT to microservices and high-availability) which can only be utilized on Azure.

    Interestingly, the initial roll out on Github *only* supports Linux-based containers/platforms/app services. This is likely because the Linux stuff was mostly done both recently and in a more open-source (if you want to integrate kernel modules quickly and with a minimum of fuss, using FOSS frameworks makes a lot of sense) fashion.

    It will be interesting to see how long it takes MS to release source code for the Windows support of the service fabric.

    As I mentioned in TFS, this is clearly a move by MS to make Azure more attractive to developers/implementors.

    I'm not active in that particular field (cloud-based containerization/high-availability/microservices design and implementation), so I was curious as to what tools were available on other platforms and how they stacked up against MS.

    It will be very interesting to see how interested MS is in incorporating new features/use cases/bug fixes and/or device support into their code. That's not as irrelevant as you might think, in that (IIUC) the service fabric software *requires* components of the Azure platform that haven't been open-sourced. As such, any fork would need to be blessed by MS or it just won't run on the only platform that supports it.

    Contrariwise, other CSPs might seize on this as an opportunity to be an alternative to Azure (possibly even to "Embrace, extend, extinguish" [wikipedia.org]) by supporting not only the canonical MS service fabric, but also any forks and, eventually their own incompatible versions.

    As I intimated in TFS, I wouldn't be surprised if this was MS playing catch up with its competitors (it wouldn't be the first time) and attempting to differentiate its CSP business from its software business.

    I guess we'll just have to see.

    --
    No, no, you're not thinking; you're just being logical. --Niels Bohr