{{announcement.body}}
{{announcement.title}}

OS Framework Selection: The Seven Sins Of Vendor Lock-in With Frameworks

DZone 's Guide to

OS Framework Selection: The Seven Sins Of Vendor Lock-in With Frameworks

Learn more about the seven deadly sins of framework vendor lock-in.

· Open Source Zone ·
Free Resource

7's on slot machine

Learn more about the seven deadly sins of framework vendor lock-in.

When selecting frameworks, both open-source and enterprise software, there is always a risk of vendor lock-in.

Frameworks are easy to add, but they can be hard to remove. And some frameworks are more difficult than others; it can take a special effort to secure their place inside your codebase, and be nearly impossible to remove later. This is the kind of framework you should try to avoid.

All frameworks have some sort of vendor lock-in. It's the extent of the lock-in that matters. To learn more, read Lock-In: Let Me Count the Ways

During selection, you should estimate the degree of vendor lock-in of a framework. Will getting rid of it, later on, be impossible, difficult, or easy?

Replacement always takes effort. For example, SQL databases may as well be the best-standardized frameworks in the world, but to replace one, you always need to make modifications and run an import/export script. It is never as easy as changing a light bulb. All have unique features, language dialects, and differences in field primitives, DateTime limits, error handling, and blob lengths, to name a few.

These are the seven sins of vendor lock-in that you should always watch out for:

  1. Intrusiveness
  2. Vendor geopolitics
  3. Vendor champions
  4. Unnecessary languages
  5. Service plugging
  6. Cloud sales
  7. Immersiveness

#1: Intrusiveness

Intrusiveness is the most common and ugly form of vendor lock-in, and selecting an intrusive framework should be a major "no" unless there is no other option.

How to Detect Intrusiveness Fast

The first sign of intrusiveness can be found in your gut feeling as you read the documentation. Do you sense complacency, absoluteness, arrogance, and/or über-hipness? Those are immediate signs of intrusiveness.

Also, be alert when frameworks use Freudian superlatives like "Awesome", "Definitive", and "Final" in their product name or tagline.

Concrete Ways to Spot Intrusiveness

Here are some other things to look out for in the documentation:

  • Claims one-letter global variables like g , Z , $, or _
  • Claims exclusive control of a standard object in another environment
  • Claims global or shared namespaces or not use name_prefixes.
  • Claims commonly used keywords or names
  • Forces your web application into using their URL structure
  • Claims well-known TCP/IP port numbers exclusively
  • Takes control of a resource, data, or functionality you need to control yourself
  • Takes control of a standard directory such as /tmp or ~
  • Model View Control in name only; on the lower level, these are tightly entangled
  • Documentation boldly states incompatibility with certain software
  • Claims the entire HTTP document root and points you to the places where they allow you to do your work, instead of the other way around
  • Multi-tenant use is impossible; certain data is hardcoded to be one single space
  • Pre-defined field names only, forcing you to use wrong fields names for your data
  • Assume no similar framework or technology will ever be used in the same space

Why Is Intrusiveness So Dangerous?

While this may seem like a concept too small to worry about, frameworks that are intrusive can break other frameworks at any upgrade or install at any time in the future. This will force you to make big and hasty repairs because two frameworks block each other out. That is never a good thing.

Intrusiveness is a design issue.
It could have been avoided if the maker wanted to.

#2: Vendor Geopolitics

All businesses try to make it easy to enter and hard to leave. But software giants sometimes take this principle to the next level, where it becomes a whole new ballgame.

Vendor geopolitics are power strategies to use the community against the competition, locking developers users down to ultimately lock out a competitor.

Let's take an old example: the Great Browser War of the early 2000s. There was JScript, an incompatible version of JavaScript, which was meant to lock developers in on a browser from a certain brand and operating system. Therefore, it locked end-users too, as JScript-using sites failed on other browsers.

The goal was for the public to stop using competing browsers because "sites are always broken on that one." The giant was nice enough to "help" the public with "best viewed with" badges that developers were expected to put on the sites they built to suggest what browser to use if the site looks broken.

