DEV Community: TechWorld with Nana

A Guide of how to get started in IT in 2023 - Top IT Career Paths

TechWorld with Nana — Mon, 19 Dec 2022 15:50:43 +0000

In this blog article I want to give you kind of a roadmap of how to get into the IT world.

This is the written version of my new youtube video ✍️

The tech industry is currently one of the hottest industries for the job market, so it's completely logical that so many people are thinking about changing careers to tech or getting into tech just after graduating from school or college.

Entry into tech can be overwhelming 🤯

And it's true that tech industry offers lots of career opportunities, but when you are at the very beginning of your journey it can be very overwhelming too. 🤯 It is a broad industry with so many options, so many IT fields and professions. There is so much to learn and often you don't even know where to start. It's also hard to know which IT field you will be interested in and will eventually choose, before actually trying things out and seeing for yourself what you enjoy doing the most. You may even have self-doubt thinking that it's too late to switch careers or there's so much to learn you can never catch up with the people, who have been in tech since early age.

And I understand all these concerns, the self-doubt, the time pressure, insecure not knowing where and how to start etc. And that's why with this blog article, I want to kind of show you various career path in tech and give you some general guidance for how to get started. 😇

And for every IT field, we will see:

whether it's an entry-level profession
what they actually do and what are some of their job responsibilities
as well as what skills you need to have to get into that specific field
and some of the technologies you need to learn for it

My Background 👩🏻‍💻

First of all, I want to start by saying that it's never too late to get into IT. 👏

I myself transitioned from my marketing and business studies and had nothing to do with IT before, not even an IT subject at school or college 👀 and switching my career to tech was probably one of the best decisions of my life! 🤠 This field is becoming more popular every year and it comes with so many benefits and opportunities for people working in this field. Plus it's an interesting, exciting and fulfilling field to be in no matter which specialization you choose.

So let's see what are actually some of the most popular IT professions today, that will be even more demanded in the future, so what options you have for IT jobs that you may want to specialize in.

Most popular IT career paths 💎

Of course there are many different statistics and rankings out there and many names for the similar jobs, but there are several professions that definitely stand out, which have become the most popular. The popular and demanded jobs in IT are usually paid very high 💸, so many of those rankings are also based on salary and career growth statistics.

Based on several rankings, the most demanded and popular IT fields that have been growing in popularity even more over the years are 👏:

Software Engineering
DevOps Engineering
Cloud Engineering
Cybersecurity or Security Engineering
Data engineering or generally data related professions
and Machine Learning Engineering

And these top fields will actually be even more demanded in the future. So there is a lot of growth and future potential in each one of those fields. 👍

So most of you will probably want to get into one of those fields, but many of you may not know right now what you want to choose exactly, maybe because they all sound equally exciting for you or equally overwhelming so you have no idea which one will be a better choice or which one will be the most interesting one for you, which is absolutely okay, because that's exactly what I want to help you with in this overview. 😊 ✅ So let's get into it!

General Learning Approach 🧠

First of all, it's absolutely fine to try out multiple things to see what you like the most. In fact, it's a really good idea, because you have so many opportunities, so many options, so you want to take advantage of that and find the one that fits you the best.

However, you need to approach this with some structure, just randomly learning things here and there in the hope to make sense of many things at once or even worse trying to learn multiple of those fields at once is not a good strategy. It will make your learning journey difficult and it will surely make it longer as well and you won't properly find out what field you like the most.

So let me help you structure your learning process by laying out the map that shows you all these professions individually and the learning path to those as well as any overlaps and common knowledge between them. ✅

1 - Become a Software Engineer 👨🏼‍💻

Let's start with the broadest and the most widely least spread IT field, which is "software engineering". I believe it's also the easiest entry point into IT and where most people actually start their IT careers and that's how I started as well.

A software developer or software engineer is someone, who develops any kind of software applications.

What is software? 🤔

This can be a web application a mobile or a desktop application. Whenever you think of any software, whether it's on your computer the mobile phone in your smart TV. So for example, Amazon, Netflix and all these applications you use on your smart TV. These are all software. Or think about smart cars, again these are applications for navigation and some other controls of the car. You have smart homes, software in production machines and robots.

So these are all software developed by software engineers.

Different subfields of software engineering

But software engineer is a very broad term itself and covers many subfields and you can actually specialize in any of those subfields, since they are each their own separate professions.

Frontend, Backend or Full-Stack

For example, you can become a "frontend developer", which is basically developing the front of the application, the part that the users see in their browser or their phone screen or TV screen.
You can become a "backend developer" and develop the backend part of the application, the part that connects to the database, saves and updates user data, processes data and so on.
Or you can become a "full stack developer". They're basically people, who can develop both frontend and backend parts of the application.

Web, Mobile or IoT

Then you also have categorizations like "web developer", which is basically developing web applications that you see in a computer or laptop browser. You have mobile app developers, which are developing applications for Android or iOS. You may be an "IoT developer", which is "Internet of Things", like software in your car for your TV the smart home, the smart lock systems for hotels etc.

Specialize on programming language

And you can even specialize in a specific technology or programming language or even a framework. So you may choose to become a "Java developer" a "JavaScript developer" or maybe a "React developer". You can specialize in Android development for mobile applications. You can become a "Python developer".

So these are all separate career paths, because each of these is already such a big area and field on its own.

Generalist or Specialist

So you can go deeper into a chosen technology or area or you can go broader and become a full stack engineer as I mentioned. And both have their values. You need experts in one specific area, but you also need people, who have a good overview and knowledge of many things on a higher level and that's really a personal preference, whether you are a generalist or a specialist, so you can decide what you like more. I am personally a generalist. I like knowing many things and how they fit together and integrate together and knowing things on a high level, rather than deepening my knowledge in one specific area, but as I said that's a really personal preference.

Roadmap to become a Software Engineer ☡

However, no matter which of these professions or subfields you choose, you have a pretty similar entry point for all of those.

1 - Learn basics of Software Development and Programming

You have to first understand basics of software development and programming. For example you take any programming language and learn the basics of programming with that language.

Things like variables, functions, data types and so on, because these concepts are actually the same for every programming language, no matter whether it's mobile, web, frontend or backend development.

I usually suggest JavaScript as the entry point language, if you want to get into any kind of software development, because it can be used in frontend and backend and even in mobile application development, plus it's easy to learn compared to Java for example.

2 - Develop simple example projects

Once you get the basics right, the second step will be to actually start developing simple example projects to really understand how software is written from scratch. 🚀

The complete setup of frontend and backend, whether it's a web or mobile application, because that's how you really learn the concepts behind software development. I'm a big fan of learning anything with an example project, rather than by book or watching some tutorials passively.

This way you're not learning just a specific language and what features they have, you are learning how to develop an actual application that is usable.

So depending on what you want to specialize in, if it's web development you can learn HTML and CSS on top of JavaScript and start creating a little bit more complex web applications with a database connection.

If you want to go into mobile development you can choose one of the languages for mobile development and practice using that language.

How to choose a programming language?

Every language has its advantages and disadvantages. Some of them are cooler, some of them are more widely used, but the important thing is that you learn the concepts first, because you can always learn the syntax or you can even Google the syntax, if you need to.

If you're not sure, which language you want to choose, always go for the most popular one, because it increases your chances to get a job with that language and it has a large community behind it and it has to be popular for a reason.

Concepts over Features and Syntax 💡

So as I said, instead of learning features and syntax of a language just one by one, take an example project either from web or think of your own project and develop that. You will learn way more in that process of doing it, but it has to be simple so you don't get stuck and overwhelmed in the process.

No knowledge is wasted, you can always switch

And here's the thing, if you are thinking: "what if I make the wrong choice and start with the wrong thing and find out that I don't like it at all?"

Well, if you start with backend web development for example and after months of learning that, you realize it's not really for you and you like mobile app development better, that knowledge is not wasted. You aren't starting from scratch. That knowledge that you gained will help you switch to another area, plus you had a chance to find out what you like and what you didn't like. In fact, that isn't wasted even if you decide you want to go into a completely different area like data engineering or cloud engineering or DevOps.

And I want to say that, the fields in software engineering are usually the entry-level tech professions. So it's relatively easy to get started in IT this way and later you can always transition to another tech area.

And as I said your knowledge will never be wasted, because lots of concepts are related and interconnected in different areas of IT:

Your programming skills will be useful even if you go to machine learning or DevOps engineering.

Tips on how to learn 🧑🏼‍🏫

Important thing here is not to do everything at once, as long as you build your knowledge in tech step by step, like one area at a time, one programming language and technology at a time and stick to that for at least six months or so and then move on to the next thing you should be fine. Just don't rush from one thing to another, trying to absorb everything at once, which I know many of you are probably thinking to do.

And if you do want to start with this path, I actually have a mini bootcamp for learning everything you need to know for web development specifically, full stack development with frontend, backend, database connection plus even more the complete software development and release life cycle:

And my goal was exactly to make people's entry in IT easier and remove that fear of tackling this scary thing of getting into tech, by making things simpler and easier. Plus with actual real projects to make it fun and engaging.

Just a shameless plug here for our IT beginners course. 😊 So if you want to know more about that you can see the video, where I explain exactly what you learn there in detail: Complete Overview of the course

2 - Become a DevOps Engineer ♾

Now as I said, you can use knowledge in software development in other IT fields and software development is actually the best stepping stone to transition to our next most popular IT role called "DevOps engineering".

So DevOps field is rising in popularity year by year, it is the field that I personally found extremely exciting and some years ago from being a senior software engineer transitioned to DevOps. And if you know my videos, you also know that my whole channel, courses and educational programs are all about DevOps 😍

But very important to note here, that DevOps is not really an entry-level IT profession. It is a bit more advanced, which means you need to already have some engineering know-how in order to transition into DevOps, but what is DevOps anyway?

DevOps is all about automating the processes in the software development and release life cycle.

Which means logically enough that you need to understand those processes and the whole life cycle first so you know what you're automating.

So DevOps is a more complex and difficult field, which I do not recommend to start in, if you have zero IT background 🤷🏻‍♂️, but if you build up your knowledge step by step and you find it as interesting as I do, it can be an extremely rewarding profession.

It is a highly demanded and also highly paid IT profession, because there is actually a big shortage of these professionals, probably way more than for software engineers.

If you want to know more about DevOps and what type of person it is for and what skills you need to become a DevOps engineer, I actually recommend you watch my videos from my "DevOps as a career" playlist, where I explain all of that in detail. So after watching them you will know exactly "nope DevOps is definitely not for me" 👎🏼 or "yes that's exactly what I want to do"! 👍

Transitioning to DevOps

Before we move on to the next profession though, I want to mention that lots of people transition to DevOps not only from software development background but also from systems administration or test automation or network engineering role and various other roles actually. I would say IT professions that are becoming less demanded or less interesting are moving towards DevOps engineering, because it is the new hot thing. 🔥

And if you don't already know about our famous DevOps bootcamp. Two years ago we actually created the complete educational program to teach people all the necessary tools and concepts to become a DevOps engineer:

We have educated more than 2,500 students with this bootcamp so far, but as I said the DevOps bootcamp is for people with some level of IT experience or IT pre-knowledge. And that's why we created the IT Beginners mini bootcamp to help people with the zero background learn the fundamentals first they need to, to even get started into DevOps. So I created this course actually as a prerequisite for the DevOps Bootcamp. So if after watching the "DevOps as a career" videos you decide you want to get into DevOps, then these two educational programs will be the perfectly laid out path for you to get there in the most efficient easy and fast way. 🙌

But if you decided DevOps sounds like it's definitely not for you, then you can consider one of the IT professions I'm going to talk about next.

3 - Become a Cloud Engineer ☁️

The next IT field, which is actually pretty related to DevOps is cloud engineering.

Very simply explained, a cloud engineer basically builds and maintains infrastructure in the cloud.

As many companies move from managing their own infrastructure to using cloud platforms, Cloud Engineers are becoming increasingly demanded.

Cloud engineering is also an entry-level profession. If you have some basic systems administration experience, then this will be probably the easiest IT field to transition into, but if you're a complete IT beginner, you can actually start your IT journey directly here as well.

So how do you start in cloud engineering?

Roadmap to become a Cloud Engineer ☡

Well in cloud engineering, there are actually two most popular cloud platforms out there, which are

Amazon's AWS
and Microsoft's Azure.

Both of them have various certifications, which you can take to help you get a job as a cloud engineer for that specific cloud platform. So if you want to get started in this, choose one of those cloud platforms and start learning for their basic entry-level certifications and basically specialize in that cloud platform.

I personally suggest choosing AWS, because it is currently the biggest and most used cloud platform. A good way to start here will be using AWS certification programs. AWS has multiple certifications from basic cloud practitioner to more advanced certifications. So obviously start with the basic AWS cloud practitioner certificate and start learning and preparing for that. This will give you knowledge in all important AWS services, but more importantly in the main concepts of cloud engineering in general.

And remember I said, when you learn one programming language, learning another programming language actually becomes way easier, because you already learned many of the common underlying concepts. The same way if you at some point decide to go for Azure after learning AWS or you find a dream job at a dream company, who uses Google Cloud platform instead, you can learn them way easier, because you already have learned one Cloud platform and the basics of cloud with that platform. In fact learning two cloud platforms will be a major asset, because you now have a good comparison between them.

So the best starting point will be getting the cloud practitioner certificate from AWS to get you the first job in this field.

Cloud vs DevOps

Now I want to mention here that DevOps and Cloud often fall into the same category and often they get mixed up. However even though they have some overlaps, they are actually two very different fields and I plan to create a video for "DevOps engineer versus Cloud engineer" describing in detail what are the common tasks and responsibilities, those overlaps as well as what actually differentiates them.
So you understand exactly the difference between these two fields. ✅ So be sure to subscribe to my Youtube channel and activate the notification bell, if you don't want to miss that. 😇

4 - Become an IT Security Engineer - Cybersecurity 🔐

Now cloud, DevOps and software engineering fields have one thing in common, they all need security.

When you build a cloud infrastructure you need to secure it, when you program an application you need to make sure it doesn't have any security loopholes that hackers may use to hack into your systems, when you build DevOps processes which actually affects your application, your cloud infrastructure and many different systems, again you have even more security responsibilities to make sure you don't expose passwords and secret keys to your systems etc.

This means software developers, cloud engineers and DevOps engineers they all have to know about security.

But security is an extremely large field and it affects every piece and step of the software development and release life cycle and you have security in other IT fields as well. So we actually have a separate dedicated profession for IT security engineers, who specialize in all things security.

Tasks and Responsibilities of a Security Engineer

As a security professional you know security tools and technologies that help you scan and identify security issues at different levels as well as help fix them and also validate that other engineers have secured their systems properly.

There are even external security companies who provide services to other companies to secure their systems. For example they try to hack into their systems and see where the systems of the company are vulnerable, because if they can hack into them, actual hackers can also do that.

So as a security engineer you identify those vulnerable points and advise the company how to secure them. Also security as I said is on multiple levels, every system, every software, that companies using or developing needs to be secured:

the infrastructure
the application platform
the frontend
the backend
database
the application itself

So security engineers usually have a wider cross knowledge of security on all those levels and can plan a general strategy of securing the complete setup using various technologies for automating security checks and security testing and so on.

Huge Demand 👀

And it goes without saying that security engineers have extreme value to the companies 💎, because security breach is the worst scenario for any big known company. Cyber attacks are becoming more and more sophisticated and for applications, who have millions or hundreds of millions of users and the user data obviously the impact of the attack is huge, when data of so many users is compromised or even think about your online banking application. Obviously you don't want them to have any security issues in their system, right?
For this reason there is usually a tremendous demand for security engineers in many industries and it's definitely going to become even more important in the future.

Roadmap to become an IT Security Engineer ☡

So if you want to go on this challenging but very exciting path you need to first understand the concepts of what you are securing.

