Justin, let’s jump right in. What do you do as a Sr. Developer Advocate at AWS, and why did you choose to go down that route after being an engineer?

I am part of the EKS service team at AWS so I’m part of the feedback and prioritization efforts to make our container services better for customers. I’ve worked as an engineer at various companies before this and being a developer advocate lets me stay in touch with my developer roots, and it gives me the opportunity to take an active role in the Cloud Native and Kubernetes communities.

My previous engineering roles were focused on internal engineering efforts, and I wanted a role that would give me freedom to help the community and customers with non-code resources like blog posts, videos, and workshops.

How did you start your real-world experience with Kubernetes and what have been the most important changes since you began working with containers and orchestration?

I was trying to solve problems to allow development teams to ship applications faster and make the infrastructure more reliable. I was looking at containers because the VMs with configuration management we were using at the time weren’t enough.

We started with a handful of container hosts which worked well and I became the human orchestrator. This worked until I wanted to take a vacation and we needed to scale some of our applications. That’s when the need for a software orchestrator made a lot of sense to me.

The biggest changes with Kubernetes since then have been the ecosystem. So many new features and projects have emerged. Some fix pain points with existing infrastructure and others solve problems in Kubernetes native ways.

Where do you see Kubernetes going in the next five years? What excites you the most?​

Kubernetes is starting to be invisible for a lot of organizations. This is great because it is becoming so ubiquitous and reliable that we don’t need to think about it anymore. When I drive to the store I don’t think about the engine or cylinders. I only think about pedals and steering.

Kubernetes is the engine for a lot of people’s infrastructure, but the interface to the engine abstracts away the details. If we switch to gas, or hybrid, or electric engines the user doesn’t worry about it because their interface is still the same.

That’s the part that excites me the most. Kubernetes was intended to be extended but it keeps a similar interface for the user. More things are able to be controlled through the Kubernetes API with controllers that we can help people focus on driving.

I’ve seen you writing about dockershim being deprecated. Can you give a brief overview of that for some of the less experienced readers, as well as explain the repercussions?

Many users want to run docker commands from inside their workloads for things like building containers or monitoring. Running docker inside a docker container requires a way to communicate with the docker engine on the host which is usually accomplished by mounting the docker socket.

When Kubernetes first started it was tightly coupled with the docker engine for running containers through code in Kubernetes called the dockershim. As the container ecosystem matured, alternative container runtimes became available with unique features and the Container Runtime Interface (CRI) was developed to help users pick whichever runtime they wanted. New container features can be developed in the runtime and Kubernetes only needs to use the CRI to run them, but for docker engine, Kubernetes still needs to use the dockershim code.

The dockershim code is being removed from Kubernetes in favor of runtimes that support the CRI interface. This means that to build containers from inside Kubernetes pods, users will need to move to different build tools that do not require the docker engine or run instances outside of Kubernetes that run the docker engine.

I built a tool for users to check their clusters to see if any workloads are mounting the docker socket volume to make sure they are not affected by this change. You can find it at this link: https://cftc.info/dds

Regarding scaling, how is Karpenter an improvement over past autoscaling technologies such as Cluster Autoscaler? Are there distinct advantages to using it with a comprehensive service like EKS?

Automatically scaling Kubernetes nodes works similarly to scaling workloads. If you don’t have enough resources you should add one (or more) nodes. This has worked great for clusters that have similar workload needs.

Workloads are not always similar and don’t always need the same thing. Some workloads need ½ a CPU and 1 GB of memory while others need 8 CPUs and 16 GB of memory. The only way to have both of those workloads run in the same cluster is to either pick the largest workload requirement (e.g. machines with at least 8 CPUs and 16 GB of memory) or create separate node groups for each workload. This gets more complex when you have multiple CPU architectures (e.g. arm) and compute accelerators (e.g. GPUs). The amount of configurations and groups you need to configure and autoscale grows rapidly.

Karpenter is groupless. Nodes are created directly for workload needs without any pre-configuring. I like to call it “workload native” because whatever the workload needs is what it gets. This opens up the possibility for more variety of workloads and lowers the overhead for management.

Karpenter works great with EKS to lower the complexity required to run a Kubernetes cluster. With a fully managed control plane and a workload native data plane the operational burden goes down a lot. Application developers can get the right sized resources when they need it. It’s a project I’m really excited about and think it can help companies scale and manage their clusters better than the traditional “one size fits all” approach.