So, the vendor rewarded its self-created incompatibility with free ads for their own browser to make the public perceive it as the "standard" browser. Cunning and shrewd. Later, the EU fined them for $731M for this affair, which was 3.3 percent of their net profit (source and source). 

You should be on the lookout for signs that you might be getting caught up in geopolitics:

  • Not supporting a relevant and obvious open standard
  • The framework can only be used if you adopt their much bigger ecosystem or language
  • Competing for hardware or operating system restrictions
  • Vendor-specific variation or dialect that deviates from the known open standard
  • Choosing them forces you to say goodbye to something else
  • Exponential pricing for scaled-up use
  • Marketing suggesting incompatibility with a standard is a new standard

Geopolitics might be irrelevant because "the other continent" is nonexistent in your situation. But you should understand the strategy used before you can judge whether it is a problem for you or not.

Being locked down to a big vendor is a treacherous one: It appears too far-fetched to worry about, and it may take years to take effect, but when it does, the price is high.

#3: Vendor Champions

Big vendors often set up frameworks so that they are part of an entire suite of products; if you choose a framework of that vendor, you get an entire chain reaction of other products that depend on it that you need to use as well, or else it does not work.

Such vendors offer a wide range of products and solutions for every programming challenge in the universe, so in their eyes, you have no real need to do go outside the bubble.

In theory, you could use frameworks of other brands instead, but no one ever tested it. In practice, disloyalty is punished by having to tinker endlessly before it finally works, and the tiniest changes break everything again, making you go through a tinkering cycle for each upgrade, constantly regretting your infidelity.

And if that champion obsoletes, you obsolete with it, because everything you made is based on their frameworks. Your innovation capability is limited to what your vendor champion has to offer.

#4: Unnecessary Languages

If a framework does things fundamentally different, it makes sense to make a new language to express its full potential.

But sometimes, framework vendors introduce their own programming or control language for no other reason than making it hard to move to the competition. The framework itself does nothing so different that a language adds value. You'll recognize it when you see it.

#5: Service Plugging

Commercial frameworks, open-source or enterprise, often make their money off of professional services. That's fine, something has to pay the bills. Just make sure it isn't set up so that you get nothing done without bringing in their consultants time and time again.

A tell-tale sign is that the API has a very murky structure, like hundreds of functions sorted by the alphabet and many functions with very similar names without explaining the difference. Or explicitly undocumented, advanced features, such as:

The FFGGHH module is very advanced. Seek advice from our consultants for assistance.

Which is IT-speak for:

The FFGGHH module is full of bugs and we're not going tell you so that you keep needing our consultants to make workarounds for you. If we'd document it, you could fix it yourself, or you'd dismiss us for poor quality.

If you only need their consultants to get it to work, fine... sort of. But with some business insight, vendors aim for a recurring dependency. Even if you don't mind the fees, the price you pay is being in a constant state of waiting and begging for the availability of their consultants, trashing your release schedules and breaking promises to customers. You pay them a lot, and all they do for you is keeping an unhealthy circle intact.

6: Cloud Services With No Data Portability

With cloud services, a lack of portability is a specific vendor lock-in tactic.

Cloud frameworks that store your data in their cloud, but no proper API to get it out again, are a big no

Whatever framework you choose, if it stores data, that data must be reachable and portable at all times. When investigating a cloud solution API, you must be able to find calls to fetch your data in a machine-readable format with perpetual, unique IDs.

Alarm bells should already ring with hipster-appealing talk about joining the community, our API is a breeze, hip cartoons, but no clear mention of data portability if you go look for it in the documentation.

Such frameworks belong on the dismiss list.

#7: Immersive Frameworks

Immersive means a framework wants you to do everything their way, you have to completely "immerse" yourself in their approach, or else it doesn't work.

Mind the difference:

  • Intrusive frameworks claim namespace and thwart other frameworks' functioning
  • Immersive wants you to do everything their way, no way around it

The combination happens too, and it's evil.

