Fork me on GitHub
#architecture
<
2020-09-23
>
javahippie06:09:38

Yes, you are right about that. DO is not as “comfortable” when it comes to deployment.

javahippie06:09:56

I did not know about render, looks interesting!

pithyless07:09:57

DO + managed DBs + dokku is also an option, if looking for a heroku-like experience

lukaszkorecki14:09:38

IIRC, dokku is not distributed right?

lukaszkorecki14:09:44

just runs on a single box

pithyless14:09:07

True, they've got some kind of nomad or k8s scheduler - but if you're going down that route, probably easier to go for private services. http://render.com looks like they have some pretty competitive pricing!

pithyless14:09:42

(probably the devil is in the details... ram / cpu / ssd / network - it all adds up :))

lukaszkorecki14:09:50

Oh definitely. Deploying things is such a rabbit hole

emccue17:09:12

Very much already AWS locked in, so thats not an issue

hiredman18:09:17

I think to some degree a lot of the ops(automation, containers, etc) stuff you see is driven by the needs and trade offs of very large shops. Large shops can do things like tasking an engineer (or teams of engineers) to work on automation can free up other engineers to do other things

hiredman18:09:10

but the constant factors (that don't scale with org size) are going to be a real headache trying to pursue that stuff if you are a small shop

hiredman18:09:05

so maybe the best advice for someone at a small shop is to examine any solution from a large shop with a very critical eye before adopting it.

hiredman18:09:35

I would also lean hard into traditional unix sys admin stuff. Write shell scripts, write expect scripts. Bash combined with the awscli and jq can move mountains

lukaszkorecki19:09:02

my 4 people team is running on ECS, it's all glued with a bit of terrafrom, bash and jq

lukaszkorecki19:09:19

oh, and some babashka here and there