Forem: Karl Mathias Moberg

K8s is overkill for your workload

Karl Mathias Moberg — Fri, 01 Dec 2023 08:00:00 +0000

I hate to be the bearer of bad news, but since you’re reading this, I guess that, most likely, you’re running Kubernetes in production. Sorry to break it to you: chances are - you’re using the wrong tool for the job.

In the IT industry, few other products in recent years have become so well known or become such an industry buzzword as Kubernetes. In a relatively short time, Kubernetes has become how organizations, from small startups to internet-sized enterprises, run their container workloads to organize, connect, and scale applications on demand.

What is Kubernetes?

If you haven’t heard of Kubernetes before, let me summarize. Kubernetes, known as k8s, is a widely recognized and extensively used platform in the IT industry. It allows organizations to manage and scale their container workloads by providing comprehensive tools and features. Kubernetes enables seamless organization, connectivity, and scalability of applications, making it a popular choice for businesses of all sizes, from small startups to large enterprises.

K8s has its roots in 2015 as a Google project and was built upon Google’s cluster management system known as Borg. Google worked with the Linux Foundation to kickstart the Cloud Native Foundation (CNCF), a non-profit organization that nourishes and grows open-source software projects. It offered Kubernetes to the CNCF as its initial seed project.

Why Kubernetes has become so popular

Kubernetes has gained immense popularity recently thanks to its ability to manage and scale container workloads effectively, and its comprehensive set of tools and features allows organizations to organize, connect seamlessly, and scale applications. K8s has become the preferred choice for businesses of all sizes. Kubernetes provides a resilient and highly available infrastructure, automates tasks, ensures efficient resource utilization, and simplifies application deployment and management. Its flexibility, portability, and compatibility with various cloud providers have further contributed to its widespread adoption.

Kubernetes’ excellent cloud compatibility is also one of its most substantial advantages. All three major public cloud vendors and many private cloud vendors have implemented Kubernetes in some form, creating abstraction layers to reduce the complexity for the end users.

But this is also the crux of K8s - complexity

DevSecOps and Kubernetes

Taking one step back for a second, there is another factor we need to keep in mind. Alongside the rise of Kubernetes, a movement has risen in the IT world: bringing developers (Dev), Security (Sec), and Operations (Ops) together. Although DevSecOps is a topic for a post on its own, I argue that without its rise of DevSecOps, Kubernetes would not have been as popular as it has become in that short time.

Allowing developers to write (relatively) simple application declarations and then have a (somewhat) easy way to throw them up in a cluster and have the application up and running quickly is a massive plus for many businesses! If you have a company pushing for SRE and app teams to work together to build something great, this can be a potent combination.

However - this perfect world is often not the reality we live in…

Kubernetes might not be the right tool for the job

Imagine you’re going to build a house. If you want to do the job well, you will need several tools. A power drill will undoubtedly help you a long way, but you will get to a point where you probably will need other tools too: you will probably need a hammer, a nail gun, a bubble level, a saw - you name it, and this is also the case with Kubernetes.

Kubernetes is **great**. But if you’re only running a few containers or microservices here and there, using Kubernetes for that work is like bringing a battleship to a water balloon fight - it’s overkill. Even if you’re running larger workloads, 10 or 20 containers, you could still have a better chance using other readily available container runtime environments or something completely different, such as serverless functions.

The issue we keep encountering across hundreds of businesses is that Kubernetes is not just Kubernetes. If you’re going to run a Kubernetes cluster ********effectively********, you need so much more. You most likely need a way to deploy to K8s in some CI/CD pipeline, then have something keep track of your running pods and versioning, such as Argo. It would be best if you had a way to keep track of secrets, logs, authentication, some service mesh, and so much more. Using Kubernetes in production is an iceberg. It's a vast iceberg; like real icebergs, you only typically see the top 10%.

Fig 1: An example Kubernetes Iceberg

And here is the crux of the problem - most businesses are not set up to handle this sort of iceberg! We don’t have enough engineers with the infrastructure experience to deal with the intricacies that come with such a complex issue that is K8s, and what we keep seeing time and time again happen to businesses is developers being forced to do infrastructure work and hating it.

This isn’t always the case. Many developers enjoy working with K8s, and doing infrastructure work is often a new and exciting challenge for them, but we see burnout rates explode for those who don’t enjoy it and are being “forced” to do that sort of work.

Developer satisfaction is not the only thing to consider here. What we see time and time again is a lack of resources on the operations/platform or security sides, and you struggle to maintain the cluster. Kubernetes has a reasonably frequent release schedule and regularly releases breaking changes, and this is just talking about the cluster itself. It becomes much more complicated when you start looking at maintaining the nodes and their operating systems, plus all the Kubernetes dependencies.

And the fact is - chances are, you’re not developing an internet-scale application. You’re bringing a battleship to a water balloon fight.

Managed Kubernetes

One way to relieve some of this pain is to run managed Kubernetes in some form, typically from a public cloud provider. This is undoubtedly an excellent way to reduce significantly the workload your team needs to do to keep up with the platform. Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), and Azure Kubernetes Service (AKS) are all excellent ways to avoid having to maintain the K8s nodes themselves. However, you’re still not eliminating the issue of Kubernetes dependencies, such as tools and services that typically are the leading resource thieves.

The alternatives

So, what should you consider instead? First, let’s clarify: we don’t want to return to Virtual Machines. We want to move forward to newer and better things. So what are they?

If you still want to keep running containers with minimal changes to your workflow, consider running in a completely managed container environment such as Amazon Elastic Container Service (ECS) or, if you have a small app or limited services, Azure Container Apps. ECS is an excellent production and internet-scale equivalent to K8s/EKS, but without the need to maintain a cluster - everything is done by using managed Services in AWS. Here, you still use the same containers you have been using and have a very minimal declaration and configuration setup, then let Amazon do the rest for you.

However, if you want even less maintenance and are prepared for an application rewrite, cloud functions alongside an event-driven architecture can do wonders for your teams with less complexity and less work for everyone involved. For some, it might be slightly more expensive per compute hour, but based on experience, you’ll quickly make up that difference in engineering hours, which are typically significantly more expensive.

Fig 2: Example of an event-driven architecture (Source: Amazon Event-Driven Architecture)

The future?

Managed services are usually the way to go for a lot of teams. Most organizations simply don’t have the resources to build a well-designed and well-built production environment without cutting back on developer productivity. By combining the usage of well-maintained managed services and considering using a different tool for the job, you can significantly increase developer satisfaction and productivity - both of which are often in short supply. Adopting these managed services is also often not something that takes a lot of time or is hard to do, and it can be the quick win many teams are looking for.

As stated before - if you’re looking for long-term changes or starting from scratch - an event-based infrastructure will set you up for the future and allow you to scale quickly and easily.

But what do you think? Should everyone adopt Kubernetes, or do you know of good alternatives businesses should consider?

My Favorite AWS Tools and Resources that I Use Every Day

Karl Mathias Moberg — Fri, 10 Jun 2022 07:48:06 +0000

Working as a developer and cloud platform engineer working with AWS, I use a ton of tools every day. A lot of these are OS agnostic, but there are some that are not - I'm a Mac user: sorry.

Terminal: iTerm2 + Fig + Starship =

My main tool is my terminal. I use it all day, every day and it is probably my most important tool, which is also why it has gone through a ton of modifications over the years and has now gotten to a point where I'm mostly happy with it.

As for which shell I'm using, I'm still using ZSH with Oh-my-zsh installed, but with mostly default settings and a theme applied.

iTerm2

iTerm is the base of the terminal. It has a ton more options than the built in terminal, although I rarely use most of them these days.

Cost: Free! from https://iterm2.com

Starship

Starship is where the customization begins! Starship a customizable prompt that gives me a ton of information at a glance. The prompt is very much context aware, and will change depending on what folder you are in, displaying only relevant information to you.

