Hot Shot 007 – Decent DevOps Defined [Podcast]

Hello there, once again, and welcome to another hot shot. My name is Peter Pilgrim, Platform engineer and DevOps specialist, and Java Champion.

What is a definition of decent DevOps? Here is a simple explanation. It is a combination of software development skills with that of a system administrator.

If you know how to program and very well, then you are similar to me, then your approach to DevOps is closer to that of a tactical and top flight software engineer.

You most likely have been programming application software almost all of your life. You can write decent quality and productive programs, impressive ones to boot. You possess creative skills, you already know plenty of programming languages from experiences. You might be efficient in high-level programming on the JVM such as the mother of them all, Java. You already might have an alternative language under your belt, such as Groovy, Scala and even Clojure. If it is not the JVM, then you have experience of native programming such as C / C++ from way back in the day. In the modern terms, you might have developed using GO or RUST. If you have no JVM experience, then you might have come into this from the Microsoft community with C#, Dot Net and if you are truly hipster, you might have Ruby experience.

(These notes are a little bit more off the cuff than usual — my apologies)

System administration is to ensure that all related computer systems and services keep working, available for use by the business (a system can be a website, it can be a persistent store, LDAP and a suite of core applications).

A system administrator, or sysadmin, is a person responsible to maintain and operate a computer system or network for a business. The role of a system administrator can vary a lot from one organization to another. For example, inside one organization, such as a forward-looking financial institution, you might be looking about AWS and PaaS solution. In another organization, such as a utility energy business, you may only have to deal with a traditional RDBMS and Java application servers.

In the old school way of thinking, classic System administrators are usually charged with installing, supporting, and maintaining servers or other computer systems, and planning for and responding to service outages and other problems. In the new school of thinking, especially with the cloud computing, system admins are heavily involved in automation features, monitoring and eventually site reliability.

System administrators share programming duties with their classic software engineering folk. Practically, every system administrator knows how to program. They know how to test code (whether test-driven or not). Other duties may include scripting or light programming, project management for systems-related projects, supervising or training computer operators, and being the equivalent of a handyman for computer problems beyond the knowledge of technical support staff.

I didn't have an operational background, but throughout my career, I had to dig under the hood of the computer, to install databases, install and understand operating systems, such as Linux, various distributions such as SuSE, Red Hat and Ubuntu. I even stuck the CD ROM into machines into install Solaris. I learned the first thing about continuous integration by configuring Jenkins, web server management, application servers, database management, bug trackers, setting up fundamental security for users and learning to program using scripting languages. (*Skipped* ad-libbed at the beginning).

So modern DevOps encompasses both software engineering and system administration ideas. These are reasons why people and businesses are into DevOps:

• Reduce the communication gap between engineering and administration.
• Avoid Unicorn businesses with silos
• Become proactive rather than reactive (especially if one adds Security to DevOps)
• Improve code quality
• Generate production code with very little downtime
• Share knowledge and competency between individual

Notice that I say very little about productivity in the above bullet items. This is because, DevOps if organized and executed with the correct procedure, attitude and organizational freedom ought to provide better visibility, transparency, enhanced feedback and human teamwork. The road to DevOps can be mudded severely through corporate misunderstanding, cultural organization, and other economic factors. DevOps is easier to "install" in a new young company, division, or department. It is far harder to provide the function is organizations with legacy technology dependencies and waterfall software development process and methodology.

From the business point of view, they are already might understand two concepts: SLO and SLI.

SLO - service level objective - this specifies the SMART goals that define business application reliability. These objective define the minimum requirement for business operations to function in order to do the productive work. It might be building the next fleet of cars in a manufacturing or it could be how many foreign exchange payments will be processed in the month of May, next year. These are achievable goals and not vague and so the idea that I want my website up and running for 24/7/365 is simply not good enough for an SLI.

SLI - service level indicator - this specifies the ways technical, business related to how we can measure through metrics that we are reaching the SLO. These are definite, clear and concise, periodic and reliability measurements that demonstrate how the business application is hitting its set goals. So this means that we have indicators from various analytical tools, prefer dynamic over static, that humans can digest in real time. I am glossing a bit over automatic scaling of cloud runtime instances, but there is no point is having auto-scaling if you can understand the measurement data that you are reading. If you cannot intercept, don't do it.

This is, for me, the high-level view of what is Developer Operations. It is about building application build pipelines, providing and securely manage in-house and third-party artifact or assembly dependencies, managing persistence datastores, short term and long term (like data laike), it is about providing functionality to monitor applications, analyse the data going in and out of the applications, lifecycle and payload and of course the best is saved for last, the biggest and important one, security protecting user's data GPDR, and commmercial data.

DevOps and platform engineering are essentially about building an automated pipeline that allows implementation of business logic and ideas to be coded and then deployed to production. Some people will want to throw the C word "continuous" in that last sentence, however, I recommend strongly that you crawl before you walk, you walk before you run.

I think that I will stop here. Bye for now.