Also, keep in mind the difference between vendor champions: A vendor champion is many frameworks for everything, and an immersive framework is one framework for everything.

Often, it's easy to recognize immersive early by how they communicate their vision, which boils down to:

"I am the sun, and you are the little planets."

Often, literally, we see this with a block diagram like this:

How immersive frameworks present themselves

How immersive frameworks present themselves

Then, in practice, you will become a little planet indeed; you'll be running in circles around the almighty sun. Nothing can happen without going through the framework. You will have to adapt the rest of your world to keep the immersive framework running.

Technical Traits of Immersive Frameworks

Usually, the framework dictates the superstructure of your application, and designates you a place to put your code: /* your code goes here */

Server-side frameworks dictate the file structure of your application; they tell you where to put which code, and where to put data, and the bare existence of code folders in certain places often has a meaning too.

In web applications, immersive frameworks often claim ownership of the entire DOM tree or the entire document root of httpd or whatever is the central resource in your world.

How Does Immersive Turn Evil?

Immersive frameworks are rooted in an elegant principle for a concrete problem, and the wrongdoing lies in applying that elegant principle to everything else.

Usually, version 1.0 of an immersive framework is elegant and simple, yet powerful. Later, the real-world pop their head around the corner. The wishes of the world are way too diverse to fulfill them all by one principle. To keep up the elegance, the framework must come with solutions for many problems that are far away from the original goal or scope.

This has serious consequences:

  • The framework becomes bloatware, full of half-baked solutions for everything
  • As a developer, you are constantly confined by leftover limitations
  • Your attempts to innovate by adding new frameworks cause technical conflicts
  • It is easier to stay on the immersive platform than to battle those conflicts
  • You have no choice but to live with the framework's limitations
  • You obsolete along with them

As a result, immersive frameworks take away your options to innovate.

The wrongdoing lies in not having built-in options to fence the area where the framework does its work, and outside the fence, let other frameworks to theirs.

Don't get me wrong, frameworks based on an elegant principle are good and there should be more of them.

How to Spot Well-Behaved, Non-Immersive Frameworks

In general, I prefer frameworks that take full advantage of sticking to their elegant principle, without making themselves immersive: you decide on its work area, and it has ways to bypass its elegant principle where it would only make things needlessly complex.

You Can Use it Where You Want

The framework explicitly avoids a rigid place where for your code files, or where in the code files you may put your stuff. Or, offers an easy, pretty and logical way to tell the framework where its code tree begins, without using a global variable.

Look for the Hook

For the API calls that risk complexity growth and need to perform well under high load, you should look for "hooks": pass a function pointer, function object, or another piece of code, to do whatever crazy stuff you want that doesn't belong in that framework so that the actual API call stays simple.

You might have to dive deep in the API to find it or text-search the API documentation for words like "callback", "hook", "patch".

I admit hooks don't make pretty code, but in the end, immersive code gets way uglier.

Look for Extendible Parameter APIs

To me, the most preferred way to handle the hard parts of an API is an extendible input control, for example, an extendable JSON string or free-order optional parameters (like the kwargs in Python and R), or an on-the-fly created object structure or function that you can pass. Then, both you and the framework developer are free to extend whatever you like, and "regular" use stays simple and clean.

The price you pay is some parse overhead.

But the mere fact of offering extendible parameter structures is a good sign. The framework developers were realistic and acknowledged that even the richest control set cannot cover every imaginable use case. They wisely chose not to burden the many with the needs of the few and keep the framework focused on what it does best.

Conclusion

When selecting frameworks, avoid the seven sins of vendor lock-in. Replacing a framework without is hard enough already. Instead, select frameworks with a narrow purpose, a modest scope, and that offer ample extendibility for the more complex use cases.

Further Reading

Lock-In: Let Me Count the Ways

Five Things That Can Go Wrong With Vendor Lock-In

Topics:
framework ,vendor lock-in ,vendor lock in ,frameworks compare ,frameworks ,open source ,open source cloud ,portability ,open source framework ,vendor checklist

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}