So this is also not really an entry-level IT position, you definitely need some pre-knowledge in one of the IT fields like network engineering, cloud engineering, software development etc. And on top of that you'll have to learn many security concepts and tools in order to develop this general security strategies.

5 - Become a Data Analyst, Data Engineer, Data Scientist - Big Data 📊

One of the hottest IT jobs, which are more in demand than ever are data related jobs. Now why is that?

Human generated data 👥

When we have software that millions and billions of people use daily, those users produce loads of data, right? Think about social media, the posts and media we create and upload every minute or every second. Think about search data generated when millions of people search daily, GPS data from Google Maps or other applications that track your location, when you buy groceries at the supermarket, when you buy stuff online. So basically the user behavior data.

All of this is data that we humans produce daily through our digital footprint.

Device generated data ⚙️

But apart from this human generated data there is also massive amounts of device generated data, such as cars, IoT systems through sensors, production machines, robots, logistics data, shipment tracking.

So even more data than humans generate is coming from these sources.

With all this, the data has grown dramatically in the last years.

In fact worlds 90% of the data was actually generated in the last two years.

As some sources mentioned, we generate so much data, every single day that if it were written down in form of books and we could pile those books on top of each other, we would have enough to build a bridge to the moon and back.

And because of the sheer volume of this data, we also call it "Big Data". So that's where the term comes from.

Raw vs Processed Data

Data has become a precious asset of any organization 💎, because it helps them understand things better. 💡 Like make predictions, political campaigns are driven by data, like you have polls and online searches etc. Many companies use data to optimize their processes, to save time and money in those processes.

However, just raw data has no value to the company. Imagine these are massive amounts of data in raw form, generated in different formats and from different sources. It's really difficult for humans to make sense of data in this form. It only has value once the data is processed, cleaned, analyzed and visualized.

So it's easy to consume for us humans and big data related professionals are exactly the ones, who use tools to turn these massive amounts of data into usable and extremely valuable information for companies.

And companies can then use these visualized data to make decisions, make future predictions, cost optimizations and so on.

And there are various data related professions with different tasks and responsibilities such as

data analysts
data scientists
and data engineer

So let's see comparisons between them.

Data Analyst

Data analyst is basically the entry-level profession, if you want to get into this field and is the easiest to start with.

As the name suggests, data analysts analyze and interpret data to extract meaningful information from it. So they need to basically make sense of the data, like identify any patterns.

Main Skills

The main skills they need to have are knowledge of math and statistics and various tools that help them in data analytics and data visualization.

But in addition to the technical skills, data analysts must actually have a good business and product understanding. So they analyze the data with the goal to make good decisions for the business and product development and then communicate those decisions to people, who actually need them like, product owners, business decision makers in the company.

However, data analysts work with already processed and prepared data. So the raw data needs to be collected from multiple sources with different formats and be processed first to be usable for the data analysts.

Data Engineers

And this is something that data engineers do. Data engineers need knowledge of databases and programming to do their job and data engineers actually build something called "data pipelines" to collect, store and process the data:

So you can start into data engineering by learning:

A programming language like Python and its data processing frameworks and libraries
Learning databases and query language like SQL for example
Big data specific frameworks like Apache Hadoop, which is a popular framework that allows you to store and work with massive amounts of data.

Data Scientist

And the third one I mentioned is a data scientist, which is usually the highest paid profession among these three.

Now interesting to mention that companies often use data analysts and data scientists job titles interchangeably. Now they are two different professions, but there are definitely some overlaps between those two. And one of the overlaps is that you need to have advanced math and statistics knowledge here as well.

So generally contrary to the popular belief, you don't need any math or statistics knowledge for software development and definitely not for DevOps or cloud engineering, but in data science or data analytics you will be working with math and statistics a lot. 🧮

This means if you want to get started in one of those fields, the first thing you need to learn is statistics and the programming languages for statistics like R or Python.

However, in addition to statistics, data scientists usually require more advanced technical skills than data analysts and that's where the main difference between those two professions lie:

So data scientists are usually more experienced engineers, who can create advanced machine learning models for example and algorithms to make future predictions.

6 - Become a Machine Learning Engineer 🤖

Which leads us to the next and final hottest IT profession called a Machine Learning Engineer or ML Engineer, which actually is yet another big data related profession.

Data Science vs Machine Learning field

We said that data analysts and data scientists use data to analyze trends and identify patterns and make some decisions and predictions based on the data. So data can be used by humans to make data-driven decisions, but data can also be used by machines by programs.

So that clean processed data that data engineers prepare can be fed into machines, so they can learn from them and they can use them for different tasks. And that's where machine learning actually comes in.

What is Machine Learning? 🤔

Now what is machine learning exactly and why do machines need data, what do they do with it?

In software development we write programs and instruct them to do something. In machine learning, machines can perform a task without being explicitly programmed to do so. 🙅🏻‍♀️ How do they do that? They learn how to perform that task from large amounts of data using algorithms, which are also called machine learning algorithms:

So machine learning is about computers being able to think and act without being explicitly told or programmed to do so.

And there are two main parts of this process:

First one is writing the machine learning algorithms so that machines can use them to learn
And the second part is feeding large sets of processed data into those algorithms, so basically using the data to train the model.

Skills you need to have

Again there are some overlaps between data scientists and machine learning engineers that you will encounter, they both need strong math and statistics skills to work with data, however, while data scientists focus on making sense of the data, visualizing and presenting it better, machine learning focuses on using the data for machines to learn to carry out certain tasks:

So entry into machine learning engineering is actually pretty similar to data science:
You need to start by learning a programming language like Python, which has powerful machine learning frameworks and statistics, which is a very important part of machine learning engineering.

Python - General Purpose Language 🐍

Now you probably already noticed that in all those fields I actually mentioned Python programming language and that's because Python is a general purpose language.

You can use Python in every single one of those areas, however that does not mean that you need the same Python knowledge in each field.

Using Python for web development is completely different from using Python for DevOps automation or machine learning and that's an important difference.

Python Core vs Python libraries for specific field

So first you learn the Python core with its syntax and general programming concepts and then you learn the specific libraries and frameworks for each IT field on top of that Python core:

So you have completely different frameworks and libraries for web development and machine learning and DevOps automation, which you need to learn for that specific field. So you basically learn different parts of Python for each field and that's an important thing to differentiate.

Python language just happens to have popular frameworks for all those fields and their use cases, but of course the Python core is the same everywhere.

If you want to learn Python core, like syntax and programming concepts of Python, you can definitely check our free course on Python.

So we've covered a bunch of career options in IT and I tried to categorize them so you have a better overview and comparison between them. ✅ So hopefully something stood out for you where you think: "well that field sounds pretty interesting to me so I'd like to get into that field".

Where and how to learn - CS Degree, Courses, Bootcamps, Self-Learning? 📚

Now of course when you know approximately which direction you want to go and what you want to start learning, the next question becomes: "Where and how do you learn this?" Do you get a college degree in computer science? Do you take an online course? Do you join a data science bootcamp or a coding bootcamp or our DevOps bootcamp? 🤷🏻‍♂️

Well, I personally started my informatics studies at a technical university, but I was using mostly online resources for my studies like YouTube videos and some coding websites. And as soon as I got an internship as a software developer in my second semester, I actually quit my studies and used my work to learn by doing.

At work I was actually learning way more practical stuff that I actually needed for my job than at the university

So I usually recommend learn the relevant skills you need to get hired as fast as possible. 🚀

But learning at work wasn't always easy, so I continued learning new things from YouTube videos and blog articles and online courses. I was often all over the place trying to learn anything and everything that I stumbled upon. I didn't really have a roadmap that I could follow, but it was still useful in some way.

So I still think that online resources are one of the best ways to learn, especially in IT field, but as I said having some kind of roadmap and structure definitely makes the learning journey easier, because you don't just learn things randomly, but you learn things in a certain order without being distracted by massive amounts of information. 💡

Find a clear roadmap

So whatever field you want to choose: Go find a clear roadmap for that profession. There are various articles and videos about those roadmaps and then just try to follow that roadmap.

And of course if you decide for DevOps, as I mentioned we have a complete roadmap for that, even if you're starting off without any IT background:

So you don't need to do the research, put together a learning course and find good resources. We have done that whole work for you. You just follow along and learn by doing and if you know my videos I create the content with the goal of giving practical actual usable knowledge with easy explanations. I love helping people learn easily without getting frustrated and being overwhelmed. 💙

Start your journey into IT 👩🏻‍💻

So generally as you see, you have various options, choose an entry-level career based on what you want to do later and you can build on top of that.

And again no knowledge is wasted in IT, everything is still interconnected, so if you start in software development and later want to do DevOps or machine learning or cloud engineering you can still benefit from that knowledge and won't be starting from scratch in that field.

So if you don't know yet where you want to end up you can start with any one of those, maybe the easiest one and you can always progress in any other direction later. 👍

I hope I was able to help you make these important decision for your future, you definitely made the right decision by choosing IT in general. With that, all the best in your future career! 😊

Like, share and follow me 😍 for more content:

Is DevOps right for you? 🤔 13 Points to consider

TechWorld with Nana — Mon, 21 Nov 2022 15:44:40 +0000

You all know that DevOps is already very popular and highly demanded. You see organizations adopting it worldwide and it seems like a great career choice with lots of job opportunities, high salary and generally a very rewarding work 🔝, but maybe DevOps is not for everyone?

It takes a specific type of person to be interested in DevOps, so the question is: "Is DevOps profession right for you?" 🤔

And in order to answer this question, I will explain

what are the qualities and characteristics you should have if you want to get into DevOps?
what kind of thinking and approach is required in DevOps?
which soft skills as well as technical skills you need to have?
and finally what are some challenges of being a DevOps engineer?

And if at the end of the video you do find out and decide that DevOps is indeed for you, I will also show what next steps you can take to get into DevOps. ✅

So let's get into it! 🙌

This is the written version of my new youtube video ✍️

1) Generalist instead of Specialist

First of all, you need to be a generalist rather than a specialist. What does that mean?

In DevOps you don't just learn one tool or one concept and then specialize in it. Instead you need to master combining many tools. Some people love focusing on one area of expertise and deepening their knowledge in it, like if you learn JavaScript you can master it on an advanced level and become an expert JavaScript developer, but in DevOps you can't just learn Docker or Terraform and become an expert Docker or Terraform engineer, you need to have a tool set of various tools you combine in order to build DevOps processes:

Even as a junior DevOps engineer just knowing two or three tools won't help you here, so you should like learning many different things and building a wide skill set.

2) Analytical and Strategic Thinking

Because you need many tools you also need to develop a skill to compare, quickly assess and decide on which tools and concepts you will use in your projects. Like

"do we need GitOps or is it just over engineering for our specific use case and project"
"This tool is great, but is it ready and mature enough to be used in this project?"
"Should you use Terraform or Pulumi ?"

It's a strategic decision, right? Use Terraform, which is an industry standard or Pulumi, which is more developer friendly and developer centric.

And for those decisions you need to be able to evaluate and test various tools, you also need to consider many aspects and make efficient comparisons between different technologies to decide which tools and concepts match to your specific use case and will work best for your project.

3) High Level Thinking

In order to make those strategic decisions on which tools are best for your specific project and use case, you need to have a good high level overview and end-to-end understanding of DevOps processes. You need to understand which tool fits into which part of those processes and why you're using them:

You need to zoom out to see the connections between the tools and different roles in your team, the bottlenecks, possible issues and improvement opportunities:

So the skill of high level thinking is one of the most important ones when you're getting into DevOps.

For example, when you're building a CI/CD release pipeline:

you need to understand the whole software development life cycle
you need to understand which roles it affects
what steps need to be combined in which order
which systems are affected and
who is responsible for what.

Just like an architect, who designs the whole house 🏠, considering the size of the lot, size of the house that needs to be built, the surrounding space, inner space and all the aspects around it, making a master plan for building the house. The same way you are architecting the DevOps processes on a high level.

4) Problem Solving and Solution Oriented

As I already mentioned, when you have a good high level overview, it's easier to identify issues, bottlenecks that slow down the process or possible improvement opportunities in the DevOps processes, like release pipeline, monitoring infrastructure management processes etc.

So when you see the whole DevOps process in one continuous line it's easier to see those.

Identifying issues is the first step in solving them and considering that many DevOps processes are pretty complex, it may be challenging to see those issues and ways to optimize things. So you need to be constantly observing and actively looking for ways to improve things and fix the issues.

For example if you identify that developers always need to manually perform some tasks, which takes two hours or you notice that running tasks takes really long, so the CI pipeline runs are very slow 🐌, you should actively look into it and see how how you can speed up or automate things.

Things can be optimized endlessly in DevOps. You don't just build a release pipeline in two months and that's it. It's a continuous improvement process, just like you don't program an application in two months and be done with it, you continue adding features and fixing bugs and so on. It's the same with DevOps processes.

This means as a DevOps engineer you need to have a solution oriented approach, constantly looking for ways to optimize and solve things.

5) Creative and Innovative

Now coming up with those solutions and improvement ideas will also require creativity and innovative thinking. Why is this especially important in DevOps? Again because in DevOps the processes are very complex and covers so many parts of the software development life cycle, things are often not so straightforward. 🙇🏼‍♀️

So for one specific task there may be 10 different ways of doing it, so you need to combine things in a creative way to find solutions.

This means most of the time you need to be creative and think outside the box when deciding how to solve bottlenecks, how to speed up DevOps processes, how to increase the quality of product delivery etc.

This also requires innovative thinking, because often the issues you have are very individual for your project. So you need to have a fresh perspective and approach problems this way. Often you can't just see how other companies solve the problems or how your company solved it in the past, because it's a completely new and unique use case so you need to find a unique solution for it.

6) Persuasive

When you make a plan and come up with solutions that affect many people, various roles in your organization and many team members, of course those affected people should also be on board with those solutions. You may get resistance from engineers or people may be opposed to making changes to existing processes:

So you need a skill to persuade people that your plans are really good and will indeed help them in their work and have positive impact overall on the organization.

So as a DevOps engineer you will need to know how to communicate your ideas and planned changes, get people on board and advocate for your ideas.

7) Communication Skills and Team Player

So another super important skill you need in DevOps is communication skills. Now let's see why this one's so crucial. 🤔

In order to identify the issues, bottlenecks, improvements and the respective solutions to those, you often need input from various people and various roles in your organization and good understanding of their work and their pain points. 👥

Once you have identified issues and come up with solutions and persuaded the team to implement those, you need to also work closely with engineers to actually implement that plan. So communication is the skill that ties it all together.

As a DevOps engineer you don't work alone. The whole DevOps concept is based on the collaboration between different roles and team members and often these are the roles that have different interests and tasks and sometimes even conflicting interests:

So you need to enjoy working with people and communicating with them since this is going to be one of the major elements of your work as a DevOps engineer. So being a team player is definitely a must here. 🤝

As part of communication skills you also need to be able to effectively express your ideas and explain your plans and strategies to the team members. 🗣 So this also goes hand in hand with the persuasion skills. Let's see why?

As I already mentioned, your work affects many people, you solve problems and bottlenecks for different roles, which means you need to get people to work with you, but also share your knowledge with them, explain new concepts and processes and so on. DevOps engineers are also often the mediators between different roles.

So you need to understand and communicate efficiently with people, who have different interests, tasks and responsibilities. For example let's say you are setting up a CI/CD pipeline.

CI/CD pipeline affects developer workflow first of all. So developers need to be on board with what you're doing and how you are designing their workflow, because they need to work with it. On the other hand, you need input from them to understand what they need in order to work efficiently. So you can use this input to implement the CI/CD pipeline.

CI/CD pipeline also affects test engineers, system administrators, security professionals. So the same way you need need to understand what these engineers need in order to do their part of the job and naturally all their interests need to be aligned as well. So for example, if security needs to validate any security issues, test engineers may write some automated tests to detect those security issues and this automated tests will then be integrated into the pipeline or if a system administrator needs to enforce any policies for developers before deploying the application changes to let's say a Kubernetes environment, you can help them create those automated policy checks and then integrate them into the pipeline as well. And if the development fails, help developers interpret those policies and comply with them.

