Becoming a DevOps Engineer

From a Sysadmin turned DevOps Engineer’s perspective.

I was a Linux Admin for the better part of my career, I jumped on the opportunity to become a DevOps Engineer when I got the chance, but I had to change everything I knew. I would like to share what I learned, hope it helps.

Let’s start from the basics, in any software company the final product is what we sell that’s what makes money for the business.

Business ——— Product——→ Customer

Business ←——Money$$ ——Customer

The guys who build the software/features/bug fixes and make money are the Engineers.
Everyone else is there to help them do their job better so we can deliver new features or better features fast to the customer.

In the old days when the Engineering team(from now on I’ll refer to Software Engineers as just Engineers or the Engineering team) has an idea for a product and has a PoC (proof of concept) and are ready to go live….

To go live aka to get it across to customers, it could even take up to months for the Server team, Database Team, Networking teams to get in place the physical servers, switches, cabling, networking, preparing the OS in the servers, prepping the Databases and everything else we need to deliver the software.

Enter Cloud Computing…..

Now we have cloud computing where we can have a server, database, networking all done in a matter of few minutes if not seconds.

DevOps is a culture that breaks silos where the Engineering team and the support teams work together to deliver software faster.

A DevOps engineer could be a

System admin who has learned programming tools and can automate what he knows using those tools to build the infra that the software needs.
Or
A Software Engineer who has a solid foundation on automation and learns the systems(Server) side of the business and uses his preexisting skills as a software developer and his gained knowledge about the cloud to build the infra fast.

That being said one tool that sits at the center of the whole thing is the CI tool.

Source Code
|
|
|
What happens here?
|
|
|
\/
Customer

The software is developed and

The code is — Ready
The cloud infra is — Ready

How to deliver the code that has new features FAST?

Introducing the CI tool — This sits at the heart of delivering software fast.

This tool takes the code and runs steps you have defined and it finally delivers the software to the customer.

So what are these steps that the CI tool runs?

Have you ever used software that’s buggy or played a game that has a strange glitch? Did that make you wonder?

Why didn’t they fix this?
Don’t they use the software before releasing it?
Don’t they play the game before selling?
In other words — Don’t they test this?
Welcome to the world of Testing.

This is where professional Testers test the software developed by the Engineering team.

There are many kinds of Functional and non-functional tests, few examples are Unit testing, Integration testing, End-to-end testing, Smoke testing, Usability testing, Scalability testing, Volume testing, Stress testing, Maintainability testing, etc.,

A big part in delivering new features fast is to automate the tests as much as possible, Enter Shift left.

In traditional software development testing happened somewhere here.

Source Code=====> Testing=> Customer.

When the testers find something that needs to be fixed we’ll have to go back and do the whole thing all over again.

Shift left principle is where we move Testing closer to development, aka Test Driven Development(TDD) more we do this more solid and sound tests we can have that will become part of the pipeline(uh oh a new word!).

A pipeline is the name we’ve chosen to call the flow of code in the CI tool.

Let’s look at the DevOps tools and how they work together in the coming articles.

Thank you.