It’s best to solve technical problems with technical solutions and people problems with process, but identifying which is which is not always easy.

In general, do you think the challenges of using a multi-cluster architecture (when warranted), outweigh the challenges? What are some types of situations that warrant a really sophisticated multi-cluster architecture?

I often tell people not to use Kubernetes unless they have a Kubernetes problem. The same goes for using lots of Kubernetes clusters. Don’t create 20 clusters until you’re able to maintain two. Don’t run 100 clusters until you know you need to.

The problems users are solving with dozens or hundreds of clusters can be everything from availability, localization, or internal company process. Sometimes it’s easier to create 50 clusters than it is to change a legacy policy. Figuring out which problems you’re solving with multiple clusters is always a good start.

It’s best to solve technical problems with technical solutions and people problems with process, but identifying which is which is not always easy. If you have problems of workload isolation, multi-region deployments, request latency, or incident blast radius, then running multiple Kubernetes clusters is probably a good option. If you have problems of slow upgrade cycles, varying application stability, deployment delays for review boards, or it takes weeks to deploy an application update then multiple clusters will exacerbate the existing problems.

What are some of the main challenges with massive scale Kubernetes?

Scaling Kubernetes has similar problems to scaling servers. If you use more compute resources you’ll run into limits like open file limits and PID exhaustion. If you scale horizontally and add more servers then you have to synchronize configuration, patching, and help processes coordinate. Kubernetes has similar problems. Some people use large, shared clusters and others use lots of smaller clusters. There’s no right answer for everyone which makes it difficult to know which option is best for you.

Some of the solutions we’ve created with Linux servers (e.g. configuration management) can apply to Kubernetes, but there are new interfaces which create new challenges. Many companies use service providers to avoid needing to deal with lower levels of abstraction. You don’t have to rack and stack servers any more if you move to the cloud. You don’t have to manage the Kubernetes control plane with Amazon EKS, and you don’t need to patch servers if you use compute options like AWS Fargate. It doesn’t eliminate all of the challenges, but it greatly reduces your responsibility.

Does EKS do anything special as the cluster scales in terms of adjusting the cluster configuration as the number of nodes and/or the number of pods increases?

There are multiple areas where Kubernetes needs to scale as clusters get larger with more nodes or workloads. There’s the API server which is the main point of communication, but there’s also the etcd database and controllers. EKS handles control plane scaling automatically for customers as the clusters require it.

We help solve pain points for Kubernetes that are not part of EKS. Customers can use Fargate as serverless and isolated workload compute. We built Karpenter to help simplify EC2 instance selection and management, and we’ve created AWS Controllers for Kubernetes (ACK) which help developers provision additional AWS infrastructure without leaving the comfort of kubectl.

We know many customers have use cases for Kubernetes outside of an AWS region. We support AWS Local Zones and AWS Outposts for EKS worker nodes and EKS Anywhere to create EKS clusters on customer owned hardware.

All of these environments have different constraints and scaling properties. We make it easier for customers in each use case to run Kubernetes the way they want.

How do users gain confidence in EKS to use it for their different use cases?

One of the cool things about EKS is how much of it is open source. You can look at what we use for Kubernetes binaries through the EKS Distro project. This project powers all the different deployments of EKS. You can download them and use the same binaries we use. If you want to use our container native operating system Bottlerocket, it’s open source and you can build your own copy of the OS from scratch.

We know some customers want the ability to see what goes into their infrastructure. It helps build trust and allows us to show exactly how we manage Kubernetes at scale.

The post Scaling Kubernetes with an AWS Senior Developer Advocate appeared first on Cloud Academy.

Docker is about developing and shipping applications within containers – also known as Docker images – while Kubernetes is high-level orchestration to potentially billions of these containers. They’re different but complementary and work well together in large-scale, complicated deployments.

As we discuss the differences and advantages of each platform you’ll understand the big picture and be able to learn more with in-depth resources to get you both book knowledge and hands-on experience.

What are containers?

To better understand the merits of Kubernetes vs Docker, it’s helpful to take a step back and get comfortable with the concept of containers in application development and deployment. 

