Succubus

Logo

A universal project manager based on cloud-native

View the Project on GitHub Fazendaaa/Succubus

Succubus

The cloud-native way to code

Say Thanks!

English README Portuguese README

Made With Go Made With Docker Made With VSCode Maintainability Test Coverage Codacy Badge

Succubus can help you out!!!

What is it?

Basics

basics

I know, it’s a pretty ugly drawing

Just to make it clear:

  1. You write a program – any language, any framework, any version
  2. You call Succubus to handle any request that you issued
  3. Succubus looks up this request in the provided manifest then reads up the code
  4. Executes the invoked command in a container

You can develop your own patterns inside the manifest standard and share them across projects; or just use one provided by a third party.

A example of this manifest is the following:

image: python
interact: python

objectives:
  base:
    run: python manage.py runserver
    test: python -m pytest .
    add: pip3 install $$ARGV
    rm: pip3 uninstall $$ARGV

  dev:
    anal: |
      python -m mccabe --min 5 ./src
      python -m bandit -r ./src
    linter: python -m mypy ./src
    doc: python -m sphinx-apidoc -o source ../

Which can be accessed by just running the following command:

succ run

In your terminal in a Python + Django project to open a website running and start using containers:

The whole idea is a effortless software development experience while providing safety and speed of development. That’s why you won’t need to install anything in your machine, because Succubus handles all and you can run it without having to install Go or even it; you can see this like a real broker in real life, even tho he might work for you, you won’t have to have it in your house or a place for him at your company.

And if you need to interact with something just to see whether or not will work, just:

succ interact

A screen like the following should pop up:

Python 3.9.5 (default, May  9 2021, 14:00:28)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

And then you will have a REPL (Read-Evaluate-Print-Loop) experience without ever needing to install Python and the great thing about it is that later on this will be the same environment shipped to a production environment.

Index

Security and Reliability

Universe

And the best part is that this works as well in projects based in:

The possibilities are endless, you can take a look at Docker Hub to look at more community driven options or you can even roll up your sleeves and make your own language more accessible to other trough this – or even use a non public available technology just fine because Succubus works the best to help you out, even in a protective corporative environment

And making the Project Manifest a many-to-one way of development, you can rise your productiveness without having to worry about the context-switching overhead related to it.

Possibilities

The main idea behind this project is to open possibilities to encapsulate that projects that you are working on just like we are doing at the company that I work on – you can take a look at this right here –; but, besides that, you can ask yourself:

If you said “aye” to any of the previous of the questions you want Succubus. But, besides this, the idea is create a platform to easily, securely and fast patterns development and testing so you can use it yourself in a project or share with others – maybe even landing a hand and help others understand better how to make a awesome project.

And you can use it in any language, cross-compile to any architecture afterwards because you will be running running containers under the hood; so if you are rocking that last M1 Mac you can easily share your work with your coworkers or even deploy it to the cloud.

Project Manifest

The concept behind the whole “manifest” idea is to make it easier to deploy a new project trough a familiar interface so the programmer can work on it.

Overview

          Project
|--------------------------|
|        Objectives        |
| |----------------------| |
| |        Tasks         | |
| | |------------------| | |
| | |     Commands     | | |
| | |------------------| | |
| |----------------------| |
|--------------------------|

The core idea is to develop a project based in a set of concepts:

  1. A Project is formed by Objectives
  2. Those Objectives are formed by Tasks
  3. And each Tasks is a sequence of Commands

You can look at this like a docker-compose joining forces with npm to help maintain healthy a project.

Broker Model

As you saw you can think in Succubus as a “broker” to your project:

Why broker?

A broker according to Cambridge Dictionary:

a person who buys and sells foreign money, shares in companies, etc. […]: “I called my broker for advice about investing in the stock market”

That being said, Succubus acts like a broker to a programmer:

That definition put together with the whole Project Manifest concept, allow the broker – Succubus – to proper operate by the given guidelines.

Lean approach

Bringing the whole Just In Time (JIT) production philosophy to the “code development” environment – kinda like the one used in compilers –; making the whole pipe process more efficient by default by avoiding late binding or some late checks down the process. This also allows to easily reproduce the whole “production” environment in your machine but looking only at a part of a service, a project; this allows us to better understand and made a translation of some sorts of the microservices idea but in looking even deeper in in your machine, kinda like a behavior-service approach:

This approach is a tool to enforce some well-know software developments like:

And you can see this without fear of having a too fine-grained control that overweights your whole process; a one person project cannot handle the complexity of a 500 employers company software development pipe process; but both of them can increase or decrease the granularity measuring during the process whether or not they will provide a measurable return of investment to you, reduce your total cost of owning this process or even trying many workflows without having to changing any code to check a hypothesis test.

This whole process also helps you to automate tasks later on down de line like:

That’s because you are controling the environment commands, that’s improve reproducibility by a lot as a side effect. You can see this as a FAB (Semiconductor fabrication plant) factory in which, by running 24/7, many teams are needed so that whole process can easily occurs without any hiccup; so FABs usually have 95% of its fabrication process automate so many teams can work upon the same product during different steps of its fabrication. In a development environment this would mean that someone can take upon the work of the previous team without having to worry about having to configuring anything, just continue to work right after where the previous team/person stopped.

jit

And this in software terms means that also the current person won’t have to handle any “hot-potato” in their hands due to previous work done in the pipe as also this ensures that the next step down the line, being a automate step or a person, won’t have to fiddle with the current step mistakes.

The cherry on the top is that as all of this is just a mix of current battle tested technologies open to everyone to improve it and making the whole process a better experience and therefore making it more a “war tested” technology; that means that one step in the process can improve something that in the next iteration can help every step.

TODO

If you read this far, please take a look at the repo and maybe to drop a star in the project, give me some feedback or even dropping some of your code in it :)

Appendix

Documentation

My college experience and work experience – inside the company and with ALL of the contractors – showed me that standardization is a troublesome task, even tho being “simple” to do and to implement and execute in some cases, it’s sometimes difficult to enforce it because the ones who were supposed to follow usually tries to avoid it, this ends up in a paradox: “if everyone has their standards there’s no standard”.

After helping out in some FOSS (Free and Open Source Systems) projects a feeling came to me that even tho many people contribute with some code to the project there’s a lack of documentation contribution specially because usually only few seniors contributors fell comfortable to do so and many of my contributions at least were something that I did only once. But in a work environment this sometimes is even worse, sometimes not even a Makefile is present in the project to point a direction to follow.

Containers are a great tool to deploy, homologate and test projects; but they are also a great tool to develop upon. I say this due to:

Unfortunately even tho I do love a well written, well thought and well delivered documentation, I think that makes me one in a million – many times I had to throw the famous RTFM (Read The Fucking Manual) because I was pissed that somebody asked about something that they did asked many times before and still didn’t give a chance and go read the project docs.

All of that being said, I do think that to avoid any problem related to doc or even dependency/setup the best thing is to bypass of that; that’s why the Project Manifest works in a way that if something ain’t working right now probably it never did worked at all. This also helps to reduce any overhead to a rookie, which to me are the most affected in any scenario.

There’s a phrase which really sunk into me and that always helped me think in which way I can better solve a problem:

The test of our progress is not whether we add more to the abundance of those who have much; it is whether we provide enough for those who have too little…

Franklin D. Roosevelt, January 20, 1937

DevOps

Cloud-Native

JIT