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.
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.
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.
> 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)
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.
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.
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?
0 - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags...
Well, if you feel that something is off you just revoke credentials.
I will update the article now. Thanks again
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.
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.
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!
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
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
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.
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.
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.
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.
No wonder AWS can get away with the prices they have since people like you (and many more VC funded startups) simply have zero care about the price.
For people who run "real" businesses (meaning you need to have a larger income than expense [meaning, everything not VC-funded]), price is always a part of the calculations, even when it comes to hosting.
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.
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?
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.
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.
But Appliku will keep being deployment solution for apps.
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.
My app is React & Django and it works like a charm on Appliku.
How does Appliku help address these issues?
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?
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.
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.
My docker-compose.yml file includes services for integration testing, like MailHog.
I use Dokku for production and Docker Compose for local development. This template is basically clone-and-go.
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 :)
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.
> 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.
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 :)
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.
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.
So I'm not sure that I follow you.
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. :)
This just needs a VPS, running a popular OS such as Ubuntu.
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.
We aspire to build a convenient service for Python/Django and there is a long road ahead.
Appiku doesn’t turn off your servers.
Scaling and spinning up/down additional servers is in plans.
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?
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.
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.
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.
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
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.
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...
Is there a demo of this app running somewhere?
I will rewrite ec2 deployment tutorial as soon as possible. Thanks for reminding me about it.
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.
The more solutions the better!
Wish you best of luck!
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