A container is a unit of software that bundles code and all dependencies together so that the application can run quickly and reliably in any computing environment.

Containers can be described as lightweight virtual machines. Virtual machines require you to virtualize the entire operating system and any software you wish to run. This makes VMs very resource-intensive.

Containers were introduced by the Linux operating system to address this problem. It’s simple: if you already have a Linux OS running on your computer, why not create a new OS for each VM using that OS? You can instead use the core OS (called the kernel) for each VM. So, VMs can only run the software they are required to.

Containers are helping teams of any size to resolve issues such as consistency, scalability, security, and scalability. Containers such as Docker can be used to separate the application and the underlying infrastructure.

What is Docker?

Docker allows you to separate your application and the underlying infrastructure. It bundles up your code with all its dependencies into one self-contained entity which will run on any supported system.

Advantages and disadvantages of Docker

Besides being the most popular platform and the defacto standard for container images, the benefits of Docker are the benefits of containerization: 

Advantages of Docker

Docker (i.e. Docker Compose) is portable, scalable, and has increased security from being isolated. This may be a different setup than what you’re used to, which leads us to some of Docker’s cons.

Disadvantages of Docker

It’s true, containerization does have some disadvantages. The naysayers say that they’re not as slow as running on bare metal, the ecosystem is general is a little all over the place and fractured, there are challenges with persistent storage since the container can be moved / is modular, and some applications (especially monolithic ones) would perform badly with containers.

What is Kubernetes

Kubernetes is the current standard in container orchestration systems.

Kubernetes makes it easy to manage and deploy containers at a large scale. Google developed it based on years of experience with containers in production. Kubernetes gives you a toolbox that automates scaling and operating containerized apps in production.

Advantages and disadvantages of Kubernetes

The advantages of Kubernetes are everything we’ve reviewed above, including:

• load balancing
• automatic packaging
• self healing systems
• powerful for CI/CD methodologies
• sophisticated orchestration of complex deployments

Kubernetes does have some disadvantages, which are the flipside of all the pros listed above:

• can be too much of a solution / overkill for all but the larger deployments
• can be slow to implement and have a learning curve
• its sophistication brings added complexity to a project

What’s the difference between Kubernetes vs. Docker?

As referenced at the start of this post, the difference between Kubernetes and Docker is pretty big. When people mention Docker, they’re usually referring to Docker Compose which is used for creating individual containerized applications. Docker Compose has become the standard so people just throw around the term “Docker” for shorthand.

Kubernetes is an orchestration system where you can control all your container resources from one single management plane.It was originally created by Google to monitor and control large (i.e. billions) of containers and is now open source.

Kubernetes vs. Docker Compose

When people ask “Kubernetes vs Docker” they really mean Docker Compose, the core Docker product which allows you to create containerized applications. When thinking about your options, a good question for yourself can be, “Why not both?” With the two technologies, you’ll be able to isolate applications as containerized systems and orchestrate huge numbers of them in a safe and dependable way.

Kubernetes vs. Docker Swarm

Docker Swarm is the container orchestration system from Docker, so comparing it to Kubernetes is much more applicable than saying “Kubernetes vs Docker Compose”. Docker Swarm is a more lightweight and simpler orchestration system than Kubernetes, but it lacks strengths that Kubernetes had in automation and self-healing – features that can be important to huge deployments.

Kubernetes vs Docker certifications

Kubernetes has more certifications than Docker, but since the two technologies are different it’s still useful to be familiar with the certs from both. Below are resources to get you familiar with Kubernetes and Docker certs.

Kubernetes certifications 

Certified Kubernetes Administrator (CKA) Exam Preparation

This learning path covers all the general domains of the CKA certification exam. This series of courses, labs, and exams is for cluster administrators who already have familiarity with Docker.

Certified Kubernetes Application Developer (CKAD) Exam Preparation

This learning path covers all domains of the CKAD exam. This is intended for Kubernetes application developers, but is also useful for anyone who wants to learn how to work with Kubernetes.

Certified Kubernetes Security Specialist (CKS)

CKS certification demonstrates that the person has command over securing the Kubernetes technology stack. CKA certification is required before you sit for the CKS.

Kubernetes and Cloud Native Associate (KCNA)

The KCNA is a foundational-level certification that helps learners progress to the more advanced Kubernetes certs: CKA, CKAD, and CKS.

Docker certification

Docker Certified Associate (DCA) Exam Preparation 

This learning path covers six DOcker domains, allowing you to become proficient in Docker orchestration, security, etc. Ideally, Docker recommends 6-12 months of experience with its technology before you start a certification course.

Resources: Learn about Kubernetes, Docker, and microservices

Building, Deploying, and Running Containers in Production

This Learning Path will show you how to engineer and operate containers in production-like environments. The Learning Path will begin by introducing you to Docker containers and then move on to concepts such Dockerfiles. You’ll learn the entire process for container development and deployment. This Learning Path ends with you building, deploying and testing your Kubernetes cloud-native containerised application.

Introduction to Kubernetes

This learning path is for anyone who wants to manage containers at scale. By the time you’re done, you’ll be able to use Kubernetes to manage containers, as well as deploy a stateless and stateful application.

Docker in Depth

Learn all about Docker from individual containers to continuous deployment of an application in AWS.

Building, Deploying, and Running Containers in Production

With this learning path you’ll get a taste of engineering and operating containers in production-like environments, culminating with building, deploying, and testing your own Kubernetes cluster.

Python based Microservices – Go from Zero to Hero

Learn the basics of designing, building and deploying production-grade microservices using Python, Flask, and Docker containers. 

FAQ

Can I use Kubernetes without Docker?

Technically, yes you can use Kubernetes without Docker as long as you have some other kind of container runtime. A couple of options are containerd and Podman, though Docker is by far the most popular container platform.

Is Kubernetes free?

Yes, it’s free if you use the completely open source version available on its GitHub repository. A lot of users end up preferring to use the Kubernetes offering that is bundled with other services, libraries, platforms, etc. on the big cloud offerings. Some even have more fully-managed offerings that are helpful but more expensive.

Should I learn Docker or Kubernetes first?

Yes, it’s a good idea to start with the smaller part of the system: the container (Docker Compose) and then move up to the orchestration system (Kubernetes). But if you’re passionate and curious, by all means, jump into both at the same time to see where your learning takes you.

Are containers outdated?

Not yet. They’re still valuable to microservices-based architectures even though they’ve basically been around as long as virtual machines. Some people thought they would be replaced by serverless or no-code solutions but those tend to solve different solutions at different scales.

The post Kubernetes vs. Docker: Differences and Use Cases appeared first on Cloud Academy.

Welcome back!

This tip is more of a strong recommendation than anything else. 

Since the CKA and CKAD focus so strongly on your ability to prove that you can administer, or develop in a cluster, I wanted to take the time to point out that you can actually practice, free of charge, on live kubeadm clusters in the cloud with Play with Kubernetes.

All you need is a Github Account or a Docker Account.

After you authenticate, you can immediately start interacting with a cluster that was created with kubeadm by clicking “ADD NEW INSTANCE” on the left-hand side.

So, after going through our own course content, I spun up three instances with Play with Kubernetes, and practiced exam topics on the CKA rubric. This gave me real-world experience, with several nodes in the following:

• Cluster Architecture, Installation & Configuration
• Workloads and Scheduling
• Services and Networking
• Storage

Coincidentally, these happen to be four of the five sections on the exam. And I can wipe the instances and start from scratch if I want to, ensuring that I have a good understanding of these topics. In fact, I used my bookmarks to prep for a real exam by working through each individual category and subcategory, using fake questions like “How do you create a persistent volume?” and “How do you attach a sidecar container to another container?” By going down that list one at a time, I easily beat the two-hour limit that the CKA imposes (you get four in Play with Kubernetes), and I ended my actual CKA exam earlier than I thought after double-checking my answers.

So what are you waiting for? Get cracking on those instances and feel confident that you can walk into your exam day well-prepared.

The post Micro-Blog 3 of 3 – Read These Before You Take the CKA: The Cloud Is Just Someone Else’s Computer appeared first on Cloud Academy.

Welcome back to the micro-series on preparing for the CKA exam. This series is going to equip you with several tips and tricks that will help you navigate the exam and its common pitfalls so you save time and get to answering questions.

Let’s kick off this second round by focusing on what we ought to do after we clear the exam space requirements with the proctor:

HACK. TIME.

Well, no. Not really. But we are going to have a six-step process that will immediately save us time over the course of the exam.