In my case I display things like current AWS profile in use, git status, and battery information if I'm running low.

Cost: Free from https://starship.rs/

Fig

This is my latest tool in my arsenal and it's fantastic!

Fig is a terminal addition that adds IDE-style autocomplete to your existing terminal. I know you don't need this functionality, but boy is it nice to have in a lot of situations when you can't exactly remember a command or what the heck you named your file or folder.

Fig also allows you to create custom shortcuts and commands the same way aliases let you execute commands more efficiently. It's hard to stay enough good things about Fig and it's well worth a try!

Cost: Free from https://fig.io/

Jetbrains

I've used pretty much all the code- and text editors as well as IDEs that are on the market. I was a die-hard VScode user since one of the earliest betas, but after a friend showed me the power if the Jetbrains suite, it's hard to go back. Jetbrains offers a myriad of various IDEs for different languages, but they all share the same basic concepts and functionality. It is extremely customizable thanks to a well stocked plugin library from 3rd party developers as well as Jetbrains them selves and as as result, a ton of their software have gotten a permanent place in my dock as I use it on the daily.

Specifically my most used applications include PyCharm, GoLand, WebStorm and DataGrip. As I'm also still responsible for some PHP apps, PHPStorm is also still used, but not as much.

If you haven't tried out DataGrip yet, it got a significant revamp a while back and is honestly one of the best database management tools I've used.

Cost: 649 per year, ex. VAT. (For Students: FREE! ) from https://www.jetbrains.com/

Github Copilot

This is going to cause some controversy I'm sure. Other developers I know claim Copilot is terrible and makes it look like a junior developer wrote the code and is terrible insecure. I disagree. If you think this way, you're not using Copilot right and you're just accepting whatever Copilot suggests without no critical thought. That's not how it's designed, and not how you should be using it.

Copilot can help you significantly speed up your workflow by suggesting the code you are going to type. In the example below, I'm creating a Terraform security group for AWS. I specify the name and ingress, and Copilot suggests the next steps. However, as you can see, it suggests the wrong ports, and I'm not blindly accepting it. You need to be weary of what it suggests and correct what needs to be corrected. However, it even so, it saves me significant time when building these code blocks.

There are some significant privacy concerns about using copilot, as copilot transmit a good amount of telemetry when it is used, and its suggestions are based on other peoples open-source code submitted to GitHub, so if you are developing top-secret government secrets, I would read the privacy policy before blindly jumping into Copilot. However, if you're already putting your code in Github SaaS and not hosting your own server, and especially if you're using public repos, the telemetry Copilot uses should be no huge privacy concern.

Cost: Free (requires invite) from https://copilot.github.com/

AWS CLI (and aws-shell)

AWS has a great CLI, but what's even cooler is "aws-shell"! From AWS labs, you can run an interactive shell that connects to your AWS account and from there manipulate it as you wish. It provides auto completion not only for commands, but also for resource names and is incredibly powerful!

I'll be the first to admit that I typically just use the normal CLI, but as soon as I have to deal with instance names and more, the shell is a fantastic tool to be able to use!

In case you don't know - thanks to AWS "API First" philosophy, any resource in AWS should be available as an API and in the CLI, so anything you do in the console should have an API available to you.

Cost: Free from https://github.com/awslabs/aws-shell

Infrastructure as Code (IaC) - Terraform and Pulumi

If you're working with cloud and haven't looked at infrastructure as code yet - you need to do so. Today. If you're still configuring your infrastructure by clicking in the console, or running a single CLI command here and there to maintain your infrastructure, it's time to move on - trust me.

Infrastructure as Code, like the name suggest, allow you to define your infrastructure in code. This means it can be checked into version control, and that it is easily reproducible. It makes it incredibly easy to organize and make sure that knowledge isn't lost when someone leaves the company. The idea is that the infrastructure is immutable and should not change after it has been deployed without a redeploy or replacement.

There are multiple tools available for this task such as CloudFormation, Chef, Puppet and more, but I'd like to recommend two sets of tools: Terraform and Pulumi.

Terraform is probably the most well-known IaC tool on the market in 2022. It has a very robust set of tools, providers and developer support available making it incredibly powerful and easy to get started with, building your infrastructure. Terraform is made by Hashicorp, a company known for providing robust and well-tested infrastructure tools. You write your code in HCL (Hashicorp Configuration Language) a custom language that is easy to write and easy to read, but there is also a JSON version available if you absolutely prefer JSON for some reason.

In my opinion, Terraform is perfect for infrastructure or someone in operations starting on their IaC journey, or if you have a team of infrastructure people working on this. It is extremely powerful and extendable, and provides the tools a platform team needs.

Terraform is a fantastic companion to AWS and especially if you're testing new things and labbing a project as it is incredibly easy to create a new resource and then destroy everything afterwards.

However, if you're a developer with limited or no infrastructure experience, let me suggest an alternative to you: Pulumi.

Unlike Terraform, Pulumi doesn't have use it's own markup language, but instead extends the programming language you're already working in, such as Python, Go, Typescript, C# or Java! Allowing you to define your infrastructure in a language you're already familiar with.

Pulumi has a number of other extremely powerful tooling as well, allowing you to more easily deal with expressions, and logic, not directly possibly in Terraform.

For a lot of developers, it is much easier to get started with Pulumi over Terraform, so it's worth looking into. However, as Pulumi is a newer tool, it is not as well-known as Terraform, but it uses terraform providers meaning it has the same support for infrastructure as Terraform.

Cost: FREE! from https://www.pulumi.com/ and https://www.terraform.io/(Terraform has some paid cloud functionality for working with enterprise functionality)

Alfred

Ok - on to some very Mac specific apps I use, that are incredible. First of all: Alfred.

I first used Alfred on my very first MacBook, in 2006 - back when Spotlight on the Mac in MacOS X 10.4 was awful and took multiple minutes to launch an application. However, once 10.6 and 10.7 rolled around, Spotlight got to a point where I really didn't feel I needed to install Alfred anymore, since I was just using it as a fancy app launcher anyway.

That was a mistake.

I started using Alfred again this year, after not having used it for 10 years, and boy has it been great! Yes - Alfred can function as a fancy app launcher, but that's not why you want it. You want Alfred for all the small functionality here and there you can do. Like moving a file from one folder to another with two presses, or searching through Apple Music instantly from your keyboard and without ever leaving your current application.

Alfred is incredibly powerful in ways you could probably never imagine. It's FREE except for some functionality, so it's well worth you trying it out!

Cost: FREE (some paid features) from

Snippetslab

This is a small useful utility that I have yet to utilize to it's full potential, but it's a very lightweight and useful application for storing snippets of code for reusability.

It has built in integration with Github Gists, allowing you to instantly publish and share code with others, as well as syntax highlighting for a ton of languages.

However, what makes Snippetslab most useful to me, is the incredible Alfred integration! With a simple CMD + Space, then type in snip <search> followed by ENTER to instantly insert a snippet.

There are tons of other snippet managers around, however what makes this one great, is the fantastic Alfred integration.

Cost: $9.99 from https://www.renfei.org/snippets-lab/ or on SetApp

Dropshare

There are again plenty of uploading tools available, but Dropshare has been my favorite for a while. It's a simple menubar application that allows you to easily upload screenshots, documents, videos, or what you want to a myriad of destinations, including AWS S3!

It's also highly customizable, including giving you the ability to automatically shorten URLs to a custom domain.

Cost: $24.99 from https://dropshare.app or on SetApp

Conclusion

These are just a few of my every day applications that I use. I have a plan on expanding this series with a few more posts with more of the really useful Mac applications that I've found over the years.

A Guide to AWS Certifications

Karl Mathias Moberg — Thu, 09 Jun 2022 10:21:09 +0000

A Guide to AWS Certifications

AWS Certifications - What are they?

