This post is not going to introduce what MinRole in SharePoint 2016 is. You are better to get it from massive number of articles written by SharePoint experts in the community. Personally MinRole is only helpful to those who are not familiar with designing and administering medium to large farm. When Microsoft says “Hey you only need to select the role this server is going to play!” then you feel like you are going to be an unoccupied SharePoint administrator perhaps because MinRole is your friend, giving you advise on compliance from the farm management perspective. The description made by Microsoft sounds so straightforward that SharePoint farm architect can just select without really understanding and planning their farms. There is not any article which deeply tells you how SharePoint processes each role in MinRole mode behind the scene.
Today I installed and deployed my SharePoint 2016 farm for my demonstration at ExpertsLive Asia Pacific 2017 conference which will be held on the next Tuesday. Of course MinRole is used along with Shared Role mode. This time I think I would need to write even just a little bit regarding Application role that I believe it’s acting like front-end role.
If you ever read my post on how to determine any web front-end servers in your farm, you surely know SharePoint Foundation Web Application service is the sign. If this service is run on a server, this server must be playing as a front-end server. Do a test by stop this service and open ULS to see what is unprovisioned by SharePoint Timer services. There is not a difference in terms of how SharePoint Foundation Web Application service works in SharePoint Server 2016. If there is, I can’t seem to find anywhere in the world of Internet. Perhaps this is confidential information classified at Microsoft. If you build a multi-server farm using MinRole, you realize that this service is still associated with Application role or Application with Search (in Shared Role mode).
Every time when you create a new web application, IIS websites accordingly are automatically provisioned on every server where Microsoft SharePoint Foundation Web Application service is running. And if you deploy your custom solution WSP package, SharePoint timer service will extract and deploy artifact and source file to such a server. You can’t just tune your application-called role by just stopping the service because MinRole mode does not allow you to do so. You must convert to Custom role before you can stop and start service like you do typically in SharePoint 2013 during your SharePoint life.
The only way to ensure is to control incoming request to which server running Microsoft SharePoint Foundation Web Application service. This can be done via load balancer, reverse proxy or a custom HTTP module. Unless incoming request is still routed to your Application server role in MinRole.
Finally, I do recommend you to still plan what services you need to run on which server. It’s better for you to manage and serve your end user. I don’t personally see MinRole benefit in SharePoint Server 2016, but at least when I meet my customer, I will give them an introduction.
And again, please carefully read my post to identify your actual front-end server: Determine your Web front-end server