[HN Gopher] Show HN: Heroku Alternative for Python/Django apps
___________________________________________________________________
Show HN: Heroku Alternative for Python/Django apps
Author : appliku
Score : 161 points
Date : 2021-09-09 11:53 UTC (11 hours ago)
(HTM) web link (appliku.com)
(TXT) w3m dump (appliku.com)
| reducesuffering wrote:
| I'm learning to run a Django app and have been toying with
| deploying to DigitalOcean. Decided on this to learn atleast some
| generic DevOps things as opposed to too-proprietary (Heroku) and
| too-expensive (AWS). There's a decent amount of Nginx, Gunicorn,
| and Postgres things that seem to need to be scripted, and I'm
| still not sure how to quickly reproduce the server automatically
| (scripts?) and replicate the server environment on my Mac without
| adding Docker/Podman to the mix (running Django app on my Mac and
| deploying to Ubuntu server env could cause issues unknown
| locally).
|
| How does Appliku help address these issues?
|
| Edit: Also, is Appliku itself deployed with Appliku? If so, if
| Appliku experiences issues, do you have a quick method of
| deploying the fix outside your usual deployment?
| hnarayanan wrote:
| Use Ansible. Here is an example of one of my Django apps' setup
| scripts: https://github.com/scancer-org/setup
| heurisko wrote:
| > I'm still not sure how to quickly reproduce the server
| automatically (scripts?)
|
| I use Ansible. I'm not a DevOps person and found it very easy
| to get working. It just requires SSH.
|
| I also use Docker locally, because it's convenient, even if I
| don't containerise my application.
|
| I've tested Digital Ocean's managed Postgres and it seems to
| work well.
|
| Welcome to hear what Appliku offers more than this, however.
| reducesuffering wrote:
| Thanks. When people say they use Docker, there seems to be
| several different ways. Are you using Docker Desktop
| (Mac/Linux?), docker-compose, Podman, or something else?
| heurisko wrote:
| I use docker-compose on Ubuntu and when I'm on Mac, I use
| the same docker-compose.yml file running under Docker
| Desktop.
|
| My docker-compose.yml file includes services for
| integration testing, like MailHog.
| appliku wrote:
| As a developer you only pick your repo and pick a server size
| and region.
|
| If you need customization you can make your own dockerfile that
| will be used to build your image.
|
| If you need to move to another server - you provision another
| server through appliku interface and change deployment to
| happen on that server.
|
| Appliku itself is deployed with help of GitLab CI and can be
| redeployed to another location pretty fast.
|
| Hope i was able to answer your questions.
| kcb wrote:
| Is there any service that I can just upload a py file and a
| requirements.txt and it will just run? No bundling, packaging,
| git, cli, etc. Not even for a web app but main use case is to
| host a Discord bot.
| slig wrote:
| GCF might be what you're looking for
| https://cloud.google.com/functions/docs/quickstart-python
| rvanlaar wrote:
| Hey Congrats on launching this. I really hope it'll grow.
|
| Here are my 2 cts.
|
| I've used dokku for this, running Django, for years and recently
| I moved a customer over to use the digital ocean app platform.
|
| There are a couple of things I find important when evaluating
| these platforms that I didn't see on the site: - is there
| database fail over with the multi server strong and powerful
| plans? - does appliku maintain the underlying servers and
| database? - is there monitoring?
| appliku wrote:
| Hey, thanks for kind words!
|
| At the moment databases in Appliku are best fit for non-
| production environments. So while you can enjoy easy and great
| deployments of your apps, I am not ready yet to compete on the
| production databases front. So no, we don't offer fail over or
| even backups at the moment. Backups are in plans, but more
| advanced features for databases is not even in backlog.
| derefr wrote:
| Re: production-quality DBs, it's its whole own ball-game.
|
| Rather than getting into all of that, your time here might be
| better spent here finding DBaaS services that host on the
| same clouds Appliku deploys to, and partnering Appliku with
| them to guarantee predictable network-transit peering to the
| clouds your users are launching on; probably by setting up
| the install-time UX flow so that that DBaaS choice is made
| early in the setup flow, and constrains further choices (i.e.
| user chooses DBaaS X; Appliku knows what AZs it exists in in
| each cloud, and restricts user to deploying the app to those
| same AZs in order to ensure free transit.)
|
| In other words, do the backend work Heroku does to add a new
| DBaaS "add-on" partner, but without reselling/wrapping the
| resulting service, instead just giving a UX to bind to it.
| appliku wrote:
| One thought I have in mind is ability to provision AWS
| and/or Digital Ocean managed DB offerings so you don't have
| to leave appliku interface to get a production grade DB.
|
| But Appliku will keep being deployment solution for apps.
| iampims wrote:
| That's probably the way to go. Easy
| provisioning/scaling/backup based on RDS or equivalent.
| danjac wrote:
| As a long-time Dokku user, have you done any multi-server
| deployments or just stayed to a single server? I'm happy with
| Dokku for side projects but would be interested in what Dokku
| users use when they need to move up to a multi-server setup.
| futhey wrote:
| Not OP but very happy with Dokku for multi-server clusters,
| with some light load balancing or failover at the DNS level.
|
| Admittedly, this works great for clusters of 1-10 machines.
| There's definitely some missing stuff that's hard to add for
| larger deployments.
|
| But, I'd venture to say that most of Dokku's target audience
| doesn't need to worry about scaling past a couple of servers.
| howolduis wrote:
| So with Heorku, if an app has one dyno and that dyno doesn't
| receive any traffic in 1 hour, the dyno goes to sleep. Does
| Appliku have a similar thing or does it stay online longer?
| appliku wrote:
| It happens for a free dyno. For paid dynos they are always up.
|
| Appiku doesn't turn off your servers.
|
| Scaling and spinning up/down additional servers is in plans.
| DarthNebo wrote:
| Does anyone know of a FOSS app to help setup something similar to
| managed databases w/ Postgres/Mongo, but with ease of use just
| like AWS/DO have? Handling backups, scaling with minimal user
| intervention yet self-hostable?
| alexanderisora wrote:
| I am long time paid customer of Appliku. I've built a SaaS
| (https://unicornplatform.com) and before was hosted on Heroku.
| Migrating to Appliku saved me $400/mo in cloud costs.
|
| My app is React & Django and it works like a charm on Appliku.
|
| Good luck!
| xu3u32 wrote:
| How are you serving react?
| appliku wrote:
| Built during the project build and uploaded to s3 and served
| via CDN.
| howolduis wrote:
| to all web developers: no one, absolutely no one, likes huge
| popups on their screen that covers the website.
| wartijn_ wrote:
| What are the benefits over using this instead of DO's app
| platform?
|
| https://www.digitalocean.com/products/app-platform/
| appliku wrote:
| DO Apps platform in terms of pricing is as bad as Heroku's
| offering. They charge per instance of the process and it
| becomes pretty expensive. Appliku helps to reduce costs by
| putting processes on a single server.
|
| With Heroku Config Vars sync feature one of the customers
| managed to save around $7k/mo on fat Dynos that are insanely
| overpriced in Heroku.
|
| So while DO Apps platform will definitely have their target
| audience, Appliku allows to save a lot of cash.
|
| Hope I was able to answer your question :)
| pbronez wrote:
| Can you talk a bit about the security model? Appliku requires an
| AWS user with:
|
| AmazonEC2FullAccess
|
| AmazonEC2ContainerRegistryFullAccess
|
| AmazonEC2ContainerServiceFullAccess
|
| AmazonS3FullAccess
|
| That's a lot of permissions into my AWS account. What are some
| easy ways to contain the damage that could be done if Appliku has
| a bug or the creditials are compromised?
| onphonenow wrote:
| Google got this right w project focused permissions- accounts
| work aws side but
| appliku wrote:
| Hey! Thanks for question. I guess there is an article that
| needs updating. Appliku only needs AmazonEC2FullAccess.
|
| Well, if you feel that something is off you just revoke
| credentials.
|
| I will update the article now. Thanks again
| mikepurvis wrote:
| The point of a rich authorization model is not to have to
| rely on feelings.
| deberon wrote:
| I would recommend dedicating an entire AWS account to this. Or,
| if you have a solid tagging strategy[0], you can craft your IAM
| policies to only allow Appliku access to resources tagged with
| a particular tag.
|
| 0 -
| https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags...
| appliku wrote:
| Separate account will be the best strategy. I prefer having
| separate accounts for every project. Hustle to login between
| them, but the best isolation that can be between projects.
| slig wrote:
| Congrats on shipping! I could see myself using a service like
| yours, and bringing my own server is perfect as I can adjust and
| scale it up/down as needed.
|
| I'm thankful that Heroku prices are that extreme because it made
| me learn how to deploy and run everything by myself back in the
| day.
| appliku wrote:
| Thanks for kind words.
|
| While I know how to deploy myself I am fed up with that.
| Especially when it comes to a new project. There are so many
| places where you can screw up with a typo or stuff like that.
|
| So while I know how to do it by myself, I don't enjoy doing
| that and that's how the project got started.
|
| By the way if curious i wrote a post about that:
| https://dev.to/kostjapalovic/tired-of-deployments-built-my-o...
| thih9 wrote:
| Congrats on the launch!
|
| > Create as many instances of Postgres, PostGIS, Mysql, Redis and
| RabbitMQ as you want. They are hosted on your servers and we
| don't charge extra for them.
|
| I'd love to learn more about this, I couldn't find any details.
| Is there a page with more information? Specifically, I'd like to
| know more about backups and upgrades.
| appliku wrote:
| At this moment we are not fighting for the niche of Production
| grade databases with failovers and all these valuable things.
|
| The feature to back up at least postgres is planned, fail overs
| , replication, etc is not even planned yet. There are companies
| that have whole departments working on managed DB offerings,
| sadly - we don't. yet :)
| RussianCow wrote:
| This looks sleek, but I'll ask the obvious question: Why use this
| over Heroku? I couldn't find a good answer to that question from
| a quick look at the website, aside from maybe the fact that it
| uses AWS and Digital Ocean.
| capableweb wrote:
| Heroku is a general apps platform. This seems to be tailored
| specifically to Django/Python (with the option of using your
| own Dockerfile so could deploy anything). One could easily
| imagine that the performance and stability should be a lot
| higher than with Heroku. If you're a Python-only shop, it might
| make more sense.
| vldo wrote:
| having something that specific, tailored for dynamic
| language, seems like overkill i'd undestand if it was for
| something highly performant and hard to deploy
| capableweb wrote:
| Maybe, but maybe not. If you're using Python/JavaScript and
| have a ton of dependencies, most of your deploy-time is
| gonna be spent downloading dependencies. If the host you're
| using is specifically setup for Python/JavaScript, they can
| run a registry mirror with 100% of the packages right next
| to the host, and remove basically most time spent
| downloading the packages.
|
| Same goes for other time-consuming activities like code
| coverage or even running the tests. If the applications
| running on the platform are somewhat heterogeneous, then
| you can start doing really aggressive performance work.
| RussianCow wrote:
| > One could easily imagine that the performance and stability
| should be a lot higher than with Heroku.
|
| No, I can't imagine that. Why would performance be any
| different? I imagine most of these kinds of solutions use
| Docker behind the hood anyway, so they're likely to be
| identical.
| capableweb wrote:
| See https://news.ycombinator.com/item?id=28468943
|
| To clarify, I mention "performance" in terms of the speed
| of "from commit to deploy", not the CPU/IO performance of
| an already deployed application.
| RussianCow wrote:
| That makes more sense, but the deploy cycle is already
| really fast with Heroku. I'm not sure if there is very
| much value in trying to shave off a few more seconds.
| appliku wrote:
| Depending on your requirements build ties in Heroku can
| be quite long. One app i've recently observed take 7
| minutes to build because it always had to build both JS
| and Django parts(buildpacks for both were executed every
| time). We made it way faster with custom docker file that
| used caches and often built under 40 seconds. i am not
| saying that is not doable in Heroku, but would take more
| effort.
| danielheath wrote:
| Because Heroku is phenomenally expensive.
| appliku wrote:
| As i said in another comment Heroku is unbelievably
| expensive.
|
| What they offer for $250 per process can be done at
| $60/mo per whole app.
|
| When I helped them move all background workers and all
| non-production apps to Digital Ocean they ended up saving
| $7k/mo which blew my mind.
|
| It is easy to start on Heroku, but staying there is a
| black hole in any budget.
|
| Thankfully we've built Heroku Config Vars sync so one can
| move off of Heroku gradually.
| fnomnom wrote:
| >Heroku is unbelievably expensive.
|
| only if developer/devops/admin time is free and for most
| it isnt. if 60 vs 250 /month is a breaking factor for you
| and your use case: go for it. if you need the software
| deployed to make real business it just doesnt matter.
| appliku wrote:
| $250/mo per process. And with appliku it is done
| automatically so there is no need for admin/devops time.
| vldo wrote:
| actually i'll ask something similar, why this over dokku?
| appliku wrote:
| You can do Dokku, you can setup dokku and deploy apps with
| dokku. no problem.
|
| But I wanted a solution where I don't need to remember
| anything DevOps while writing/shipping my apps.
|
| I also added a generous free plan that allows all features.
| Then AWS has free credits so one can start their next big
| thing without expenses and not learning a single thing about
| deployment at all
| appliku wrote:
| Price.
|
| It is easy to start on Heroku. With one app, one process.
|
| When you have multiple apps and several processes there is a
| way to reduce costs and not loose in convenience.
|
| $10/mo droplet can hold plenty of apps and it is still $10/mo.
| If you don't need a production grade Database - Appliku has
| them at 0 cost.
|
| Back in a day I moved several of my side projects to Heroku. I
| was happy until i received a $90+ invoice by the end of the
| month. Now a $10/mo droplet holds even more projects for me.
| RussianCow wrote:
| Thanks for the response. My two cents: price is not the thing
| that I would compete on. For any "real" business, the cost of
| Heroku is negligible compared to its benefits; a few hundred
| dollars per month in savings is just not enough to convince
| most companies to migrate to a completely new service that
| isn't as battle tested and has fewer features. At the same
| time, I'm not convinced you could make any significant amount
| of money tailoring your service to side projects.
|
| With that said, I think you have a great product and could
| probably make some decent money by offering some combination
| of niche features. Ideas off the top of my head:
|
| * Integrated metrics. Since you're primarily targeting Django
| apps, it should be feasible to collect health/performance
| stats from the apps and display them in a simple dashboard.
| You don't need to offer very much here; most companies would
| be more than happy with basic stats related to response times
| per route, although SQL query times would be really neat to
| see.
|
| * Automatic scaling for your Python projects. If you could
| apply the same ease of deployment to horizontal scaling, that
| would be really valuable.
|
| * Easy integration with AWS services like S3, SES, and SNS.
| You could do this in a number of ways. One idea is to provide
| a set of Django libraries that, for instance, makes sending
| SMS messages super simple, with no configuration needed when
| used via Appliku. Or you could integrate with existing
| libraries and just remove the configuration step for the
| developer.
|
| With at least one of the above (or some other
| differentiator), I could see Appliku taking off. In any case,
| you have a great product, and I wish you the best of luck!
| appliku wrote:
| Thanks A LOT for kind words.
|
| So first I am thinking what is the best way to offer
| scaling. There are so many ways how it can be done and in
| other comment threads there are hot debates happening about
| that. It is still an open question.
|
| I was thinking about tailoring more features for django
| too. Not only price is different, but I picked Django for a
| reason. It is a great suggestion about metrics per route. I
| haven't thought about it before.
|
| Integration with AWS services - Yes. That's why initially i
| had a wide range of recommended Policies to include in AWS
| credentials. My goal was to make automation around creating
| not only app but all auxiliary services without the need
| for user to deal with AWS manually.
|
| basically let appliku orchestrate 3rd party services in
| order to get the "recommended setup".
|
| So not only I have limited positioning to Python/Django
| niche, but next tools that will appear will make people
| using this popular framework way happier by taking away
| their pain.
|
| Thanks for your suggestions. Hope to speak with you in our
| Discord :) https://appliku.com/discord
| eirki wrote:
| This is my experience as well. $10 for each running process
| (server, worker, database) adds up very fast.
| appliku wrote:
| It doesn't seem like a lot when you enable one more
| resource for $7-10/mo. You can clearly see invoice "growth"
| when it adds app, right? :D
| caymanjim wrote:
| Heroku is AWS.
| pcardoso wrote:
| I have been using CapRover for this purpose
| (https://caprover.com)
| axelthegerman wrote:
| If anyone is looking for a similar service to deploy Ruby/Rails
| apps, check out https://www.hatchbox.io from Chris Oliver.
| Unfortunately doesn't come with a free tier but worth every
| penny!
| dayvough23 wrote:
| Seconding Chris' work. I love having not to worry about DevOps
| for my Rails apps.
| excid3 wrote:
| Thanks for the support! Glad you've been enjoying Hatchbox.
| We're wrapping up v2 and can't wait to share it. Upgrading to
| Caddy for the web server has been wonderful.
| appliku wrote:
| Tell me more about Caddy vs Nginx. What are the biggest
| benefits? I honestly not exactly happy with nginx in some
| corner cases.
| BilalBudhani wrote:
| Bilal here, I'm working with Chris on v2.
|
| Caddy providers benefits compared to Nginx, like
|
| - Out of the box SSL certificates
|
| - REST api for providing configuration
|
| - A vibrant plugin ecosystem to extend traditional web
| server functionality
|
| - Easier setup for load balancer
|
| We are quite happy with the results so far.
| appliku wrote:
| Yes, I can def-ly see it is way better. Question here, as
| far as i understand Caddy is a paid product, how its
| licensing works while deploying on customers servers?
| appliku wrote:
| I would like to say that existence of Chris Oliver's Hatchbox
| was initial inspiration and validation after finding which i
| decided to build Appliku. So, Thanks, Chris!!!
| pelagicAustral wrote:
| Hatchbox its an absolute lifesaver for my deployments... I
| cannot stress how helpful and well crafted it is... But every
| single day of my life I worry about what is going to happen to
| all my infrastructure if something were to happen to
| Chris/HB...
| _tardigrade wrote:
| recently started working on something very similar for
| Python/Django apps! I'll have more competition I guess
| appliku wrote:
| It only proves there is market for that.
|
| The more solutions the better!
|
| Wish you best of luck!
| saevarom wrote:
| This is very interesting to me. I'm essentially a one man devOps
| team at a small web agency hosting multiple client websites
| mostly based on Django.
|
| One question; what do you do about compiling and transpiling
| Javascript? Right now it's done via webpack in the local
| environment and then pushed out to S3/CDN.
| appliku wrote:
| hey!
|
| I have a question. Are you deploying it to your servers/cloud
| accounts or clients' accounts?
|
| Regarding your questions: it is responsibility of the app to
| build and upload the static assets where needed.
|
| If you want recommendation what to do, I'd say you'll need a
| custom dockerfile, install node, run webpack in there and
| collect static.
|
| If you are not using collectstatic in that process then given
| the lack of details I'd say why are you doing it in the same
| repo at all. But again - you provided very little details.
|
| So if it is a website(server rendered pages, SEO is
| important,etc) - you should have node and do optimisations
| before pushing to s3.
|
| If it is an app (RIA,SPA) then I'd say don't mix frontend and
| backend. Decouple it and ship frontend separately.
|
| Appliku Interface is built and served with Netlify. I still
| remember those dark times when I had frontend inside the main
| repo. It was largely inconvenient.
|
| Either way happy to chat about your issues in our discord
| server. I am more than happy to help you figuring this out.
| saevarom wrote:
| Yes well separation of frontend/backend is of course a good
| idea, but most of the projects are mostly django templates
| with some React sprinkled on top to make interaction and
| interfaces nicer. It's also a good idea if you have just a
| single project or a few of them.
|
| I'm talking about maybe 30-40 projects with django as base so
| it would make my job so much more complicated if I would
| split them all up in repos.
|
| The frontend code is mostly isolated but is shipped in the
| same repo to be built and distributed for django to find.
|
| So your answer about a custom dockerfile is probably what
| would be needed.
| appliku wrote:
| Oh yeah i totally understand what it means having so much
| projects - every minute spent on manual task becomes an
| hour if done on all projects.
|
| Let me know if you need another set of eyes or discuss it
| options. https://twitter.com/KostjaPalovic or in our
| discord https://appliku.com/discord
| john-radio wrote:
| We should get this added as as backend option for cookiecutter
| Django.
| appliku wrote:
| I completely agree :)
| georgeleon wrote:
| We tried Heroku, and that was expensive. We tried deploying
| manually on AWS but it took a lot of time with a devops
| freelancer.
|
| Got sold on Appliku and haven't had to think about infrastructure
| and deployment at all. We also survived for a long time on the
| free plan, until we decided to have a separate server for staging
| environment.
|
| Works pretty well. Never had to learn anything about servers and
| SSH.
| air7 wrote:
| I must have been living under a rock but I don't fully understand
| the appeal of these types of services if I have to run my own
| server anyway.
|
| What I'm thinking is that it only saves me the initial setup of a
| web server and a git hook and perhaps a DB (which is one tutorial
| away for anyone with basic technical skills) after which
| deployment would just mean a git push. What am I missing?
| tamersalama wrote:
| It's the difference between a managed service (getting the
| 3:00AM phonecall) vs doing it all yourself.
| appliku wrote:
| In a nutshell it is delegating all this manual work to a
| service.
|
| I was happy with manual deployments for a while too, until i
| got fed up with this activity.
|
| It is just a question of quality of life, automation.
|
| Also, yes - there are tutorials, but what if you are not
| willing to spend time learning it even if you have tutorial?
|
| Most of developers have a very high pain tolerance for manual
| tasks and search for yet another tutorial how to do X by
| themselves instead of delegating a task to some app or service.
|
| Not everyone is like that.
| [deleted]
| agustif wrote:
| I just have to say I'm very happy with Dokku/Ledokku for my
| Node/React apps!
| debarshri wrote:
| I have been following this space alot. Heroku like deployment
| spaces have exploded recently partly because people miss that
| experience, partly because buildpack is opensource[1], partly
| because we have gone through a techshift where it is pretty easy
| to emulate that. There are two broad categories - 1. Dokku's of
| the world, one VM (very recently tried adding multi node) and
| then more recently getporter.dev[2] and okteto[3] of the world
| that is trying to replicate heroku on kubernetes.
|
| One of things, I noticed is that, It looks really cool at first
| look but every organisation has their own complexity in deploying
| stuff. It is an integration hell, you have to provide white glove
| treatment to all customers and eventually you have a hard time
| scaling. We tried it too, and what we noticed if you have to go
| an enterprise and sell, you start doing leaky abstraction. It
| works really well for early stage startups but once they have the
| money you prefer something more customizable and robust solution.
|
| This project looks cool. I do not want to discourage anyone but
| again, it is a red ocean out there.
|
| [1] https://buildpacks.io/
|
| [2] https://www.getporter.dev/
|
| [3] https://okteto.com/
| nkotov wrote:
| We're[1] in a similar space and our winning strategy has been
| to provide white-glove onboarding to get our customers
| environment up and running. It's part of doing something that
| doesn't scale (easily) but it also allows us to figure out what
| else we can automate away to increase pace on these onboarding.
|
| [1]https://atomizedhq.com
| debarshri wrote:
| The product looks great. I don't want to discourage you guys,
| I am failing to see a moat as compared to you guys and lets
| say getporter or others in the spaces. Funny enough you guys
| are also YC company.
|
| Product with a high touchpoint I think does not scale this
| early on as a company.
|
| For reference, Porter as a product is doing great because I
| think they have invested a lot in building a community. I
| think that works to certain extent as at scale community
| helps each other.
|
| But, just beware of the fact that market cap is actually
| pretty small. You have enterprise competition from VMWare
| Tanzu and others. On the cloud space, you have digitalocean's
| app deployment thing, AWS has app runner. I have at least
| seen over 20 companies doing pretty much the same thing. Just
| a thought.
| zerkten wrote:
| The problem is the layering of the abstractions. Having PaaS on
| top of Kubernetes in a way that you move down to a more
| powerful primitive is going to be the most scalable.
|
| What happened in the public cloud space was a disparate set of
| services which made the choices really costly. Azure went in
| heavy on PaaS while AWS was focused on VMs. The easy adoption
| and migration was on AWS. K8s seems like a reasonable
| abstraction that reduces the cost of these decisions because
| people seem to agree that K8s is a reasonable base.
|
| Being able to slide on a compatible PaaS layer shouldn't negate
| that K8s investment, and make it easier to adopt for some
| organizations, or parts of those organizations. But, I wouldn't
| argue that we are the point where that layer is mature.
| debarshri wrote:
| I do not agree with you. PaaS abstraction becomes super leaky
| on top kubernetes as you start solving real world problems.
|
| That is one the first mistakes newly formed platform teams in
| a company makes, abstracting infrastructure. Happy flow of
| PaaS on kubernetes is great. It is magical to certain extent.
| But negative flows is a really mess. The customer no clue why
| certain things do not work and you as a engineer had no clue
| that this would have happened.
|
| Secondly, the amount breaking changes you have deal with as a
| result of abstraction is crazy. People pushing code does not
| care. It is basically moving complexity from one place to
| another.
| westurner wrote:
| dokku-scheduler-kubernetes https://github.com/dokku/dokku-
| scheduler-kubernetes#function...
|
| > _The following functionality has been implemented:
| Deployment and Service annotations, Domain proxy support via
| the Nginx Ingress Controller, Environment variables,
| Letsencrypt SSL Certificate integration via CertManager, Pod
| Disruption Budgets, Resource limits and reservations
| (reservations == kubernetes requests), Zero-downtime deploys
| via Deployment healthchecks, Traffic to non-web containers
| (via a configurable list)_
| rcarmo wrote:
| If you want to host your own, check out https://github.com/piku
| :)
| appliku wrote:
| I wanted to host nothing. I wanted click click and deployed.
| But I've heard about piku many times seems like a great thing!
| conradbez wrote:
| Looks very interesting, will have to give it a shot!
|
| I made an open source "dashboard" for dokku that tries to give
| you Heroku ease of use with the cost of a single server.
|
| Basically you run one script on the server and it deploys a dokku
| app which manages the deployment of additional dokku apps. Gives
| you GUI access to deploying new apps, changing env variables etc.
|
| Would love feedback from anyone looking for an easy way to deploy
| dokku apps regularly.
|
| https://github.com/conradbez/dokku-dashboard
| throwaway77384 wrote:
| Long-time dokku user here. This seems interesting. How nicely
| does this play with more complicated things, like configuring
| ports for SSL, or using additional Dokku plugins? How about
| things like configuring the container network and things like
| upload size variables, or the wait time when deploying, etc.?
| cabalamat wrote:
| The existence of Heroku/Appliku etc (and my personal experience)
| suggests that setting up web apps isn't hassle free.
|
| Maybe the fix for this would be to have a language/library
| combination designed from the ground up to make it as easy as
| possible?
|
| So for example, the language would come as standard with:
|
| - a web server for production use - a web server for development
| use - a built-in SQL database - a built-in NoSQL database - a web
| server library
|
| Then, as all the components for the system would part of the
| language's standard library/environment, the difficulty of
| configuring/running a server (such as a web server) on another
| machine would be limited.
| ezekg wrote:
| It's not that setting up a server is hard. The reason Heroku
| exists is because they are your devops team -as-a-service.
| cabalamat wrote:
| If I understand you correctly, you say that setting up a
| server isn't hard, but then you seem to imply that it's hard
| enough that you might want to employ a team of people to do
| it, which seems pretty hard to me.
|
| So I'm not sure that I follow you.
| ezekg wrote:
| Setting up a server and database is not hard. Maintaining
| and scaling it is. I don't want to use my valuable time on
| these things, so Heroku is worth the cost. People who say
| Heroku is expensive are not in their target market --
| businesses who want to avoid their team unnecessarily
| spending time on infrastructure instead of product.
|
| Heroku is much, much cheaper than 1) me spending my time on
| these things, or 2) hiring a capable engineer to do it for
| me. It's build vs buy. I'd rather buy.
|
| But that's not to say I'm not interested in a Heroku
| alternative. But it needs to be a *real* alternative. :)
| appliku wrote:
| I would correct the last part. Appliku is an automated devops
| as a service. Heroku is selling you a very much overpriced
| complete service. And that's where Appliku comes in as a way
| to fight insane costs.
|
| But yes, setting up a server is not super hard. Doing it
| often and with convenience that's where improvement is needed
| compared to doing it manually.
| ezekg wrote:
| I think your project is cool, but deploying an application
| to a server on `git push` is not devops. Heroku is selling
| managed servers and databases with easy deployment, you're
| selling easy deployment to unmanaged servers and databases.
| zshift wrote:
| Dark has exactly that, https://www.darklang.com
| metalliqaz wrote:
| I think you're missing a big part... getting it hosted on the
| internet, stable, and scalable. Can't do that from your laptop
| no matter what the language environment comes with.
| cabalamat wrote:
| > getting it hosted on the internet,
|
| This just needs a VPS, running a popular OS such as Ubuntu.
|
| > stable
|
| This is important, I agree.
|
| > and scalable
|
| The scalable part doesn't matter, since it's premature
| optimisation, which is the root of all evil.
|
| Once the project is used by enough people that it cant run
| just on one dedicated server, then you'll hopefully have
| enough revenue coming in from it to make it scalable.
|
| > Can't do that from your laptop
|
| A VPS would typically have less power than a laptop.
| nkmnz wrote:
| Scalability does not only refer to the setup being able to
| serve a lot of users, but also to the development processes
| being scalable. Setting up and maintaining dev and demo
| environments needs a scalable process for example from the
| day you have a junior person on the team that cannot handle
| all the complexities by herself. Or, if you start to have
| multiple internal dev environments to evaluate different
| technology choices that might impact long term development.
| We're mostly JS based, and even though everything is
| dockerized, it still sucks to onboard people and manage
| multiple deployed branches on AWS EC2.
| appliku wrote:
| Also every provider offers different things, at different
| costs, etc. So it is up to providers to build solutions that
| are easy with a given language or framework.
|
| We aspire to build a convenient service for Python/Django and
| there is a long road ahead.
| TekMol wrote:
| The readme of the example app just says "R":
|
| https://github.com/appliku/appliku_start
|
| Is there a demo of this app running somewhere?
| appliku wrote:
| Please refer to more up to date Djangitos project template.
|
| https://github.com/appliku/djangitos
|
| I will rewrite ec2 deployment tutorial as soon as possible.
| Thanks for reminding me about it.
| TekMol wrote:
| Thanks.
|
| Woops, that is a pretty big beast.
|
| 2172 lines of code in 98 files.
|
| I would not feel comfortable by starting from a base that is
| already this complex.
| samirsd wrote:
| very cool. does this work with celery/redis?
| appliku wrote:
| of course it does. Appliku out of the box provides a way to
| provision redis and rabbmitmq.
|
| I have yet to write a tutorial about celery.
|
| To specify processes to run you use Procfile. Specify your
| celery commands and enable them in Process tab in Appliku
| interface.
|
| In order to have celery beat working you should use redbeat:
| https://github.com/sibson/redbeat
|
| Other than that - no specific requirements. Drop me a line in
| contacts on our site if you need any help. Or in our Discord
| Community: https://appliku.com/discord
___________________________________________________________________
(page generated 2021-09-09 23:01 UTC)