If you've worked in the IT industry for a while, you'll know that a lot of the industry thrives on certifications. Certifications are exams designed by IT vendors to verify your knowledge about their products and services, resulting in a diploma or badge you can show to employers to prove you have that competency.

Who should go for a certification?

So who should consider spending the time, energy and money needed to pass one of these exams in the first place?

Well, there are many reasons why you'd take a certification exam such as:

You want to verify that you have the knowledge in a field and to get the recognition.
Many employers view certifications as a good way to check that applicants are competent in that field.
Negotiating pay rises at your current company.
You just want to learn!

Especially the last point is important: you don't have to take the exam at the end of a course material (but you should!), however: certification course materials are a great way to learn new topics as they introduce you to a myriad of ideas thoughts and concepts you might not be aware of.

Introducing the AWS Certifications

Amazon Web Services (AWS), like most other vendors provide at the time of writing, 12 different certifications grouped into four categories:

Foundational
Associate
Professional
Specialty

If you have no experience with AWS certifications, it can be hard to know where to begin your certification path, which is why I wrote this blog post: Where should you begin?

Well: In theory, you could start anywhere. Unlike many other vendors, AWS do not have prerequisites for any certifications and you can at any point, take any certification feel comfortable with. However: that doesn't mean that is a good idea. I've created a flow diagram based on AWS own certification guides with suggestions on what path to take.

As you can see, there aren't that many certifications, especially if you do not count the specialty certifications, and we'll talk about those later.

Before I start discussing each certification and it's worth, I'll quickly introduce you to my journey on the AWS certification path.

My Background

Coming from a background in systems administration and operations, I started working with AWS services in 2017, and since then, I've held two AWS associate level certifications: Solutions Architect Associate and Developer Associate.

I got started with AWS in 2017 when I joined a small company as a Sysadmin, running their internal IT services, but I was also responsible for managing a number of clients that were hosted in AWS. Having no experience at all with AWS when I started there, I did a lot of research before starting, and ended up finding two certification books to get me started, the SysOps Administrator certification guide, and Solutions Architect Associate certification guide. Being a SysAdmin, I figured the SysOps book would be perfect for me - that was not the case. That certification assumes a lot of preexisting knowledge about AWS services, or at least service names - making it a very difficult read. I gave up. A few weeks later though, I started on the Solutions Architect book that fortunately gives a better introduction to each service covered and made it easier. It didn't make it easy, but easier... I studied for a few months, took the exam, and failed. Miserably.

Turns out: The certification guide itself back when I used it - is not enough to pass, not by a country mile. I went back after the exam, feeling annoyed, but sat down, found services like A Cloud Guru (#NotSponsored!) that provided great video training and gave me the additional materials I needed so I passed the exam, two weeks later.

Fast forward a few years, and I used the Solutions Architect Associate certification to score a new job at a new company, with higher pay, and way better working conditions. At that company I took the Certified Developer exam. This time, I was more prepared, has a couple of years experience under my belt, and studied using both the certification guide and video materials.

AWS Certifications

Now - with that background: learn from my mistakes! If you do not have any experience with AWS - do not start at the associate level. I see a lot of people do the same mistake I did - go straight for the Solutions Architect exam, but they either, don't plan on working as SAs or have no experience in the field. Don't do it. It's a hard exam, and without the prerequisite experience, it's not a good experience, and chances are that you have to study significantly more than you need for a more relevant exam.

My suggestion is to start with the foundational exam, the AWS Cloud Practitioner.

Foundational

AWS Cloud Practitioner

Who is it for: Anyone who is interested in AWS! Both technical and non-technical personell.
Requirements: None. However recommended to have: 6 months of exposure to the AWS Cloud. Basic understanding of IT services and how they relate to AWS. Knowledge of core AWS services and use cases, billing and pricing models, security concepts and how cloud impacts the business.
Cost: $100 USD
Time: 90 minutes.
Number of questions: 65 either multiple choice or multiple response

The AWS Cloud Practitioner exam is the entry level certification in AWS. It gives an introduction to the concept of the cloud in general, AWS, and the various AWS services. It is an exam made for both technical and non-technical personell who are interested in learning more about how AWS works.

It is the recommended entry level certification as it contains a lot of foundational knowledge that can be useful at a later state in your certification journey, but doesn't dive too deep into detailed technical knowledge about each service.

Associate

Something to note about the associate level exam is that all three exams cover some of the same materials about how the cloud and AWS is structured, and as a result, it can be relatively easy to go from one associate exam to another. Each exam does however require a significant knowledge of specific domains in addition to the foundational knowledge.

AWS Certified Developer Associate

Who is it for: Application or infrastructure developers working on applications deployed on AWS.
Requirements: None. However ==recommended== to have: 1 Year or more of hands-on experience developing and maintaining an AWS based application.
Cost: $150 USD
Time: 130 minutes
Number of questions: 65 either multiple choice or multiple response

Once passing the Cloud Practitioner, my strongest recommendation for developers is to move straight to the Certified Developer Associate exam. This is the most relevant exam someone coming in as an experienced developer can take.

The exam covers topics such as introducing AWS features including managed databases, servers and services, how to write code optimized for the cloud, automating building and deployment of code and debugging in the cloud. All topics that are extremely relevant to a developer making the exam a more fun experience than other more infrastructure focused exams.

When working in the modern cloud, it is, unfortunately, no longer possible for a developer to say: "I don't care about infrastructure". A developer needs to understand the basics about a database, how utilizing a read-only DB URI when possible is preferable to pushing all traffic to a single URI, or know how basic networking functions when configuring access between a front and backend application. This certification covers these things in a way that makes it understandable for someone with limited or no infrastructure experience.

AWS Certified SysOps Associate

Who is it for: IT personell with infrastructure experience, typically sysadmins, architects, etc.
Requirements: None. However ==recommended== to have: 1 Year or more of hands-on experience developing and maintaining an AWS based application.
Cost: $150 USD
Time: 180 minutes
Number of questions: 65 scoring opportunities, may be multiple choice, multiple response, or exam lab
URL: AWS Training and Certification

If you've previously been working as a SysAdmin, IT admin, Linux Guru, Windows Server God, etc. this is the exam for you. The SysOps administrator exam gives you more in-depth knowledge about AWS services, how to maintain them, how to scale out and up as needed, and how to optimize your cloud for security and cost.

The exam is designed to test the candidates experience in both daily tasks on how to build and maintain auto-scaling groups, and how you can ensure your data is securely stored with access logged. It is ideal for personell tasked with maintaining and optimizing AWS infrastructure and will introduce you to incident response, disaster recovery procedures, and how you can figure out what has gone wrong and how to remediate an incident.

AWS Certified Solutions Architect Associate

Who is it for: IT Architects.
Requirements: None. However ==recommended== to have: 1 or MORE years of hands-on experience architecting AWS infrastructure
Cost: $150 USD
Time: 130 minutes
Number of questions: 65 multiple choice or multiple response
URL: AWS Training and Certification

The AWS Certified Solutions Architect Associate (a mouthful to say and type...) is most likely the most misunderstood exam in IT. I see a ton of people, including myself, take this exam, yet have no need for the exam in practice, as they don't work as an architect, but rather either work as an engineer or developer which this exam is not geared towards.

The Architect Associate exam is difficult. Really difficult. It requires you to know a significant number of services, not very in depth, but you must understand what they can do and how they work together. You must know how you can design an infrastructure to be resilient against failure, yet be high-preforming, secure and finally cheap.

The exam is a very interesting exam, but for most people it is very much not relevant. And it is most certainly not the exam you should be going for after the foundational level. If you have previous experience with the developer and/or sysops, and want more, the SA might be for you, but personally I'd go straight for the DevOps Pro exam instead.

This is a wide-spanning exam and you'll be expected to know the difference between most of AWS various services and how these services work together.

Professional Exams

AWS Certified DevOps Engineer - Professional

Who is it for: Developers or SysAdmins
Requirements: None. However, ==recommended== to have: 2 or MORE years of hans-on experience
Cost: $300 USD
Time: 180 minutes
Number of questions: 75 questions, either multiple choice or multiple response
URL: AWS Training and Certification

The professional level exams are where the fun begins! These are the two hardest exams AWS has to offer, and are considered some of the most difficult exams in IT, period.

The DevOps Pro is a very fun exam! It covers foundational DevOps concepts and how to implement these in AWS. It requires you to have an understanding of how AWS services interact and how you can automate building and deploying code on AWS using tools such as Infrastructure as Code (IaC) and Pipelines.

Just like all other AWS exams, it has no prerequisites, so anyone can take the exam at any time, however - I strongly recommend having a ton of experience before taking this exam. It does require a deep experience working with a breath of various AWS and DevOps tools, with experience that is hard to come by without having tried it.

AWS Certified Solutions Architect - Professional

Who is it for: Architects.
Requirements: None. However, ==recommended== to have: 2 or MORE years of hans-on experience
Cost: $300 USD
Time: 180 minutes
Number of questions: 75 questions, either multiple choice or multiple response
URL: AWS Training and Certification

Considered by many to be one of the hardest exams in IT, the SA Pro is complicated... It requires you to have experience with most of the AWS tools including the AWS CLI, API, CloudFormation templates, billing, scripting languages and Linux and Windows administration. Yeah, I said it was complicated.

There are a metric-ton of features you need to understand (see my mind-map from my notes from the SA pro below - this image is at 10% scaling and my 1440p monitor cannot display more than half at a time...) and have a fair bit of comprehension about. You don't need deep specialty competency in all of them, but you still need a fair bit.

Another thing to keep in mind about this exam is that you will most likely have limited time. Even though you have 180 minutes and only 75 questions, giving you 2 1/2 minutes per question - each question is long. The questions are for the most part scenario questions with one or more paragraphs of information that you need to decipher and figure out what is the correct answer. To make things even worse, in most questions there are multiple plausible answers. You must pick the most correct answer which can be really, really hard at times.

Specialty Exams

There are six specialty exams at the time of writing, and I'm not going to cover them as if you're interested in them, you're going to need to know how to study for them on your own anyway. Unfortunately the specialty exams often have very limited official support and you need to rely on white papers and notes.

However, when you take one: good luck! I see more and more people take them every week and I'm equally as happy every time I see people do so! <3

Learning Materials

For all of these exams, you'll need learning materials. No matter what exam you are going to take, make sure you do a few things:

Go to the AWS Training and Certification website
Download the exam guide and read it!
Download the sample questions. They'll help you out in understanding the exam!
AWS Has FREE practice exams for all exams! You need to go to a separate website, linked from the Training and Certification site.
Read the white papers linked for each exam. I know they are boring as all hell, but they contain a ton of useful information, I promise!

With those things taken care of, I personally learn a lot more from a combination of reading and watching video materials. I've used the official certification guides (available on Amazon) in the past, combined with video materials from multiple sources. I recommend:

They have very different teaching styles, and I'd say I prefer Stephanes approach in a lot of situations, but both work very well.

The Exam

Booking The Exam

Booking the exam is easy and is handled through the AWS Training and Certification site. Find the correct exam and click "Schedule an Exam". You'll be redirected to either Person VUE or PSI - the official proctors of AWS.

You can book either an in-person exam at an official testing center, or an at-home exam. If you do an at-home exam, in mind that there are some very strict requirements for at-home exams and you are required to have a webcam and microphone on at all times during the exam.

Exam Day

On exam day, make sure to read up on the exam requirements for either the in-person on at-home exams. You are not allowed to have a phone or watch on you or nearby when taking the exam, nor any other electronics.

Most of the exams are multiple choice, situational questions where you will be presented with a situation and you will pick one or more correct answers.

Post Exam

Once you are done with the exam, you will immediately be told if you passed or failed, however, you will not be told your exact score immediately, this will be sent to you within a few business days.

If you fail, you can reschedule a new exam after a set period, depending on which exam you took.

Finally

The AWS Certification path is pretty simple and straight forward. However, if you have any questions, feel free to reach out!

AWS Can Be Confusing: Where should I run my crap?

Karl Mathias Moberg — Sun, 15 May 2022 16:57:10 +0000

AWS has over 180 different services with a myriad of different names and it can be incredibly hard to figure out where you should run your applications. In this post, my goal is to make it a bit easier for you to get started with AWS, and know what services you should consider researching moving forward.

Basic Services

We'll start with a quick introduction of some of AWS most popular and well known services, just to get a brief understanding on what services we are going to be talking about later:

Amazon EC2 - The backbone and arguably one of AWS most famous services. EC2 is AWS Virtual Machines. You select how much CPU, RAM and disk space you need, then what operating system to run. You can pick from a myriad of Linux distributions, Windows Server and Desktop and even macOS (special rates and restrictions apply). You’re billed by the second you have the virtual machine running.
Simple Storage Service (S3) - Amazons unlimited object storage, making it easy to store files for access by other AWS services or serving them to the internet (although you might want to put a cache such as Amazon CloudFront in front if you chose this last service).
Amazon Elastic Cloud Service (ECS) - Have you containerized your application and need somewhere to run them, but don’t want to deal with the complexity of Kubernetes? ECS is for you. Amazons ECS service is a fully managed container orchestration service making it easier for you by abstracting away most of the complexity that comes with container orchestration.
Amazon Elastic Kubernetes Service (EKS) - A managed container service to run and scale Kubernetes applications in the cloud or on-premises with EKS anywhere!
AWS App Runner - Just want to run a stupid simple container, and not have to worry about it? Try out App Runner. It connects directly to a code repository, or to a container registry then builds the application on the fly for you. Whenever you push changes, App Runner reacts, rebuilds and republish the application.
Amazon Relational Database Service (RDS) - Databases are a mess to maintain on your own, so why do it yourself when Amazon can take care of it for you? Pick a database engine, MySQL, PostgreSQL, Oracle or even SQL Server, select how much CPU, memory and how you want to store the data, and Amazon takes care of the rest for you.
AWS Lambda - Serverless computing! Lambda is a serverless, event-driven compute service that lets you run code for virtually any type of application or backend service without provisioning or managing servers. At all. You can trigger Lambda functions from most AWS Services, or your own code.
Amazon CloudWatch - Collect, access, and correlate data on a single platform from across all your AWS resources, applications, and services.

Flow Diagram

For a quick and dirty suggestion to where you can run your application, here is a quick flow diagram:

What are you trying to run?

With the services primer in place, the question becomes "What are you actually trying to run?" and "how do you want to run it"?

If you’re migrating a work load directly from an on-premise virtual machine, without the ability to containerize or refactor the application, Amazon EC2 is probably the right choice for you. You pick the number of CPU cores and how much memory you need, and you can use Amazon Application Migration Service (AWS MGN) to automate the migration for you!
Got a brand new application you’re building, with limited dependencies? Consider going a brand new direction, where you don’t have to worry about servers, or infrastructure. Serverless compute, using services such as AWS Lambda and Amazon API Gateway lets you build applications and run them only when you need them, and only pay for when the functions are executed - and the cost is dirt cheap. Fractions of what it would cost to run code in any other service. I recommend checking out how a company such as “A Cloud Guru” runs their entire video training platform on AWS Lambda and Serverless. This architecture requires you to rethink how you’re building your application, but it’s not very complicated, and you can save a significant amount of energy and money.

Containers

When you have containers to run, you have multiple choices depending on how much control you want over the the orchestration of the containers themselves.
- If you just have a simple container, with minimal dependencies, AWS App Runner is a great way to run your container.
- Alternatively if you do not expect to get much traffic to the application, Amazon Lightsail is a dirt cheap way to run containers too, just don’t expect too much integration with other AWS Services.
- Want container orchestration, with automatic scaling out and in, using load balanced solutions, but don’t want to maintain it? Amazon Elastic Container Service (Amazon ECS) on Fargate is perfect! Running on Fargate you have no servers to maintain or have to worry about provisioning capacity, AWS takes care of it all for you, including scaling, load balancing, and maintaining the control plane. It’s simple to configure, and integrates very well with other tools such as CodePipeline, CodeBuild and CodeCommit.
- Kubernetes is an amazing technology allowing for incredible scaling and expandability thanks to its open source nature, but it can be complicated to set up, and especially to maintain in the long run. Amazon EKS works to solve a lot of the complicated parts of running a Kubernetes cluster by delivering a managed control plane, across multiple data centers for high availability and taking care of availability and scaling, as well as automatically detecting and replacing unhealthy control plane nodes. EKS gives you the flexibility of Kubernetes, without necessarily requiring an entire infrastructure team to manage your cluster. It also makes it much easier to integrate and authenticate with other AWS services.

Databases

In most cases, you not only need a compute service, you also need somewhere to store your data. Amazon provides multiple database services depending on your needs:
- After having spent a number of years working with databases in AWS, I cannot emphasize enough how much I recommend Amazon Aurora if you’re running MySQL or PostgreSQL in production. Amazon Aurora takes the concept of a managed database to the next level, and automates replication across multiple availability zones, or regions, distributed storage, and has incredible performance. No longer do you have to worry about scaling out, or increasing database storage - Aurora takes care of it all. For production, we’d go for Aurora in 10/10 cases.
- For smaller projects, development, or if you need OracleDB, MSSQL or even some custom databases, Amazon RDS is a managed database service, abstracting away the need to maintain the database server itself, and making it incredibly easy to maintain a database. You still need to provision capacity and monitor it, but it is still an amazing service in order to avoid having to maintain a database server.
- The last half a decade has also seen the meteoric rise of NoSQL databases. AWS offers a fantastic managed, Key-Value NoSQL database service known as DynamoDB. It features single-digit millisecond performance with nearly unlimited throughput and storage. It has encrypted data at rest, backup and restore and automatic multi-region replication. The storage is cheap, and is well worth a shot for projects that work well in NoSQL databases.
- Another good alternative for NoSQL workloads is Amazon DocumentDB with MongoDB compatibility. Built upon Amazon Aurora, and supporting MongoDB 3.6 and 4.0 APIs, DocumentDB allow you to manage your database in JSON with incredible performance and AWS tooling support.

On top of all the traditional database types, AWS also has a number of other databases such as Amazon ElastiCache with support for Redis and Memcached, graph databases with Amazon Neptune, data warehouses with AWS Redshift and more. All of these are well documented and often require some special use case, so I’m not spending much time on them.

Thoughts about Vendor Lock-in

A lot of these services mentioned in this post are Amazon proprietary software, and a question we get a lot when working with cloud, is customers being worried about being locked into a vendor and not being able to move to a different cloud vendor at a later point if needed.

This is very much a valid concern that the business needs to consider when building their cloud infrastructure, and I’ll provide a few observations from my years working with all three major cloud vendors.

As long as you’re working with a cloud vendor, you will always have a lot of features that you are required to use, that are cloud proprietary. Examples of this include IAM and account provisioning, VPC design, database design (unless you run your own database as a VM - and if you do that: why are you in the cloud, and not just in a datacenter…) (also note, this does not include data!) and a lot more.
Making sure you’re declaring all of your cloud infrastructure in a cloud agnostic IaC language will mitigate a lot of these issues.
Your data is almost never locked in, but how you manage that data might be to some degree or another. However: no matter what cloud you use, and what service you use in that cloud, migrating that data OUT of any cloud vendor, will be insanely expensive if you have more than a few TB of data. We’re talking tens if not hundreds of thousands of dollars in data egress cost depending on how much data you got. Most cloud vendors, including AWS, have migration tools you can use, to very easily migrate data into their service, meaning your data is safe. There are some caveats: AWS Lambda isn’t directly transferrable to Azure Cloud Functions without a rather large refactor. Moving from Google Kubernetes Engine to Amazon EKS will require you to refactor how your Kubernetes cluster integrates with other services, but migrating from an Azure managed MySQL database to a Google managed MySQL database, is not complicated - at all.
Very, VERY few companies ever migrate to another cloud vendor. I’ve seen companies build their infrastructure, avoiding the use of any cloud vendor native solution, but instead managing it themselves, to be cloud agnostic, yet never ever actually investigate migrating their infrastructure. Instead, they are paying many, many times more for their infrastructure than they need to. Managed infrastructure is often cheaper, and is absolutely cheaper when you start counting the amount of hours of maintenance they require.
Having a plan for what you need to do if you wish to migrate, is extremely important. It’s a plan B, incase AWS goes under, or Azure decides they no longer want you on their platform. Having spent a few hours thinking through, and writing down a sketch of what you need to do, in case you need to migrate, is extremely helpful. Additionally, writing down the reasons why you picked your cloud provider in the first place, can also help ease the doubts you might have later on, and reduce the stress of “what if we want to switch” years down the road.

For a vast majority of companies, a migration will be a costly job no matter how you design your infrastructure, including just using non-propriatorey solutions, so for most, it is much easier just to use the services you need to, in the first place and deal with it, if it ever becomes a problem. Trust me, your engineers will be much happier.

Conclusion

Amazon Web Services consist of a vast web of interconnected services, and with over 200 different services with confusing sounding names, it can be a very complicated and confusing area to get into. Starting with the basic services mentioned in this post, can be a great starter for a lot of users that are just getting into cloud computing. As with most AWS services, all the services listed here integrate very well with the rest of AWS and allow you to keep expanding on and further build your infrastructure.

Additionally, if you want to try out most of these services (EKS not included), AWS has a very generous free-tier allowing you to try out most services for free, without paying anything.

If you have recently started using AWS and want to know where to go from here, I highly recommend looking into the study materials for some of the AWS certifications. You don’t need to take the certifications if you don’t want to, but the materials for certifications such as the AWS Certified Developer - Associate give you a great introduction to a vast number of services in a short amount of time.

And if you're ever in need of help picking a service, or have questions about how you should run your crap - feel free to reach out to me!

How we migrated an entire AWS Organization to a new one, without anyone noticing.

Karl Mathias Moberg — Mon, 09 May 2022 11:23:06 +0000

Background

Usually when working with AWS, you typically either work with an existing AWS organization that already has guardrails and services in place, or you’re starting from scratch and building a new one. This last one however, is fairly uncommon and being in a situation where you need to establish these things yourself is something even consultants like myself rarely do. However, something that is even more infrequent, is migrating all the accounts from one organization or MSP to another. Amazon has excellent documentation on how to do some of these steps, but they are all typically from individual actions such as settings up a new organization, and not about moving like this.

So how does the process work, and how would you go about migrating from one MSP to another?

In this post, I will discuss how we migrated a production organization from one MSP to another, and try to keep in mind all the minute annoyances that are important to keep in mind when performing such a process.

Why are we doing this migration?

First, a bit of background on why we’re doing this entire process in the first place.

When the organization I consult for, first started to dip their toes into AWS and cloud production workloads, the parent organization already had an agreement with a MSP that had a good existing security framework and procedures in place. So with limited AWS competency in the organization, it was natural for the company to utilise the help available from the MSP and the guardrails they had in place. However, as the production workloads grew and competency and maturity in the organization grew along with the increased production workloads, the existing framework and procedures to get certain things done felt clunky and slow, resulting in less productive- and happy developers.

After doing more research, and figuring out the parent organization had reseller agreements with other partners that allowed for more options for us as a company, the decision was made - we were to migrate the entire organization to a new provider. This - as it turns out - is not a simple process…

Prep Work

In theory, AWS organizations are independent of the accounts, and it should be a simple process to move from one MSP to another. However, in reality, there are a lot of steps you need to complete before, during and after the migration. A couple of key things to remember:

In our case, the MSP had the responsibility for the accounts, and set the root email and MFA. This meant that because of how AWS accounts work, we needed to create unique email accounts (or aliases) for each account we owned. Not a huge problem, but if you’re using Office 365, each account can only have a very limited number of aliases meaning, we ended up with a huge number of mail accounts that someone needs to manage and keep track of.
MFA needs to be removed, and then re-applied. For a single account? No big deal. For 50+ accounts, this becomes real tiring, real quick. You also need to establish a system for keeping track of your MFA (or virtual MFA) devices, and which device belongs to which account - then, you need to secure these devices so no-one that should not have access to them, has access.
** You actually need to submit a PDF document to AWS where you need to apply to do the migration.** This takes time. You first need to contact AWS support, that sends you the PDF that needs to be signed by a valid signatory from both the outgoing MSP and the new owner, then sent back to AWS. Once submitted, it takes 2-4 weeks for them to process it. This is a step that a lot of MSPs are not aware of, and is vital you don’t forget…
In most cases, if the outgoing MSP had AWS Security Hub, Config, etc. security policies in place, they will most likely remove them before the move. This means you need to ensure you have a plan in place for how to deal with security in the new organization. This is a major task!
There are billing considerations to be taken as well, an AWS Solutions Advisor will give out specific details here, but it is recommended to do the migration on the last day, or the first day of the month.

With plans laid out for all these hurdles, we set a date for a couple of days where we would do the migration agreed upon by the outgoing and incoming MSPs, and AWS.

Migrating

The migration itself, turns out is a pretty smooth process, as long as you have done the prep work, and the outgoing MSP know what they are doing.

On each account, SCPs were removed, MFA was removed, the old organization was left, then invited to the new one. Once complete, a new MFA device was added to the root user to complete the initial migration.

On average, it took somewhere between 5 - 20 minutes per account we migrated, depending on how many policies were applied to the account and was an incredibly smooth process. The biggest annoyance was reapplying MFA, which is not fun when dealing with this many accounts.

In the end, we spent about a day and a half migrating all accounts, with zero downtime for any applications, and no users noticing that we even did anything, except that guardrails that had been in place were gone.

Post Migration

With the main migration complete, the next step is to establish and rebuild new SCPs, AWS Control Tower, and Guardrails to meet the standards of the new organization.

Although this is a pretty smooth and straight forward process, we discovered one major hurdle that was pretty annoying. AWS Config uses “Delivery channels” and “Configuration Recorders” to do it’s thing, but didn’t automatically delete these when Config was removed. You need to manually remove them. No big deal, right…? Except that they are applied to each region AWS Config is enabled in, and can only be removed via the AWS CLI or SDK… “No big deal”, you say, AWS Config can just overwrite the existing ones? Nope. They need to be removed. One by one. In each region. Note, you only need to remove the default ones, if you have your own custom, they should be fine.

This can somewhat be automated, but you need to swap credentials between each account, so it isn’t amazing.

Checking if channels and recorders exist for the account

aws configservice describe-configuration-recorders
aws configservice describe-delivery-channels --region eu-north-1

Deleting potential objects - note, you need to do this for EACH region:

aws configservice delete-configuration-recorder --configuration-recorder-name default --region eu-north-1
aws configservice delete-delivery-channel --delivery-channel-name default --region eu-north-1

Once each recorder and delivery channel are deleted, you can enrol the account in AWS Config and Control Tower again!

Conclusion

Migrating an entire AWS Organization from one MSP to another takes a lot of time. It isn’t necessarily that much physical work, but there is a lot of waiting for each step in the process to complete, and there are a lot of them.

However, if you do the prep work prior to the migration starting, creating a plan and ensuring everything is in place prior to the move, it turns out it can be a pretty smooth process!

I highly recommend reaching out to an AWS Solutions Architect prior to such a migration so they can oversee the process and ensure that it goes smoothly, because there are a lot of steps that can be screwed up, and could lead to potential problems. Fortunately, in most cases it should be pretty simple!

Why Terraform is the perfect lab companion - and how to use it on AWS!

Karl Mathias Moberg — Mon, 18 Oct 2021 08:52:27 +0000

Have you ever wanted to quickly spin up one or more virtual machines, then take them quickly down afterwards, but have been frustrated by the amount of manual work it is to set up a server, configure ports and make sure it works?

Infrastructure as Code (IaC) is here to save the day!

There are several IaC tools out on the market, available to everyone, Amazon Cloud Formation, Terraform, Pulumi, and to some degree Ansible and Packer all provide a way for you to declare what you want your infrastructure to look like in code, then run a command or playbook, then the tool will set it up for you!

How is this relevant to you in your lab? IaC tools will allow you to very easily declare what you want your infrastructure to look like and very quickly have it available to you, be it in the cloud or even in on-prem environments.

Unlike some of it’s competitors, Terraform is a declarative language, meaning you tell Terraform your desired state, and it will deploy everything to make sure it matches your request. If you say you want two Ubuntu instances, Terraform will spin up two instances for you. However, unlike some other alternatives, if you run the command again - Terraform will not spin up two MORE instances, because it knows two instances already exist. If you manually terminate one instance, then run Terraform again, it will spin up a new single instance, to ensure that the environment matches your desired state. Pretty cool, right?

In addition to being super useful for managing home labs, Terraform is quickly becoming extremely popular in businesses, especially ones moving to the cloud, so learning a bit of Terraform can give you a huge leg up on competitors in your next job search!

Honestly - Terraforms own documentation and tutorials are first-class, and extremely well written, so there really is no good reason to reinvent the wheel here, but even so I will give you the absolute bare minimum you need to get started with your first Terraform project for your home lab.

Installing Terraform

Installing terraform is extremely easy, no matter what operating system you’re on.

MacOS

If you’re on a Mac, you really should get the [Homebrew] package manager. It will make your Mac-life a whole lot simpler.

With Homebrew installed, all you need to do is run:

brew tap hashicorp/tap

This installs the Hashicorp (the makes of Terraform) Homebrew tap, allowing you to download their tools.

Then run:

brew install hashicorp/tap/terraform

To update Terraform (and any other tool you’ve installed through Homebrew), just run:

brew update

After installation, you should be able to run

terraform -help

to verify that Terraform is available in your path.

Windows

If you’re on Windows, you really should get the [Chocolatey] package manager. Just like Homebrew on MacOS, this package manager, can make your life a whole lot simpler.

With Chocolatey installed, just run:

choco install terraform

You can then verify that terraform is working by running

terraform -help

Deploying a simple instance in AWS

Before you can deploy anything to AWS, you need to have the AWS CLI installed and configured with credentials first. If you don’t, Terraform won’t be able to authenticate with AWS. Terraform will look for valid credentials in ~/.AWS/credentials on MacOS and Linux and in %UserProfile%\.AWS\credentials on Windows.

Make a new project where you will run your code out of, and change into it, then create a new file named main.tf

touch main.tf

Open this file in any text editor and add the following configuration:

terraform {
    required_providers {
        aws = {
            source  = "hashicorp/aws"
            version = "~> 3.27"
        }
    }

    required_version = ">= 0.14.9"
}

provider "aws" {
    profile = "default"
    region  = "us-west-2"
}

resource "aws_instance" "app_server" {
    ami             = "ami-830c94e3"
    instance_type   = "t3.micro"

    tags = {
        Name = "MyTestInstance"
    }
}

This is all you need! For more information about what each individual line does, refer to the AWS documentation, but there are a few key points to take note of here:

region = “us-west-2” We’re deploying this instance in the US-West-2 AWS region.
ami = “ami-830c94e3” This is the AMI or “Amazon Machine Image” we’re using. Keep in mind - this is a static ID for an AMI, and each AMI is only available in a SINGLE region. This means: If you’re trying to deploy this same code in a different AWS region, you need to change the AMI ID to a corresponding AMI from the region you’re using.
instance_type = “t3.micro” is one of the smallest AWS instances, with 2 vCPUs and 1GB RAM. This instance is eligible for the AWS free-tier.

Now, save the file, and return to the command line and run

terraform init

Great! Terraform is ready for use. To deploy, use

terraform apply

Don’t worry, you’ll get a confirmation of what Terraforms plan to do before it actually creates anything.

From this prompt, we see that Terraform plans to 1 to add, 0 to change, 0 to destroy. You can see additional information as well. To execute the change, type yes which will tell Terraform to commit the change.

Once it completes, you can run

terraform show

which will show you the current status of your infrastructure.

Amazon Machine Images

As I previously mentioned, when starting up a virtual machine, you need an AMI or Amazon Machine Image. This is a snapshot of a system in time which you can get access to in a multitude of ways. If you just want a clean system, you can use one of the provided images that are available through AWS EC2. If you want a specific piece of software, a lot of companies offer their software such as Cisco Firewalls, N2WS Backup software, pre-configured Kali Linux images and more. Some of these providers charge you extra for the usage, some are free, but if you want - you can also create your OWN AMIs! 
To create an AMI, you first spin up your base image that you want, then install and configure the machine exactly to your liking - once that is done, you can, through the AWS console or CLI generate a new AMI from that system - a snapshot of exactly what that system looks like at that point in time.

With this in mind - what use can this be to us? Imagine if you regularly spin up a virtual machine with Apache and NGINX that you quickly upload code to, then take it down afterwards. Using an AMI, you can configure Apache and NGINX, then generate an AMI for it, and use that AMI-ID in your Terraform code!

Sample Lab with Apache

Using the example above, here is a primer for your lab. It will spin up TWO EC2, t3.micro instances, using an AMI we assume already have Apache and NGINX configured, opens port 80 and 443 making it available to the internet.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.27"
    }
  }

  required_version = ">= 0.14.9"
}

