If every team attempting to do THE-METHOD were to use the approach of building MBM then we would end up with hundreds of MBM. This seems wasteful and redundant. Perhaps this is why we’ve not heard of such a tool. I have another perspective about this. Let’s explore it.
The MBM’s purpose is to make building the machine easier, faster, more reliable, with higher quality. The businesses we all work for, and who fund the work, don’t work in the MBM business. From both a business perspective and a funding perspective, building that machine that builds the machine is a tough sell.
In the story I told at the beginning of the MBM article about when I built the form builder, I left one part out. I had done my work in “stealth-mode.” When people realized what I had been doing they freaked out. I got calls from “management” telling me that this is not the work we were paid to be doing. Why was I “wasting my time” and “the clients money” doing this. To be honest, the reason I hadn’t told anyone about the nature of my work was that I was certain I could accomplish it and I was also certain that everyone would freak out. I did accomplish it and when they found out they did freak out.
This story is an important part of the context for the MBM. Modern teams probably shouldn’t do this work in “stealth-mode.” The efforts and timeframe of meaningful work are too big. But getting pre-approval for this sort of work is challenging.
What might be easier is finding some technology or library that already fits the bill for the MBM. iDesign’s ServiceModelEx already does this for WCF. MS has abandoned WCF in favor of .NET Core and gRPC but in doing so they have also abandoned much of SOA (Service-Oriented Architecture). gRPC is specifically a web technology. SOA is specifically a set of service technologies. Not all services run via web protocols, so a lot got dropped when MS gave up on WCF.
Still, we may be able to find technologies that help us build the MBM. Specifically, we might find something already built that we can use. Both Monty and Juval constantly mention “mesh” networks but they never seem to follow up with specific technology recommendations. I get the impression that they are both waiting on the release of a product that does not yet exist.
The SOA weakness of gRPC is that it only speaks web. It doesn’t (easily) speak message, queued-message, SMTP, named-pipes, FTP, or any number of custom protocols. This sounds like nitpicking but there’s a dilemma here. This lack of protocols is rarely important at the beginning of a SOA effort. But as your services become more successful the desire to use those services and automate them across a wider and wider array of technologies grows. The web may have satisfied an early requirement but what will happened when you bring in mobile, offline, store-and-forward, inter-business-communications, and more? Look at the complexity involved in simply providing two-way messaging to SPA apps in a browser. It’s nuts that this problem has not been solved. WebComponents move us forward but OMG this process is slow. The web, as a technology platform, moves glacially.
Name a general purpose technology that takes an algorithm and make it a service that is protocol independent and allows these “remote-methods” to be grouped logically (perhaps with a shared context made possible by the grouping)? ServiceFabric, WCF, and some container services are attempting to solve this problem but they sure don’t seem like they’re working for us.
Remember what it felt like when you realized that an MVC framework allowed you to instantly put a method on the web? It was like magic. Then remember when you realized you had to deploy an entire server (getting charged outrageous cloud fees every second of the day) just to put that method on the web? That’s basically the current state of instant services.
MS/Azure is trying to solve the service mesh problem with layering services on top of containers the way that MVC solved web-methods by layering web-methods on top of web servers. You’ve automated the fly-swatter by tapping it to a bazooka. It’s not only overkill, it’s overkill to the degree that it kills the original idea. It works, but at what cost?
Epilogue-Sidebar: You might be asking yourself why Microsoft never built MVC directly into Azure. Or you might be shouting at the screen to tell me they did with Azure Functions. Honestly, I was super excited to find and use Azure Functions but as a service/web-method replacement they had a few problems that an MVC application does not have. There is no way to group the units of behavior. We need this. There is no way to share a context. We need this, and to be enterprise ready this context would need to include logging and security. Scaling would need to be at the group level, not the method level (or both). Ironically, ServiceFabric solves all these problems but does not (easily) expose it’s methods as web-methods. Sigh.
As far as I can tell, the only technology that has solved this problem is the combination of WCF and ServiceModelEx. I personally discovered this practically on the day that MS announced they were abandoning WCF.
You are not working on the MBM because you feel it is a platform responsibility that someone like MS should be working on. The platform vendors like MS are not working on it because they don’t feel you/we are sophisticated enough to use it if they built it into the platform. Sadly this is fait accompli. When SOA was built into WCF it went largely unused. ServiceFabric is both hamstrung and undersold. To date the most popular “service models” have been the MVC platforms (RoR, ASP.NET MVC, Spring/Java). I believe that AWS has similar issues. While they arguably have the better services model they have no language platform within which to distribute an SDK. To butcher a metaphor, AWS is a chicken that can’t lay eggs.
Coming full circle we discover the dilemma. YOU are going to have to build the MBM. The platform providers have built these tools for themselves but have no incentives to provide them to us as part of their platforms. WCF was deprecated years ago. I doubt it will have an obvious replacement on the 10th anniversary of it’s demise. No, YOU are going to have to build your MBM.
