[kodablah]

I'll take a startup in a box. I want Kubernetes, Elastic, Kibana, FileBeat, Prometheus, Consul, Grafana, databases, HTTP gateways, etc all set up on on the cloud (or set of servers) of my choice and a dashboard that lets me add users (e.g. like a modern Webmin/cPanel+WHM) and make minor config changes if I don't want to run these myself. I want those things HA and I want stable hostnames for them (e.g. Consul DNS on every box). Then I want an empty app template where I can provide a few things: commands to build my app (including dependencies), a systemd conf for start/stop of my app, a config value to tell you where the logs will be, a config value to tell you how to consume metrics from me (e.g. a local HTTP path for prometheus), etc. I feel like we're close with Helm and Kubernetes but I'll be damned if coordinating and setting all of this stuff up HA, getting notified of failures, getting notified when I need to add more servers, being cloud-independent, etc isn't an extreme burden to entry.

I want to write code and deploy, not spend most of my time on ops or marry myself to a cloud vendor. I started my company as the only tech person and I feel like I have to be more admin than dev even though I'm doing the same thing as everyone else.

[franciscop]

I don't think for a startup you need K8s and most of the things you have outlined! Maybe for a late-stage startup, but then you are already doing something so a generic slap-it-there solution might not be the best idea.

You are describing a large-scale setup boilerplate, far away from what I'd call a startup in a box. Slap in a simple server like my own project [1] or no server at all until product-market fit, and then but only then start scaling.

[1] https://serverjs.io/

[mikepurvis]

But if the cost of having those things is low enough, maybe it's worth it to have them sooner rather than later.

I've experienced many of those tools in the context of a 200-person company; I can definitely see how managed versions of them could deliver value to a much smaller org.

[kodablah]

Of course you don't "need" them. However, I don't believe I'm describing a large scale boilerplate. You can get this with a few servers and a couple hundred a month these days. Heck, you can do it on a laptop w/ minikube probably (though obviously not ok to do in prod, just goes to show the costs are not the problem here). Sure it's easy to run an app. But it's not easy to admin it as you grow (even though you are not yet "big" and still may be only one or two people).

[atmosx]

Who will troubleshoot when shit hits the fan?

It seems to me that you are introducing technical debt from day one because it’s cool.

[merinowool]

What technical debt?

[BjoernKW]

The kind of technical debt otherwise known as premature optimisation. If you don't even know yet that your app has to scale - and in which way - preparing for that contingency is a waste of resources.

[merinowool]

I wouldn't qualify that as a premature optimisation. Kubernetes is de facto standard of running applications now and you get all the benefits for almost free. Premature optimisation in this case would be over provisioning - throwing more servers than you need.

[awmartin]

Take a look at Cloud Foundry, especially the Container Runtime.

The Application Runtime (CFAR) is like an OSS Heroku, installable on AWS, GCP, Azure, vSphere, and OpenStack. Then just push your app and scale it out. It was first built as an enterprise Heroku competitor, and the commercial flavors power a bunch of big companies’ infrastructures. It even uses the same “buildpack” model that Heroku uses to provide language and framework dependencies.

The Container Runtime (CFCR) packages k8s in a way to make it easier to deploy, maintain, and scale, and it also deploys and manages the health of the underlying VMs. It originated in collaboration with Google.

Source: I’m a Cloud Foundry Foundation project lead.

[iopeak]

Hey! This is what we are building at Asyncy.com - we are inviting users into our private Alpha release in about a month. I highly recommend you inquire and check it out. 100% OSS, full stack app out of the box using microservices.

[mon1key]

Even if someone assembles a product like you ask, how will they monetize it?

I'm assuming you want the product to be built with open source components, so then the startup would be selling a glue script to package these open components together.

The only feasible way to make money with this would be to sell a proprietary glue script. Not sure how acceptable that would be to you or to potential customer base of this startup.

[w_t_payne]