The first thing we’ll do is navigate to the cheatsheet provided in the kubernetes.io documentation. It has some commands we can copy-paste straight into the terminal to gain an advantage. Specifically, these four:

source <(kubectl completion bash) 
echo "source <(kubectl completion bash)" >> ~/.bashrc 
alias k=kubectl
complete -F __start_kubectl k

There are two more not listed above that will speed up yaml creation if we need to create a resource from scratch:

Echo ‘alias kdr=”kubectl --dry-run=client -o yaml”’ >>~/.bashrc
Echo ‘complete -F __start_kubectl kdr’ >>~/.bashrc

Let’s break these commands down:

The first enables auto-completion provided for Kubernetes in the current shell. And the second adds it to the bash profile for perpetuity in case you need to resource your shell.

The third sets up an alias for kubectl to be invoked as k.  And the fourth makes sure that autocompletion is enabled for that alias. Those four alone are great, and will work wonders for your imperative commands.

The fifth and sixth are two little flavors I use and enjoy in my Kubernetes environments. For example, the fifth adds the alias of kdr to be kubectl --dry-run=client -o yaml and puts it in the bash profile. So you can create any resource that has dry-runs supported with three letters. And the sixth ensures that if we start with kdr, we can autocomplete.

I typically source the profile, to be extra-sure everything is set up correctly before getting started:

Source ~/.bashrc

That’ll do it for this microblog. Our next microblog will focus on the hands-on practicality that the CKA is well-known for, and how we can get that practicality.

The post Micro-Blog 2 of 3 – Read These Before You Take the CKA: Hack. Time. appeared first on Cloud Academy.

I know what you’re thinking, read a Kubernetes book blah blah blah. Actually no, but you will be reading something. This tip is all about breaking down the exam’s content to a molecular level and bookmarking the documentation that pertains to that content for reference during the exam.

“WHAT?! BOOKMARK RELEVANT DOCUMENTATION AND OPEN IT DURING THE EXAM?! HERESY!”

According to the official rules and policies surrounding the CKA you can have one tab open that references any of the following:

• https://kubernetes.io/docs
• https://github.com/kubernetes
• https://kubernetes.io/blog

And any of their subdomains. You do have to be careful to stay within those sites, as some links within them navigate to external websites. You can always hover over the link and verify in the bottom left corner if you’re unsure.

What does this mean? It means you can create a folder on your Chromium browser that specifically breaks down the exam objectives by their title and their respective content. This was how I structured my bookmarks for the exam:

[Folder] CKA-Links
[DO FIRST] 1. autocompletion/cheatsheet
2. <exam-focus>/<exam-objective>

And so on and so forth. Each <exam-focus> was specifically titled to what the CKA Rubric covered, so I was never lost.

That does it for this microblog. For our next one, we’ll cover how to hit the ground running when we first jump into the exam terminal environment.

The post Micro-Blog 1 of 3 – Read These Before You Take the CKA: Becoming the Bookworm appeared first on Cloud Academy.

What I wish I knew before I took the CKAD: Steady as she goes!

This may come as a “no duh” to most, but I used a wireless connection during my exam. To be honest, I felt fine with wireless for the following reasons:

• I built my own computer with a dedicated WiFi card and modular antenna
• I sat right next to the router
• My internet connection is stable and runs at 1gbps down 30mbps up
• Everyone else was off the internet during the two hours of the exam
• It had not been a problem as of yet

The last bullet point was the one that got me. You see I had no problem with my WiFi because it hadn’t reared its ugly head during a stressful moment. Such as taking the CKAD. That’s why when you sit down for the exam, ensure you are wired directly into your modem or router for a consistent connection. Consistency is key.

What it did to my experience…

The reason I bring this up is that I lost several minutes (arguably more) of precious exam time due to my session dropping with the proctor. When this happened, it immediately interrupted my focus, left me feeling frustrated and I then had to wait for the proctor to re-initiate the connection with me (which took about a minute at most). That put me back at the home screen of the exam, not on the question I was interrupted on. I was flustered, lost, and had to quickly navigate back to the question (if I remembered which one I was on!). 