So you see that as a DevOps engineer you are kind of in the middle of all those different roles, connecting them and basically encouraging and enforcing this collaboration between different team members. 👀

8) Detail Thinking

As a DevOps engineer you don't only create the high level design of the processes like a solutions architect, but you also implement things like

provisioning the infrastructure
configuring servers
writing automation scripts
infrastructure is code or
X as code

So once the high level plan is in place, the next step is implementation:

Now there are differences across organizations on the role of a DevOps engineer and what its tasks and responsibilities are. Originally DevOps was not even meant as a separate role, but rather as an overlaying concept. So traditional roles like developers, system administrators etc were supposed to take on those tasks that are now done by DevOps engineers, but in practice it emerged as a separate role who designs the DevOps processes and also works hands-on to implement those processes.

So in order to implement things you need detail oriented thinking, to consider and pay attention to various details and actually implement the things that you have designed.

So you need to be able to focus both on the big picture and small details or in other words create a zoomed out map with an overview and then zoom in into specific spots on the map. When needed you also need detail orientation when troubleshooting issues especially in complex systems like Kubernetes clusters on cloud environments or in complex infrastructure setups.

9) Sharing knowledge in an organized way

Now let's say you design the processes and workflows, you implement things and so on. Since these workflows affect other engineers, they need to know how these processes work.

When you create a CI/CD pipeline, developers need to know how to use it and how to develop, what to do and what not to do. So that their code changes actually get released by that pipeline.

Or let's say you have implemented infrastructure as code concept in your organization. When a new systems administrator or cloud engineer joins the team, they need to know how the process of creating and configuring infrastructure works.

So documenting things and making them transparent for others in your organization is extremely important in DevOps.

The processes should be transparent for everyone. 👀 This will make work and collaboration of engineers much easier, but also make onboarding new engineers way easier as well. This means you need to be an organized person, who document things in an organized and structured way. This could be textual documentation or also graphics and diagrams for let's say visualizing architecture, workflows and different processes in your organization. Making things transparent, sharing knowledge, making sure everyone has access to the information they need.

Now apart from personal characteristics you should also have personal preferences for things that are essential for the DevOps daily work.

10) Enjoy dynamic and diverse work

First of all, you should love dynamic, diverse work with a wide range of tasks, because as I said you don't just work on one tool but rather your tasks may range from coding to configuring infrastructure to monitoring, scripting and so on.

This will also mean doing things outside your comfort zone instead of doing comfortable work, like only doing the tasks in your areas of expertise:

In DevOps you keep pushing out of your comfort zone, constantly working with new tools you don't know. So you should not be just open to changes, but love the changes and actively drive changes and improvements in your organization.

This also means being on the edge of the technological changes and industry trends, being the front of your organization that keeps an eye and observes industry changes and trends and improvements to implement them and bring them into your organization. 🚀

11) Enjoy optimizing and improving

Another personal preference that's super important is that you enjoy identifying optimization opportunities in the existing processes. And I think this is a very important one. ⚠️

For example you should have fun and enjoy solving bottleneck, spitting up things, automating things and seeing the progress from slow manual tedious work 🐌 to smooth streamlined automated processes. 💯

12) Challenges

Now as you're probably already thinking DevOps is quite a challenging job. 🤯 It is definitely exciting and rewarding, but it comes with some challenges, which you may also want to consider when deciding whether DevOps is really for you.

First of all, constantly learning new technologies and concepts could be overwhelming for many people.

The responsibility and the challenge in working with people, who may be opposed to your ideas and suggestions or generally resistant to changes can be very difficult as well. And since you need to communicate with various teams in the organization, it can be frustrating if they don't cooperate:

Another common challenge is that often there are unclear requirements about DevOps in the companies themselves, because some companies don't know exactly what DevOps is and where the responsibilities of DevOps actually lie. 😑
So you may get pushed into some role or in doing tasks, which are not really part of the DevOps area. Now this may change in the future when DevOps processes become more standardized and DevOps role becomes more standardized as well, but currently this is a common issue across organizations.

Something that may also bother some people is that most tasks are not visual, but rather in the background, not directly visible by the end users or even the team members. Sometimes the fact that you don't even notice a DevOps process may in some cases be exactly the purpose of the DevOps task.

Like removing the bottleneck so the processes become more streamlined and smooth and generally when working with people, you need to be a person who is able to cope with that resistance and be empathetic and don't get frustrated so easily.

So overall being a DevOps engineer is a bit challenging, but extremely interesting as well especially for people who love to learn and are always ready to tackle complicated issues.

13) External Factors

Now apart from the personal qualities and preferences, there are some hard facts that may be very important and influence your decision on whether you want to become a DevOps engineer.

Something that speaks very strongly for choosing this career is that DevOps is currently one of the most demanded professions in the IT field 🥇 and is probably going to become even more demanded in the next years as DevOps adoption keeps growing. 📈

So if you're someone who takes the market demand into account, then this will be an important factor in the decision. 👍

What to do next? 👀

If after reading this you think that DevOps is indeed right for you, then check out my video from Zero to DevOps engineer, where you see how you can transition to DevOps with your specific background. 🔝 Whether you are a systems engineer, software developer, test engineer or a complete IT newbie.

And if you actually decide to get into DevOps and become a DevOps engineer and want to commit to learning it, then you should definitely check out our six month DevOps bootcamp, where you learn all the tools and concepts you need to become a DevOps engineer in a structured step-by-step way. 👏

From Zero to DevOps Engineer - DevOps Roadmap for YOUR specific background 🔥

TechWorld with Nana — Thu, 13 Oct 2022 13:35:37 +0000

As a DevOps professional, sometimes I forget how it is getting into DevOps from the perspective of a beginner. So I wanted to create this article outlining a path I would take, if I was starting from zero again. 0️⃣ And having the knowledge that I have now, what would be the most efficient path to get there.

So basically what are the steps to becoming a DevOps engineer, what you need to learn and in which order. ✅

I already made a video about DevOps roadmap, explaining what concepts and tools are part of DevOps, but in this video I wanted to approach it from a different perspective and show how you can become a DevOps engineer, if you were starting from zero.

And I wanted to make it more individual for the people with the most common backgrounds of transitioning into DevOps and based on your replies on LinkedIn, I picked 5 of the most common backgrounds:

system administrators
software developers
test automation engineers
network engineers and
people with zero or very very little IT knowledge.

So if you have one of those backgrounds, this blog post will be very useful for you, showing YOUR individual path into DevOps. So let's get started! 🙌

This is the written version of my new youtube video ✍️

What is DevOps?

If you don't know what DevOps is. You can check out this video first:
👉 🎬 What is DevOps?

What is the DevOps skillset?

Now first in order to understand how to become a DevOps professional, let's define exactly what skill set you require for that. 🤔

1 - Software Development Basics

As you are working closely with the development team to improve and automate tasks for them, you need to understand the concepts of:

how developers work and
what workflows they use,
how they collaborate on developing features,
the modern processes like agile and scrum,
what Git workflow they use and
generally understand what software development life cycle covers from idea to code all the way to releasing it to the end users.

Now here it's important to mention that you don't need to be a software developer or the one implementing those agile and scrum processes. You need to understand how those things work on a high level, conceptually.

2 - Software Deployment

The next one is software deployment. Once the feature is developed, it needs to be released to the end users, which means you need an environment, where your application will be running and be available for the end users.

2.1 - Operating Systems & Linux Basics
And as a DevOps engineer you need to know how to

provision and prepare these environments and
how to maintain them.

And for that you need knowledge of general server administration like creating virtual machines, mostly with Linux operating system, installing software, doing patches, configure networking on premise as well as on cloud.

2.2 - Containers with Docker
And as part of the more modern infrastructure concepts you need to understand how to work with containers and the most popular container technology, which is Docker.

👉🏼 🎬 FREE Docker Course

2.3 - Container Orchestration with Kubernetes
And for projects with tens or hundreds of Docker containers you need to know how to work with container orchestration platforms like Kubernetes, which is the most popular one nowadays.

And again, all these tools can be used either on premise or on cloud.

👉🏼 🎬 FREE Kubernetes Course

2.4 - Cloud - Learn 1 of the most popular cloud provider
If you're working on cloud like AWS, which is the most popular and most used cloud platform for now, you also need to know AWS specific services and how to manage the whole deployment infrastructure on AWS.

Source: Statista Cloud Infrastructure Market Share

3 - CI/CD - Continuous Integration and Continuous Deployment

And connecting all these pieces together and kind of the heart of the DevOps processes is CI CD pipelines.

How do you connect these two software development and deployment? In other words, when software is being developed, how do you deploy those developed features?

It's not just about deploying it to the deployment environment, we don't just take it and throw it on there. Why? Because humans make mistakes, either because of lack of knowledge in some area or just accidentally. So instead we add many gatekeepers before the deployment, so the deployed code needs to go through various of these gate checks in order to be allowed on the final environment and that's what the DevOps CI/CD pipeline is for:

testing code,
packaging it and
deploying all the way to the end environment to deliver it to their end users.

Now what are those gatekeepers? Well, testing the code quality, testing code logic, testing that it didn't break any previously existing code, checking for any security issues, testing that it functions as it's supposed to etc. So tools for implementing this whole CI/CD pipelines with all those gatekeepers is a super important skillset.

So knowing any CI/CD tools like Jenkins, Gitlab CI/CD, GitHub Actions, Circle CI and so on. And most importantly how to integrate this tool with all other technologies to test things, deploy the code and so on is very important.

👉🏼 🎬 FREE GitLab CI/CD Course

4 - Monitoring and Observability

Now again we are humans and we can assume that even with the most cautious measures and a lot of extensive testing, we can't always 100% test every single aspect of the deployment and some issue may slip through in the production. 🤷🏻‍♂️ That's why we have bugs in production and that's okay as long as we have a plan for handling a bug or issue when it appears in production.

So again a part of DevOps skillset is to create a process of handling discovered issues in production instead of having a panic mode. So what does that skillset include? Well, it's a thing called "monitoring and observability".

So in the last stage of CD or continuous deployment, after deploying the code changes, we don't just say: "hey we're done, that's deployed so now let's move on to the next task", instead we observe and monitor closely what happens. If some user encounters an error, if something crashes or doesn't work, so we know we need to proactively fix that. So maybe for a couple of hours or within the next days of deployment, we're actively looking and observing whether some kind of issue appears in production.

👉🏼 🎬 Prometheus Monitoring explained

5 - Automation

And finally the last missing piece of really conquering DevOps is automating all this. 👏 So basically you automate most of your own work and work of other engineers, automating especially in areas where the same task needs to be repeated.

Let me give you some examples, for every new code released:

you always need to test your application,
you always need to check for security,
you always need to package and
deploy application changes.

These tasks should happen automatically, so you make sure to execute automated tests that developers or test engineers write, you have automated security checks, quality checks and you have scripts or automation code that deploys that code to the end environment:

So you don't deploy the application locally from your own machine, but rather CI/CD pipeline deploys it automatically.

Another one is monitoring. Obviously you don't want to be sitting in front of a computer and observing and waiting to see if something breaks in the application, instead you want to deploy tools that monitor the application and notify you if something's off or if something happens:

So monitoring and observability tools go under your DevOps toolbelt as well.

5.1 - Infrastructure as Code
But in DevOps we don't stop there with automation, we also automate things that don't repeat on every code change deployment, but still prove to be incredibly efficient.

So for example provisioning infrastructure or setting up a Kubernetes cluster is not something you do very often but we still automate it in DevOps. Why? Because we want to be able to easily replicate our deployment environments if they get corrupted or if we need multiple staging environments, like DEV, TEST and PRODUCTION:

And generally having everything in code versus some manual scripts that some person on a team executes and no one knows about has many benefits:

First of all, encouraging collaboration in a team on infrastructure configuration
Documenting changes to infrastructure
Transparency of the infrastructure state and
Accessibility to that information in a centralized place versus being scattered around on people's local machines in the form of some scripts.

This is an infrastructure as code concept as part of the whole movement towards automating all workflows to make them more efficient.

And some of the most popular tools in this area are Terraform for Infrastructure Provisioning and Ansible for Configuration Management.

👉🏼 🎬 What is Infrastructure as Code?
👉🏼 🎬 Terraform explained
👉🏼 🎬 Ansible explained

5.2 Scripting skills
While you don't need to actually program the application as a DevOps engineer (more to that later in the article), you will need some scripting or basic programming skills to automate various DevOps processes.

This can be simple shell scripting or even better a full-fledged programming language like Python. However, you don't need to be able to develop web applications with Python like a software developer. Being able to write automation scripts with Python is absolutely enough and is actually way easier to learn.

Some examples would be writing a shell script to do a task in a Jenkins job in a CI/CD pipeline or writing a small utility script for flushing the cache, starting the builds and deployments, connecting different tools etc.

There are many programming languages, but I would recommend starting with Python. Python is widely used, easy to learn and used for many different use cases, especially in DevOps. And the good thing is, programming concepts stay the same, so when you learn one language well, you can easily learn new ones quite quickly.

👉🏼 🎬 FREE Python Course

6 - Version Control with Git

You write all automation logic mentioned above as code.
And just like developers manage the application code with a version control tool, like Git, you need to manage this automation code and configuration files with a version control tool as well.

So these are the fundamental processes and respective tools that are part of DevOps. So any other DevOps tools you may come across - and there are hundreds of them - are simply optimizing or improving different parts of this workflow.

What is YOUR zero or starting point? 🤔

So having those DevOps skills is the final goal and you're starting from zero, but many of you are transitioning to DevOps or starting your DevOps journey having various different backgrounds. So the zero or that starting point is different for all of you and as I mentioned at the beginning you may be systems administrator or software engineer or QA engineer etc or may not have an IT background at all and want to transition into DevOps:

So now I want to show you how you can transition to DevOps and basically learn all these tools that I just mentioned starting from your specific background. ✅

Starting as a Systems Administrator 🧑🏽‍💻

If you are a systems administrator you know how to administer servers and other systems. So you already have some skills in:

setting up infrastructure
configuring and preparing it for deployment
so working with operating systems, installing and running software
security, networking configuration etc is already familiar for you.

Some of the other tasks you do as systems administrator are things like monitoring systems, health, backup and disaster recovery, installing and patching servers and so on.

In smaller projects you may have to also do database administration, network administration or security administration.

All of these are very useful skills, if you want to become a DevOps engineer. 👍 So you already have a lot of skills you can use in the deployment and operations side of DevOps:

This includes Day 0 activities such as initial setup of the infrastructure, but also Day 1 tasks like maintaining and operating this infrastructure.

Many systems administrators also know scripting, so that will be helpful in the automation part of DevOps. So as a systems administrator you already have a very good foundation to get into DevOps, however the big part missing here to start in DevOps is learning the software development basics:

understanding the git workflows
how developers work and so on

Now very important to note, even though some DevOps engineers do know how to program, it's not an essential skill in DevOps, because as a DevOps engineer your main task is not developing and programming the application it's creating automated processes for delivering the developed software to the end users efficiently with as few bugs and issues as possible:

But to be able to deliver the application changes, of course you need to understand how that application was built, developed and how it works.

Starting as a Software Developer 👩‍💻

If you are a software developer, again you have a pretty good background, because you already know an important part of DevOps, which is the software development processes and how these work.

But most probably you are missing skills in server management. So you need to start by learning about:

virtual machines
creating and configuring servers
configuring infrastructure security, networking etc

And since most modern applications run on cloud, you need to also learn how to do all these on cloud infrastructure.

So that would be your starting point when learning DevOps as a software developer.

And once you have that foundation you can build on that by learning about how containers work on top of the virtual machines and how to run applications in containers and how to run containers on a platform like Kubernetes etc.

And of course your programming skills will be great help in writing automated scripts for various parts of the application development and deployment processes. 👍

Starting as a Test Automation Engineer👨🏼‍💻

Another common background people have when transitioning into DevOps is a test automation engineer. Now here you may have a bit more catching up to do and more skills to learn compared to developers or systems administrators, but you can definitely reuse many of your skills in DevOps.

As a test engineer you most probably know how the software developers are working, like the agile processes, Jira workflows and so on. And as part of your test automation knowledge you understand the different testing scopes like

testing on code level
testing the whole application on a more abstract level
testing how the application integrates with other services etc.

You also understand how to test different aspects of an application and that knowledge is really helpful for setting up an automated CI/CD pipeline, because in order to automate the pipeline and streamline delivering your application changes all the way to the production environment, you need extensive automated testing:

Because as soon as you need a human element you will break the automated pipeline and add a bottleneck:

And since you know how to write automated tests in various programming languages, your skills in various testing frameworks is definitely helpful here for scripting and coding some automation parts of DevOps processes. Or let's say it won't be completely new to you. 👍

Starting as a Network Engineer🧑🏻‍💻

The last honorable mention of a background going into DevOps is network engineering. This is probably the farthest from DevOps compared to the other three that I just mentioned, but you still have some skills that you can bring into DevOps as a network engineer.

As a network engineer you know how to configure devices and networking between devices. So you have valuable knowledge in configuring networking for infrastructure on premise.

Transition to Cloud Network Engineer
But as most companies are moving their infrastructure to cloud, many network engineers transition to cloud network engineering:

So they do all of that on cloud platforms. And instead of configuring routes and switches and networks on on-premise infrastructure, they configure virtual routes and virtual switches and virtual networks on cloud infrastructure.

With networking and virtual networking knowledge you have an advantage to understand networking in virtual machines and containers, which is a big part of how modern applications are running. So it will be easier for you to understand Docker and Kubernetes networking for example and these are usually pretty difficult parts to manage and troubleshoot or secure, when you're configuring and maintaining the deployment environments with Kubernetes and containers on them.

So you can definitely use your knowledge and expertise in this area. Some network engineers even know scripting in bash or python for example, which is another helpful skill when it comes to automation part of DevOps.

DevOps Bootcamp considering these different backgrounds 💡

Now all of these backgrounds we actually considered when creating our DevOps bootcamp curriculum.

So we added the Linux Basics module, where you learn everything about Operating Systems and Linux as well as Networking, Bash scripting and so on. Everything from scratch:

So if you are a software developer or a test automation engineer, this will give you the prerequisite knowledge and foundation for learning things like provisioning deployment servers, configuring servers and preparing for deployment etc as well as how to administer some DevOps tools like Jenkins and Kubernetes cluster and so on.

Obviously as a system administrator you would skip that part, but instead you would need to learn Git and how to work with Git workflows, to use it for writing infrastructure as code for example. You also need to learn about build and packaging tools to package the applications written in various languages.

So as you see there are some prerequisites you need to have in DevOps and various backgrounds bring various of those prerequisites with them and we included those prerequisites as well for those missing them, but after those prerequisites are fulfilled the path pretty much looks the same for everybody, because tools like Kubernetes, Terraform, EKS, even Docker are pretty new to many professionals and there is no one profession that was specifically dedicated to those tools previously. So everyone needs to learn them no matter what their IT background is:

Starting with no or little IT background 🙉

Finally, we also get many questions about starting our DevOps Bootcamp with very little to no IT background. Which means there are probably many of you reading this article, who are thinking about getting into DevOps without much IT pre-knowledge and want to know what the path is to DevOps.

Now this is a very tricky one, because DevOps is NOT really the entry-level profession in it. It's not the first thing you learn when you want to get into the IT field.
Now why is that? 🤷🏻‍♂️ Because DevOps is about

automating processes and software development and deployment that people have done manually for a very long time.

This means before you automate processes and tasks that are done manually, you first need to understand what those processes and tasks are in the first place. If you don't understand those, you won't know what you're automating or why you even need DevOps.

1 - Understand complete software development lifecycle

So if you're completely new to IT and already know you want to eventually become a DevOps engineer, then you should start by understanding the complete software development life cycle first. And the good news is, it's easier than it sounds. You don't need to go and learn software development for months for that and you definitely don't need to become an expert in managing infrastructure and configuring servers.

If you learn the right things, you can actually do it in a relatively short time:
Go find some example projects, where you create a super simple application and learn how to deploy to a virtual server, so learning the steps of developing, packaging, maybe even automatically testing and then deploying an example application on a Linux server on a cloud platform.

This will actually be a very good foundational knowledge for building on it to learn DevOps. In this process

you will learn the basics of creating an application,
you will learn how to create a virtual machine with a Linux server on some easy to use cloud platform and host your application there.

And then repeat the whole process once more, simulating making an update to your application and this will teach you basic skills for each part of the software development process, but most importantly it will make you understand the complete workflow of what goes into that. 👀

You don't need any fancy tools for that, no Jenkins, no fancy programming framework, not even Git. Again these are to understand the basic concepts and then you can start learning those DevOps tools like Jenkins, Docker, Kubernetes and so on. Because this phase is not about learning the tools, it's about understanding the concepts and the complete workflow.

2 - How software development teams collaborate

After that go ahead and watch some tutorials about agile and scrum methods and how software development teams collaborate and work in software development projects.

3 - DevOps Pre-Requisites and 4 - DevOps Skills

And these skills will actually be enough to start our DevOps Bootcamp, because Linux, Git and all these basic tools you actually learn in our bootcamp from scratch. 🚀 But again you need to understand those workflows first in order to understand, why we're using Git, why we need Jenkins, why we're learning Linux and scripting etc.

And because of a lot of requests for our Bootcamp from IT beginners 🙈, we actually also decided to create a complete bootcamp prerequisites course. So if you're interested in that you can already sign up to get notified when the course is out 🔔: IT Beginners Course

So you can of course learn this as I said all by yourself following those steps and put a learning path together by yourself or you can use our prerequisites course when it's out.

Summary - DevOps Roadmap

So to summarize there are 4 phases:

1 - Getting the pre-requisites right

First one getting the prerequisites right. So depending on which background and pre-knowledge you have, you need to first make sure to get any missing prerequisite knowledge.

So as a system administrator or a network engineer, learn the software development workflows. As a developer, learn the basics of infrastructure, virtual servers etc. Of course with zero IT background, you have to get all this prerequisite knowledge from server administration to development first. So you have a more difficult entry, but it is possible if you know what to learn.

2 - Cloud, Docker, Kubernetes

Second step is learning cloud, Docker and Kubernetes. After learning the prerequisites, you can already get started with important DevOps skills of working with containers and container orchestration tools. So basically learning Docker and Kubernetes to help your teams deploy and efficiently run the application. Kubernetes itself is a very complex tool, so it may take some time to master it and make it production ready.

And since most of the modern applications and Kubernetes clusters are running on cloud, you need to learn cloud infrastructure, how to work with cloud infrastructure, how to configure it, how to scale it and so on.

3 - Automation

The third step is automation. Once you have mastered the above skills and technologies it's time to learn how to optimize and automate the existing processes. And as a DevOps professional automation skills are one of the most important ones.

As the heart of DevOps, learning to build CI/CD pipelines is an essential skill.

And finally you will learn how to automate parts of the complete DevOps processes one by one using the concepts and tools of what's called X as code, including Infrastructure as Code, Configuration as Code, Security as Code, Policy as Code and so on, which basically means just automating everything in the form of code

4 - Go from there. Keep learning 🙌

Number four is just go from there. DevOps is evolving and new tools are being developed all the time. So as a DevOps professional, you should learn how to evaluate and test many new tools, always with the same goal to optimize and automate existing processes and make them efficient.

Some notable concepts and tools:

GitOps (ArgoCD 👉🏼 🎬 ArgoCD Tutorial)
Service Mesh (Istio 👉🏼 🎬 Service Mesh and Istio explained)

I also have a video where I explain how I personally learn new technologies fast and efficiently, which I will also link right here: How I learn new technologies as a DevOps Engineer (without being overwhelmed)

Now I hope this information is going to be useful for you and I was able to show you what your next steps are for getting into DevOps 😊

Good luck on your DevOps journey! 🎉 💪

Like, share and follow me 😍 for more content:

Top 5 reasons to choose DevOps as a Career 💎

TechWorld with Nana — Tue, 13 Sep 2022 14:31:29 +0000

Many of you may be wondering if DevOps career is for you. 🤔 If you have been following and watching my videos you probably already know that I love DevOps and have a lot of passion for it, but is DevOps for everyone and what are some of the reasons why I personally like DevOps and chose it as a career? And what are some of the advantages that speaks for choosing DevOps as a career in general?

I hope sharing my insights on this topic will be useful for some of you 😊

This is the written version of my new youtube video ✍️

1 - My personal preference 💙

I want to start with my own background and story of how I ended up in DevOps.

I started off as a software developer and in one of my software development projects, I started taking over tasks of configuring servers, configuring builds in Jenkins, configuring application packaging etc. Or configuring things around Docker and running containers, making the builds faster, making tests faster and so on. 🙌 And I noticed that tasks that were related to configuring stuff and optimizing processes were more enjoyable for me than programming. 🤓

Now these are just a subset of tasks in DevOps. I was basically doing some tasks around CI/CD configuration, but DevOps is much more than that:

It spans the whole software development life cycle, essentially optimizing and configuring things for different parts of that software development life cycle.

Source: https://about.gitlab.com/topics/devops/

Now if you don't know exactly what DevOps involves and what that software development lifecycle includes I have a dedicated video on that: What is DevOps?

So basically when you're doing software development you are zoomed in into one specific part of that software development life cycle. When you're doing operations, again you are focused on a specific area of that life cycle.

With DevOps however, you zoom out from those specific areas and parts and start seeing the big picture or a bird's eye view of the whole software development workflow. And you start analyzing how each of those areas are connected like software development processes with Git workflows connect to CI/CD pipeline or CI/CD pipeline connected to infrastructure etc.

And you start analyzing, which areas need improvements, which ones have bottlenecks: like development workflow is super optimized, so your team's generating new features fast, but the pipeline is slow and blocking the release of those features to production.

High Level Thinking 🧠

Now what I also observed is that a different type of thinking is required for DevOps. You need high level thinking connecting dots on a high level: Width instead of depth.
Like an architect making the plan of the whole building and planning how different parts are connected and implemented and then you have different specializations, who actually carry out that plan. So I personally like that role a lot 😇

2 - Diverse tasks and rewarding 💎

And because DevOps covers the whole software development life cycle, the set of tasks or the range of tasks is much more diverse and rich in variety:

Like you could be looking at front-end code and optimizing application packaging process
The next thing could be configuring deployment servers on cloud
Then scripting a program to automate some infrastructure configuration tasks

And if you're like me this may be much more interesting and exciting for many people and again this is probably a personal preference.

Go broader

Some people love focusing on their area of expertise deepening their knowledge in it. Like I learned JavaScript and then I just learn JavaScript to the most advanced level, different frameworks, different features etc.

And there is enough to learn for years in each language and technology, but for many this can be boring. If you're like me you want to have more diverse set of tasks, you want to go broader.

I like architecting processes instead, instead of specializing in just one tool or technology I like to understand whole software development life cycle process and how it all works and more importantly how I can optimize different parts of that life cycle, identifying opportunities for improvements and optimizations 🙌:

like packaging the application takes too long
setting up environment for tests is too slow
security of the build image is not properly checked
or maybe not enough bugs get discovered before deploying to the end environment
or the build process is taking too long
or we find out about issues in production too late
maybe operation team has a lot of effort and needs long time to update and maintain Kubernetes cluster
it takes too long to approve and be confident about deploying new features into production
...

As a DevOps engineer you can solve all these challenges and that in itself for me is a very fulfilling work: Improving things, optimizing, making things faster, automating etc. 🚀

And this leads to the next reason, which is the impact.

3 - Impact ⭐️

As a DevOps engineer you can have a huge business impact in your company by having a good understanding of the whole software development life cycle and improving and optimizing it. And this again can be super fulfilling to know that your work has such an impact and affects many people eventually.

Impact on co-workers 🫂

You can build processes through automation that make the work of your fellow team members in the organization much easier. Smooth well architected processes means that engineers can focus on their areas of expertise and generally enjoy their work much more, instead of doing some boring manual things instead. So you can make lives of developers, operations, testers, project managers and so on easier.

Huge business value 💎

But you also bring huge business value. Well implemented DevOps processes will lead to faster time to market and constant improvement of business quality, cost savings etc. Which means end users are happier and company can innovate and deliver much better. So you have an impact on the whole business.

And this brings me to the next point which is demand for DevOps and salary.

4 - Demand and Salary 💵

Since this is a position that has such a huge impact, it automatically means that you are super valuable for your team and your company, because you literally have direct impact on time to market, cost savings, how satisfied the engineers are with work etc. And companies see that value. 👀

That's why the demand for DevOps engineers has increased so dramatically over the past few years. 📈 Organizations that have implemented DevOps practices are in fact seeing the benefits of high performance, much faster deployments compared to competitors and logically are willing to pay high salaries to find DevOps experts.

The demand is very clearly visible on job platforms as well: indeed.com a major job platform for example had a 75% increase in DevOps job listings and on LinkedIn there was a 50% increase in mentioning DevOps as a skill.

And combine these huge value you are bringing to the company and the high demand for DevOps skills with the fact that there are very few engineers, who actually have those skills and can fill the role. This means if you are a DevOps engineer you are highly demanded and companies will pay premium for having you. This means ✅ flexibility, ✅ lots of options, ✅ high salary with lots of added benefits. So you have a super high leverage.

This means if you actually learn DevOps you will drastically increase your value on the global marketplace and get a whole new set of opportunities out there.

And I think people should definitely take advantage of this opportunity but I also know learning DevOps can be daunting and difficult and that's exactly why we created this full educational program to give people the opportunity to learn all necessary skills to become a DevOps engineer. And we created our program to give you exactly the skills and knowledge to confidently go out there apply for a job as a DevOps engineer, who can help the company implement the DevOps processes from day one and that's what extremely valuable for the employers.

Company perspective 🏢

From the company's perspective, when they are looking for a DevOps engineer they usually write a job opening and either they cannot find any DevOps engineer or get candidates that want to be DevOps engineers, but don't really have enough knowledge yet. 😐 Like they have been developers or can configure servers, but they don't really have any DevOps or core DevOps skills.

So usually what companies do instead is they upskill their existing employees or hire young engineers and train them specifically in DevOps. Because if they can't find them, they should train them. 🙅🏻‍♀️ But again to train people to become DevOps engineers, you need a DevOps engineer to actually train them. 🙉 So we have a lot of companies, who upskill their engineers in DevOps using our bootcamp, which is another proof that companies are willing to invest in building DevOps know-how internally to implement DevOps throughout the organization.

DevOps was not meant as a role

Now I know that there is some controversy around DevOps as a role. That it was meant as a set of concepts and principles and not as an engineering role, but the reality is that there are real DevOps engineering job positions and people who actually work as DevOps engineers 🤷🏻‍♂️ and I actually made a dedicated video on that as well, explaining the topic and how it all evolved so if you're interested you can check it out: What is DevOps?

5 - Continued learning opportunity 📚

Finally, since in DevOps you are covering the whole software development lifecycle, it means you work with lots of tools, so you need to be constantly learning and expanding your knowledge.

Now this might be an advantage, if you're like me and really enjoy learning new stuff all the time or it could be a disadvantage, if you want to focus and solidify knowledge in a few technologies:

This is actually a necessary thing, since DevOps is still evolving and there is a lot of dynamics and changes in DevOps area. So you have new tools, new concepts and solutions that people come up with all the time and as a DevOps engineer you need to actually stay up to date and see what new solutions are available to make the processes even better.

Also DevOps processes are never completed, you don't just build stuff and complete your work once, it's a constant ongoing process. Just like developing an application, you don't just create an application once and you're done, you make improvements and continue making the application better and better, adding new features, fixing the bugs and issues etc. It's the same thing with DevOps processes. So lots of new things to learn all the time.

Downsides 🤯

As I said this could also be a disadvantage and of course like with everything there are pros and cons here as well.

DevOps does come with some challenges as well, like

too much to learn and
too broad of a responsibility can be overwhelming for some people.

Also often there are unclear requirements, because companies themselves don't know what DevOps is exactly. So you may get pushed into some role or in doing tasks, which are not really in the DevOps area. 🤨

Another big challenge is communication with various teams in the organization and it can be frustrating if they don't cooperate. 🗯

Own video: "Is DevOps right for me" 🎬

But I plan to make a separate video, where I talk about advantages and challenges of DevOps as a career in general, so that you can decide whether a career in DevOps is right for you. 👍

If you don't want to miss it, you can subscribe and activate the notification bell to get notified: TechWorld with Nana

Career path is extremely personal 💡

Now finally I want to mention that choosing a career path is extremely personal and depends on many personal circumstances. For me being a DevOps engineer is working on a wide variety of tasks with a wide variety of technologies and tools. It's understanding the bigger picture and being able to investigate issues efficiently. And for me the impact and fulfillment from the work definitely outweighs the challenges 😊

Now I hope this gave you good insights into DevOps and that I could provide some valuable information around it. 😊 It would be really interesting to know what are your experiences in DevOps and your personal preferences?

Share them in the comments for me and for others 👏

Like, share and follow me 😍 for more content:

GitLab CI/CD for Beginners [FREE Course]

TechWorld with Nana — Sun, 12 Jun 2022 12:00:29 +0000

In this GitLab Crash Course, I will teach you everything you need to know to get started with GitLab CI/CD in 1 hour 🚀 😊

Overview - What you’ll learn in 1 Hour ✅

What GitLab CI/CD is
GitLab compared to other CI/CD platforms
Overview of GitLab Architecture
Build a full GitLab CI/CD pipeline for a Python demo app that
- executes tests,
- builds a Docker image,
- pushes to a private Docker repository and
- deploys the app to a remote server on DigitalOcean
Learn GitLab Basic Concepts on the way:
- Pipeline, Jobs,
- Stages
- GitLab Runners and Executors
- Variables (Variable and File Type)
- Docker in Docker

What is GitLab CI/CD?

First of all what is Gitlab CI/CD and why should you even care?

GitLab platform generally is striving to become THE DevOps platform or a one-stop shop for building DevOps processes for your applications.

So they have exactly this roadmap and they're working towards that, which means they're actually integrating and creating new features to basically give you everything in one platform to build complete DevOps processes and big part of those processes is a CI/CD pipeline.

What is CI/CD in simple words

So first of all what is CI/CD in simple words.

CI/CD stands for Continuous Integration and Continuous Deployment or Continuous Delivery and what it basically means is automatically and continuously testing, building and releasing code changes to the deployment environment.

So that means when a developer commits a new code into the Gitlab repository, Gitlab will automatically execute a CI/CD pipeline that you have configured for your project to release those code changes to the end environment, where the end users can access them:

But this CI/CD concept is a topic of its own. If you want to understand it on a deeper level then you can check out my video about DevOps and CI/CD pipeline, where I explain this in more detail here: What is DevOps?

But as I said in simple terms CI/CD is to continuously release your code changes to the end environment and in this crash course we will be building a simplified version of a CI/CD pipeline using Gitlab CI/CD.

Many CI/CD platforms

Of course there are many CI/CD tools, one of the most used ones in the industry still being Jenkins. And Gitlab CI/CD is just one of those other CI/CD platforms:

Source Code & CI/CD on same platform

All of them have their advantages and disadvantages, but a big advantage of using Gitlab to build CI/CD pipelines for your applications is that you already have your code on Gitlab, so this is an extension of your software development processes in your team, where you can also build CI/CD pipelines on the same platform:

So your team already works with Gitlab, you have your code there, so this is basically an additional feature that you can extend your workflows on Gitlab with and you don't need a separate tool for that. 👍

Apart from that Gitlab makes that extension very seamless by allowing you to get started without any setup effort and also having your pipeline as part of your application code compared to Jenkins for example, where you have to set up and configure the Jenkins server, create a pipeline and then connect it to the Git project:

With Gitlab you can start without any of this configuration effort and we will see that in the demo part.

GitLab Architecture

Now if you don't have to set up anything and configure any servers to run the pipelines how does it actually work?
And this leads us to the topic of Gitlab architecture and how it works.

GitLab Instance

You have a Gitlab instance or also called Gitlab server that hosts your application code and your pipelines and basically the whole configuration. So it knows what needs to be done.

GitLab Runners

And connected to that Gitlab instance you have multiple Gitlab runners, which are separate machines connected to the Gitlab server machine, which are actually the ones executing
the pipelines.

So Gitlab server knows what needs to be done and Gitlab runner actually does that:

Managed or SaaS

And www.gitlab.com is actually a managed Gitlab instance that offers multiple managed runners already out of the box.
So these are all maintained by Gitlab and that's why you can start running your pipelines without any setup and configuration effort using this managed setup.

Self-Managed

And this is already enough for starting out but of course for your own organization you may want to manage the runners or the whole setup yourself.

So you can create partially or completely self-managed Gitlab setup as well:

In this crash course we will use Gitlab's managed infrastructure and free features to build our release pipeline. So we will not need to configure anything ourselves. 👍

Pipeline Configuration - .gitlab-ci.yml

Now the question is how do we create a Gitlab CI/CD pipeline? 🤔

Well, following the concept of Configuration as Code or Pipeline as Code, the whole pipeline will be written in code and hosted in the applications git repository itself in a simple YAML file.

And the file has to be called .gitlab-ci.yml, so that Gitlab can automatically detect that pipeline code and execute it without any extra configuration effort from our site:

So in the root of the project's repository, we're going to create this YAML file and we're going to write all the pipeline configuration inside and we can actually
do that directly in the Gitlab UI as well, so we don't have to switch back and forth from the editor to Gitlab.

Jobs

The tasks in the CI/CD pipeline such as running tests, building an image, deploying to a server etc. are configured as what's called 'jobs':

So Jobs are the most fundamental building block of a .gitlab-ci.yml file. They define what to do.

Each job has a name and inside the job we have a couple of
parameters or a couple of attributes or things that we want to configure for the job.

The first attribute and the only required attribute of a job is what's called a script. And script is basically, where we list any commands that should be executed for that job:

So for example for 'run tests', we need to execute `make test* for our python demo application. This is the command that needs to be executed in order to run the test, so we're going to write that command:

However, in order for this to run successfully we need to do a couple of things.

But for the actual demo part, let's continue with the video, so you can follow along more easily: 🤓

▬▬▬▬▬▬ R E F E R E N C E S 🔗▬▬▬▬▬▬
► Git repo we build the CI/CD pipeline for: https://gitlab.com/nanuchi/gitlab-cicd-crash-course

▬▬▬▬▬▬ Course Pre-Requisites ▬▬▬▬▬▬
💡 Docker - learn here: ► https://youtu.be/3c-iBn73dDE
💡 YAML - learn here: ► https://youtu.be/1uFVr15xDGg
💡 Basics of Git

Hope you will learn a lot in this beginner tutorial!

Like, share and follow me 😍 for more content:

How I learn new technologies as a DevOps Engineer (without being overwhelmed 👏)

TechWorld with Nana — Wed, 06 Apr 2022 14:10:32 +0000

In this blog article I talk about the challenge of learning multiple technologies and staying up to date with new ones in the DevOps field and how I personally manage not to be overwhelmed by it and make the learning process much easier. 💯

I hope sharing my experience and tips on this topic will be useful for some of you 😊

This is the written version of my new youtube video ✍️ 🙂

Why it's overwhelming 🙉

As a DevOps engineer you need to learn so many tools to even start your job as a Junior DevOps engineer. So the minimum entry requirement is already super high. Which is logical, because DevOps is about creating end-to-end processes for the complete software development and deployment and there are many tools involved in creating these processes.

👉🏼 More on that here

But in addition to having to learn 5 to 10 technologies right at the beginning, which is you can't just learn them in isolation, but you have to know how to combine them as well how to integrate them together to build those processes.

But it doesn't stop there. To add to this challenge the DevOps space is developing really fast and we see new technologies new concepts emerging all the time so many engineers feel pressure to learn new tools to use in their projects. 🤯

So how can you keep an overview and not get too overwhelmed by all this but at the same time still stay up to date and know when a new tool comes up that can actually make your work easier and more efficient or help you and your team in your software development and deployment process. 🤔

Separate Concepts and Tools

First of all, when we're talking about developments in the DevOps space, there are two main categories:

the concepts 💡 and
the tools 🛠

And it's important to separate them. Concepts are the foundational basis of DevOps processes, they are guidelines to how things should be done. Therefore understanding the concepts before learning the tools is super important.

Tools are just means to an end

It's also important to understand that tools are just means to an end. Every tool is there to solve a problem or to serve some purpose. Understanding the concepts helps you know what processes you have, what problems and challenges are in those processes. And when you have that as a basis, then you can start learning the tools that can actually solve those challenges or implement those concepts.

CI/CD Example:
To give you some examples, before learning any DevOps tool you should actually learn the CI/CD concept first:
👉 What does a CI/CD process look like?
👉 What challenges does it have?
👉 What is its purpose? which is to release application
improvements fast and in an automated way to the end users
👉 What does it include? What steps does it have? Like
building the application, testing, deploying to development, to staging and so on:

And then you learn the tools that implement this concept and help you achieve its goals.

So if you're just getting started in the DevOps field this will be the first step or the first concept to learn.
👉🏼 Here a video exactly on the topic that you can check out

Infrastructure as Code Example:
Another example would be, before learning any Infrastructure as Code tool, you should learn the Infrastructure as Code concept first. Again asking yourself:

Why is it needed?
What is its purpose? Like doing manual work versus automated code for infrastructure provisioning, because manual work is more effort. It has more mistakes, it is less transparent and so on.

And also understand what are the challenges of the Infrastructure as Code concept and then again you learn the tools that implement these concepts and you also understand how these different tools address those challenges.

So now when you're learning DevOps tools or you know a bunch of them already and the new tool comes up, your first question to challenge that technology, is to understand what problem does it actually solve and is that problem relevant for you? So you have a big picture of the concepts and the DevOps processes, because you learned the concepts first, so now you can easily fit each tool into that big picture by just understanding the main purpose of the tool on a high level. 🙌

Use Cases - What problems does it solve? 🤔

So when I start learning a new tool, the first thing I want to find out is, not the cool features that it has or the cool UI that it provides or that it can integrate with 100 other technologies in the ecosystem or that it's super cloud native, Kubernetes native with automated workflow or other fancy stuff 🙄, but instead my first question is what problem or problems does it solve and where does it fit on the big picture of DevOps. 💯 The simpler the answer, the better.

And there are tools that solve one main problem, but there are also tools that solve multiple problems. In which case I want to find out, which one of those problems are the most important, the main ones, because a tool is usually good at 1 or 2 things and the rest of the use cases are additional bonus features. So in this step I investigate the use cases of the tool.

Once the problem is clear, then you can evaluate and measure how important or relevant that problem is to decide, whether you want to dig into that tool deeper and basically learn more about it.

Also for established tools

And for already established tools, like Kubernetes, Docker, Terraform and so on, which you anyways have to learn, it's still the first step. Because you may know that everyone is using Kubernetes and Docker, but you may not know why 🤷🏻‍♂️ and that's the first thing you should understand and find out when approaching any new technology.

How does the tool work? 🧐

After that you can dive in the 'how the tool solves that problem'. There are many tools that address the same issue but in different ways.

So if you are learning an Infrastructure as Code tool like Terraform, you should find out how it does its job, like:
Terraform uses state management

It has modules and providers
It uses declarative approach
It has a command line interface with its own commands
How it connects to the cloud platforms that you want to provision infrastructure on
And also how does it compare to alternative tools that you may already know about

So you learn about the core concept of the tool itself on a high level overview.

Hands-On Practice with realistic use cases 👩‍💻

Once
✅ I understand the problem and the use cases of the tool,
✅ now I know why I'm even learning it,
✅ I also understand how it works theoretically
✅ so i know more or less how I could integrate it into my existing workflow processes.

Now it's time to get started and actually use the tool, because the confidence comes from practice.

Learning with real use cases 🚀

And here is a super important thing to understand about practicing a tool hands-on. You should always practice with an actual example use case, something you can actually apply in real life projects.

So the way I do it is, I first define the actual simple, but realistic use case with the tool, because starting with hands-on practice without an example use case can be demotivating and confusing.

Let me give you some examples:

1) Docker Example 🐳

If you want to learn how to use Docker, just take a simple application and dockerize it with Dockerfile to learn how this process works. Then think about how you can build and run this dockerized application. By implementing these simple steps you will actually learn much more than just randomly learning some concepts about the tool through the official documentation or some blog articles.

So you create a use case like, I have a basic Node.js application:
👉 I dockerize it
👉 I build an image
👉 Push it to the repository
👉 Then I run it and test that the application is accessible

And for each step you can learn how to do it and what are the Docker concepts related to implementing those steps 🚀

Later you can expand that use case. Like you want to add a database connection to your dockerized Node.js application and you want to run multiple Docker containers. So you learn about Docker Compose and how to use it 👍

2) Kubernetes Example

Another example would be, if you're learning Kubernetes. Again think of a simple use case, like you already have a dockerized application with 2 other services. So you want to deploy all of them in Kubernetes with multiple replicas.

By doing just that one simple use case, you will already learn so much about how Kubernetes works and how to deploy applications in it and again you can expand on that use case and add more steps. 🙌

Resources to learn from 📚

Now of course you need some resources to be able to learn how to do this, right? I personally go to the official documentation or blog articles and video tutorials to learn how to do each step individually. So specifically on that topic, because it's much easier to find out resources on specific individual steps, than just learning about the whole
setup.

And while I'm implementing that individual step, I also learn all the concepts related to that on the way or find tutorials and online courses, like ours, where the instructor guides you exactly through this kind of simple but, realistic use case that you can follow along:
💙 FREE Docker course
💙 FREE Kubernetes course

And again you can expand on that finding more advanced use cases at your work or just by yourself and trying to implement those as well.

Patience while learning 😌

Now there is another super important thing I want to point out, when learning the basics of a tool. Especially if it's a tool like Kubernetes or Docker that you know you will definitely need long term in your DevOps career and it is to: have patience while learning. So take your time ⏰ when learning the foundational concepts of the tool in order to avoid leaving any knowledge gaps and trust me it always pays off at the end, because building on a good foundational knowledge is way easier, because you always have reference knowledge for new stuff and the more you learn the more things make sense, the things just click more and learning new stuff becomes more and more easier.

In comparison if you rush into things 🏃🏾, because you don't have patience or you don't have time without really understanding the main concepts and learning things kind of chaotically with lots of knowledge gaps, you may actually get more and more confused if you just add stuff to it. So learning new things may actually become more challenging. 🤯

Embrace lifelong learning 😎

As an IT professional, learning never stops, because the tech world is rapidly changing:

new versions of the existing tools are being released
as well as new tools are being developed all the time

So with the above techniques that I mentioned you will have a good foundation for quickly evaluating new tools, whether they are relevant for you and worth learning but also if you have a good understanding of a specific tool, you can easily learn the new features of that tool as well.

So it's also a mindset of lifelong continuous learning. ♾

How to stay up to date? 🎯

Finally you of course need to be aware when a new version of a popular tool gets released or a new technology is becoming more mainstream and popular so you have to adopt that.

For that you also have many ways to stay up to date with industry developments, like:

🌐 you can follow some industry peers on social media accounts or blog platforms that basically post about these kind of new developments
👥 you can join DevOps communities either online or offline communities, where people exchange this kind of information
🎬 or you can also subscribe to Youtube channels like ours, but also many other channels that make really great videos on DevOps trends as well
and much more ways like podcasts 🎤, newsletters 📩 and so on.

If you're interested, you will find a way to stay up to date that suits you.

How are you tackling this challenge? 🙋🏽‍♂️

Now I hope sharing my experience and tips on this topic was useful for you. 😊 Please share below how you are tackling this challenge and generally share your experiences how do you keep up with technology developments and what are some of your tips on that? 🤔

Like, share and follow me 😍 for more content:

SRE and Tasks of an SRE explained ✅

TechWorld with Nana — Tue, 08 Feb 2022 15:10:43 +0000

SRE is becoming a very popular term in the DevOps and generally the software development world. Probably some of you have already heard about it, but are not sure what it is exactly.

So this article gives a detailed look at what SRE or Site Reliability Engineering really is with the goal to clarify all questions and doubts around it 🙌

This is the written version of my new youtube video ✍️ 🙂

Table Of Contents 📝

Why was there a need for SRE?
What is SRE? - Official Definition
What is system reliability and why it's important?
How to make systems reliable?
SRE in Practice: SLA & Error Budget
SRE Tasks and Responsibilities
Who is doing SRE? SRE Role
SRE vs DevOps

First of all, I recommend that you read my recent DevOps article first, where I explain DevOps in detail. This will make it definitely easier to understand the topics in this video 😊

What is DevOps? REALLY understand it

TechWorld with Nana ・ Jan 18 '22

#devops #beginners #development #sre

How SRE emerged and why was there even a need for SRE? 🤔

In a traditional software development process, we have developers and operations as two separate teams. Each of them with their own goal:

Developers: Want to push out application changes as fast as possible to the end users
Operations: Want to keep the application stable

So Operations are very careful about each and every change and this causes a conflict of interest between these two roles, forcing them to work against each other instead of collaborate:

And DevOps was actually introduced to help fix exactly this issue. However, while DevOps made release process faster, these releases were not as stable as ideally wished by DevOps principles. Plus in DevOps team there was no dedicated role or person that actually focused full time on keeping systems reliable.

And that's how the need for SRE and a Site Reliability Engineer as a separate role emerged. 💡

So what is SRE?

What is SRE? - Official Definition

SRE was conceptualized at Google by Ben Traynor, a software engineer, who was given a task to run a small team of other software engineers to do what used to be Operations work.

And according to his own definition:

SRE is what happens when you treat operations as a software problem and staff it with a bunch of software engineers. 👩‍💻🧑🏻‍💻

At its core:

But this definition is of course too vague and high level to really understand how it's implemented in practice. 🧐 So let's break it down and analyze each part of this definition step by step. 👍

What is system reliability and why it's important? 🧐

First of all, what is a system that we want to keep reliable? Or what does a system even mean in this definition?

What is a System?

The system is the servers, infrastructure, the platform. So the whole deployment environment, where the application runs.

What is Reliablity?

Now what exactly is reliability and why is it so important to keep our systems reliable? 🤔

Unreliable Services ⛔️
Imagine you work with emails daily and your email provider is down once a week or your online banking application is down and not accessible regularly. This would be unreliable services. 🤨 You can't rely that it's available when you need it.

Reliable Services ❇️
On the other hand, many popular services like Gmail, Twitter, Youtube etc are rarely inaccessible. 👏 So these systems are pretty reliable.

But the thing is, users usually do not notice reliability of the system. 🙄 It only becomes visible when something goes wrong and the services are down. Do you remember the recent outage of Facebook, Instagram and other related services that made huge news?

What about AWS server outages that also affected other applications that were hosted on AWS?

Of course everybody noticed and knew about it when it happened. So the more popular and bigger the product or service and the more used, the more impact it will have 👀, if the service had an outage, which means more their team should worry about its reliability.

Why reliability is important?

What are the effects or impact of outages or system unreliability? For most of the services this is a lot of unhappy customers and lots of lost revenue:

Like imagine an online shop is down on a holiday or an online bank is not working, because of traffic overload. This means lots of lost business, because people cannot order anything on that shop.

How to make systems reliable?

Okay, so we understood that systems need to be reliable, but how do we make a system reliable or asked differently:
What makes a system unreliable, what affects its reliability? 🤔

The main cause of system becoming unreliable is, when you make changes to your system ⚡️:

Like change something:
⚡️ in the infrastructure
⚡️ the platform, where the application is running
⚡️ the application itself and its services
⚡️ and so on

These changes may cause a disruption and break something in the whole setup.

Bad Solution 👎🏼

As a solution we can say no changes allowed or limit the amount of changes 🙅🏻‍♂️ to keep systems reliable, but that really limits the business. We want to make changes and improvements to our application to make it better and increase its business value and stay competitive etc. 💪

Because if our competitor is bringing out new features, we need to keep up, and that's the main focus of software developers, to make those changes and improvements.

But on the other hand, if the application is not accessible that's also bad for business, because you may have awesome features, but nobody can use it. And it's the operations job to take care of that and make sure the application is accessible.

This means Devs want to release fast and Ops want to keep stability. So traditionally, Devs would make a change and Ops would analyze with hundreds of checklists and mechanisms to make sure the change would not affect the system:

This whole analysis and evaluations slows down the release process and that's been the major challenge of the traditional way of software development. And that's exactly what DevOps and SRE try to solve. 🚀

So what's the specific solution of SRE here? 💡

Well, SRE tries to automate the process of analyzing and evaluating the effects the change will have on our system reliability. Automation means no checklists or discussions of operations team, whether to release the change or not or what threats and risks are involved:

Instead, the evaluation is based on automated processes and this makes releasing changes fast and safe at the same time. 🚀

SRE in Practice: SLA & Error Budget

Now how is that automated evaluation done? 🤩

The way it works is using what's called SLAs. So what is an SLA? SLA is basically, how reliable a system is going to be to its end users. So how often it's going to be up and how often it's going to be down. And it's expressed in percentage.
A service that works all the time, is never down, has a hundred percent SLA. 💯

No need for 100% Reliability

Now you may be thinking: "Of course any service should be 100 reliable right isn't that a natural goal?" 👀
Well, not really. First of all, it's very hard to achieve 100% reliability and there are very few services in the world that actually need a 100% SLA.

So for example, if your internet provider or the customer's device itself is not 100% reliable, which is the case with most laptops, mobile phones and so on, then your service does not need to be either. It can be available maximum at the same rate as the underlying network or device. 💡

And in those cases a reliability of three nines or four or five nines may be enough, so that users don't even notice that there is an issue. 👌

The closer, you try to get to 100%, the more effort it is, which as you see is an unneeded effort, because you don't need 100% SLA for most applications

Examples of SLA

For example you can define a service level agreement about the accessibility of your application:

Source: https://en.wikipedia.org/wiki/High_availability

So for example a 99 SLA for application accessibility would mean that the system can be down maximum 3.65 days in a year. An SLA with 5 nines or 99.999% allows an application to be unaccessible maximum 5 minutes a year, so the rest of the time it should work.

You can actually define multiple such agreements or SLAs, not just the accessibility or availability of the system.

Other SLA examples:

application response time
error rate

For example if you have an application that serves a million requests a week with 99% SLA, you define that 990 000 of those requests will be successful.

Who defines these SLAs? 💁🏻‍♀️

Okay now you may be wondering who defines these SLAs? So basically who decides how many requests must be successful out of these million requests or how much downtime is allowed for the application? Who makes this kind of decisions?

As this decision affects the end users and their user experience, naturally business people are also involved in this process. So business people together with the engineers like SRE and DevOps Engineers decide together what service level agreements they want to define for their application:

Based on the industry benchmarks, competition, user feedback and so on, business people will define the desired SLAs on a higher level and the engineers will then define them on a technical level and also make sure to integrate them into their DevOps and SRE processes.

Error Budget

As I mentioned SLA for availability defines how long the service should be available or how much downtime is allowed for that service and that allowed downtime is also what's called an error budget:

In SRE, a team can "spend" that error budget on making unreliable changes. So basically that error budget says that we're allowed to have that much downtime in our system without losing business, making customers unhappy, etc.

Way to regulate the release speed ⚖️

So SLA is like a barometer, you can turn it up or down based on how reliable your system needs to be. And of course the closer to 100, the more effort you need to put in to guarantee the reliability of your systems.

Now once the SLA is defined the system performance can be measured against this number.

⛔️ If systems are more unreliable than the SLA allows: Then more resources from the SRE team will be put to make the systems reliable. Again because we have exceeded that allowed amount of downtime. And until the system is recovered to be within the defined SLA, fewer changes will be allowed:

✅ On the other hand if the system is performing well beyond the defined SLA: Developers in the SRE team can release more changes.

So it's a simple way to regulate the release speed of developers. ⚖️ If we turn up the SLA, releases will slow down and vice versa:

SRE Tasks and Responsibilities 👩‍💻

1) Automation - Create automated processes for operational aspects 👏

The SRE or the Site Reliability Engineer is the one, who creates automated processes to calculate and evaluate, whether the service is within the SLA or not.

So now the policy for launching is not the endless checklist that operations use to decide, whether to launch or not, instead an SRE helped design processes that can automatically evaluate an SLA. ✅

2) Configure Monitoring and Logging (Observability for System Performance) 🔎📈

Now of course to measure the performance of our systems and whether services are within the SLA, we need proper monitoring of our systems.

So as another big part of SRE tasks and responsibilities is to configure proper monitoring and logging of the systems to get visibility of what's going on inside.

3) Configure Monitoring and Logging (Observability for Detecting Issues) 🔎📉

Now we said that for most applications SLA is not 100%, which means we accept that it won't work 100% of the time. So at some point we will have an outage 😱

Now the question is, what do we do when an outage happens? Or how do we prepare for it? And that's where another big part of SRE tasks and responsibilities comes in.

The first one is monitoring and alerting, which I already mentioned. So in addition to giving you a visibility to measure your system's performance, but more importantly it helps you detect any indications for issues, before they happen or very early when they happen and then alert the teams about it:

4) Develop custom services to achieve this 👩‍💻

Now another important part of this whole configuration is that, when the issue is alerted and ideally the right person in the team gets the message, the alert message should contain all the needed information to identify and fix the issue fast.

Instead of:
❌ "something is wrong in the cluster"
a more detailed message like:
✅ "service a in cluster b is throwing 500 error"

So know you know exactly:
👉 which service is having a problem
👉 in which cluster and
👉 what that problem exactly is

So more detail the alert message, the better!

In many cases SREs will develop their own custom services to achieve this proper monitoring alerting and logging configuration for their systems.

5) Do On-Call Support ☎️

Another thing that SREs do is on-call support.

Basically, when things go wrong and users need real-time support, somebody is responsible for doing that and that is the on-call support team. And putting SREs on this support team has several benefits:

It helps them really see and understand what issues to expect
How the support deals with the issues?
And what improvements can be made to make the support process more efficient?

Such as:

do alert messages and logs have enough information to quickly identify the issue and the cause?
Where issues identified too late?
etc

So overall the main goal of SRE is to make sure the scope of outage is small when it happens, which means

👍 the outage doesn't last long and is fixed very quickly
👍 and less people and few services are affected by that outage

6) Post-Incident Reviews 🧐

Now fixing an issue or an outage is not the end of the SRE team's work. We want to use that outage as a chance for lessons learned and of course avoid that this happens in the future.

So as a principle of SRE is, to do, what's called Post Mortem, which is latin for "after death". So in SRE terms "after issue" or "after outage analysis".

This includes a thorough analysis, meaning taking time to really go deeper and understand the issues:

But of course during this analysis it's super important to stay blameless, which is one of the major points of this post-mortem analysis, in order to encourage people to admit and learn from their and other people's mistakes ✅

And finally it's important to document everything for future reference!

Who is doing SRE? SRE Role 👤

Now you may be thinking:
"How much more should software developers learn? They already have to know all these software development technologies, now they also have to take over the operations tasks and learn all these operations tools?" 🤯

SRE as its own Role

That's why we have SRE as its own role. So a dedicated person, whose full-time responsibility is to work on keeping systems reliable:

So in many projects along with developers, you have SRE teams, which are the new Operations team. Basically a team that does the operations, where both teams work for the same goal of keeping the systems within the defined SLAs:

So the SRE team maintains and takes care of the automated delivery operations and all sorts of automation that will help developers release their changes safely and fast. 🚀

Software Developers as SREs

However, it's also common to have 1 team of SREs and Software Developers, where SREs also do the software development job. And this means that Site Reliability Engineers must know software development as well, unlike DevOps engineers.

But in both cases, as you see we, started off with a traditional way of software development with separate dev and ops with opposing incentives and with SRE we gave devs and ops the same incentives and put them on the same side. 💙

SRE vs DevOps

Finally, one of the majorly discussed questions in this area is: What is the difference between SRE and DevOps Engineer or generally between these two concepts?

If you already watched my "What is DevOps" video, you know that there are two definitions of DevOps:

the original definition, which is more high level and more broad and doesn't specify how exactly DevOps should be implemented
and a more practical one, which evolved over time with its own DevOps engineer role.

So when we compare DevOps with SRE it's important to know which definition of DevOps we're using for this comparison?

1. First broader definition of DevOps vs. SRE
DevOps is a more high-level concept that defines what needs to be done to achieve the automated streamlined release process, while SRE is more specific about how to exactly implement this process and how to implement DevOps principles.

So many people would say that SRE is a specific implementation of the DevOps concepts:

2. Practical DevOps vs. SRE
But as we saw DevOps itself also became more practical with its own role and specific technologies and ways to implement it. So what's the comparison here? 🤔
Well, in many companies this practical DevOps implementation became more focused and concentrated on the speed of delivery for the application changes and of course even though it's part of the DevOps principles to not only release fast, but release quality code many DevOps teams in practice again seemed to optimize more for the speed than reliability.

So as a great complementary part of DevOps, SRE emerged with the same principles and goals in mind, which is release quality code fast, but as the name suggests more focused on reliability and keeping systems stable, while allowing for fast changes:

So SRE is its own role with its own set of tools for making systems reliable. So these two were kind of parallel developments and are now often seen as two sides of the same coin and it's not uncommon for teams to have both DevOps engineer and SRE helping implement the DevOps principles.

Now I hope you learned a lot in this article and that I was able to answer all of your questions about SRE. 🙂

Like, share and follow me 😍 for more content:

What is DevOps? REALLY understand it

TechWorld with Nana — Tue, 18 Jan 2022 15:18:45 +0000

A detailed look at what DevOps really is with the goal to clarify all questions and doubts around it ✅

This is the written version of my new youtube video ✍️ 🙂

DevOps has been gaining a lot of popularity and is taking over the traditional way of software development.

Difficulty to define DevOps

However, "DevOps" term itself is so broad and includes so many things that it became difficult to exactly define it and clearly set the boundaries of DevOps compared to other IT fields. So this post tries to answer the question of "what DevOps is" in detail.

The simplest definition is that "DevOps is an intersection of Development and Operations".

But where do boundaries of DevOps start and end? Which part of development is not DevOps? Or what part of operations is not DevOps? And why was there even a need for something between development and operations? 🙉

Development and Operations are two main components in the whole application release process:

So let's look in detail at this release process starting from the very beginning!

Application Release Process

Whenever we're developing an application, we always have the same process of delivering that application to the end users. So this is the main goal no matter if you use waterfall or agile or whatever approach. At its core: 1) you create an application 2) and you want to deliver it to your end users so that they can use it. 👩‍💻

So let's say you have a great idea about a cool application. You define its functionality or in other words what features it will have,

you code it,
you test it
and now that you have a tested application you want to actually deploy it on a public server and let users access it.

For that you build and package your application in some kind of executable form so that it can run. You configure the public server with all the needed stuff like installing any tools the application needs and deploy your application there, you configure firewall rules to allow access to the application on the server and you have launched, users can start using it! 🚀

So that's the simplified basis of any application release, but that's not the end of the journey. While in use, you of course have to check in on your application:

Is everything running fine?
Are users experiencing any issues?
Maybe there are bugs in the application that you didn't catch when testing
Can application handle high user loads?
etc

So after launching it, you have to actually make sure that your application is accessible and usable by end users and if there are any issues for users, of course you should fix them.

Now that was the initial launch of your application, but the application development is not done yet. If you see users like your application you would want to make it even cooler, add new features, maybe optimize the performance by getting better servers or making your application faster and so on. So you still have a lot of things to do and every time you improve your application either the code itself or the server configuration you want to make this improvement accessible to the end users immediately.

So after the initial launch you do multiple updates to your application and to keep track of these updates you version those changes.

And you do that over and over again:

you have an idea of improvement
you implement it in code
you test it
build and package it
you deploy it
and once released, you observe it in the production to see whether there are any new improvement possibilities or any issues that need to be fixed right away

So this gives you a process of continuous delivery of changes an endless cycle of improvements to your application.

And DevOps is about making this process of continuous delivery fast and with minimal errors and bugs:

So with DevOps improvements get created and delivered to users fast, but also those improvements are of high quality and well tested. And that is a big challenge: quickly delivering high quality code. 😳

Challenges DevOps tries to solve

Now let's see what are exactly the challenges that teams may face during this process and which DevOps tries to solve.

During this whole release process we have roadblocks and frictions:

Now what are the frictions and roadblocks in the release process? 🤔

1) Miscommunication and Lack of Collaboration ⛔️

First and the most important challenge is miscommunication and lack of collaboration between developers and operations.

So releasing application has two main parts:

you code the application
you deploy and run the application

Developers are responsible for coding. Operations are responsible for running the application.

And between these two there might be a gap of: "I wrote an application, but I can't run it" or "I'm running the application, but i don't know how it works" 🙇🏻‍♂️:

So developers would code without considering where or how the code will be deployed, while operations would try to deploy without really understanding what and why they are deploying or how the application even works. And this would result in miscommunications between these two.

For example:
Developers finish coding but the deployment guide for the operations team is not good enough or well-documented enough, so operations team struggles deploying it, so release takes longer.

This kind of miscommunication could cause stretching the release periods for days and weeks and in complex badly maintained projects maybe even month.

So between the developer is done with the feature and operation starts deploying it, there is no clearly defined automated process of handover. It's based on a complex bureaucratic process of what checklists 📝 need to be completed and what needs to be documented and who needs to manually approve what for the release and so on. So no streamlines or automated processes here.

2) Conflict of Interest ⛔️

Apart from miscommunications between development and operations, in a traditional setup, where one team is only responsible for development and other team only for operations, these two have seemingly different incentives that make it hard for them to work together.

Developers want to push out new features fast, while operations want to make sure those changes don't break anything, because operations are incentivized to maintain stability in production. Their main focus is to make sure the application is available, doesn't crash, doesn't show 500 errors to the users and so on.

This means that operations need to resist the speed of release and check all the aspects of a new release to make sure it's 100% safe, which again slows down the process, especially considering that operations don't really understand the code or the application. So it's even more effort for them to evaluate this new release.

So even though the main common goal of everyone in a company should be to deliver high quality applications to the end users fast, in practice the more immediate goals are for each role to do their job. And developers job is to quickly create new features and push them out, operations job is to maintain the system stability and resist new changes being pushed out:

This gives us a conflict of interest and this kind of setup naturally makes it difficult for those two to collaborate. 🤷‍♀️

3) Security ⛔️

Another showstopper when releasing a feature is Security. Just like operations team carefully evaluates and changes to make sure they won't affect system stability, security team will evaluate any changes to make sure they don't affect systems security:

And in a traditional setup this is the same manual bureaucratic process as operations, which takes days or weeks and slows down the release process.

And as I mentioned DevOps is about removing any roadblocks that slow down the process, so it includes this one as well.

However, even though this is part of the DevOps solution, there was a separate term created for that called "DevSecOps" in order to highlight and just remind the teams of the importance of security, because it somehow got left out.

I actually have a separate dedicated video on DevSecOps, which you can also check out if you're interested: DevSecOps explained

4) Application Testing ⛔️

Now adding to the list of show stoppers is application testing. In many projects there are separate teams or roles for testers, who test the application changes on different levels:

like testing just the feature
testing the whole application,
testing on multiple environments etc.

And often these tests are done manually, when teams cannot totally rely only on their automated tests and only after manual testing is done, can the change be released:

Even though this may not be done by development or operations role, but rather a separate tester role, this is an important part of the release process and may also slow it down considerably!

5) Manual Work ⛔️

As I mentioned, many of the tasks during the release process like testing, security checks, deployment etc used to be done manually. 🙇🏻‍♂️

For example, operations would do most of the operations tasks manually, either by directly executing commands on the servers to install tools, configure stuff, do patches or have scripts or small programs they execute. But in both cases this is manual work:

Drawbacks of manual work
This manual work is slow and more error prone, because of human error plus with manual work you have a disadvantage that knowledge sharing is very difficult, because people who do the tasks would have to document it and others would have to read it.

It's also very intransparent, because it's hard to trace, who executed what when and finally when infrastructure configuration and so on was done manually, if something happens to the infrastructure, it may be really hard to recover and replicate the exact state fast. You would have to remember exactly what was done on the servers, in which order to get to that previous infrastructure state. 🤦🏽‍♀️

DevOps tries to remove these roadblocks ✅

So you see the main characteristic of all these issues is that they all slow down the release cycle and create roadblocks on the way. And you also see in case of security and testing, that DevOps may even go over only development or only operations responsibilities and tasks:

That's why to understand DevOps instead of focusing on the name and what it means, we're focusing on what it tries to achieve: 💡

DevOps tries to remove all these roadblocks and things that slow down the release process, whatever that may be and instead of manual inefficient processes helps create fully automated streamlined processes for release cycles.

And this can be done step by step, removing one roadblock at a time until you have a fully optimized and automated DevOps process, that makes your application release super easy. 🚀

DevOps Concept as a Solution

So how does DevOps help achieve this and solve all these challenges? 👀

Well, by the official definition and this was the original idea of DevOps:

DevOps defines a combination of cultural philosophies, practices and tools for doing that.

So DevOps is not just one set of tools or one specific concept, it's a combination of anything that creates the process of releasing the software fast and with high quality. And the main part of the concept was that developers and operations people should work together more often, talk to each other more often and collaborate better to achieve that.

DevOps in Practice: DevOps as a separate Role

But actually this definition is too broad and too high level and makes it hard to imagine how it works in practice. 🙉 So it's just not specific enough. So naturally different companies implemented DevOps in different ways. So the actual implementation of DevOps looked pretty different from company to company.

But since companies started adopting it, gradually it got a more concrete form with some of the common patterns across many companies and one of these patterns was that DevOps evolved into an actual role called a "Devops Engineer", where either developers are doing DevOps as a job next to development or operations are doing it or someone is doing DevOps exclusively as their only job.

And a set of technologies that were used to implement the DevOps principles became DevOps technologies, which now DevOps engineers would need to learn:

And I understand that many people are resisting the idea of DevOps engineer and the creators of the DevOps concept didn't see it used this way, but the reality is often different from the theory. We see that concept was adjusted and bent to meet the needs of the end goal and DevOps engineer role is what came out of it. 🤷‍♀️

And that DevOps role is responsible for creating a streamlined release process without any roadblocks slowing down the release and that's why in the center of DevOps is the well-known Continuous Integration / Continuous Delivery process

DevOps in Practice: How to become a DevOps Engineer

Check out my other blog article to see:

DevOps Roadmap - How to become a DevOps Engineer

TechWorld with Nana ・ Jan 17 '21

#devops #career #beginners #cloud

After reading this, you may be thinking, these are a lot of things to learn and it may be hard to know, where to start or what to learn first or what resources to use. 🤯

Well, there are many resources out there to learn individual DevOps technologies, 👍 I actually cover many of the DevOps technologies on my Youtube channel. 😊
But ideally you want to follow a well-structured step-by-step roadmap and more importantly learn how to use these technologies together in combination, because that's what DevOps engineers do. They use and integrate multiple technologies together to create DevOps processes and of course you want to learn all these with actual real-life project examples to know how it will look like in a real job. And very few courses and learning resources offer this and that's exactly why we created a complete DevOps Bootcamp with a clear structure and lots of hands-on projects.

So if you're thinking about becoming a DevOps engineer or slowly transitioning into DevOps you can definitely check out our DevOps bootcamp 🚀

DevOps vs SRE - How SRE fits into the whole DevOps process

To get a full picture of DevOps I want to mention one more concept, which is SRE or Site Reliability Engineering and how it fits into DevOps.

We just learned that there are two definitions of DevOps

the original definition, which is more high level and more broad and doesn't specify how exactly DevOps should be implemented
and a more practical one, which evolved over time with its own DevOps engineer role.

So when we compare DevOps with SRE it's important to know which definition of DevOps we're using for this comparison?

So many people would say that SRE is a specific implementation of the DevOps concepts:

Own 'What is SRE' video coming soon.. 🎬
This was just a short look at SRE to understand it in comparison to DevOps, but since I have received many questions about what SRE is, I will release its own follow-up video on SRE in the next weeks to explain in more detail like how SRE works in practice, what are the tasks and responsibilities of a Site Reliability engineer and so on.

For DevOps I hope I could clarify all your questions about it. If not leave a comment in the video and I will try to answer them 😊

Good luck on your DevOps journey! 🎉 💪

Like, share and follow me 😍 for more content:

Golang Tutorial for Beginners [FREE Course] 🎉

TechWorld with Nana — Mon, 20 Dec 2021 15:13:23 +0000

In this full Golang course you will learn about one of the youngest programming languages that is becoming more and more popular in the cloud engineering world.

You will learn everything you need to get started with Go and start using it in your projects. ✅

What is Go? 💡

Go is a programming language, which was developed at Google in 2007 and open sourced in 2009. So it's a pretty young language.

The language is called Go. However, it's also commonly known as Golang. This is because the website was originally golang.org

Now whenever you hear about a new programming language the first question you probably have is:

Why do we need yet another programming language? 🙄
What is the purpose of it or how is it better or different from other already existing languages?

So before diving into the syntax, let's see what was the motivation behind creating the Go language?

Why Go was developed? How it's different from other programming languages? 🧐

Infrastructure changed

Well the infrastructure, where the applications were deployed changed a lot in the last few years:

Multi-core processors became common
and also using cloud infrastructure with hundreds or thousands of servers with multiple processors to deploy applications became pretty universal

So infrastructure became much more scalable, dynamic and had more capacity. However, most languages couldn't help in writing applications that would take advantage of these infrastructure improvements. So basically you had applications that would just execute one task at a time in order.

But with infrastructure improvements it was possible to now
write applications that would execute tasks in parallel, do multiple things at once. This way making the application faster and more user-friendly. 🚀

Multi-Threading - Do multiple things at once

A simple example is, if you are using Google Drive you may be uploading or downloading files and folders, but you can keep navigating back and forth in the UI. So downloading, uploading and navigating the UI all happen in parallel.
So the application allows you to do multiple things at once without affecting any other task:

And this is a concept of multi-threading. So each thread is basically processing one task and you can have many of them running in parallel and this makes applications fast but may also cause some issues. 👀

Challenges

For example on Google Docs, many users can work on the same document at the same time. So when you have two users changing and adding stuff at the same time to the same document, this should work smoothly without one user overriding all the changes that another user is making.

Another example where such issues may happen, when things are processed in parallel is a booking system for buying tickets or booking a hotel etc. Let's say again two users are trying to book the last remaining ticket at the same time. Of course this should work in a way that no double booking happens.

And this concept is called concurrency and needs to be handled by developers in code. So they must write code that prevents any conflicts between the tasks, when multiple tasks are running in parallel and updating the same data.

Language Concurrency Support

Many languages do have features for implementing such applications, however the code can get pretty complex and
handling and preventing the concurrency issues can be pretty hard. And with complexity there is always a higher risk of human errors and that's where the main purpose and difference of Go comes into the picture.

So Go was designed exactly for that purpose to make writing multi-threaded concurrent applications that take advantage of the new performance infrastructure much easier.

We will learn about this in more detail at the end of the course, when we use goroutines:

Main Use Case of Go

So logically enough the main use case of Go or what it's best used for is writing applications that need to be very performant and will run on the modern scaled and distributed infrastructure with hundreds and thousands of servers typically on a cloud platform.

Go is used on the server side or the backend of the applications and these types of applications can range from microservices and web applications to database services.
And so in fact, many cloud technologies or technologies that run on modern cloud environments are actually written in Go, like Docker 🐳, Hashicorp Vault, Kubernetes, CockroachDB and so on.

Characterstics of Go Language

Compiled Language

Go is a compiled language and it compiles actually very quickly into a single binary. You can deploy and run it on different platforms in a consistent way, so no matter which operating system or which environment you're using you can take that same binary and basically use it across different platforms.

Combine Ease of Programming with Efficiency and Safety

For developing Go, they wanted to take the simplicity of syntax of a more high-level language, like Python and the speed and efficiency of a lower level language like C++.
So you will see the combination of these things in Go.

Language features left out on purpose for simplicity 💡 The goal was that the code should be easy to maintain over time.

The simple syntax makes your code very maintainable, easy to read and extend.
Go applications can be built very fast, they are also very fast in startup and also when they're running.
Go is very resource efficient, which means it uses few resources or it requires fewer resources like CPU and RAM to run.

Considering all these benefits of simplicity and speed and so on, Go is also becoming more and more popular for writing simple automation applications and CLI applications for DevOps and SRE tasks as well.

So now that we know why Go was created and what differentiates it from other languages 👍 , let's jump right into learning the core concepts and syntax of Go.

Learn Syntax and Concepts while writing a simple application 👩‍💻

In the tutorial, we're going to write a very simple ticket booking application to learn the basics of Go. So instead of learning the concepts and syntax of Go with isolated examples, you will learn them while building an actual application throughout the tutorial. 😎

But for the demo part, let's continue with the video, so you can follow along more easily: 🤓

▬▬▬▬▬▬ COURSE OVERVIEW 📚 ▬▬▬▬▬▬

💎 Part 01: Introduction to Go

What is Go? Why Go?
How it's different from other programming languages?
Characteristics of Go and Go Use Cases

💎 Part 02: Local Setup

Install Go & Editor
Write our First Program & Structure of a Go File

💎 Part 03: Go Syntax & Concepts

Variables & Constants in Go
Formatted Output - printf
Data Types in Go
Getting User Input
What is a Pointer?
Arrays & Slices
Loops in Go
Conditionals (if / else) and Boolean Data Type
Validate User Input
Switch Statement
Encapsulate Logic with Functions
Organize Code with Go Packages
Scope Rules in Go
Maps
Structs

💎 Part 04: Concurrency in Go

Goroutines

Hope you will learn a lot in this beginner tutorial!

Like, share and follow me 😍 for more content:

Redis - the What, Why and How to use Redis as a primary database

TechWorld with Nana — Thu, 02 Dec 2021 16:38:05 +0000

This is the written version of my new youtube video ✍️ 🙂

In this Redis tutorial, you will learn about Redis and how Redis can be used as a primary database for complex applications that need to store data in multiple formats.

Overview 📝

What Redis is and its usages as well as why it is suitable for modern complex microservice applications?
How Redis supports storing multiple data formats for different purposes through its modules?
How Redis as an in-memory database can persist data and recover from data loss?
How to scale and replicate Redis?
Finally since one of the most popular platforms for running microservices is Kubernetes and since running stateful applications in Kubernetes is a bit challenging, we will see how you can easily run Redis in Kubernetes

What is Redis?

Redis stands for remote dictionary server

Redis is an in-memory database. So many people have used it as a cache on top of other databases to improve the application performance. 🤓

However, what many people don't know is that Redis is a fully fledged primary database that can be used to store and persist multiple data formats for complex applications. 😎

So let's see the use cases for that.

Why Multi-Model Database?

Let's look at a common setup for a microservices application.

Let's say we have a complex social media application with millions of users. For this, we may need to store different data formats in different databases:

Relational database, like Mysql, to store our data
ElasticSearch for fast search and filtering
Graph database to represent the connections of the users
Document database, like MongoDB to store media content shared by our users daily
Cache service for a better performance for the application

It's obvious that this is a pretty complex setup.

Challenges of having multiple data services

❌ Each data service needs to be deployed and maintained
❌ Know-How needed for each data service
❌ Different scaling & infrastructure requirements
❌ More complex application code for interacting with all these different DBs
❌ Higher Latency (Slower), because of more network hopping

Having a Multi-Model Database

In comparison with a multi-model database you resolve most of these challenges. First of all you run and maintain just 1 data service. So your application also needs to talk to a single data store and that requires only one programmatic interface for that data service.
In addition, latency will be reduced by going to a single data endpoint and eliminating several internal network hubs.

So having one database, like Redis, that allows you to store different types of data or basically allows you to have multiple types of databases in one as well as act as a cache solves such challenges.

✅ Run and maintain just 1 database
✅ Simpler
✅ Reduced Latency (Faster)

How Redis works?

Redis Modules 📦
The way it works is that you have Redis Core, which is a key value store that already supports storing multiple types of data and then you can extend that core with what's called modules for different data types, which your application needs for different purposes. So for example RediSearch for search functionality like ElasticSearch or Redis Graph for graph data storage and so on:

And a great thing about this is that it's modular. So these different types of database functionalities are not tightly integrated into one database, but rather you can pick and choose exactly which data service functionality you need for your application and then basically add that module.

Out-of-the-box Cache ⚡️
Of course when using Redis as a primary database you don't need an additional cache, because you have that automatically out of the box with Redis. That means again less complexity in your application, because you don't need to implement the logic for managing populating and invalidating cache.

Redis is fast 🚀
As an in-memory (data is stored in RAM) database, Redis is super fast and performant, which of course makes the application itself faster.

But at this point you may be wondering:
How can an in-memory database persist data? 🤔

How Redis can persist data and recover from data loss? 🧐

If the Redis process or the server on which Redis is running fails, all the data in memory is gone right? So how is the data persisted and basically how can I be confident that my data is safe? 👀

Replicating Redis?

Well, the simplest way to have data backups is by replicating Redis. So if the Redis master instance goes down, the replicas will still be running and have all the data. So if you have a replicated Redis, the replicas will have the data.

But of course if all the Redis instances go down you will lose the data, because there will be no replica remaining. 🤯So we need real persistence.

Snapshotting & AOF

Redis has multiple mechanisms for persisting the data and keeping the data safe.

Snapshots

First one: the snapshots, which you can configure based on time, number of requests etc. So snapshots of your data will be stored on a disk, which you can use to recover your data if the whole Redis database is gone.

But note that you will lose the last minutes of data, because you usually do snapshotting every five minutes or an hour depending on your needs. 😐

AOF

So as an alternative Redis uses something called AOF, which stands for Append Only File.

In this case every change is saved to the disk for persistence continuously. And when restarting Redis or after an outage, Redis will replay the Append Only File logs to rebuild the state.

So AOF is more durable, but can be slower than snapshotting.

Best Option 💡 : Use a combination of both AOF and snapshots, where the AOF is persisting data from memory to disk continuously plus you have regular snapshots in between to save the data state in case you need to recover it:

How to scale a Redis database?

Let's say my 1 Redis instance runs out of memory, so data becomes too large to hold in-memory or Redis becomes a bottleneck and can't handle any more requests. In such case how do I increase the capacity and memory size for my Redis database? 🤔

We have several options for that:

1. Clustering

First of all, Redis supports clustering. This means you can have a primary or master Redis instance, which can be used to read and write data and you can have multiple replicas of that primary instance for reading the data:

This way you can scale Redis to handle more requests and in addition increase the high availability of your database, because if master fails 1 of the replicas can take over and your Redis database basically can continue functioning without any issues.

2. Sharding

Well that seems good enough, but what if

your dataset grows too large to fit in a memory on a single server.
Plus we have scaled the reads in the database, so all the requests that basically just query the data. But our master instance is still alone and still has to handle all the writes.

So what is the solution here? 🤔

For that we use the concept of sharding, which is a general concept in databases and which Redis also supports.

So sharding basically means that you take your complete data set and divide it into smaller chunks or subsets of data, where each shard is responsible for its own subset of data.

So that means instead of having one master instance that handles all the writes to the complete data set, you can split it into say 4 shards, each of them responsible for reads and writes to a subset of the data. 💡

And each shard also needs less memory capacity, because they just have a fourth of the data. This means you can distribute and run shards on smaller nodes and basically scale your cluster horizontally:

So having multiple nodes, which run multiple replicas of Redis which are all sharded gives you a very performant highly available Redis database that can handle much more requests without creating any bottlenecks 👍

Top 8 Docker Best Practices for using Docker in Production ✅

TechWorld with Nana — Sun, 21 Nov 2021 12:53:45 +0000

Docker adoption rises constantly 📈 and many are familiar with it, but not everyone is using Docker according to the best practices. 👀

Before moving on, if you don't know what Docker is, you can learn everything you need to get started in this free Docker Crash Course 🐳

Why using Best Practices? 🤷‍♀️

So, in my new video 'Top 8 Docker Production Best Practices' I want to show you 8 ways you can use Docker in a right way in your projects to:

✅ improve security,
✅ optimize the image size,
✅ take advantage of some of the useful Docker features
✅ and also write cleaner and more maintainable Dockerfiles

1️⃣ Best Practice

Use an official and verified Docker image as a base image, whenever available.

Let's say you are developing a Node.js application and want to build and run it as a Docker image.

Instead of taking a base operating system image and installing node.js, npm and whatever other tools you need for your application, use the official node image for your application.

Improvements:

Cleaner Dockerfile
Official and verified image, which is already built with the best practices

2️⃣ Best Practice

Use specific Docker image versions

Okay, so we have selected the base image, but now when we build our applications image from this Dockerfile, it will always use the latest tag of the node image.

Now why is this a problem? 🤔
❌ - you might get a different image version as in the previous build
❌ - the new image version may break stuff
❌ - latest tag is unpredictable, causing unexpected behavior

So instead of a random latest image tag, you want to fixate the version and just like you deploy your own application with a specific version you want to use the official image with a specific version.
And the rule here is: the more specific the better

Improvements:

Transparency to know exactly what version of the base image you're using

3️⃣ Best Practice

Use Small-Sized Official Images

When choosing a Node.js image, you will see there are actually multiple official images. Not only with different version numbers, but also with different operating system distributions:

So the question is: Which one do you choose and why is it important? 🤷🏻‍♂️

1) Image Size
❌ Well, if the image is based on a full-blown OS distribution like Ubuntu or Centos, you will have a bunch of tools already packaged in the image. So the image size will be larger, but you don't need most of these tools in your application images.

✅ In contrast having smaller images means you need less storage space in image repository as well as on a deployment server and of course you can transfer the images faster when pulling or pushing them from the repository.

2) Security Issue
❌ In addition to that, with lots of tools installed inside, you need to consider the security aspect. Because such base images usually contain hundreds of known vulnerabilities and basically create a larger attack surface to your application image.

This way you basically end up introducing unnecessary security issues from the beginning to your image! 🙉

✅ In comparison by using smaller images with leaner OS distributions, which only bundle the necessary system
tools and libraries, you're also minimizing the attack surface and making sure that you build more secure images.

So the best practice here would be to select an image with a specific version based on a leaner OS distribution like alpine for example:

Alpine has everything you need to start your application in a container, but is much more lightweight. And for most of the images that you look on a Docker Hub, you will see a version tag with alpine distribution inside.

It is one of the most common and popular base images for Docker containers.

4️⃣ Best Practice

Optimize caching for image layers when building an image

So what are image layers and what does caching and image layer mean? 🤔

1) What are Image Layers?
A Docker image is built based on a Dockerfile.
And in a Dockerfile each command or instruction creates an image layer:

So when we use a base image of node alpine like in the above example it already has layers, because it was already built using its own Dockerfile. Plus, in our Dockerfile on top of that we have a couple of other commands that each will add a new layer to this image.

2) Now what about caching?
Each layer will get cached by Docker. 👍
So when you rebuild your image, if your Dockerfile hasn't changed, Docker will just use the cached layers to build the image.

Advantages of cached image layers:
✅ - Faster image building
✅ - Faster pulling and pushing of new image versions:
If I pull a new image version of the same application and let's say 2 new layers have been added in the new version: Only the newly added layers will be downloaded, the rest are already locally cached by Docker.

3) Optimize the Caching
So to optimize the caching, you need to know that:
Once a layer changes, all following or downstream layers have to be re-created as well. In other words: when you change the contents of one line in the Dockerfile, caches of all the following lines or layers will be busted and invalidated. 😣

So the rule here and the best practice is:
Order your commands in the Dockerfile from the least to the most frequently changing commands to take advantage of caching and this way optimize how fast the image gets built. 🚀

5️⃣ Best Practice

Use .dockerignore file

Now usually when we build the image, we don't need everything we have in the project to run the application inside. We
don't need the auto-generated folders, like targets or build folder, we don't need the readme file etc.

So how do we exclude such content from ending up in our application image? 🤔
👉 Using a .dockerignore file.

It's pretty straightforward. We basically just create this .dockerignore file and list all the files and folders that we want to be ignored and when building the image, Docker will look at the contents and ignore anything specified inside.

Improvements:

Reduced image size

6️⃣ Best Practice

Make use of Multi-Stage Builds

But now let's say there are some contents (like development, testing tools and libraries) in your project that you NEED for building the image - so during the
build process - but you DON'T NEED them in the final image itself to run the application.

If you keep these artifacts in your final image even though they're absolutely unnecessary for running the application, it will again result in an increased image size and increased attack surface. 🧐

So how do we separate the build stage from the runtime stage.
In other words, how do we exclude the build dependencies from the image, while still having them available while building the image? 🤷‍♀️

Well, for that you can use what's called multi-stage builds 💡

The multi-stage builds feature allows you to use multiple temporary images during the build process, but keep only
the latest image as the final artifact:

So these previous steps (marked "1st" in the above picture) will be discarded.

Improvements:

Separation of Build Tools and Dependencies from what's needed for runtime
Less dependencies and reduced image size

7️⃣ Best Practice

Use the Least Privileged User

Now, when we create this image and eventually run it as a container, which operating system user will be used to start the application inside? 🤔
By default, when a Dockerfile does not specify a user, it uses a root user. 🙉 But in reality there is mostly no reason to run containers with root privileges.

❌ This basically introduces a security issue, because when container starts on the host it, will potentially have root access on the Docker host.
So running an application inside the container with a root user will make it easier for an attacker to escalate privileges on the host and basically get hold of the underlying host and its processes, not only the container itself 🤯 Especially if the application inside the container is vulnerable to exploitation.

✅ To avoid this, the best practice is to simply create a dedicated user and a dedicated group in the Docker image to run the application and also run the application inside the container with that user:

You can use a directive called USER with the username and then start the application conveniently.

Tip: Some images already have a generic user bundled in, which you can use. So you don't have to create a new one. For example the node.js image already bundles a generic user called node, which you can simply use to run the application inside the container. 👍

8️⃣ Best Practice

Scan your Images for Security Vulnerabilities

Finally, how do you make sure and validate the image you build has a few or no security vulnerabilities? 🧐

So my final best practice is, once you build the image to scan it for security vulnerabilities using the docker scan command. 🔍

In the background Docker actually uses a service called snyk to do the vulnerability scanning of the images. The scan uses a database of vulnerabilities, which gets constantly updated.

Example output of docker scan command:

You see:
1) the type of vulnerability,
2) a URL for more information
3) but also what's very useful and interesting you see which version of the relevant library actually fixes that vulnerability. So you can update your libraries to get rid of these issues. 👍

Automate the scanning 🚀
In addition to scanning your images manually with docker scan command on a CLI, you can also configure Docker Hub to scan the images automatically, when they get pushed to the repository. And of course you can integrate this check in your CI/CD pipeline when building your Docker images.

So these are 8 production best practices that you can apply today to make your Docker images leaner and more secure! 🚀😊 Hope it is helpful for some of you! Of course there are many more best practices related to Docker, but I think applying these will already give you great results when using Docker in production.

Do you know some other best practices, which you think are
super important and have to be mentioned?
Please share them in the comments for others 🙌 👍

The full video is available here: 🤓

Like, share and follow me 😍 for more content:

Kubernetes Crash Course for Absolute Beginners 👏

TechWorld with Nana — Thu, 30 Sep 2021 14:18:53 +0000

Kubernetes, also known as K8s, is the most popular platform for container orchestration for automating deployment, scaling, and management of containerized applications.

Why we need Kubernetes? 🤔

After you have learnt Docker 🐳 you can start creating very complex applications with tens or even hundreds of containers, with containers talking to each other and interacting in some way.
And these containers would need to be deployed across multiple servers in a distributed way.
So you can imagine the overhead and effort you would have, if you had to manage these hundreds of containers manually without automation. 🤦‍♀️

Every time containers crash or the communication between them isn’t working across multiple servers, you would have to interfere and fix the problem.

So it would be great to have a tool that will automatically fix such issues and recover the application state. That tool is a container orchestration tool. ⭐️

And Kubernetes is one of the most popular container orchestration tools out there.

Getting started with Kubernetes 😎

In this crash course you will learn everything you need to know to get started with Kubernetes in 1 hour. You will learn all the core concepts, its architecture and how Kubernetes works including the main Kubernetes components that you need to learn to work efficiently with Kubernetes.

Finally, I will show a hands-on demo project, where you will learn how to deploy a web application with its database into a local Kubernetes cluster. It's a simple but realistic application setup, which can also serve as a blueprint configuration for most common application setups.

The full tutorial is available here: 🤓

▬▬▬▬▬▬ COURSE OVERVIEW 📚 ▬▬▬▬▬▬

💎 Part 01: Introduction to Kubernetes

In the first section you will learn all the core concepts.

What is Kubernetes
Benefits of Kubernetes
Kubernetes Architecture (Control Plane and Worker Nodes)

💎 Part 02: Main Kubernetes Components

K8s has tons of components, but most of the time you are only working with a handful of them. This part shows you step by step how each component helps you to deploy your application and what the role of each of those components is.

Node & Pod
Configuring Access with Service & Ingress
External Configuration with ConfigMap & Secret
Persisting Data with Volume
Replication with Deployment & StatefulSet

💎 Part 03: Kubernetes Configuration

In this part you'll learn the syntax and contents of K8s configuration file , which is used to create and configure components in a Kubernetes cluster.

💎 Part 04: Setup Kubernetes cluster locally (Minikube and kubectl)

What is Minikube
What is Kubectl
Install Minikube and Kubectl

💎 Part 05: Complete Demo Project: Deploy WebApp with MongoDB

I will show a hands-on demo project, where you will learn how to deploy a web application with its database into a local Kubernetes cluster. It's a simple but realistic application setup, which can also serve as a blueprint configuration for most common application setups.

Demo Project Overview
Create MongoDB ConfigMap
Create MongoDB Secret
Create MongoDB Deployment and Service
Create WebApp Deployment and Service
Pass Secret Data to MongoDB Deployment
Pass Config Data to WebApp Deployment
Configure External Access
Deploy all K8s resources into Minikube cluster
Interacting with Kubernetes Cluster
Access Web Application in Browser

▬▬▬▬▬▬ Course Pre-Requisites ▬▬▬▬▬▬
Docker - learn here: ► https://youtu.be/3c-iBn73dDE
YAML - learn here: ► https://youtu.be/1uFVr15xDGg

Like, share and follow me 😍 for more content: