
Show HN: Layer – Get a dozen staging servers per developer - colinchartier
https://layerci.com
======
colinchartier
Hey HN,

We're Lyn & Colin and we built Layer - It creates a unique staging server for
every commit.

Before Layer, I was CTO of a startup with a 10-person developer team, and
dealing with staging servers (and end-to-end tests) was one of the most
annoying parts of our workflow.

Layer lets you define staging servers the same way you define Docker
containers, and get a unique one for every commit going back a week. We run
them in the cloud, so there's no need to pay for AWS servers you're not using.

Also, if you're running a webserver, you get a unique URL for each unique
server automatically so that you can post it to a slack channel and get
feedback immediately.

When we're setting up the staging server, we use the same sort of cache as
Docker so that you can skip repetitive tasks like setting up a database or
running database migrations if they haven't changed.

Would love to get your feedback, it only takes five minutes to do the
onboarding tutorial.

~~~
lasdfas
How is this even possible for $35?

50 staging servers per seat ($1450 Value) 11GB RAM per server 8 CPUs per
server

~~~
colinchartier
We spent six months developing a hypervisor that lets us treat any linux VM as
a lambda - We pass on the efficiency to our users as a value add.

~~~
lasdfas
You should probably be selling that if it works well. That is something I have
not seen.

~~~
deadbunny
<mostly sarcastic>

Bakevm with tooling > create userdata script for cloud init to copy payload to
server > create systemd oneshot service to run payload && shutdown

~~~
colinchartier
You should try it! Our baking interface looks more like Docker than a
traditional VM provision (ala Packer)

Also, we keep the baked images around for a week and trigger them whenever
they are requested (with, say, HTTP, or terminal access)

------
joshribakoff
I also feel like this is the “wrong” vertical. You should be competing with
Amazon and Google in the general cloud business if you’ve achieved
breakthrough efficiency. This doesn’t necessarily help because often the issue
isn’t server efficiency, it’s that people haven’t properly setup 1 button
builds or there’s unmocked dependencies with shared state

~~~
colinchartier
We think it's important to find a profitable path to beating Google or Amazon
- even the best tech in the world will not convince someone to use your cloud
service if they are afraid of counterparty risk.

Our goal is actually to help teams that have unmocked, difficult to test
codebases. You can make multiple Layerfiles and share the setup time between
them, so that you can run destructive tests with a real database if you want
to test that, say, signing up via API works.

------
Kwantuum
So i'm a new dev and we have a system like this at work, I had kind of assumed
it was standard in the industry but clearly, considering the replies that is
not the case. You can check it out here:

[http://runbot.odoo.com](http://runbot.odoo.com)

(it's an internal tool, don't look for a pricing page)

------
mlejva
Shameless plug - my co-founder and I are working on a somewhat similar tool
called [Foundry]([https://foundryapp.co](https://foundryapp.co)). It
automatically creates a development environment for you that is a copy of your
production environment. You also get access to a copy of your production data
and real-time feedback through our REPL tool - we evaluate your code every
time you save a file and send you back the output.

So far we support Firebase and their Firestore, RealtimeDB, and Cloud
Functions. In action, the development with Foundry looks like this:

\- (1) Start Foundry session in your terminal

\- (2) Specify a slice of your production Firestore/RealtimeDB we should copy
for you

\- (3) Specify what Cloud Functions we should trigger for you and with what
data

\- (4) Every time you save your code we trigger those functions as you
specified and send you back the output

Every development environment is created for each developer separately on the
fly (it takes less than 30seconds to have your environment ready). You don't
have to wait minutes for your Cloud Functions to get deployed. You get a
response usually in just a few seconds.

We are also working on a new feature that will make it possible to have one
"master" always-online environment that is publicly accessible.

~~~
ignoramous
Release (YC W20), a similar product to Foundry:
[https://news.ycombinator.com/item?id=22486031](https://news.ycombinator.com/item?id=22486031)

------
anamexis
Looks really cool! "Get a dozen staging servers per developer" is a great
pitch, it immediately caught my attention.

~~~
colinchartier
Thank you! It took a lot of refining to find a pitch that resonated.

Let us know if you have a chance to try out the tool and have any other
feedback. :)

------
topher200
Very cool! At my previous position we spent a lot of time creating staging
environments for QA and UX to use. I love the idea of having an "environment
per feature" which can exist for a week while the release candidate gets
checked by UX and QA.

The "spin-down" feature sounds like the killer -- the only reason we didn't
have an environment per build already is because it would be cost prohibitive.
Instead, we tried to time-slice with a static set of staging servers... very
frustrating with a 50 person team.

~~~
colinchartier
Glad we're solving something that you empathize with. I'll never turn down a
warm intro, so let me know if you think we'd be useful to any folks at your
previous company.

------
sandGorgon
Okteto does something very similar - but uses kubernetes.
[https://okteto.com/](https://okteto.com/)

------
tschwimmer
Hey Lyn and Colin,

Cool stuff! I worked on a very similar project for a small chunk of my life. I
was a PM whose life was made a lot harder by not having a tool like this and
when I joined a startup that had built a similar tool internally, I realized
that it would be a great business. I want to provide some free (and
unsolicited) advice:

Your number #1 challenge is going to be go to market strategy. There are
actually a number of companies that have tried to solve this problem and
either outright failed or seemingly hit some bumps. YC funded a few of them:
Release, FeaturePeek, Dockup. There's also a company called Runnable that was
acquihired by Mulesoft. Initially I was encouraged by the proliferation of
companies in the space - we couldn't all be wrong. In hindsight I should have
realized that it wasn't as rosy as I had thought since it doesn't seem like
these companies have had gangbusters success.

In my experience, there are roughly three types of pushback you're going to
get from potential customers:

1) We can build that better in a week. This one is very difficult to overcome
because at the end of the day it's not really about the truth of the
statement, it's more about the engineering skill of your prospect. Building
this product is a unique and interesting engineering challenge, and I haven't
met a DevOps person who wouldn't be excited to try to build it themselves. I
tried a lot of different approaches but have never successfully convinced
someone it would be a lot easier, faster and more efficient to buy an already
existing solution from us. Your mileage may of course vary.

2) Our setup is too custom to work with any generic tool. This one is probably
pretty frustrating to hear since you folks have clearly put in a lot of effort
to make it work with a variety of build configurations. The interesting thing
here is that this reason can often then turn into (1). Our solution required
people to containerize their app if it was not already and most people replied
that if they were going to do the work to containerize their app, they would
just do a bit more work and build this internally.

3) My database is too big/too sensitive to work with this. Many startups have
small databases that can easily be copied quickly. However, some have
multihundred gigabyte ones that are too large to copy on demand. You either
have to include that latency in the product which in my opinion makes it
borderline useless, or figure out some way to work around it. You can use RDS
snapshots but by our calculations those will be quite expensive. You can hope
your customers have some test database (they don't) or you can try writing
back to their shared staging (or more realistically) their production
database. None of these options are realistically very attractive.

All of that said, it's clear you have some really cool technology here. One
thing I'd suggest you'd look into is a related market: developer environments.
Most companies I've worked at have software engineers putzing around for the
few days/weeks getting their dev environment set up. This is a very expensive
waste of time IMO. If you could provision a cloud development environment on
demand, that doesn't require any scripts to set up or database migrations to
run, that would be huge. The value of skipping that ~2 week setup time
multiplied by the number of engineers a company hires really begins to add up.
Just my 2c.

Happy to chat about this more if you're interested. I don't feel like sharing
my contact info on HN but if you are determined enough I'm certain you can
probably get in touch. Best of luck :)

~~~
zimpenfish
> Most companies I've worked at have software engineers putzing around for the
> few days/weeks getting their dev environment set up.

I'll second this as a real pain point. And I would absolutely love to be able
to spin up a staging/test environment for myself[1] when needed instead of
having to wait for someone else to refresh staging and not knowing what
precise combination of commits are on there.

[1] I'm new and on a Mac, everyone else is here years and on Linux; my local
dev experience has been somewhat challenging as a result due to their
assumptions.

------
gavribirnbaum
Staging was a bit of a nightmare where I worked. We even had this silly google
calendar where PMs competed for time at our staging server.

Will give this a try.

~~~
colinchartier
Let us know what you think, and we'd be happy to jump in a call to show you a
demo or get you set up.

------
colinchartier
We (the founders) are heading off for the night. If anyone wants to get in
touch, my email is colin@layerci.com

