DevOps! Where do I Start?

“To begin, begin.” ~ William Wordsworth

IT World loves buzzwords, the most recent one that you could hear and see more often is DevOps. What is it, and why is there so much hype around it in the IT community?

DevOps is Huge and Growing Fast

The DevOps market is expected to grow up from $3.42 Billion in 2018 to $10.31 Billion by 2023. It gives us some idea that this is something growing up amazingly fast — 3 times in 5 years, quite impressive. But what illustrates the interest of the industry much better is — 149,941 job listings in LinkedIn returned from ‘DevOps’ job search Worldwide and the fact that in average, DevOps Engineer in the U.S. makes $100K and above.

Let us find out what is so attractive in this mysterious six-letter word.

What is the purpose of DevOps?

The term DevOps consists of two parts — it comes from a combination of Development and IT. Operations. It is a set of modern practices and tools used in Software Development. Its main goal is to help organisations to increase speed in the delivery of applications and services with high-quality standards to satisfy their customers’ needs. Basically, this is the goal of any business — to grow by attracting more customers which is only possible if you deliver results better and faster than your competitors.

There are a few questions you might be thinking already. How exactly can DevOps help in achieving this goal? Why is it considered a game-changer?

How did we live without DevOps before?

First, let us remember how software development was done in the past. In the good old days, when computers where large — every server was a single piece of hardware that used to perform some predefined set of instructions, Mostly considered as “Program”. The number of programs and servers were quite a few. There were people whose job was to develop programs for these machines — “The Developers”, and there were people who used to maintain, service and operate Backend Servers, Operating Systems, Databases etc. — “The System Administrators” (or IT. Operations). These two roles did not have much of the intersection of skillset, and their tasks were pretty much isolated from each other. Systems or Software development lifecycle (SDLC) was quite long, and before some program could be deployed to the production server, it could take weeks or even months. Each change or code fix had to go through a long, tedious and mostly manual process which was prone to delays and human errors.

This classic SDLC process consists of the following stages:

Analysis → Design → Development → Testing → Deployment → Maintenance.

This approach still works fine in many companies; it is well known; it has its own project management methodologies and approaches and is not going to disappear any time soon.

What could be improved in SDLC?

But there is one significant drawback in this practice — And that is, the lack of continuity and a gap between Development and IT. Operations. In this process, the ball is being passed sequentially from one team to another, and there is no fast feedback mechanism to pass it back or to restore if something is suddenly broken. In case of a software failure — Admins can blame Developers for producing low-quality code; Developers can claim that it is Administrators who could not properly configure the servers. The common problem is when a developer runs his program on his own machine, it is working fine, but once the program is shipped to a server, it crashes.

Developers says, “It works on my machine” and Admins are to figure out what is wrong with the server, Operating System configurations, 3rd party software, libraries, dependencies and so on. This process was meant to be improved, and it eventually was.

With the growth and popularity of Microservices software architecture; and also with the evolution of development and system administration tools, the processes and best practices have also changed. The number of software products has drastically increased, so also has the workload on the entire IT Operations.

DevOps is the Way!

To support operations of multiple servers and later virtual machines and later containers, they needed automation. It was inevitable. Admins started to develop their own custom-built scripts to spin up new servers from pre-configured images, develop in-house monitoring solutions, create automated tests and checks before rolling out a patch, configure monitoring and alarming systems to trigger a notification if something goes wrong during or after installation. Eventually, those scripts, practices, and tools evolutionary have converted into commercial and open-source software products.

The software process itself has also changed. Agile methodologies were invented and adopted by many companies. These Agile processes focus not only on classic metrics that are being measured, such as Cost and Capacity (Resources) but also introduced a new on — Flow (Time). In the World of Agile methodologies, speed of delivery is crucial. These days, businesses and consumers are not willing to wait for weeks and months to get a new feature. New requirements appear constantly; old requirements become obsolete before new ones are delivered. If a competitor can deliver it faster, then I must do it even faster and, at the same time, without sacrificing the quality.

So, excuses like “It works on my machine” are not valid anymore.

There Must Be A way.

1. There must be a way to make the software work the same way on all environments: regardless if it is on developers’ machines or production servers.
2. There must be a way to reduce the time it takes from the developer’s code commit to Version Control System (VCS) such as “Git” until the feature, or the fix is deployed to production.
3. There must be a way how to automate this process, make trackable, measurable, flexible and to have a clear picture and actual state of all resources and tools being used.

If it is not a silver bullet, then it must be something close to it.

We are not talking only of a set of software tools to automate software development and delivery activities; it is also a set of practices and approaches on how to organize the process itself; how to train personnel with relevant skills; how to continuously improve the process and make it as agile as possible.

DevOps-ready ecosystem

Of course, DevOps is not something that works on its own; it organically fits current software development ecosystem:

1. Where high-level programming languages like Python and Javascript have become more developer-friendly.
2. Where Virtualization, Containerization and Cloud Computing has converted servers from pieces of equipment into virtual entities that can be transferred over the network as a regular file.
3. Where modern version control systems allow multiple programmers to work with the same codebase without conflicts.
4. Where software testing is automated.

Having said that, we can conclude that the whole software industry has changed, and DevOps is an inevitable result of combining the best out of two worlds — Software Development and System Administration (IT. Operations).

Compared to classic SDLC, DevOps is more granular and offers continuous feedback from Dev to Ops and back in an endless loop.

Source Wikimedia.org

DevOps engineers are universal soldiers that have an extremely broad set of weapons in their arsenal; they are highly skilled and trained to make software development and delivery as smooth as possible.

What else? More awesome tools for automation

Another quite common term that you might also hear when talking of DevOps is Continuous Integration & Continuous Delivery (CI/CD) — is a set of automation tools that complements DevOps practice. The main idea is that small and frequent releases will less likely break the system, and it is also easier to be fixed rather than big ones. Of course, it does not mean that these releases have to be rolled out to production and affect end users — if it fails it better fail fast and it better fail at the earliest possible phase, for example, on a test server. This approach allows to test small releases much more often, basically after every code commit and reduce risks of failing big in production.

Want to practice DevOps in your organization?

So, what does it take to implement DevOps in a company, and how can you become a part of this exciting community?

As I have mentioned, it is not only about tools and processes — DevOps is a philosophy that a company must adopt and follow. It includes the transformation of business processes, decomposition them into measurable atomic blocks and composing as more automated processes as possible. It is an almost never-ending iterative improvement process that can help you to satisfy business needs faster with the best quality.

The key points DevOps brings:

• Automation
• Measurability
• Continuity
• Monitoring and proactive reaction
• Release often.
• Fail fast
• Recover faster

DevOps Engineer is now an incredibly attractive position in the IT. World and decent experts are of high demand on the market. But it’s also a very competitive, challenging and demanding role; you have to master not only multiple technologies and tools, but also have a deep understanding of its concepts, share this philosophy of constant improvement, total automation, tracking and monitoring every possible action and retrospectively analyze what can be further optimized and automated.

Here is only a part of the technologies you might be asked to be familiar with in a DevOps interview.

But do not be scared, it is still young and a dynamically evolving practice and a lot of tools perform similar specialized functions. It is much more important to know what they do and overall concepts. If you know one Version Control System well it will be relatively easy for you to pick up another one if you are asked to. Same goes to Configuration Management Tools or Monitoring Tools. It is a very “Knowledge” and “Skills” demanding role, but it is also a very rewarding one. You can be a part of building great software solutions end to end and if you master in DevOps — you can further strengthen your skills in this area, or move forward up to CTO/CIO role.

Join DevOps army!

You might be wondering, Where do I start? What skills shall you master? What technologies to study? And so on.

Many DevOps engineers have come from IT. Operations, System Administration, Development or QA. backgrounds; thus they have pretty deep knowledge in Server Administration (Windows, Linux, Unix), Network (TCP/IP), Web (HTTP), Security (AAA), some Database administration knowledge (SQL) and one or more scripting language such as Bash, Perl, Python or Javascript.

Indeed, this is a background you will be comfortable to start with. You shall have this knowledge of basic IT. Concepts in your toolkit before you start learning more DevOps specific technologies such as CI/CD, Infrastructure as Code (IaC), Containerization and Orchestration, Cloud Computing (IaaS, PaaS, SaaS), Monitoring and Logging, Complex Process automation etc. The more you learn, the more you can contribute in end to end software delivery process, the more valuable you become on the job market.

And moreover, a DevOps Engineer probably has the best view and best understanding of the core business process in a software company, even better than CTO because he has them constantly tracked, measured, and monitored.

What if I don’t have any IT Background?

Hope is definitely not lost if you are coming from a completely different career. As a matter of fact, I have seen many people from other career fields such as Accounting, Management, or field engineering become DevOps engineer in 6 to 12 months period. But that can only happen when you have a dedicated Mentor to guide you, and also get the opportunity to work on real-world projects. Especially, with a real company practising DevOps. This is where DAREY.IO shines. We at darey.io have established a system that helps people to learn the DevOps tools on the job. Check it out.

There is no better time than NOW!

And the last question you might ask “Is it too late to start learning DevOps by now”? The answer is simple — it is not. There is no better time to start than today, it is a vast ocean of knowledge, and there will be much more, the progress is not going to stop. If you start today — in the future, you might invent something completely new, improve existing tools or just lead some exciting project helping this World to become a better place.

Conclusion

As we have learned, DevOps is a mixture of technologies, processes, and people with the right working culture and mindset. Only this combination can compose a strong value chain. It is a self-improving mechanism that ensures constant measurable and monitored enhancement of the software delivery process. It is the right time to become a part of it.

Let us begin!

Would you like to know more?

To get the hands-on practice of DevOps implementing real-life scenarios visit our website and become a DevOps expert!

Stay tuned for more blog updates.