
Ask HN: Learning material for basic level knowledge about Docker, AWS and NoSQL - akaralar
I will have an interview next week for an iOS role where the company representative said that I will be expected to know basic stuff about Docker, AWS and NoSQL databases. Being an iOS dev, I don&#x27;t know much about these. What should one know to cover &quot;basic&quot; stuff? What materials would you recommend for learning about these?
======
jonathan-kosgei
Docker 1\. What containers, images, image repositories are and how to create
them 2\. How to write a simple Dockerfile and build it into an image 3\.
Launching multiple containers with docker-compose 4\. Basic docker commands,
starting, deleting containers, listing running containers, checking container
logs, exec'ing into a container, deleting images, running daemonized
containers etc

AWS 1\. Creating an ec2 instance 2\. Writing a lambda function 3\. s3

This is very non-exhaustive but would cover the very basic. Good luck!

For Nosql try writing something simple with redis, look at mongodb etc

------
chatmasta
It makes sense that you don’t know much about this stuff as an iOS dev. But
it’s reasonable to expect you to have at least basic knowledge of major
technologies adjacent to iOS dev. After all, your iOS apps will likely
communicate with systems built on these technologies. Certainly it’s necessary
to have at least a passing familiarity with them.

Therefore, if you feel weak during the interview when asked about one of these
technologies, you should defer to speaking about your experience interacting
with it as an iOS dev. For example, speak about a backend API you had to
interact with, and how the queries it allowed you to make impacted your iOS
architecture. Talk about JSON, relations, indexes, etc. Challenges you faced,
problems you discovered, lessons you learned. Make it relevant to both iOS and
whatever technology the interviewer is asking about.

It’s never a bad idea to tell a story.

~~~
akaralar
Makes sense, actually reading through this I was reminded of a few stories
that I would be able to tell. Thanks!

------
atmosx
Regarding docker:

0\. Understand the use-case: What's the point of using docker for dev,
production, etc. Read about the 12-factor app by Heroku.

1\. Make sure you understand why ppl use init systems vs launching multiple
processes inside a container

2\. Why ppl use a container vs a VM

3\. Can you run windows on a docker daemon running on linux host? If yet how?
If not why? Can you run a linux container on a mac host? If not why? If "yes"
how?

4\. Make sure you understand the different network drivers (host, bridge,
overlay, etc.) and what they do

3\. Know what are orchestration tools (swarm, kubernetes, mesos, rancher,
etc). Why do we use them, what problems do they solve? I'm guessing that this
is out of the scope of the interview, if it's not, make sure you understand
how to solve: Service discovery (consul, etcd, build-in), Traffic routing
(mesh network, port mapping, etc.) and Persistency (EBS volumes via rexray
plugin or cloudstor, other tech.). Try to design a fully automated deployment
cycle, basic steps should be: deploy, test on push (Jenkins/Drone/other CI
tools), run on staging (ab/qa testing?), then push into production (git
branching models?!).

Regarding AWS:

1\. AWS is a shit-show in the sense that there is _too much_ to know, from an
admin perspective. Companies use just a subset, but which one?! Usually people
will about the following: EC2 instances (basic types, like T, M, I, etc.).
Storage options for throughput (EBS volumes types: io1, gp2, st1, sc1). When
to use which one.

2\. S3, storage options and types. I will serve you better if you understand
what AZ and Regions are and how they are spread geographically. If you have
time to dive into "Object Lifecycle Management" which involves Glacier, would
be nice. Also make sure you understand the "s3 read-after-write consistency"
model, which is different for writes and deletes.

3\. Take a look at RDS offerings vs DynamoDB (See NoSQL bellow).

4\. Other services to look at: ElasticCache, Route53, CloudFormation, Lambda,
IAM.

Regarding NoSQL:

1\. What RDS (SQL databases) / NoSQL (dynamodb) does AWS offer and which one
offers what. It's a bit too much for an entry level question but Aurora vs
MySQL AWS Offering could be a tricky question, very AWS specific.

2\. I've wrote a high-level MySQL vs NoSQL overview here:
[https://www.convalesco.org/articles/2016/11/10/a-quick-
overv...](https://www.convalesco.org/articles/2016/11/10/a-quick-overview-sql-
vs-nosql.html) \- you can start from there and deep-dive into NoSQL databases.
A good way to approach databases is in terms of the CAP theorem and what it
offers[1]. It's a triangle, you can pick "2" or choose a spot anywhere in
between. The choice usually depends on a variety of facts (e.g. do you value
more Consistency, Availability or Partition Tolerance?). Each DB (e.g. MongoDB
vs DynamoDB) have specific characteristics. I'd say that it's best to _study_
at least 2 of them and then try to understand what each offering gives and
why. Also makes sure you take a look at Redis. I'd argue the the other most
famous and widely used NoSQL is ElasticSearch but ppl doesn't think (for some
reason) about ES when talking about NoSQL... I've noticed that they usually
when they talk about NoSQL they usually talk about MongoDB, DynamoDB,
Cassandra and Couchbase (the order is random although Mongo is probably the
most widely used). From an admin POV you should know how replication works,
what happens if the master or slave goes down, how master election/quorum is
achieved, etc. It's different and tricky for each DB... I'm not sure if it's
worth diving into details, maybe watch a few videos on youtube and take notes.
The important thing to know is that in a "master/slave" setup usually you
scale-out through master -> slave replication, by scaling out _reads_ not
_writes_. You need master-master replication, but then you introduce another
set of problems (consistency vs availability, etc.)

That's not an exhaustive list of course, but you get the point.

Good luck & stay strong!

[1]:
[https://en.wikipedia.org/wiki/CAP_theorem](https://en.wikipedia.org/wiki/CAP_theorem)

~~~
akaralar
Wow really detailed answer! It looks like I'll be using this as a blueprint
while studying, thanks so much for taking the time!