How about giving it away and then offering consulting?

[mon1key]

There is an inherent conflict with that kind of business model. If your product were simple enough, that would reduce your opportunities for consulting.

So to rope in consulting offers, you'd be inclined to add complexity and config options to generate more avenues for consulting.

[w_t_payne]

Depends on your mission.

In my experience, the companies that succeed are those who are sincere in wanting to help their customers.

[ravi096]

Take a look at https://robinsystems.com

​Robin enables an App-store like user experience to simplify deployment and lifecycle management of Big Data, NoSQL and Database deployments, On-Premise and in-Cloud. It supports application-level snapshots, clones, time-travel, QoS, scaling, backup/restore, etc. It takes care of HA, stable hostnames, Application templates, events, notifications.

Check out the demo clips for [video]

Cloudera https://vimeo.com/213037162/a66e0b4e77 HortonWorks https://vimeo.com/227832200/8d9c749984 MongoDB https://vimeo.com/206348836/a36e535add ELK Stack https://vimeo.com/225899966/6000bae6f2 Controlling IOPs in shared environment https://vimeo.com/171608156 1-Click deploy, snapshot, the clone of entire Oracle https://vimeo.com/195549219 Even RAC cluster https://vimeo.com/223730427/e8cb8c92f8 and SAP HANA many more applications

Disclosure: I am the lead developer at Robinsystems

[ThomPete]

That's a solution not a problem :)

The point is to find problems to solve not just ideas.

I did the original posting of that question and wrote an essay about it afterwards:

http://000fff.org/the-problem-with-problems/

[nathan_f77]

I've also been searching for this for years, and the closest thing I've found is Convox [1]. Unfortunately they only support AWS for now, but it's a really good PaaS on your own servers. It's open source, too [2]. You can run a convox rack without using their hosted console.

One problem is that it requires a minimum of 3 instances, so it can be more expensive than Heroku to start.

[1] https://convox.com

[2] https://github.com/convox/rack

[jwilliams]

I'd second this -- and very occasionally I think of spinning off my current code into this.

If find PaaS can be a little too opinionated. You get boxed-in too quickly. Whereas IaaS is too raw. I had a bit of a head scratch when I recently moved to Google Cloud and was a bit flummoxed on where to put my (backend) session state. Similar experience trying to get Blue-Green deployments on GKE (Kubernetes).

I feel GCP/AWS and friends will get there. But for now there are definitely some gaps.

[herlitzj]

Sounds a lot like Terraform https://www.terraform.io/

[kodablah]

I am somewhat familiar w/ this product and I'm afraid I'm not articulating how simple I expect. Where do I click to search my logs?

[daxfohl]

re k8s: https://medium.com/@steve.yegge/honestly-i-cant-stand-k8s-48...

But ultimately all these arguments converge to: something that beats k8s's suckiness is a potential startup.

[hashkb]

Oh, also: https://www.openshift.com/products/pricing/ is kind of like what you're talking about. It may not have everything, but it's managed k8s on your cloud with support.

[kodablah]

Closer. Things like being able to see the logs of all your apps and searching them is a common thing I assume. We have all the tools today, that's not the problem. The problem is me having to read pages like [0] just to do what almost 100% of companies have to do. I am having trouble articulating the simplicity of what I would expect.

0 - https://docs.openshift.com/enterprise/3.1/install_config/agg...

[biswajitsharma]

Biggest problem in this is, one size does not fit all.

It is hard to compile a stack - which would be useful for most companies.

Yes, there have been attempts made - for Example, Open Stack. But then I feel, there is always an element of specific technology based on the needs of the product being built.

[hashkb]

Aren't you talking about Heroku?

[kodablah]

No. Some of my quotes: "set up on on the cloud (or set of servers) of my choice", "being cloud-independent", "not [...] marry myself to a cloud vendor", etc.

[BerislavLopac]

You know why you can fill your car's tank on any petrol station? Because all the different players -- pump vendors, car makers, oil companies etc -- are using the same standards for the size of nozzle, fuel composition etc. They have concluded that standardisation is in their interest, as opposed to locking the customers in.

In software there are no such standards, or rather there are too many standards, and new ones are being released every day. Currently there is no clear incentive for vendors to standardise, and it's quite possible there will never be, it's early to tell.

What you're describing currently requires enormous resources, and no single company can pull that off -- even Google is struggling with keeping both back-end stability and front-end simplicity (I'm currently working on a new GCP tool which just got into beta, so I can see it firsthand). Standardisation allows many different vendors to focus only on a part of the whole supply chain, while with the cloud you have single vendors trying to cover everything under one roof.

It would be great if we could combine Digital Ocean's droplets with Google's BigQuery with Amazon's RDS, all through a simple front-end UI -- but the nozzle size is not standardised, and I wonder if it will ever be...

[hashkb]

If you bought all of this pre-made from a vendor, you'd be tied to that vendor, subject to their pricing whims, support SLA, etc. Maybe they'd be multi-cloud, maybe not.

[kodablah]

I don't want to buy it pre-made. I want to buy the coordination/orchestration software. And I don't want to spend forever in yaml/chef/ansible whatever to setup these things every company does. I want to download it and I want to run it. I'll give it a list of servers and some SSH keys. It can tell me if it needs more capacity. The dashboard can even be local.

[orf]

That sounds like an open source collection of things, rather than a startup idea.

i like it though, could really help in some situations.

[lwansbrough]

I mean, everyone has different requirements or preferences, so you don't get it all set up for you generally. But there is at least one such solution which more or less fits your description: DCOS.

[kodablah]

> I mean, everyone has different requirements or preferences

I've found this is only kinda true. Most people need the same supporting infrastructure and most people only need to deploy their HTTP-visible app, maybe a cron or backend daemon, and probably a data store. Everything else from logs to metrics to alerting to HA gateways and so on are quite universal.

[dchuk]

Are you starting new companies that frequently?

[w_t_payne]

Could be good for a VC that doesn't want its' investments wasting money reinventing the wheel.

[kowdermeister]

Or maybe start small to test your startup idea and then you don't need a military grade server setup ready for WW3. :)

[kodablah]

Depends on if, by "start small", you mean small effort or small money. Having those things I mentioned shouldn't be expensive, but are huge effort. I want to start small, but if I can't do something as simple as delegate SSH access or search my logs, I can't even test my idea. What I'm talking about is meant to increase the ability to start small for those of us w/out dedicated ops teams.

[kowdermeister]

My point is that you don't need an ops team or lots of ops to being with. A single server can do miracles for a good period of time.

[jononor]

Just use a PaaS like Heroku? Keep the tech simple and vendor locking is minimal.

[j45]

Someone recently mentioned to me that platform.sh does some of what you're looking for

[maerF0x0]

besides the " marry myself to a cloud vendor" part it sounds like you want a platform as a service. AWS and Google both provide more or less what you've asked for. Just takes minimal glue to turn the features on.

[kodablah]

Yup, I basically want self-hosted PaaS in a box, but also w/ opinionated interoperability (e.g. use Prometheus alert manager to tell if my DB disk is reaching 90%, use consul DNS to have stable names for my log server, use Grafana to show me memory usage across every container/app, etc). It's always the "minimal glue" that takes forever and often once "glued" it becomes stale because it's not maintained unless it's someone's job or something breaks.

[w_t_payne]

Yup. Me too.

[beamatronic]

Could you not go with serverless and eliminate all of that complexity?

[kodablah]

Not easily across cloud. If as part of this package, it included a "cloud functions"/"lambda" component, cool. There are a few vendor-independent ones out there. But I need to search logs, store data in a database, etc. I don't want to go to the Google console to see my logs. Also I think traditional apps have many benefits wrt cross-request state management that are not as easy to do generically when serverless.