The Problem with Frameworks
The price you pay with frameworks is abject dependency with its author(s). Not to mention the following:
- Leaky abstraction
Frameworks like Chef, Puppet, Ansible, SaltStack and others all define a specific language (DSL or API) for a particular functionality. Of course, some are extensible but when you hit a dead end, it’s game over. You have to wait for the framework author to build the functionality specific to your use case.
If you are going to design an abstraction, make sure the foundation is sound and solid. A half-hearted effort is worse than nothing at all.
2. Cognitive overload
Frameworks entail massive documentation. You have to wade through pages just to find the solution to your specific need. And worse, there might be API incompatibility among major versions (sigh). If you are familiar with Kathy Sierra (author of Badass: Making Users Awesome), you can relate with her message of saving users from the burden of too much cognitive resources.
3. Corner cases
Because frameworks don’t nail the solid abstraction, you are figuratively building a house on sand. When the storm comes, you are left to pick up the pieces (sigh).
4. Bloated code
Frameworks like go-kit and go-micro suffer from boilerplate code (and boring type assertions). Just ask Olivier Poitrey from Dailymotion. It is not just in Golang. Frameworks abound in all programming languages.
5. Performance problem
Just ask database administrators. They hate ORM because they couldn’t optimize your code when speed is of the essence. Not to mention, ORM is a hindrance as far as visibility instrumentation is concerned.
Is it a coincidence that frameworks are monolithic? Certainly not! It is in their nature to become monolithic because they are trying to solve all use cases. It is the anti-pattern with respect to the ideals being promoted by UNIX Philosophy.
Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. — ALAN KAY
AngularJS, anyone? Oh never mind, we use SAM Pattern and Meiosis with VueJS which are both libraries (not a framework).
7. Multi-purpose or Single-purpose Tool?
It all comes down to UNIX Philosophy regardless if it is software development or operations. If Ansible or SaltStack is your cup of tea, be my guest. But to everyone else, you are better off with single-purpose tool.
Randy Bias puts a damning view about multi-purpose tool in Ceph. Read it here.
8. Somebody’s Mental Model
When you are knee-deep on your problem, it doesn’t mean you reach for quick and dirty tricks. That may solve your problem for now, but technical debt will rear its ugly head in no time. Which is why you need to learn the basics.
This is when you realize the primacy of the problem domain. When you are in a certain situation, you are more knowledgeable than the rest as far as the business domain is concerned. As a developer, you are hired to solve the business problem. The choice of software is just as important but only insofar as it is being used based on its design (aka “use the right tool for the job”).
So what is the fuss about frameworks?
The trouble with frameworks is that, it is somebody else’s abstraction. There is nothing wrong with an abstraction as long as it is a solid abstraction or building blocks. Of course, everyone is entitled to their own opinion and methodology. More often than not, your framework simply solves a particular use case. And even if it attempts to address a broader problem, you are at the mercy of its designers (oh did I hear you say PaaS?)
You see, framework designers take advantage of the economics of knowledge called asymmetry. They know more about a certain domain than you do. It is no different with technology vendors. Granted, the vendor may be backing an open source project. Whether software is open source or not is immaterial.
The fact of the matter is, software of no trivial scale is basically opaque (unless you are one of its contributors).
When you are using a framework (or any infrastructure software for that matter), you are basically buying into their own point of view or methodology.
And that is a recipe for time sink (OpenShift, Deis and all PaaS out there. I’d say build-your-own PaaS for your own use only because your requirements are unique).
It’s like entering into their own world complete with adventures, surprises and idiosyncracies. You have to explore all the nooks and crannies. Hell, you just entered a technology version of spelunking!
But IT is no fantasy island.
Technology is just a tool, not an end.
The goal is to address the business problems as fast and as efficient as possible.
When you use a framework, be prepared for the trade-offs.
Personally, I prefer doing it my way. After all, the business domain is more important than somebody’s take. They may be more experienced and wiser than I am, but at least I know how to construct my Lego bricks or whatever bricks you throw at me (as long as it has the elegance of Golang packages or the like).
- Good things come in small packages (just like in Go)
- Mix and match packages or libraries of your choosing
- Software development is a creative endeavor. Why not strut your stuff?
- You know more than them? Why rely on them? This is not the case of reinventing the wheel or NIH syndrome. It’s the case of imposing your will by using best-of-breed packages.
- Abstraction considered harmful — Tyler Treat
- Anything goes — Paul Feyerabend
- A quick high-level overview of the problems of frameworks here
- Understanding the problem domain is more important than the solution — Isagani Mendoza (that’s me)