The biggest factor in this interruption was that it took me some time to get back into my groove — the focused, confident mind that I know I have. In fact, it can take up to 23 minutes to get back into a focused mindset (The Cost of Interrupted Work: More Speed and Stress). So don’t let something as easy as a consistent internet connection knock you around! Use a stable, wired Ethernet connection directly to your modem if possible. 

That does it for our microblog tips on becoming a Certified Kubernetes Application Developer. Be sure to share your tips below on how you feel best prepared to pass the CKAD!

The post Micro-Blog 3 of 3: What I Wish I Knew Before I Took the CKAD: Steady as She Goes! appeared first on Cloud Academy.

What I wish I knew before I took the CKAD: Bourne Again

You’re given two hours from the start of the exam to when you run out of time, or you request it to end. In my certification journey, I have never hit the time limit except when it came to the very first one I took. The CKAD is yet another exception in this journey.

That’s why it’s imperative that you complete your commands in as few keystrokes as possible and that your pinky is sore from going to the “Autocompletion Gym.”  That’s why this tip is all about setting up your bash profile so that when you get into the exam, you pound out the required completions, set up the right aliases, and save time throughout the exam.

Aliases

Try these aliases and commands out on your own before you commit to them, but they helped speed up my troubleshooting during the exam:

echo 'source <(kubectl completion bash)' >>~/.bashrc
kubectl completion bash >/etc/bash_completion.d/kubectl

This will set up your basic kubectl auto-completion. But, if you’re anything like me, we can get even lazier:

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc

The first command sets up an alias for kubectl to be “k.” Yep, “k.” Why type seven letters when we could type one? The next command ensures that the autocompletion we set up previously works with that new alias. For example, if we wanted to see all of our pods across all namespaces for a bird’s-eye view, it would be:

k get po -A

This gets us pretty far in terms of speed. But you might have to generate some YAML with the --dry-run=client -o yaml command. How do we speed that up? Let’s add another alias:

echo 'alias kdr="kubectl --dry-run=client -o yaml" ' >>~/.bashrc
echo 'complete -F __start_kubectl kdr' >>~/.bashrc

Now, if we want to generate the base yaml for a pod that needs to be created, all we have to run is:

kdr run nginx --image=nginx > nginx.yaml

This will work for any resource you need to generate YAML for; all you’ll have to do is redirect it to a file that you want to edit if needed.

Make sure you use our previous tip to source tmux from the correct profile, so all of these new configurations stick. And one last thing, before entering the exam, commit these commands to muscle memory. That way, as soon as the exam starts, you’re already hammering away at your profile. Before I took the CKAD I made sure to practice them at least ten times before entering the exam.

That does it for this micro-blog. The next one focuses on a very easy-to-make mistake, so don’t miss it!

The post Micro-Blog 2 of 3: What I Wish I Knew Before I Took the CKAD: Bourne Again appeared first on Cloud Academy.

I recently sat for the Certified Kubernetes Application Developer (CKAD) exam. And as someone who has taken over 10 certification exams (read more on the strategies I use to pass exams), the CKAD was the first exam to throw a wrench into my strategies and affect my “during the exam” confidence. That’s what motivated me to write these microblog posts about things I wish I knew going into the exam.

There’ll be a total of three posts over this coming week, so make sure you check back regularly for the next tip!

Without further ado —

What I wish I knew before I took the CKAD: Multi-what?

There’s a time period before the CKAD, and after the CKAD. Pre-CKAD and Post-CKAD, if you will. Before the CKAD, I was a fervent typer in the terminal, quick to use all the shortcuts I knew to enable the quickest workflows possible. Opening up new terminal windows and snapping the terminal to the side of my screen, resizing it, adjusting it to be exquisitely perfect. After the CKAD? Why bother with that many keystrokes? Just open up tmux and split my pane horizontally, and voila, kubectl explain on one screen, my main kubectl window on the other.

It’s important to note that the CNCF tips for the CKA and CKAD are even “pro-multiplexer”! They state that:

“Only a single terminal console is available during the exam. Terminal multiplexers such as GNU Screen and tmux can be used to create virtual consoles.”

With the ability to split terminal panes into separate panes, it is possible to have an easy reference for YAML construction/modification and then use another pane for creating the actual YAML. Use it and abuse it to your heart’s desire when you get into the exam, echoing the following command to make sure it sources the .bashrc profile. This is important for the next tip we’ll cover regarding your shell environment during the exam.