provider "aws" {
  profile = "default"
  region  = "us-west-2"
}

resource "aws_instance" "app_server" {
  count                       = 2
  ami                         = "ami-830c94e3"
  instance_type               = "t2.micro"
  associate_public_ip_address = true
  vpc_security_group_ids      = [aws_security_group.allow_web_traffic.id]

  tags = {
    Name = "MyTestInstance"
  }
}

resource "aws_security_group" "allow_web_traffic" {
  name        = "allow_web_traffic"
  description = "Allow inbound web-traffic"

  ingress {
    from_port   = 80
    protocol    = "tcp"
    to_port     = 80
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    from_port   = 443
    protocol    = "tcp"
    to_port     = 443
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    protocol    = "-1"
    to_port     = 0
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "Allow Web Traffic"
  }
}

We can now apply this using terraform apply and see our lab being created!

We can also confirm that everything is working as planned in the Amazon console:

When you’re done, remember to destroy the work using
terraform destroy

Don’t worry. If you want it back, just run terraform apply again, and you will be right back to the same starting point! However, any data you created on the server, EBS storage or other sources that gets destroyed will be gone.

Final Thoughts and Suggestions

Terraform is amazing for labbing. This is only an introduction, so make sure to check out Terraforms own documentation - it’s fantastic!

