AWS Explained: The Basics
inqdo.com
inqdo.com
I was asked at an interview what developers need to know about AWS. I think there are three things to keep in mind:
Consider higher level services for operational simplicity. Unless you are at a certain scale, you'd never run your own object store, you'd use s3. I always say if you are thinking about downloading and installing any software system on a server, see if AWS has a managed offering and at least evaluate it.
Use the elasticity of the cloud. Shut things off. Build scaling systems but make sure they scale both ways.
If you aren't automating you aren't doing it right. Tools like cloudformation and terraform let you really treat your infrastructure like software and force attitude changes.
Bonus: keep an eye on bandwidth costs, especially between AZs as these can be shocking and can drive architecture.
Source: user of AWS for 10 years and former AWS instructor.
One of the other hidden benefits of AWS is the API which is available for every service (I can only think of one thing you can do from the UI that you can't also do via the API) and maintained by them. (I know that cloud foundry offers this as well, as do other cloud providers.)
Leveraging that API really unlocks the value of the cloud.
A good guide to transition from heroku, where everything is handled and you don't need to know anything, to AWS (or similar) where you end up having to either manage everything, or at least be aware of how things work and what are all the tools available (beanstalk, etc).
I find it missing, and it makes me scared of transitioning, while still be interested in learning more about server management / linux.
I want to see a react-native based full stack.
I feel like every app needs: css, html, javascript/react native, data management/redux, json, (LAMP is easy enough), PHP, larvel, mysql/mongo
Getting everything set up(IDE, servers, debuggers, and the code) for the first time has taken weeks, despite the actual programming being pretty simple.
Surprises me these dont exist since so many people have apps that require login and payments.
?
Or something like https://aws.amazon.com/quickstart/ which is slightly lower level.
That might get you part of the way there. I suspect there's no business model for the full stack because every developer is going to say "it'll take a few days to set up and then we'll know the stack from first principles."
I'd also love to see someone templatize backend stream processing and API integration systems.
I may not get what you are saying, but isn't this what kinesis and kafka (which Heroku has an offering of: https://www.heroku.com/kafka ) do?
> API integration systems
So you're saying something like Zapier but more general? I'm not sure what you're looking for.
With Kubernetes you can build the Platform as a Service (PaaS) on a shared Containers as a Service (CaaS) foundation (definitions are in https://github.com/cncf/wg-serverless/tree/master/whitepaper... )
You see multiple organizations trying this, Rancher 2.0 just got released, and we at GitLab just announced a partnership with Google's CaaS to make Auto DevOps more usable.
Our goal with Auto DevOps over Heroku is:
1. Open source 2. Run anywhere you want (don't pay extra for compute) 3. Smooth graduation (no need to start from scratch when you need a customization)
The biggest piece still missing to replace Heroku is idling of containers, we're hoping that this will get added to Kubernetes https://github.com/kubernetes/kubernetes/pull/29471
People want IaaS, FaaS or SaaS.
If you're smart enough to configure Elastic Beanstalk there isn't much holding you back from using CloudFormation.
BTW We're considering calling it an 'application platform' instead of PaaS, what do people think?
I really like where gitlab is going with regards to replacing many external services with integrated services within gitlab. Of course there is the concern of lock-in that is created this way, but I can't really pretend that teams don't get locked into Heroku, TravisCI/CircleCI, AWS, etc.
I did watch them at 2x, though, and I skipped a couple of things... the specifics about how he setup WordPress hosting during my course was not how I'd handle it so I didn't bother with that part of it. I feel a lot better about my handle on AWS though.
To answer your question tho, a lot of things. Heroku makes it difficult to customize your stack, server, etc. Once your company and systems grow, you want more control.
When they screw you on price/performance https://genius.com/James-somers-herokus-ugly-secret-annotate...
1) Put existing system into maintenance mode (as much as possible).
a) Write lots of tests
3) Move functionality and/or adventurous customers over slowly.
a) Fix bugs
b) Repeat
[This assumes your product is mature enough and not in active development, and can survive a dearth of new features for many months. If not, look into microservices and possibly move functionality over that way.]
Few tools grow with us users as we use them.
Why not?
At any rate, convox looks to be pretty decent and perhaps might be nice for Heroku looking to migrate to something like AWS
Edit: link is convox.com
So my question would be, could you think of a reason to use convox over just elastic beanstalk? They both look relatively simple to me
The UI is great for learning about services, but automating via CLI (or related services) is the ideal goal.
GCP is discoverable and follows the principle of least surprise quite consistently, and they show REST/CLI references for everything you're doing in the web UI too.
I mean imagine you're a new user and ask yourself "what does route53 do?". Then ask yourself "what does cloud DNS do?"
The AWS UI doesn't handle multiple subscription, it's somewhat annoying when you have multiple accounts (let say dev and prod ones). With Azure, you can federate several subscriptions.
Having no consolidated view for all regions is also somewhat annoying, as it is to search a specific resource since these can only be searched in their corresponding panel (ec2 for instances and ELB, RDS panel for DB, IAM for certificates, etc). In contrast, the Azure UI allows you to search accross all resource types in one search box.
There are other issues where I don't have a point of comparaison, but:
If you have a lot of certificates/domains, selecting the correct certificate in an ELB or a cloudfront distribution serving HTTPS is a pain. Same with selecting security groups for an RDS instance or an ELB.
The AWS UI is also painfully slow if you have a big account. The RDS panel used to timeout past 600 or 700 instances, it's a little better now (yay pagination \o/), but still quite slow (10 to 20 seconds to search for a specific instance). The EBS snapshot UI is not usable past 100000 snapshots.
I do agree that as long the API is working, the UI is not critical (don't get me started on API throttling, which are really painfull to track down and handle). It would be nice however if it worked reasonnably well, a UI is still quite efficient when you have to explore and understand what is going on.
It is annoying dealing with multiple AWS accounts.
To mitigate this, you can supposedly use IAM to switch your current IAM User role to a role owned by another account.
This is not correct. A SG is used to define per-instance inbound/outbound firewall rules. To say this applies to the network is misleading. To use an analogy--SG is like Windows Firewall.
Network-level "firewall" rules are done via Network ACL.
Security Groups have some key differences from a host-based firewall. A packet destined for an EC2 instance will not make it to the instance IP stack and be evaluated there, it will be evaluated before it gets there.
It depends on your audience. A web dev that's relatively new to syadmin tasks... sure, it's like a host based firewall. For a syadmin or network admin, that explanation might be more confusing than helpful.
I'm trying to get AWS certification next month and sucking up all info I can get :D
Doing a cloud guru courses right now.
It's a whole new world for me coming from 10 years of front-end development.
I’ll have to give it another go and see if I can make an “ignore this sales pitch section” for others to save their ears/time.
However, He likes to ramble on about stuff not so relevant to the course, so setting your player speed to 1.5x is a good tip.
"We also got a full dynamodb course, check it out!" is just one click away...
1.75 was my sweet spot, but I could do 2x in a pinch with high focus.
The guy talks so slow!
Read the intro doc to Simple Workflow Service, because for some reason the test oddly fixates on that, and basically everything else is something you should run into in your day-to-day work.
As far as I know the ACG practice exams should pretty much cover the real thing, but I'll probably some whizlabz tests to be safe.
Having said that I have come to the conclusion that AWS certs are compared to lot of other certs actually decent ones (or at least some). Even as a meter of your skill memorizing AWS facts. If you found Associate level too easy Pro cert is probably more suitable for your level. I think you're again downplaying it a bit maybe to give yourself a little egoboost.(not knowing your experience level of course) It might come as a surprise to you that not everyone think they are such easy tests.
But yeah they suffer from the fact they are multiple choice exams. But I think they are decent and better than many IT/tech exams. Practical / performance based exams will always trump these...
Really enjoyed ACG and found it quite helpful.
I have a hard time remembering because I was working remotely part of the time, but I was actually working, so virtually all of my study time was after-hours (hour or two most evenings) over the span of a few months. I had no prior AWS experience and did very little additional work.
That said, I do have a couple of decades of sysadmin work under my belt, so most of the concepts were not particularly new.
So a legacy architecture will for instance specify the "frontend servers subnet" (and a unique SG, hopefully!), while a cloud-native architecture will only specify a SG. I think, asking which subnet some machine is in, is kind of like asking which core some process is running on at the moment: any one of the subnets for any one of the availability zones in that region, and the next one will automatically and on purpose be assigned to a different one by the ALB/ASG combination.
Thanks for putting this together. I think you did a good job conveying a high level overview of AWS while also giving enough detail to satisfy those who want/need it.
This balance is a tricky thing to get right. I have a few pieces of feedback I'd be happy to share with you if you'd like. Grammatical and story-arch wise, not technical.
As a teacher turned developer who loves writing, these things fascinate me.
Can I schedule 3 exams at the same time and simply take them all at once?