-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the INV wiki!
Inv stands for "Intertwined Network Valuables". Implemented in Groovy, it allows connecting all your operating systems, middleware, applications and tools together. These are Network Valuables.
At the current pace of new tools and frameworks releases, there's always a gap between your existing infrastructure and what's the new trendy thing out there. Obviously, rewriting your whole ecosystem is not always (and rarely) a good idea - it costs too much and you may lose key features that are critical, but not common to everyone. Thus, to make good use of new technologies with an existing ecosystem, you start recycling and segregating processes in an attempt to make it "new-ish". There's no big deal having a business using AS/400 with some C++/C# for fat clients with Java Web/Webservices using Websphere version 7, 8 and 9 simultaneously. It is completely acceptable. You do evolve as your client's needs, so is your ecosystem.
The real matter is not "what", it is how, and even, how efficiently. How efficiently you do manage your ecosystem will impact directly your ability to surpass expectations in a reasonable timeframe.
Imagine renovating your bathroom (old-to-new) with your grandpa's tools, your parent's tools, and your own tools. Some require physical force, some wired electricity and other works on battery. There are different brands, different types. Some are nearly new and others are almost in the trash. Then, your significant other tells you "Honey, you have 3 weeks to complete this sprint including the user story "destroy bathroom" and "clean everything" and "put it back together, but nicer and 'new-er'"-feature." You may ask yourself "But I don't even know what's working, what's not, how it used to work, who used it, ...". Sadly, it is really common. Yep, we all have been through this once in our programming life.
After our 3 weeks, exhausted stressed, but satisfied you did achieve positive results at the end with your new knowledge, you bring yourself to this conclusion: "It is the last time, I mean, really the last time I feel like this. I will automate, script or whatever this thing. ". With all your motivation to make a difference this time, you stumble a common principle in automation: responsibility.
You can't script all the processes at once. You do not know everything about it. It could even be someone else's job. Also, it could require maintenance from those parties, but since it is your scripts, how could they efficiently make them evolve. This is also a core component of the DevOps principles. How do we draw the line between the user (dev) and the knowledge keeper (ops)?
This is where Inv comes into the play.
Inv helps you to get through your own ecosystem. Sometimes people quit, get a promotion, documentation is lacking, you're working with legacy's legacy. Inv is a multi-purpose automation tool to connect all your Network Valuable together and sync their respective process together. Inv allows writing efficient, simple to use script instructions to sequence, to keep, to check and to automate your internal processes for which will take care of your ecosystem. Script your Network Valuables has each one of them were web services. Also, since Inv uses scripts, it's easy to manage under an REPO with all your other apps. In the end, your source code is the only valid source of information about your ecosystem.
Let's drill down an example
I'm hosting an app on a Server. Quite simple... not. You may ask yourself these:
- When can I deploy?
- Does it use Docker/Kubernetes, Tomcat, IIS, Weblogic, ...?
- Who has access to the server?
- What is the OS?
- Is it up?
- Is there already something deployed there?
- Do I need a database to boot up? Where is that database?
- What is the JDBC/ODBC connection URL/key?
- Does the schema exist?
- Is it up to date?
- Am I in the production, development or QA environment?
- Do I need to send a request email to a responsible person?
- Who is responsible for this server?
These are all valid questions that require a valid answer. Automated processes tend to last longer and give better answers to those questions. So, one script per NetworkValuable, everything is responsible for their own box, nothing more, nothing else.
- Convention over configurations
- Automation over processes and protocols
- Responsibility is a core requirement
Inv uses Groovy since it's the best suitable for DSL programming. DSL allows easy to understand scripts to develop and shared amongst your colleagues from different backgrounds. It also allows you to define your own data and callback structure without any other tool or framework. This is the key factor that made Groovy the most suitable.
New 2020-07-12! Inv does support YAML files. Using the same mechanism as Groovy script files, with a little bit less features, YAML ease the learning curve for non-Java-like programmers. Take a look.