A physical server, only utilized by you
โข you have to know or guess the CPU & memory capacities you need
โข high risk of overpaying (underutilized server) or under-provisioning (too much load)
โข you're able to run multiple apps, but need to make sure that you're not causing conflicts by resource sharing
โข you're solely responsible for the security
โข up- or downscaling is tedious & not quickly possible
Running a machine in a machine
โข sharing a physical server with multiple customers
โข only paying for your provisioned capacities โ a fraction of the whole server
โข still having risks regarding provisioning & resource sharing
๐๐ผ๐ป๐๐ฎ๐ถ๐ป๐ฒ๐ฟ๐ ๐ณ
Another abstraction & encapsulation which will run on a virtual machine
โข multiple containers can run on the same virtual machine
โข containers are sharing the underlying OS, but are not limited by them
โข greatly reduced operational management
๐๐๐ป๐ฐ๐๐ถ๐ผ๐ป๐ ฦ
Highest abstraction, as you're only bringing your code
โข your code is running on a managed VM within managed containers
โข still provisioning capacities like memory
โข low responsibility: only your code & data
โข only pay for the time your code is executed
If you're new to Azure, I'll highly recommend checking out the AZ-900 course on FreeCodeCamp by @andrewbrown!
Thanks for reading & be sure to follow me for regular AWS & Azure content! ๐งโ๐ป
โข โข โข
Missing some Tweet in this thread? You can try to
force a refresh
The concepts are crucial & being confident in them is a necessity.
From basics to advanced concepts ๐งตโ
For seriously working with AWS, there's no way around IAM.
Skipping to understand its core principles will bite you again and again in the future๏ธ ๐ฅ
Take the time to do a deep dive, so you won't be frustrated later.
My most received questions:
"How do I start my cloud engineering journey & what's the right path?"
There's not a single or correct path.
There are only recommendations.
A small recap of mine to get yourself going ๐งตโ
(1/7) Pick a cloud provider you're interested in:
ยท Amazon Web Service
ยท Microsoft Azure
ยท Google Cloud Platform
It doesn't matter which one you start with.
Even though they are completely different in some ways, a lot of your learnings will be transferable.
(2/7) Register yourself an account
Yes, you need a credit card, but you don't need to be scared of unexpected or exploding costs.
All of the providers are having a generous free tier, allowing you to test and explore their services.
But they are only useful if you're able to make sense out of them.
Most important for that: using log levels consistently!
ยท โน๏ธ Trace
ยท ๐ก Debug
ยท โช๏ธ Info
ยท ๐ Warn
ยท ๐ด๏ธ Error
ยท โก๏ธ Fatal
A small thread about when to use what ๐งตโ
(1/7) โน๏ธ Trace
Your most verbose logs containing the most fine-grained information.
It gives you detailed insights into what's happening - not only in your code but also in third-party libraries.
Can go as far as documenting every step in a single algorithm.
(2/7) ๐ก Debug
Less information than 'trace' level, but still extended to a way that's needed to troubleshoot problems in detail.
Majorly used for pre-production/testing environments and often logs out sensitive information that can't be logged on production.