Where do you go from here? I highly recommend you create your own AMIs for what you want to do. It’s super simple to do from the AWS console, and saves you a lot of time. Just remember to keep updating your operating system and updating the AMIs every now and then to keep up with security updates.

This methodology for creating and destroying instances is extremely powerful and allow you to very quickly build an infrastructure, test your problem, then get rid of it. Most of it can be done on Amazons free-tier, and if not, the fact that you are destroying the infrastructure afterwards makes it very cheap.

How you can try out new technology in the cloud - for FREE!

Karl Mathias Moberg — Mon, 06 Sep 2021 13:17:18 +0000

Background

In IT, we do a lot of “lab” work. Trying new things, testing out a theory or an application that you have developed, or simply learning a new technology, such as Linux or Windows server.

This labbing can, of course, be done in a multitude of ways. On your computer, on an old server or even a Raspberry Pi! All of these methods work very well, however, they all have some downsides: your computer might run slowly because you’re running a virtual machine on top of your ordinary OS. Old servers consume a lot of power (and noise), and a Raspberry Pi might not support the software you want to run, or might not be powerful enough for your task. On top of all of that, a home server or Raspberry Pi might not be available to you from outside of home without configuring VPNs which adds extra complexity.

 There is however, a simple way to allow you to run your lab, from anywhere, for free* - in the cloud, using Amazon Web Services. AWS is the worlds largest public cloud provider, and according to [Forbes (2019)] it accounts for nearly half of the worlds public cloud revenue with almost every Forbes top 100 companies using AWS for some of their digital needs.

Ok, I hear you say, how does this benefit you and your lab? Well - Amazon offers one of the most generous free-tier offers for its new users out of all the large public cloud providers - a full year of free services! And if you know the limitations of the free tier, you can run clusters of virtual machines at a time if you want to try out auto-scaling instances, a platitude of databases, or want to crunch a dataset or two a month. Or, maybe you just want to host a website? You can do that too, for free, for a full year!

* = AWS offers a specific “free tier” of products for 12 months for new accounts with set limitations to usage per month. This does not include all products, but is limited to specific ones. We **strongly* recommend you configure a billing alert to warn you if any cost accumulate on your account. Refer to this post #FIXME to see how you can configure this sort of alert.

The AWS Free Tier

Amazon Web Services (AWS) has one of the most generous free tiers of the major public cloud providers. It offers a mix of over 100 always free and 12 months free products that you can use to your hearts content to lab out your new applications and it is important that you understand how the free tier works, if you want to avoid being charged for your AWS usage.

Product Naming

If you have never used AWS before, there are some common names you need to be aware of before we get started. And yes - AWS naming of products can be... Hard to understand. If you already have experience with AWS, you can skip this section. (Note: If you already have experience with AWS, you can skip this section.)

Amazon EC2 is the AWS Virtual Machine service. Ever created a virtual machine in VMware, Hyper-V or Azure? This is the same thing. An “EC2 Instance” refers to a virtual machine. Oh, and since it’s called EC*2*, you might think there was an EC1 at some point? Nope. EC2 stands for Elastic Compute Cloud = EC2.

Amazon S3 is for object storage. What does object storage mean? In S3, you can store images (I use it to store and serve all my screenshots out of), documents, config files, text files, you name it. If it is an object, you can store it here. However, keep in mind, it is NOT a file system! So what happened to S1, and S2 you might say? Again, never existed. 🤦‍♂️ S3 = Simple Storage Service.

AWS Lambda a serverless compute service. Ever wanted to write a function or an API without worrying how to run it? Write a lambda function! The code can be triggered multiple ways, and will run, without you ever configuring a server!

Amazon RDS, AWS managed Relational database service! Not only does it save you from having to become a Windows or Linux server guru just to get a simple database running, it might also even be cheaper with out the overhead of having to have an operating system as well. It also out of the box supports scaling, high availability, and can be much more secure than you having to become a leet hacker yourself.

DynamoDB SQL not your thing? DynamoDB is for you then! A NoSQL database with MongoDB support! If you ask MongoDB, they’ll say that their cloud offering is much better than DynamoDB, and you can’t compare the two, but from experience... DynamoDB is pretty good for 9 out of 10 use cases!

VPC, Virtual Private Cloud. A VPC allows you to segment your resources into multiple networks, completely segmented from each other. Think of this, kinda like a VLAN, except it’s not a VLAN. Confusing, I know, but you don’t need to worry too much about it for now.

And that’s only barely touching the surface of AWS products. As of writing, in September 2021, there are over 200 AWS services, with more being added almost monthly. In 2020, a fantastic [YouTube Video] was made of every AWS product. The week after it was made, another 10 services were launched.

Free Tier Offers

For the most up to date, and complete list of current free tier offers, make sure to check out Amazons own page on the different products. Keep in mind that although this article does list a few, very long running and most common free tier offers, they may change at Amazons discretion, so make sure to double check [https://aws.amazon.com/free/] for the up to date info.

Amazon EC2: t2/t3.micro - 750 hours/month for 12 months.
AWS offers you 750 hours per month, for 12 months. You can chose to spend these 750 hours however you like, if you want to run 10 instances for 75 hours, or 75 instances for 10 hours, you can do so, or you can run 1 instance for an entire month, 24/7. This offer is limited to the t3.micro instance, which is equivalent to 2 vCPUs and 1GB RAM. Before you think that this is not enough: A single t3.micro instance, can easily serve a hundred thousand monthly web users, if configured well and using managed RDS.

Amazon RDS: t3.micro - 750 hours/month for 12 months.
Same deal as with EC2, you can run a single DB server 24/7 for a month or 75 instances for 10 hours. Combined with an EC2 web server, this combination is very powerful.

AWS Lambda: 1 million free requests/month, always free!
Pretty self explanatory! 1 million requests a month for free! Always!

Amazon S3 5 GB storage for 12 months.
You get 5 GB of object storage for free, however, one metric to keep in mind here is that you do get a limited number of GET and PUT requests: 20,000 GET **requests, **2,000 PUT requests.

Again, there are over 100 products available on the free tier, so make sure to check out Amazons page to see details on each subject.

Before We Get Started

With an understanding of how the free tier works, it’s now time to get started with some labbing!

There are two ways to follow along with the labs in this article:

Follow along in the AWS Console, and click the appropriate buttons to complete the configuration.
Use the AWS CLI for your operating system. Everything you can do in the AWS Console, you can do with the AWS CLI from your computer. Learning the AWS CLI can be very useful and allows for scripting of commands and automatically building and tearing down configurations once you are done.

There is nothing wrong with either alternatives, and they are both perfectly legitimate ways of interacting with AWS. In fact, most people work with a combination of both tools depending on what task they are doing. However: We do recommend that you configure your AWS CLI and try it out, even if you want to primarily use the web console, as there are some things, like CloudFormation that require that you use the CLI.

Terraform

Finally, there is one more way to do all configuration, which I will touch on in a separate article, as it is another huge project in and of it self - Terraform. Terraform is an Infrastructure as Code (IAC) tool, a declarative programming language that allows you to tell the code what you want it to look like, then it will do the work for you. You can tell it to start a specific instance, with X storage and Y RAM etc. and it will do it for you. It will also allow you to destroy everything, with a single command line command. THIS is what makes labbing in the cloud extremely easy. Watch out for part two of this article series for that!

Let’s get labbing!

In the first drafts of this blog, I had a step-by-step guide included directly in the post, but it very quickly becomes very overwhelming in a post, so as a result, I'm going to link to the same workshop over on GitHub: https://github.com/Bergen-Cloud-User-Group/01-Introduction-To-Cloud-Computing/tree/master/Workshop/01%20-%20Stage%201

I recommend you try it out over on GitHub, as it is a great and fun exercise to try out! Good ouck!

Installing the AWS CLI in MacOS Sonoma

Karl Mathias Moberg — Mon, 30 Aug 2021 13:26:36 +0000

Installing the AWS CLI in macOS Sonoma

This process works on macOS 10.13 or newer, including macOS 12 Monterey, Ventura, and Sonoma.

Amazon Web Services (AWS) has posted a guide on their website on how to install the AWS CLI on macOS, however, it is mostly a manual installation, and require the user to manually configure their .bash_profile, adding a path value making it for a complicated experience.
I'm here to tell you - it doesn't have to be this hard. In fact, if you have some prerequisites already installed (which you in many cases do), it's a one-line command to install it.

Brew

If you already have the brew command line tool installed, you can skip this entire section. If you have never heard of Brew, here's the TLDR:
Homebrew or simply Brew, is a package manager for macOS, much like APT, YUM or RPM for various Linux distributions. Unfortunately, macOS doesn't come with one, so Brew has become the defacto standard for most developers and Apple Powerusers. Brew allows you to run a single command to install and manage a myriad of different tools such as the AWS CLI with a simple search instead of having to manually download, install and in many cases package and configure the application. Brew does it all for you.

You can find complete documentation for Brew on their website: brew.sh, but the way to install it is using:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Note that if the installation should fail with errors such as missing developer tools, you must first install the xcode tools. You can do this using:
xcode-select --install

Installing the AWS CLI

With Homebrew installed, we can move on to installing the actual AWS CLI.

brew install awscli
Press “Y” to accept the install if required.
It's that simple. For most users, the CLI is now installed, and you can verify the install using:

aws --version

Potential Error Messages

Some users may encounter an error message after Brew has finished installing, saying:

Warning: awscli 1.16.250 is already installed, it's just not linked.
You can use brew link awscli to link this version.

To fix this, do as the error message says, and run:
brew link awscli
This should fix the issue.

Where To Go From Here

Now that you have Brew installed, I highly recommend you check out the package [cask]. Cask is a brew extention that allow you to manage your normal graphical applications such as Firefox and many more. While this sounds stupid to beginwith, intalling applications from cask, allow you to one-line update all your applications without having to go each applications website and download the updates manually - even better? No GUI updater that you need to go through. Check it out!
Have you already been using Brew and cask and have tips? Leave them in the comments below!

MySQL charset (255) unknown to the client in MySQL and AWS RDS

Karl Mathias Moberg — Sat, 20 Mar 2021 23:47:58 +0000

Struggling with a strange MySQL error when connecting to MySQL Version 8?


 Server sent charset (255) unknown to the client. Please, report to the developers

Turns out this error is related to how MySQL sets the default charset to utf8mb4, which isn't known to a lot of the worlds programming languages such as PHP < 7.3 (?), C++/MySQL connector etc. which can be a bit frustrating to fix, having to be forced to upgrade the application.++

There is, however a simple fix! If you're hosting your own MySQL database, you only need to change the MySQL Config file (/etc/my.cnf) to the following:



default-character-set=utf8

[mysql]
default-character-set=utf8


[mysqld]
collation-server = utf8_unicode_ci
character-set-server = utf8

Once that is done, restart mysqld and you should be good to go, however, if you're using AWS RDS, you do not have direct access to the MySQL config file. Fret not! There is a way to fix this too! You need to configure some DB Parameter Groups which will allow you to add the parameters we need. This can be done either from the console, AWS CLI or RDS API. Reference the AWS Documentation for more info.

Start by navigating to the Parameter Groups menu on the left and click to Create parameter group.

Give the group a new name and description, and make sure that the group family is mysql8.0. Create the group, then navigate back to the group's page and click the newly created group.

Click Edit parameters in the top right to start modifying the parameters. In the filters box, search for "CHAR". You should set the following:

Character_set_client = "utf8"
Character_set_connection = "utf8"
Character_set_database = "utf8"
Character_set_server = "utf8"

Finish by saving the changes. Now navigate back to your database, and click the "Modify" button to make changes to the configuration of the RDS instance.

Scroll down to locate the Database options then locate the DB parameter group and set it to the group you just created. Scroll down to save.

Important!

When applying the changes, you WILL be asked when to apply the changes. This can either be done in the next maintenance window, which could be far in the future, or you can set it to happen immediately. If you set it to immediately the MySQL instance will become unavailable wile it applies the changes! This can take from a few minutes up to 10-15 minutes.

In addition to this you must do a restart of the RDS instance to ensure that the database has been updated with the changes. This will also make the MySQL instance unavailable while it is restarting!

However, once you have restarted the instance, you should now be able to connect to the instance using older programming languages once again!