I would look into AWS Lambda. Lambda host backend functions written in javascript, python or java. You can then use the AWS javascript sdk in your frontend code to invoke these lambda functions. This will be very low cost and cuts out a lot of boilerplate work. You pay on a per request basis versus an hourly or monthly basis. So if no one is using your website, then you pay nothing.
We use Teletraan heavily. Currently we have about 500 deploys per day, including the auto deploys.
Slightly off topic, I'm a big fan of continuous deployments, but 500 deployments a day seems excessive. Assuming an 8 hour work day, thats more than 1 deploy every minute. Its great that this system works that seamlessly, but are there really benefits with deploying that frequently?
As we started transitioning hosts and services to our own data center, we quickly realized we'd also need an efficient process for installing and configuring operating systems on this new hardware.
Im not positive, but it sounds like a fairly recent switch from a cloud provider to their own datacenter. If thats the case, Id expect a number of outages to come in the following months.
You were probably already "gone" once HR contacted you in June. HR's job is to protect the company, at no point were they concerned with improving your work relationship with the other employee. However, they were concerned with making sure you couldn't sue Google for wrongful termination. They gave you 6 months notice, followed up with you a few times, tied up any lose ends and then let you go.
While I do think you were already gone, it sounds like you handled things horribly during this 6 month period. You should have cut off all contact with the other person and started job hunting.
I do a good bit of weight lifting, typically 4 or 5 times a week. I find it a great way to disconnect and focus on something very simple / straightforward for an hour. Its also a great way to relieve stress.
I think you're over thinking things. Tech hiring is so random that you could have the most impressive list of projects on github, but if you get asked a single data structure question that you stumble on they might pass. Similarly, you could ace the white boarding questions, but if they check out a project of yours on github that they don't enjoy for some reason they might pass.
I would stick to doing whatever will give you the most confidence when talking to companies. If that is studying data structures/algorithms then keep doing that. If its launching a side project focus on that instead.
Hey I'm Ryan. Im a tech lead, full stack developer and Techstars graduate. I’ve built and launched multiple iOS apps which have been featured in the App Store. I have extensive experience building highly available, scalable and cost effective systems on AWS.
Other than ec2, what AWS services were you using and how did you migrate those? At minimum, I'd guess you were using elb for load balancing, sqs for queues and elastic cache for redis.
When I setup an AWS account for pet projects the very first thing I do is create a billing alarm that alerts me the second my bill goes above $0. This way if something is accidentally running without my knowledge, ill get an alert (email / sms) and can quickly take action.
Didn't mean to imply no need for Hologram or not to keep dev as close as possible to production. However, I do think you should be doing this before looking into a solution like hologram. I've seen many startups that run all their environments on a single account and eventually something bad happens knocking production offline. If you were to use hologram, but still only a single AWS account you could still just as easily kill production.
For working with AWS apis, securing access keys, and granting least privilege, the first step to take is to make completely separate AWS accounts per environment. Make a Bigco-Prod, Bigco-Test, Bigco-Dev AWS accounts. Developers only access the Development account, so even if they connect with a highly privileged key / role and a bug wipes out your services, only the Dev account is effected and production keeps on humming. AWS makes this extremely easy to do, they offer consolidated billing to pay one bill for multiple accounts. Takes no more than 30 min to set this all up and I would recommend this for even a company with just 1 developer.
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seconds and start working. This greatly helps with scaling up, doing rolling upgrades and also very easy rollbacks.
The CodeDeploy service seems to operate by you manually launching base ec2 instance with a code deploy agent and then this agent will checkout your git code on the live instance, run any provisioning steps and then if things break somehow rollback all that work, still on the live instance.
I'm sure this is still a big improvement to companies who are manually sshing into servers and running deployments by hand, but as someone who pre-bakes ami's and does rolling upgrades with autoscaling groups this service seems like a step backwards.
I have a very similar setup as the one mentioned in the article where we create a full baked ami, then create a new autoscaling group which attaches itself with a load balancer.
The reason you want a fully created ami is to greatly cut down on the time it takes to accept new traffic. Lets say you get a spike in traffic, if you have a fully baked ami your autoscaling group can get an alert of the increase in traffic, launch a new instance and that instance will start handling traffic around 60 or so seconds. If you booted a generic ami and then provisioned the box you could easily be looking at 10's of minutes before it could handle traffic depending on the complexity of your app. This could easily lead towards long periods of down time.
I've been using DynamoDB since it was released. I wrote a nodejs driver[1] and a nodejs data mapper for it[2], so I have a decent bit of experience with it. Browsing the DocumentDB docs the two services seem to be very different. DynamoDB is really just a key value store with some very nice properties, but also a lot of tradeoffs. One such tradeoff is querying data is very limited in DynamoDB. In Dynamo you can only query data by its primary hash key and optional range key. These keys you must specify upfront when you create your table and cannot be changed afterwards.
DocumentDB seems much more similar to mongodb and appears to have a very flexible query ability. In my opinion, one of the best features with DynamoDB is you can tune the number of reads/writes each individual table requires. This lets you scale up and down your database and greatly helps keep costs down. This is a feature that only a hosted database service can offer. I haven't yet read any pricing info on DocumentDB, but hopefully they offer a similar feature as this is really where a hosted database service can shine.
I recently created a login flow for a RESTful API. The solution I went with was instead of thinking of it as a high level activity such as login, what I was really doing was creating auth tokens to then be used in the Authorization header in subsequent requests.
I created a /tokens endpoint, where I POST the auth credentials and in return I get back a newly generated auth token. In my opinion this is a nice RESTFul solution.