Created
November 8, 2016 22:41
-
-
Save cfjedimaster/2c8b53ae833728ed9a749895f723fc3c to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Meric - | |
Joe, Erin and I were speaking and we wanted to make sure we were being clear about some of our thoughts in regards to a proposed LB API vs APIC. | |
If you already understand what I'm saying, please forgive us, we just feel it's important to ensure folks understand where we're coming from. | |
You've asked about the capabilities of the APIC CLI vs slc. While I've found that a LB developer *could* make use of the APIC CLI (especially with the modifications I suggested), | |
we want to be clear that our argument for a proper LB CLI is *not* about features. It is about using the *appropriate* tool for the job. | |
APIC is not appropriate for LB developers for two main reasons: | |
a) It is way over powered for what a LB developer needs | |
b) It is a commercial product, and yes, you do not have to pay for it, but amongst developers, this can lead to them avoiding it | |
While obviously we want LB developers to get introduced to APIC and make use of it, having a proper LB CLI gives us a *clear* message to them | |
without "muddying the waters" so to speak with a solution that does 900% more than they need and is not FOSS. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment