In this video we're going to talk about two
popular roles in software engineering: "DevOps" and "Cloud Engineer". Now there is a lot of mix up
of these two roles and many people, many companies often use them interchangeably. They mix the tasks
and responsibilities of these two very often. There are for example plenty of job descriptions
for DevOps Cloud Engineer or Cloud DevOps Engineer, which would naturally make you think
that they are the same role. But then why would you have two names for the same role? And that's
exactly what I'm going to discuss and clarify in this video. So first of all, let's start by
saying that DevOps in Cloud Engineer are actually two different roles with different purposes and
objectives. But the reason why people mix them up and even use them interchangeably is, because
they often have many overlapping responsibilities and skills and also because for relatively
new roles, companies sometimes have hard time defining the boundaries between roles. Like when
a software developer should program full stack web application, do operations, monitoring, build the
whole CI/CD pipeline, fix the company's Wi-Fi and change the light bulbs in the office. So basically
just putting anything and everything on one person or one job description. So in this video we're
gonna define those boundaries and see what a Cloud engineer does, what DevOps engineer does,
what are the tasks they both do, so the overlaps between these roles and what is, that really
differentiates them and draws a clear line between the two. And of course since we are on TechWorld
with Nana channel we're gonna see all of that with actual practical examples, not just some generic
explanations. But first let me get one thing out of the way, which is that DevOps engineer was
actually not meant as a separate role originally. DevOps is a concept and a set of principles and
different engineer roles like software developer, IT operation, server administrator and so on were
supposed to implement those DevOps practices and principles. So that was the original idea of
DevOps. However the reality now looks different with hundreds of thousands of DevOps Engineer
jobs, which means it actually evolved into its own engineering role, which I personally think
makes total sense. If you want to know why and all the details around it, you can watch my videos
on DevOps engineering specifically where I explain all this with the whole evolution of this role
and so on. Okay now that we've established that DevOps engineer is its own role, let's compare
the two and let's start with the objectives. DevOps Engineer's main objective is to make the
process of releasing software fast, efficient, without bugs or issues and they achieve
that by automating this whole process. So instead of manual steps of approving the
release, testing the application changes, validating that everything works or
making sure the security is configured etc. So the DevOps engineers automate this whole
process so that it's faster without manual human interaction points. And I actually have a detailed
video on that if you want to see exactly what DevOps Engineers tasks and responsibilities are,
which I will also link in this video. But in a nutshell that's an objective of a DevOps Engineer.
On the other hand, the cloud engineer's main objective is to create and manage infrastructure
on cloud, so that applications that companies developing can run on it. Now you're probably
thinking create and manage cloud infrastructure that sounds very vague and not really clear and
specific. So let's start from the very beginning. First of all we have hundreds of cloud platforms
which are basically companies who went and bought a whole bunch of computers, server machines, wired
up the whole thing, configured the networking etc., built the data centers with all those
machines in different locations and other companies can now rent those servers for the
fraction of the cost. At least that's how it started, with a simple use case to be able to
rent a server without having to do the whole infrastructure setup yourself, which is a huge
overhead if you only need just a few servers. But over time that evolved into something much
more powerful and much more complex. Now we have Cloud platforms that offer way more than
just compute resources, like renting a server. You can now get not only your whole infrastructure
on cloud, but also a bunch of services on top of that. Like your application needs
database services, cache storage backup, maybe you want to run the whole application setup
in a kubernetes cluster, you want to store the docker images on cloud, build the whole CI/CD
pipeline even and you want to do it in multiple geographic regions. And when you have hundreds
of employees you also want to manage access to your cloud resources users and permissions and
so on. In cloud platforms now offer all that through their cloud services and we have tons
of small local cloud platforms with maybe one, two data centers, who only operate in one country
or region, then we have some larger ones and the gigantic ones like AWS, Google Cloud, Azure. These
three are currently the biggest cloud platforms, with AWS being by far the most highly used one.
So now whether you are a small startup or a large company, you can create your entire setup on
a cloud platform, without having to own any infrastructure and often without having to install
and configure things from scratch, like set up a Docker image registry or installing a kubernetes
cluster on servers, because this type of things are often provided as managed ready services for
you to use by those cloud providers. So let's take AWS as an example. So with AWS you get tons of
services that are already configured on top of the actual underlying physical infrastructure. AWS has
services not only for software development, but also for machine learning, big data processing,
mobile development. It has many types of storage services based on speed, size, durability. So
you have literally everything on there. But not only that, you also have an option to create
and manage your own virtual servers and install things on that yourself or you can let AWS manage
the underlying infrastructure completely for you, by using their higher level managed services.
Or even the combination of both. So you have all these options, which is very powerful and it
makes the cloud platforms much more than just a place where you can rent your infrastructure.
But with so many options and so many services also comes the complexity, which means, sure, now
you don't have to know how to set up an entire registry and set up database with backups
from scratch or manager storage yourself, you can use the cloud services directly for those
things. But now you need to learn how to use those services and integrate them or plug them in into
your applications. And those services are specific to the cloud platform that provides them. So
you need to learn how to use Kubernetes cluster service on AWS which is called EKS. Or you have
to learn how to use and manage an image registry on AWS called ECR. If you instead go for Azure or
Google cloud or you move away from AWS to one of those platforms, now you have to learn how to use
the equivalent service on Azure or Google Cloud, because they work a little bit differently.
And these platforms provide the same services, but they work differently and have different
configuration options. So you have to learn all that specific to the platform. The same way
you need to set up the underlying infrastructure, servers, firewall configuration, proxies for
your application, security within your network, etc. So you need to learn AWS services,
that allow all this configuration. And when you use those services, you don't just
configure them so that your application runs on it, everything works and that's it. That's
actually not enough. You need to actually configure it reliably and securely,
because everything may be working fine, but you get millions of users visiting your
application and now your whole setup crashes, because your application setup was not designed
for such a high load. Or even more important, someone hacks into your setup, wiping out your
data or completely messing up your whole setup. Or a new developer accidentally misconfigures
something and ruins your AWS infrastructure setup. So knowing this cloud specific services
and how to configure them reliably, securely, in a proper way for your applications to
run smoothly, these are exactly the tasks and responsibilities of a Cloud
Engineer. Now before moving on, I want to give a shout out to JetBrains Space
and TeamCity, who is a sponsor of this video. While Space is a complete software development
platform, containing git hosting, code reviews, CI/CD issues and more, TeamCity offers a flexible
build pipeline. Using Git flow and code reviews together with Space and TeamCity means changes to
your application code base are always reviewed. And thanks to Safe Merge, you'll always have a
main branch that compiles and can be deployed. So the combination of these tools is powerful
and the native integration will save you time and effort by ensuring you have a complete
and well integrated flow, with a unified UI. Getting started is easy and free so be sure
to check it out in more detail. As always, I'll put the links in the video description.
And now let's continue with the video. I mentioned that cloud platforms are different and
their services need to be configured differently. So you need a specific knowledge of that specific
cloud provider to properly configure your infrastructure setup there. This means as a Cloud
Engineer, you usually specialize in one cloud platform and learn how to use their services. So
you're kind of an expert in that cloud platform. That's why we usually have AWS Cloud Engineer,
Azure Cloud Engineer specializations. Now going back to the initial definition of creating and
managing cloud infrastructure, what would be some example tasks of an AWS Cloud Engineer, as part
of creating and managing AWS cloud infrastructure. Well let's say a company is developing an
application or multiple applications, which should run on cloud. So AWS Cloud Engineer's job
is to decide, how to create an AWS infrastructure to run those applications, which AWS services
to use, should they rent servers and directly configure stuff on them or use managed services
instead, which cost more but are easier to configure and manage. Like install and configure
cluster database on servers or use the RDS service from AWS where all of that is already configured.
Then we have questions like, which storage to use and how to configure that. Maybe your application
needs different types of storages, so how to map those needs to AWS storage types. How to do
data backups, so in case of disaster data can be restored. Make sure the applications and access
to the whole AWS infrastructure is secure. Because of the complexity of such large cloud platforms
and so many options, it's powerful, but complex. So there are lots of ways of misconfiguring
things, so it's not that straightforward. That's why good Cloud Engineers who are able to configure
things correctly with best practices, security, etc. are so valuable. And since Cloud
Engineer has knowledge of all AWS Services, they know how to configure what company needs
with those services. So they can directly map the company's business needs and requirements
to the cloud setup. Like if a company needs geographical distribution all over the world,
because they have users all over the globe, Cloud Engineer would help configure that by using
the right services and configuring them correctly. Another example would be, if a company has a
microservices application to deploy on cloud. Of course you need expertise in how to configure
the cloud infrastructure to make sure a complex microservices application can run on it with
production best practices, like redundancy, reliability security, data backup and
restore mechanism. Again that's where the Cloud Engineering skills and expertise is needed.
Another interesting use case is as we all know more and more companies are moving to cloud,
but many of them aren't starting from scratch, but rather they have an existing on-premise
infrastructure and services so they want to migrate that to cloud. And building something
from scratch on cloud is often way easier, than migrating an existing infrastructure
to it. Many companies are also using hybrid cloud. So they want to migrate only parts
of their local infrastructure to cloud, which means they need integrations between local
and the cloud infrastructure. Many companies also do multi-cloud, which means they want to use
AWS and Azure, maybe for redundancy like if something happens to one AWS data center you have
a fallback. Or just in order to take advantage of strength of different cloud providers and
what they are good at, like they want to use AWS computing resources, but company has
lots of internal Microsoft applications, so they want to leverage Azure Cloud for that. So
with multi-cloud again services and applications need to be connected across cloud platforms
and those are all very challenging tasks. So in those cases Cloud Engineer would develop the
strategy for migrating and help successfully migrate to cloud and create integrations in hybrid
or multi-cloud environments, where services need to communicate securely and reliably across those
environments. Another example is cost tracking, because when you use many resources, many cloud
services, combine them in various ways, you need to watch out for the cost or at least be able to
predict, how much it will cost. And when you have complex setup with geographic distributions using
many cloud provided services for convenience, it can get pretty expensive. And that's again where
Cloud Engineers tasks and responsibilities are, to make sure that company doesn't have huge
cost overruns on their cloud infrastructure. Cloud Engineers would also monitor the configured
infrastructure, to detect any attempts of hacking into the systems. Maybe the cost is spiking
because some resources were misconfigured. Are service running fine, do they have enough
resources to handle the traffic and so on. And finally cloud services and infrastructure
can get very complex, very fast. Which means you don't want to be managing and configuring
or creating things in a complex cloud setup manually. You don't want people joining
your company or your cloud team wondering, how the whole infrastructure was created,
how it's configured, what's configured, where and why. So you need some transparency
of your infrastructure setups as well. And also making sure when someone joins in the cloud
engineering team they can easily get on board and not accidentally misconfigure stuff or ruin
the existing setup and so on. And in case things break, in a cloud setup you want to be able to
replicate the same cloud configuration again and recover the setup quickly without having to
remember exactly what you did to configure the current setup and what exactly needs to be done.
And that's where infrastructure as code comes in. So Cloud Engineers would automate a lot of
their own tasks for infrastructure creation and maintenance using infrastructure as code.
Because when you have really complex setups, after some point you can't possibly manually
manage that anymore. So you will 100 percent need to have some automation. Now going back to
the original comparison between DevOps Engineer and Cloud Engineer to summarize the differences,
DevOps Engineers automate software release process to make it faster, while Cloud Engineers
automate cloud infrastructure and management to make companies cloud infrastructure reliable,
fast and secure easily recoverable and so on. So obviously two very different objectives. But
here is the overlap. Part of software release is its deployment on servers, on infrastructure. So
if companies deploying its applications to cloud, DevOps Engineers responsibility naturally
becomes to make sure the cloud infrastructure is configured and managed properly to allow
for fast deployment, for automated testing, validating whether deployment works with blue
green or canary deployment strategies and so on. So DevOps Engineer's job would extend
to managing the underlying infrastructure, monitoring that is working fine so the
applications can be deployed and run successfully, making sure that it's secure, it's not running
out of resources, that it's geographically distributed and so on If application is
running in Kubernetes cluster managed by AWS, DevOps engineer would make sure the cluster is
running fine, it's correctly configured with security in place and so on. And again DevOps is
about automating things to be fast and efficient, so DevOps Engineers would also use infrastructures
code tools to automate infrastructure management monitoring etc., but only the parts that directly
affect the release process of the application. So as you see the cloud infrastructure management
that directly affects how fast the application can be released, deployed, recovered and so on is also
part of DevOps Engineers tasks. And that's where the main overlap happens. So from this perspective
it seems like DevOps kind of includes some of the Cloud Engineers tasks. So companies usually just
hire DevOps Cloud Engineer who does everything. But logically it's not possible for one role
to do everything from release management, to infrastructure management, to backup and
restore management, cost oversight and so on. So we have additional Cloud Engineer role, that is
dedicated to cloud services and managing them and should actually be a help for DevOps Engineer
to help each other in their own objectives. So the objective of Cloud Engineer, which is
reliable secure infrastructure also affects the DevOps Engineer's objective
of releasing applications fast, because they have to run on that infrastructure.
Which means Cloud Engineer takes care of managing infrastructure and makes sure it runs reliably,
so DevOps engineer can build automated processes on top of that to release the applications and
run them on that reliable properly configured cloud infrastructure. And you can even use
the controls that Cloud Engineer configured to monitor the application to do the automated
validation, implement deployment strategies and so on. So that's basically the comparison
between the two. I hope I was able to give you some clarity around these two roles and was
able to answer your questions around them. Let me know in the comments whether you work
in any of these two roles and whether you see the confusion and the mix-up of those two and
in which form. I'm sure the other viewers will also be interested to know. And with that thank
you for watching and see you in the next video!
