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.
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 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...
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.
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.
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...
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.
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...
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.
This is a good high level overview of AWS, though like all overviews there are some details glossed over.
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.
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.
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.)
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 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.
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 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.
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)
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?
'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 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.
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.
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.
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.
1) Put existing system into maintenance mode (as much as possible).
a) Write lots of tests
2) Build new system, copying verbatim (as much as possible). Resist temptation to improve.
3) Move functionality and/or adventurous customers over slowly.
a) Fix bugs
b) Repeat
4) Far in the future, move conservative customers over and retire the old system.
[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.]
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
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
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!
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'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.
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.
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.
can some one do the same with openshift, kubernetes and docker or can point me in the right direction to understand them i have an idea about them but it's a bit blurry and want to clear some things
"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.
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.
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.
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:
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.
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.
83 comments
[ 5.1 ms ] story [ 93.3 ms ] threadI'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.
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.
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."
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).
2) Build new system, copying verbatim (as much as possible). Resist temptation to improve.3) Move functionality and/or adventurous customers over slowly.
4) Far in the future, move conservative customers over and retire the old system.[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.
https://www.expeditedssl.com/aws-in-plain-english
https://github.com/open-guides/og-aws
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.
Can I schedule 3 exams at the same time and simply take them all at once?
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.