AWS Explained: The Basics(inqdo.com)
inqdo.com
AWS Explained: The Basics
https://www.inqdo.com/aws-explained-the-basics/
83 comments
Hi, Mijndert here, the writer of the article. Thanks for sharing your insights. I agree I glossed over a few topics. I will expand on these from here on out and go into more detail on some of the points you touched on.
Just to be clear, I don't blame you for glossing over some of the complexities. When I ask my auto mechanic what is wrong with the car I don't want to know about the fundamentals of combustion and differentials. (Until I do.)
That's why this article will act as a starting point for an entire series on different AWS services where I will go into greater detail.
Completely agree, which is why I think Elastic Beanstalk, CloudFormation and OpsWorks are great ways to introduce people to the AWS ecosystem. I think of them like frameworks for programming languages.
Definitely. I think that eb is a great fit for certain applications.
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.
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.
You know what I think is missing on internet?
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.
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 totally agree a good successor to Heroku is missing. A lot of organizations tried (Google AppEngine, Pivotal Cloud Foundry). I think AppEngine failed because the security sandbox was pretty constraining and Pivotal was too expensive for most companies.
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
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
I think PaaS isn't really a thing anyone wants.
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.
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.
I think there are a space between IaaS (request VMs) and FaaS (request functions). Current 12-factor apps don't run on FaaS and people rather not spend time setting up CI/CD, security testing, and monitoring for it.
BTW We're considering calling it an 'application platform' instead of PaaS, what do people think?
BTW We're considering calling it an 'application platform' instead of PaaS, what do people think?
'Application platform' is a fine name. It gives a feeling of stuff being handled for you. However, 'PaaS' is an already established concept, so when I read 'application platform' I have to learn about what you mean with it. If you just say 'PaaS' then I can start thinking about whether it is good for me right away.
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 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.
Mind if I dream too?
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.
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.
Have you seen
https://bullettrain.co/
?
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."
https://bullettrain.co/
?
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."
Bullet Train looks amazing, thank you!
I'd also love to see someone templatize backend stream processing and API integration systems.
I'd also love to see someone templatize backend stream processing and API integration systems.
> templatize backend stream processing
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.
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.
I took the classes even though I don't see a need to get the cert for my specific situation. The A Cloud Guru was indeed good.
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.
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.
On a thread yesterday, I saw someone post a link to convox. I could have sworn I saw a Heroku migration guide on their site, I even see one linked from their blog. But it just goes to the getting started section.
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
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
We run 25+ apps on convox. Let me know if you have any questions!
I have looked closely at deploying things to heroku and elastic beanstalk. I have looked at many many others, but these 2 appear the easiest and most battle tested. I had not looked at convox, though.
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
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
When __would__ one exactly transition from Heroku to AWS? Any specific metrics to look at?
Spend! I've encountered use cases where Heroku billing can be 5x what similar usage on AWS would cost. The difference between a $1000/mo AWS bill and a $5000/mo Heroku bill is justifiable when you're a small company that can't afford a dedicated DBA/Ops role, but it can break your margins when it grows to $25000/mo on Heroku vs. $5000/mo on AWS.
My point is more as an engineer, for the next app. I deploy things to heroku, simple enough, but when I feel constrained and want to learn a bit more to manage a little more things, where do I look?
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.
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 __would__ one exactly transition from Heroku to AWS?
When they screw you on price/performance https://genius.com/James-somers-herokus-ugly-secret-annotate...
When they screw you on price/performance https://genius.com/James-somers-herokus-ugly-secret-annotate...
Wow, their rap genius platform with inline annotations and comments is actually one of the best blogging interfaces I've used. Blows medium out of the water.
How much you're spending. :)
There seems to be quite a few: https://www.google.com/search?q=migrate%20from%20heroku%20to...
Are any of those "good?"
Don't you think OP would have tried that.
Google App Engine has worked really well for me as a Heroku replacement. Check it out if you haven’t.
Almost everything seems to be missing this implicit change management.
Few tools grow with us users as we use them.
Why not?
Few tools grow with us users as we use them.
Why not?
just use lambda :D it’s a good in-between
I've heard good thing about lambda, but that's not the point of my comment.
TL;DR version:
1) Put existing system into maintenance mode (as much as possible).
3) Move functionality and/or adventurous customers over slowly.
[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.]
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.]
I'm reminded of this site, AWS In Plain English.
https://www.expeditedssl.com/aws-in-plain-english
https://www.expeditedssl.com/aws-in-plain-english
AWS Explained ELI5: User Interface was written by an interns intern with the only thing being consistent is how bad it is.
Yet, it's still heaps above better than their nearest competitors in Azure and GCP.
The UI is great for learning about services, but automating via CLI (or related services) is the ideal goal.
The UI is great for learning about services, but automating via CLI (or related services) is the ideal goal.
Can't speak for Azure as I don't use it, but I really have to call bullshit on AWS UI being better than GCP.
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?"
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?"
GCP's services are nicely named, but the console dashboard is still a mess, with them shifting around the items all the time. The half-foot into stackdriver is also kinda weird.
For naming in AWS, this is a must have resource: https://www.expeditedssl.com/aws-in-plain-english
Amazed that S3's web UI fails at both pagination and search.
compared to Azure, the AWS UI is way behind.
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.
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.
> The AWS UI doesn't handle multiple subscription, it's somewhat annoying when you have multiple accounts (let say dev and prod ones).
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.
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.
I strongly disagree, they have a good service offering but using the ui is a horrible experience. Also azure has a CLI and a much better ui / experience esp around filtering and not being overwhelmed with a million different options / pages made by developers with no usability or design experience.
"Security groups allow you to set inbound and outbound firewall rules on your network."
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.
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.
Yes and no. NACLs are, indeed, associated with a subnet so more of a networking construct. It's somewhat a firewall, but it's also stateless which is different than many (non-network engineer) people's mental model of a firewall.
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.
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.
But SG are related to a network interface, not with your network (which would the VPC).
Hi, Mijndert here, the author of the article.
What you're saying is completely true, it's not factually accurate. What I was trying to achieve was come up with an analogy that's understandable for people coming from more traditional infrastructure. So while I agree this would cause some confusion for people who already know something about AWS, the intended audience will (hopefully) feel comfortable with this analogy.
Pretty cool!
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'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.
Cloud guru courses seem like something I want to do but the first time I watched one on Udemy (via work subscription), I couldn’t stand the presenter because he spent half the time promoting his other products.
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.
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.
EdX has one now too https://www.edx.org/aws-developer-professional-series - generally the quality of the content on EdX is much higher than the other platforms, I find. Definitely prefer it to say PluralSight.
Yeah, i feel you. I had the same problem in the beginning, but the promoting mostly stops after the 10000 feet overview videos.
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.
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.
Yeah, the only thing I really found annoying by the end was him apologizing for the same pronunciation at the beginning as at the end.
Not sure which course you took, but my Certified Solutions Architect wasn't that bad. He obviously has a platform he promotes but to me it was only about 10% or less of the actual course.
I thought he did very minimal pitching. I took 3 of his classes. I did typically watch at 1.5 or 1.75x though.
I found them pretty good, they did promo for other courses, but since I already got a full subscription it doesn't feel like they selling me something...
"We also got a full dynamodb course, check it out!" is just one click away...
"We also got a full dynamodb course, check it out!" is just one click away...
Gee, I feel bad enough putting a link to my website(everything is free) in my youtube description...
Your CSA associate cert? I recommend taking notes and going through your test exam multiple times and looking up correct answers for everything you got wrong. It's harder than you may think and although i find knowing specific tidbits about AWS services quite meaningless it's still a measure of some sort. Didnt even raise my salary, hah. I had 5 pages of AWS notes of sorts after i had finished cramming.
I think you're overhyping it. It's a memorization test, and not of a lot that's difficult. It took me about twenty minutes to blast through it and I got something like 63/65. It was more a disappointment than anything--I was going to then go pop through the rest of the AWS certs, and came away instead thinking they were a waste of time.
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.
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.
It is but memorizing facts by rote is still some work, right? When you get deep down to it many exams are just that - regurgitaging a set of facts and nothing else. The practical side is often omitted and the level of your understanding never fully checked.
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.
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.
I agree its memorization, but the scenario questions that have compound answers are in there too to get beyond memorization. I'd say the progression of difficulty is Dev (lots of memorization and T/F) --> Solutions Arch --> SysOps. SysOps is by far the more challenging one and is not just simple memorization or T/F.
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...
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...
I'm trying the 3 associate exams mid next month.
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.
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.
Nice work! I did the 3 associate certs over about 3 months last summer using ACG. I've been in the industry for decades but never bothered to get a cert. Starting a new role and wanting to get into AWS was the impetus to learn; I figured a formal class was a good way to do it, and I might as well set the certifications as my goal.
Really enjoyed ACG and found it quite helpful.
Really enjoyed ACG and found it quite helpful.
Do you think doing the thee associate exams with 1 1/2 months fulltime learning is possible?
Absolutely.
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.
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.
Its possible. I had zero exp with AWS beyond spinning up an EC2 instance and finished all 3 assoc certs in 3-3.5 weeks. However, I wasn't working at the time...
Nice! Keep up the good work and good luck with your next certifications!
Which AWS certification? I just did acloud guru courses as well and got my certified solutions architect associate.
One thing I've noticed having worked with many clients, is that legacy architectures that get moved to AWS start by creating subnets, NACLs, etc. while for almost all AWS-first developed applications the Security Group is the smallest unit you tend to address.
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.
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.
Hi,
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.
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.
Thanks for the kind words. I will gladly take your feedback. You can reach me on [my hn username]@mijndertstuij.nl.
I think a good bullet point would be to stress the differences between Region vs Availability Zone vs Global services.
Hi, Mijndert here, the writer of the article. From here on out this will be a series in which I will go into detail on more AWS services. I will make sure to include Regions vs AZ's in future articles. Thank you!
As a next step, check out this guide which dives in details within the multitude of AWS components and their purposes, strengths, weaknesses, and alternatives:
https://github.com/open-guides/og-aws
https://github.com/open-guides/og-aws
Does anyone know how the PSI test centers work?
Can I schedule 3 exams at the same time and simply take them all at once?
Can I schedule 3 exams at the same time and simply take them all at once?
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.