echo '[[ -f ~/.bashrc ]] && . ~/.bashrc' >> ~/.profile

I’m not going to cover how to use tmux, as that would be against this micro-blog’s philosophy (hopefully micro is implicit enough). However, these commands should be enough to get you started:

1. Linux – sudo {apt,yum} install tmux
   1. Mac – brew install tmux 
2. tmux (starts the multiplexer)
3. Ctrl+b (don’t press anything else after this keystroke)
4. Shift+”

In short order, Ctrl+b suspends interacting with the terminal pane, allowing you to interact with tmux. Shift+” splits your terminal pane horizontally. To navigate between the two, or any pane, suspend the terminal environment (Ctrl+b), and press and arrow key of your choice.

In our next microblog, we’ll cover how to quickly set up your shell environment when you start the exam.

The post Micro-Blog 1 of 3: What I Wish I Knew Before I Took the CKAD: Multi-What? appeared first on Cloud Academy.

If you want to jumpstart your learning and dive right into our playbook, all you need to do is sign up for a 7-day free trial. You’ll get unlimited access to our learning paths, courses, certification prep exams, and our most popular hands-on labs, lab challenges, and lab playgrounds.

In this article, we’ll cover the following seven plays:

1. Get prepared and stay on track
2. Find a cloud certification learning path
3. Get certified to keep cloud infrastructure safe and secure
4. Learn the top 10 skills to land a job
5. Get the real-world experience you need
6. Push your skills to the next level
7. Take some risks in a live cloud environment

Play 1: Get prepared and stay on track

Welcome to Day 1 of our Tech Skills Training Camp! Today’s play from our Tech Skills Playbook is focused on getting prepared and staying on track. Starting something new is hard, but once you get into a routine, it will be so much easier to stay motivated to hit your end goal. After a few weeks of your new routine, you’ll be pleasantly surprised at how it becomes second nature.

Set yourself up for success

1. Install the mobile app: Our app makes it easy for you to download Cloud Academy courses to learn while you’re offline. You can also use the app to cast your training directly to your TV using both iOS and Android. It’s simple. Just go the app, click the cast icon, and sit back and relax.
2. Set a goal: You only have free access for 7 days, so we want you to make the most of it. Determine how many hours you can dedicate each day, and then stick to it.
3. Schedule training reminders: We recently added training reminders into our platform to help keep you accountable. Simply go to your dashboard > click “Add training reminder” and boom — your time is booked.
4. Find a learning path: Our learning paths are guided learning experiences that provide step-by-step training to build your technical knowledge and hands-on skills.

What are learning paths?

Learning paths are objective-driven and comprised of:

• Courses: participate in video-based training to build your tech skills on industry-leading technologies
• Exams and quizzes: take assessments to help you retain what you learned
• Hands-on labs: learn step-by-step using actual accounts on AWS, Azure, and Google Cloud Platform
• Lab challenges: troubleshoot complex scenarios without guidance using live environments
• Lab playgrounds: explore and test your own ideas in sandboxed environments — without installing any software

We build the learning framework. Now you just need to log on, watch the courses, practice your skills with our live labs, and watch your tech skills catapult to the next level.

Play 2: Find a cloud certification learning path

Getting certified shows that you have some of the most in-demand (and profitable) skills as validated by one of the most recognizable entities in cloud computing. According to an AWS Salary Survey Report, 47% of those certified experienced a salary increase after earning a certification, and there’s no better time to get certified than right now.

The best preparation for certification exams is practical experience. Our certification training mixes video-based courses with quizzes, certification prep exams, and practical labs, so you’ll gain valuable experience using actual accounts on AWS, Azure, and Google Cloud Platform.

Explore our cloud certification learning paths

AWS

Foundational

• AWS Certified Cloud Practitioner

Associate

• AWS Certified Solutions Architect
• AWS Certified Developer
• AWS Certified SysOps Administrator

Professional

• AWS Certified Solutions Architect
• AWS Certified DevOps Engineer

Azure

Fundamental

• AZ-900: Microsoft Azure Fundamentals

Associate

