And why we rebranded our company to support this provocation
**Disclaimer: **this part-promotional post discussing a problem almost all tech companies experience, most are not even aware of. It’s intended to tell our company’s story; why we do what we do, and why we chose a new path to walk in. Even if you couldn’t care less about it or what we have to offer, I suggest you stick around at least for the first part.
DevOps is a term coined to describe the integration of software engineering and operations, which until recently were characterized by working in unbreakable silos, miscommunications and different motivations. As such, “DevOps” describes the methodology that allows such integration to happen. It describes communication, processes of work, changing the way we deliver software and breaking the silos between different parts of the organization. The ultimate goal for which DevOps is required in the first place is to improve production by utilizing the existing resources correctly while creating synergy between them.
Simply put; we want to improve everything we do so we can produce our goods better, faster and make more money.
“The Devops movement is built around a group of people who believe that the application of a combination of appropriate technology and attitude can revolutionize the world of software development and delivery.” — Patrick Debois, 2009
For a couple of years, Agile was the cool guy everyone wanted to be. With promises of speed by agility, quick market response and short feedback cycles it appeared as if there was no room for error. Agile was the way to go. But most companies failed to see these benefits, even after bringing in the best consultants and reading the best agile books Amazon had to offer.
Abuse of culture you say? Failing to understand core ideas? Misinterpretation of concepts leading to the birth of agile?Nah… There’s probably something wrong with this agile thing, we should definitely do DevOps. No way to go wrong there. 🤔
And so, companies started looking for those DevOps magicians; individuals that would be in-charge of enabling this “DevOps Transformation” everyone is talking about. But no one actually knew what they were looking for. Slowly, different technologies and tools came into life, presenting themselves as “DevOps tools”, or part of the “DevOps stack” and recruiters started getting the feel of what is this “thing” they are searching for. Job descriptions for DevOps Engineers emerged, listing requirements like Puppet, Chef, Ansible, Jenkins, Capistrano and others. These, and similar technologies are in the field of managing servers; and who else is the best at managing servers if not the local IT guy? But if the local IT guy starts “doing DevOps”, what do we do about IT? Either we hire a new IT guy to replace him, or hire a new IT guy to be this new DevOps Engineer.
And here we are,
As cloud providers took their first steps, the same companies strived to be in the fore front of technology by moving into the cloud. DevOps guys started being the magicians who actually deal with this new “cloud” thing. New job titles like Cloud Engineers started appearing with an even broader skillset, now consisting of AWS, GCP, OpenStack and others.
We basically ended up with a new field in the IT / Software world called “DevOps” which is somewhat amorphous. Ask a random CTO what is DevOps, and you’ll most probably notice hesitation followed by a couple buzz words like Cloud *or *Scale *or even a mash of other terms like *servers, IT, linux *etc.*
To make a long story short, we see today’s companies looking for DevOps engineers, Cloud Engineers and my latest favourite CI Engineers. Big giants like Google, Facebook and their followers, took the initiative towards understanding the new role and rebranded it; SRE (i.e Site Reliability Engineering) and PE (i.e Production Engineering), taking the term “DevOps” off of employees titles and signatures, while keeping the actual job and the silos that come with it well in place.
What companies are actually looking for today boils down to a stack of technologies and skills that can be described as operations. These are the same individuals that take care of the deployment pipeline, integrate processes and tools to improve product delivery, harden production resiliency, apply automation on as many possible steps in the development and the delivery processes. They are the ones developers talk to when they need new a deployment capability, infrastructure change or in search for best practices with handling production. They handle cloud platforms, the scalability of systems, and basically every aspect of the system and pipeline that doesn’t have to do directly with the application’s code.
Blah blah blah, what’s any of this have to do with this rebranding?
Great question, glad you asked. We used to call ourselves “DevOps IL” and “DevOps Pro” (different branches). After going through what I described here for months, we realized a few things:
-
We cannot stay true to ourselves calling our company “DevOps”
-
If we are doing something in this area, we may want to first understand what it is and to be able to describe it in words.
-
If we are empowering this skillset and methodology, we need a name that reflects what we actually do on one hand and explains what we do on the other
How did we respond to these realizations
-
We changed our company brand and transformed our business model
-
We now actually do DevOps; we provide guidance, design and plan together with hands on implementation of platforms that will let operations’ engineers and developers work together fast and reliably, while keeping best practices in mind. We do all of that in a very short period of time, while mentoring the team members and transferring knowledge so that the company can thrive standing on the ground we lay for them. Beyond all that, we help the team recruit by examining candidates and providing feedback with which they can reach the best decision to handle their production and software delivery. This, is doing DevOps per se.
-
Who are we? Production engineers What do we do? Production operations How do we put it then in one catchy name with an available domain 😉?
ProdOps!
**We **believe that much like in agriculture, laying the ground is the beginning of everything; choosing the right soil and location, using best practices, nurturing our plants carefully as they grow strong and flourish on fertile foundations.
Bringing this utopia to our own world of terminology; we design, build, integrate and implement software delivery pipelines, monitoring and alerting systems, and develop tools that support the entire production infrastructure. The practices we use and methods in which we deploy and build infrastructure on cloud and on-premise environments, provide a holistic solution that’s secure, resilient, self-healing, scaleable and robust. But above all, we do it fast and clean, so that there’s near-zero maintenance required. I know these are the buzzwords and sentences you’re used to hearing about every product you’ve ever heard of. The difference is that we actually take a product and make it so.
Integration is in our blood; being able to connect different tools and systems may sound like it goes without saying, but there’s a lot to it. Knowing how to integrate different systems, and do it right, so that the integration holds through any change or instability, is something we take pride in. This is another core concept of DevOps; making things and people work and work together, so that we utilize everything; resources, costs and production.
Our experience-based processes involve thinking of every possible parameter in the way, so that our implemented products don’t only live and serve presently, they are resilient to changes and attacks, self-healing in case of need, robust and scaleable to serve any amount of requests while quickly responding to changes in requirements. Oh yeah, and they’re fast. So fast you won’t believe the timeline you used to work by. We consider time as a core aspect of any solution with every implementation we do. Your production delivery needs to be swift as possible in order to utilize short feedback loops. The delivery systems should work, and work fast, fulfilling any demand with zero maintenance in the process.
This means that the products we produce are easily upgradeable and maintainable, ensuring zero down time with every change, regardless of extent. Our systems are always deeply monitored and automatically firing alerts when required. In the rare cases you will be notified, the reason would either be applicative or an outer-scope outage. These confident words are not careless promises; they are a result of years and years of experience along with battle-tested practices and solutions.
We deliver all of that, and we do it fast. Keep your production moving at ProdOps.
Originally published at www.prodops.io.
