
Show HN: Appliku.com Cost-Effecient and Pretty Python Digital Ocean Deployments - appliku
https://appliku.com/
======
valachio
So my website is running Django 1.11 on Digitalocean.

I'm potentially interested in using your software but I'll need some
convincing.

Right now updating the site is very easy. I use FileZilla to upload the new
files and I would simply type `sudo systemctl restart gunicorn` once the new
updates are uploaded. Also perform a `migrate` or `collectstatic` if needed.

The workflow I got right now works and is very simple, and does not rely on
any middle-software.

Is there any good reason for me to use your app to deploy changes?

~~~
appliku
hey, hi! Thanks for asking!

Let's say to deploy change I do "git push" and that's it. Everything else is
done for me.

In the case with the app you described – you have already done major part of
heavy lifting with the initial setup.

In your case you are not using git, it means you might have problems adding
anyone else to help you coding.

Side note: if you are not using git you can easily lose your code if you don't
have any other backups if the server goes down and something happens with your
computer at the same time.

Now, variables, credentials: something tells me you have them in your code,
which is bad. If you just add git, it is even worse – you will have them in a
repo and again it is bad.

Now imagine the situation when you need to move to another server. You have
all your code in the system, no containers or dockers. My gut tells me that
you don't have scripts to automatically install everything on a new server. It
will be a nightmare to install everything and try not to forget how they were
set up(judging from the Django version it was a very long time ago).

What you have it works now, but such setup makes you absolutely unprepared for
any change(new people, migration to another server, etc).

So, those were bad things I pointed out.

Let's see what (in)direct benefits of using a "middle-software":

\- you will use git. It gives you a chance to add new people to the team, code
history, code backup \- Your task as a developer is to git push the code.
DEPLOYMENT is not exactly the concern for a developer. \- You are forced to
have more up-to-date workflow. App should be tested before going out or at
least should have ability to be tested. Tests are exectured by CI/CD of some
sort. So you have to work in the way to be ready for that.

So, what I am trying to articulate here is that having benifits of modern
tools to work in team, test the app, check code quality to eventually have
better application requires certain approach to storing your code and
deploying it in automated fashion. By doing it manually over ftp/sftp and
manually running commands to update/restart it – you are not letting yourself
to use other modern teachnologies and tools. And they are middle-software in
their niche/for their task. So, if you want better quality software of yours –
you shoudl use many other things that you can called "middle-software".

When we work alone and we are not used to work with all modern tools we choose
workflow that is super fast and convenient for us at that point. I too back in
a day was running production server running in "screen" and cmd/ctrl+s applied
my changes and it felt logical and very easy.

What I realized that this setup is impossible to control and especially
replicate. And everything falls apart when you have somebody else who needs to
make changes.

Fast forward, 2020 – I don't want to think about two things: server
configuration and app deployments. I want to push my code and see changes. I
want to be able to invite others to my git repo and nothing in workflow should
change.

When you do things manually it just doesn't happen without pain.

I hope I gave you a good enough answer, and examples and metaphors to
articulate my ideas in this very huge topic.

Wish you a great day!

------
saviorand
A typo - cost-efficient! But glad to see more out-of-the-box solutions coming
out. It can get pretty time-consuming to deploy after your app is already
done. What was the trickiest part of developing that product, I wonder?

~~~
appliku
Hey! Thanks, I have fixed it on the landing page, evidently, I can't fix it
here.

What was hard, you ask? Short answer: the complexity of the product.

(Very) Long answer: Yesterday I found a note in my OneNote dated Sep 2, 2016.
It had a draft on what such deployment automation can be.

I was thinking about it since that time.

The first hard thing was to decide what tech I should use and what approach to
use.

At first, I wanted to use "supervisord" and build everything on bare metal.

Then I understood that I should put more time into learning about docker.
Everyone was saying "containers, containers, containers [balmer.gif]"

After I got familiar with docker, I've started to write bash scripts to build
app, read about how Heroku works and a lot of other materials.

Then came the long part of trying to make apps build with a bunch of bash-
scripts and eventually I was able to build all of my apps. I was happy and
thought that I was almost ready with the app, I just need to build a frontend
for that. Oh, I was so wrong.

Every new achievement that I had, every new door I was able to open led me to
hundreds of new doors to open (including those I shouldn't touch). What I mean
by that is after solving a problem, I found other things to solve and options
to pursue.

Eventually, I got so deep in this never-ending-doors fight, that I lost my
focus. My initial idea was to help deploy/run python and Django apps in the
best way possible.

When I lost my focus and got overwhelmed by constant building and mountains of
things I can/should build I had a slight depression.

I stepped back and given that I had some noticeable personal problems to solve
I was able to switch from thinking about the app.

When I got back with a fresh head I realized that I should get back to the
original focus and start to compare all new ideas and options (those doors
from metaphor) to it. Is a new feature/option/idea fits for the original
purpose of the app or not?

Then it all started to get easier.

Then I was able to plan ahead knowing what I should do and discarding what I
shouldn't. I realized that the backlog was huge. But every single task wasn't
super hard.

All this gave me peace of mind. And I started to work on it, persistently. I
understood that I will not be able to ship it super fast and there are still
technical decisions I will have to think thru and they also will take time. I
found my pace. Every day I produced a little bit of work.

What helped was some well-known people say phrases like "it is not the matter
who starts, it is a matter who keeps going". I knew that project is complex
and there are so many edge cases that I should take care of. It will take
time.

So, 14 months after buying the domain appliku.com (roughly the beginning of
the coding) I still have the stuff to do. And always will.

So to sum this up: \- For such a complex app, I set out to build I had to
figure out boundaries. \- I had to find my pace \- I had to remember that I am
building exactly the app I always needed and never found elsewhere.

told you, it will be a long answer :)

Hope I have answered your question!

~~~
saviorand
Tells a lot about how prioritization is important when approaching complex
tasks. Were you implementing this whole product yourself?

~~~
appliku
Yes. It is not based on any existing tool(except Django) and I didn't hire
anyone(yet?)

------
mecoupz
What are the advantages of this instead of using a CI/CD pipeline?

~~~
appliku
Generic CI/CD pipeline is a way to execute your automation. But you have to
code everything yourself at least initially.

With Appliku you have your web server installed, databases provisioned and
settings applied.

With CI/CD pipeline you have to write all that yourself.

You may think that one of the core features of Appliku is a niche CI/CD that
has a pipeline written for you for the task of deploying and running your
Python app.

Could you build it yourself? yes. Question is, should you?

Additionally, you have servers provisioning and setup, DNS records, SSL
certificates issued, and many more things taken care of.

