Modsy | Backend/Frontend/Full-Stack/Computer Vision Engineers | San Francisco, CA & Portland, OR | Full-Time | https://modsy.bamboohr.com/jobs/
Sparked by a lifelong passion for the intersection of design and technology, Modsy is a fast growing SF based startup that allows you to see inspirational designs and decor within the context of your own home.
We're looking for engineers of all levels. We've hit "hockey stick" growth and you'd be helping to scale a product that is used by thousands daily!
You'd be joining a diverse team of engineers, artists, designers and creators that bring the Modsy magic every day. Check out modsy.com/portfolio and see if you can tell which of our images on our site are real vs. renderings (hint: they are all renderings). Our technology stack includes: Python, Django, React, WebGL, V-Ray, MySQL and various AWS services (EC2, S3, RDS, SQS).
Remind, Inc | Backend Engineer (mid-senior) | San Francisco, CA | Full-Time, OnSite or Remote OK (within 3 hours of CA) | https://www.remind.com/
Remind is a communication platform that helps educators reach students and parents where they are: their phones. With 27 million active users, we’re one of the fastest-growing companies in education technology, but we have our sights set on something bigger: giving every student the opportunity to succeed.
The Remind Engineering Team tackles hard and interesting technical challenges, embodies our value of finding a way, and open-sources projects like Empire(http://empire.readthedocs.org/) and stacker(http://stacker.readthedocs.io/). The main tools we use in our backend include Go, Ruby, NodeJS, PostgreSQL, Redis, RabbitMQ, and many AWS services (DynamoDB, RDS, ECS, Aurora, Lambda, SNS, SQS, and more).
You should check out troposphere (https://github.com/cloudtools/troposphere/) and stacker (https://github.com/remind101/stacker/). I'm a maintainer of both - we try to make CF easier by catching errors earlier, and allowing you to do things like write for loops, in troposphere. stacker tries to take your troposphere templates and tie them together as totally separate stacks.
Just up front: I'm one of the folks developing Empire.
That said, what we do is we have our CI system build our docker images, push them to dockerhub (private registry) if the tests all go great, and then we deploy using https://github.com/remind101/deploy. We also tag all our images with the git SHA that they were created from, so we have immutable identifiers for each image, which has been useful.
We just recently put direct github deployment support in Empire, so that's been really nice (before we had to use another service that pulled deployments and put them into Empire).
Anyway, not quite the workflow you're talking about, but it's really worked well for us, so maybe it'd help you as well :)
So at this point Empire itself doesn't deal with things like Autoscaling. That said, the Demo Cloudformation template (and the bootstrap script that kicks it off easily for you) make use of Autoscaling groups for the instances that containers are being run on.
So, in theory you could autoscale just like you always would. Monitor stats for a host, if a bunch of them start to run low on resources, kick off an autoscaling event.
That said, there's been quite a bit of talk about integrating Empire with Autoscaling, so that when, say, ECS couldn't find any instances with resources free for a task, Empire could kick off the autoscaling events for you. Could be pretty awesome :)
We actually looked at VulcanD in an older version of Empire. When we decided to use a routing layer with this version of Empire, rather than just letting Empire/ELB expose each service (mostly because it is a lot easier for us to later shut off public access to each service) we threw together nginx because it was so simple.
I think at this point everytime we move a service we add like 5 lines to an nginx config, re-deploy the router in Empire, and the service is exposed.
The internal 'service discovery' makes this a lot easier, since we just have to tell nginx to route to http://<app_name> - no domain, no port, nothing more than the app_name thanks to DNS/resolv.conf search path & ELB stuff.
Sparked by a lifelong passion for the intersection of design and technology, Modsy is a fast growing SF based startup that allows you to see inspirational designs and decor within the context of your own home.
We're looking for engineers of all levels. We've hit "hockey stick" growth and you'd be helping to scale a product that is used by thousands daily!
You'd be joining a diverse team of engineers, artists, designers and creators that bring the Modsy magic every day. Check out modsy.com/portfolio and see if you can tell which of our images on our site are real vs. renderings (hint: they are all renderings). Our technology stack includes: Python, Django, React, WebGL, V-Ray, MySQL and various AWS services (EC2, S3, RDS, SQS).