• AZ-104: Microsoft Azure Administrator (replaces AZ-103)
• AZ-204: Microsoft Certified Azure Developer Associate (replaces AZ-203)
• AZ-500: Microsoft Certified Azure Security Engineer Associate
• DP-200: Microsoft Certified Azure Data Engineer Associate 
• DP-201: Microsoft Certified Azure Data Engineer Associate
• AI-100: Microsoft Certified Azure AI Engineer Associate

Professional

• AZ-300: Microsoft Azure Solutions Architect – Technologies
• AZ-301: Microsoft Azure Solutions Architect – Design
• AZ-400: Microsoft Azure DevOps Solutions

Google Cloud Platform

Associate

• Google Certified Associate Cloud Engineer 

Professional

• Google Certified Professional Cloud Architect
• Google Certified Professional Data Engineer
• Google Certified Professional Cloud Network Engineer
• Google Certified Professional Cloud Security Engineer 
• Google Certified Professional Cloud Developer

Play 3: Get certified to keep cloud infrastructure safe and secure

Now that the cloud is the new “norm,” today’s play is focused on certifications that help keep the cloud infrastructure safe and secure: Security and DevOps.

If you’ve already found a learning path that’s right for you, well done! Feel free to dive right into our dashboard to continue studying. If you’re still searching, then continue along our certification learning path journey. Finding a certification — and career path — that interests you is essential. When you’re interested in the material, you are more likely to stay engaged and maintain your motivation to earn the coveted certification.

Did you know…

The cost of a data breach has risen 12% over the past 5 years and now costs $3.92 million on average, according to a report from IBM Security. This increase is causing highly skilled security professionals to be in high demand. >>Read more.

The perception of DevOps and its role in the IT industry has changed over the last five years. Even though many believe that DevOps teams move too fast to handle security concerns, DevOps practices done right increase system security in the same way that continuous delivery increases stability. >>Read more.

Explore our security and DevOps learning paths

Security Certifications

• AWS Certified Security
• Foundation Certificate in Cyber Security
• Preparation for the (ISC)² CISSP Certification
• AZ-500: Microsoft Certified Azure Security Engineer Associate

DevOps Certifications

• DevOps Engineer – Professional Certification Preparation for AWS
• AZ-400: Microsoft Azure DevOps Solutions
• Certified Kubernetes Administrator (CKA) Exam Preparation
• Certified Kubernetes Application Developer (CKAD) Exam Preparation
• DevOps Foundations – DevOps Institute Certification Exam Preparation
• Linux Server Professional

Explore other certifications

Still haven’t found a certification learning path that’s right for you? Feel free to explore all of our certifications or explore our Training Library.

Play 4: Learn the top 10 skills to land a job

Today’s play focuses on the top 10 skills to land a job. This list might surprise you, but according to CIO.com, programming languages make up 8 of the 10 top technical skills to get hired in 2020 — yes, 8 of the top 10! Here is the top 10 list in order:

1. SQL
2. Java
3. Python
4. Linux
5. Javascript
6. AWS
7. C++
8. C
9. C#
10. .NET

Want to know what’s great about this list? Cloud Academy offers learning paths, courses, and labs on 9 of 10 top skills — and you still have plenty of time to explore our extensive Training Library!

Explore our programming learning paths

Python

• Python for Beginners
• Introduction to Python
• Pythonic Programming

Java

• Introduction to Java
• Advanced Java Programming

SQL, .NET, and Javascript

• Learn SQL – From Newbie to Ninja
• Refactoring a Monolithic .Net Application to Use Cloud Services
• Web Development Fundamentals – Javascript Primer

Other programming languages

• Application and Service Development with ReactJS
• Fundamentals of R
• Learning Git First-Hand

Play 5: Get the real-world experience you need

Today’s play is focused on getting you real hands-on experience by firing up a hands-on lab. Our labs are not “simulated” experiences — they are real cloud environments using actual accounts on AWS, Azure, Google Cloud Platform, Docker, Kubernetes, and much more. We have three very different types of labs: hands-on labs (guided), lab challenges (non-guided), and lab playgrounds (sandbox). Today we’re focusing on hands-on labs.

What are hands-on labs?

Hands-on labs are guided experiences to learn in live cloud environments with step-by-step guidance to practice your skills without getting stuck.

• Build hands-on experience using real accounts
• Solidify practical knowledge in a short amount of time
• Facilitate knowledge retention and enable experimentation

The post Tech Skills Playbook appeared first on Cloud Academy.