Tuesday 8 May 2018

MSIX - First look and my two cents!


Finally, the suspense around MSIX has come to an end! Since its announcement on Windows Developer Day in March; there were many speculations around this new file format (including one by me). I was among very few technology partners who were invited to attend a 2 days packaging summit at Microsoft last week. We got a really detailed first-hand briefing by the MSIX developers. Now that it has been presented at Build2018 yesterday, I am free to write my thoughts on it in the public domain. So, here I am penning down few points which caught my eye along with my 2 cents worth of opinion on where it will be successful and which areas need a little more thought. Let's get started with some good news first.


Learn from your mistakes!

This is a very commonly used statement, but the Windows team has lived up to it. The major difference with this new file format is that MSIX has been designed keeping in mind the learnings from its predecessor's failures (AppX, UWP).  Unlike initial releases of AppX, UWP which were more for the "Ideal world", MSIX is more for the "Real world" applications. AppX and UWP were designed with the perfect rules around security, portability etc. That’s the reason they struggled with the real world business apps. Microsoft’s idea of building highly secure, Apple type of sandboxing failed terribly due to its diverse and vast customer base (as we discussed in my previous post 16 Million Reasons to Fail). Although original AppX standards were more towards security; such a design is of no use if existing apps can't adhere to it. Think of it as a really sophisticated and securely built house; but if people don't have a route to get into it, it's of no use. To get over this hurdle, Microsoft had to compromise on the strict rules over a period of time.

MSIX - Built for Real World Apps (not the Ideal World)

In MSIX, Microsoft took a step back and looked at the bigger picture considering the practicality of imposing such restrictions. This will hugely impact its adoption and that’s why I think it will be a successful format and will be more widely adopted. Based on its initial feature list, I think it will beat AppV as well. I know that I am giving a bold statement; but as I said it’s just my 2 cents worth of opinion!


Features targeted for mass adoption (real world apps)

  • Built for developers as well as IT Pros
  • Enterprise apps have been considered (which were left behind for years)
  • Vast API Surface Area
  • Not tied to Windows Store
  • Not restricted to strict WACK rules
  • Good replacement for MSI custom actions
  • App signing made compulsory (similar to AppX)
  • A good workflow for differential application updates
  • A new way of imposing app customizations
  • Clean uninstall
  • Finally, Microsoft acknowledged that legacy apps are important and can't be left behind! MSIX comes with a framework to migrate apps to latest OS by fixing compatibility issues. In my opinion, this is the feature which will take MSIX ahead of AppV in terms of adoption. My opinion will definitely be worth more than 2 cents on this subject!

MSIX Preview Summary


It's time to get into the technical jargon and try to understand how the above features are being provided by MSIX. I wrote this section based on the slides presented at Build (MSIX Inside and Out)

1) Container Continuum

When UWP was launched, it had a very restricted standard. It wasn't possible to get Win32 apps to this format without heavy code changes. To fill the gap between old win32 apps and UWP, Microsoft introduced Desktop Bridge and diluted the strict rules imposed by original UWP standards. So, Desktop Bridge apps didn't adhere to original UWP standards.
MSIX is bringing these together so that both types of apps fit into the MSIX standards making it adoptable by Win32 apps which couldn't make to UWP standards.

2) Breaking the repackaging chain (packaging paralysis)

In the old world (with MSI, AppV) customizations were done first and then the final package was created. Which means if any customization needs to be changed, the app had to be repackaged again. MSIX is designed to break this chain of repackaging (which costs time and money each time OS or App is updated). 



In the new world, customizations will be done after packaging stage. Hence no need of repackaging again and again. This sounds good, but I am not sure how practical it would be for complicated customizations. Have to try it first, but the design looks good.


3) Modification MSIX and differential updates
This looks like a replacement for MSI custom actions where things went out of control in MSI era. Custom actions was a very powerful MSI feature. But if used irresponsibly, it could be equally harmful; which is what happened with MSI installers. In the new world, applications will be packaged in a separate MSIX container and customizations will be in a separate MSIX container. Say for example the app needs to be updated and customized, then the "modification package" will get updated and not the core app's MSIX package. This will also get rid of the hassle involved in adding customizations and repackaging apps with every update. Again, I can't say anything on this until we see it in use. But as an app can have multiple modification packages, this feature will have to be designed with package deployment prioritization in mind.

4) Other benefits (Disk Space Optimization, Network Optimization)

These are some of the good to have features. Disk Space optimization is where MSIX engine keeps a single copy of the common files shared among different apps. Network optimization involves streaming only the differential updates instead of getting the whole package every time there is an update made to the app. 

5) MSIX for Win7

It will surely be a pain to maintain the same app in two different file formats; one for Win10 and another one for Win7 deployments. It's not clear how MSIX packages would be brought onto Win7 OS. One way to get around this is to use MSIX SDK to wrap MSIX package in MSI wrapper or write a custom script which extracts the contents of the package and copies them onto Win7 machine. But I am totally against these approaches as they defeat the whole purpose of MSIX as none of the core MSIX features (like clean uninstall etc.) will be available. It's like opening a can of worms, where businesses will go back to the MSI era nightmares (with files/regs deployed in random locations, not properly cleaned while uninstalling etc.). It will be a semi-baked MSIX solution for Win7.

Instead of that, wrapping MSIX container in a 3rd party format (like that of Cloudhouse) would carry most of the MSIX's rich features to apps deployed on Win7. It will also be a single package for both Win7 and Win10. I would like to see businesses taking this approach instead of taking the MSI wrapper route. I think this is an area which needs to be thought about.

6) Package Support Framework
This was the missing piece of the puzzle. I am really happy that Microsoft finally realized that legacy apps shouldn't be left behind. Afterall they are the main line of business applications for thousands of enterprises with vulnerable apps left on old and unsupported platforms. This will open the gates for those old apps to be brought to newer, secure platforms. Who would know this better than us? At Cloudhouse, we fix legacy app compatibility issues every day. So, package support framework is a really good initiative in this direction. This is the area where we can use our expertise to help businesses move on to newer platforms and adopt MSIX. I think it will take time for Microsoft to get this right as it needs specific skill set and the learning curve is very steep to fix the tricky legacy apps. It's still a long way to go! 

That's all for now. To summarize, I think MSIX will be successful as it has been built for mass adoption. Please feel free to share your views on this.  I'll write more in detail about fixing app compatibility issues using Package Support Framework and Cloudhouse technologies in my next post in Tech Talk section. Stay tuned!


Priya Saxena.


No comments:

Post a Comment