DevOps at GBH – How did we get started?

IT team leaders must deal with both the needs of the business and their people. They are assigned the task of delivering the best possible outcomes, while maintaining a healthy and balanced relationship between what needs to be done and the people involved in getting it done.

We have learned throughout our history that focusing on business objectives (production) over workforce is the perfect formula for failure. There is a deep connection between your team’s motivation and appropriation, and the quality of deliverables they produce.

When talking about people, the behavior of an individual is deeply affected by the environment where they actively coexist, and it is a variable almost impossible to measure or predict. Here is an interesting thought: IT, the industry where every resource built is programmed to do only what it was designed to do, is run and has evolved thanks to people who are, by design, unpredictable, ever evolving, and ultimately extremely complex. We have been worrying for a long time about the inherited difficulty of our programs, applications, and systems, and delaying the inevitable task of worrying about our own complexity which often affects the quality of our deliverables.

We have thus come to a meaningful conclusion: we can’t escape the complexity of people, business, communication, and the constant need of keeping all of them together in one box and expect them to get along well.

People needs, business objectives, and communication barriers – the most unbalanced and dysfunctional relationship to ever exist.

There’s good news though. Throughout the history of the IT universe, many methodologies were designed and implemented to improve how teams work on any set of deliverables, be it the development of a system, the implementation of a server, or the eternal ordeal of fixing printers in the office. You can go from any project management method to a particular tool, such as a ticketing management system, to tackle the complexity of tasks and the high-level processes and procedures needed to accomplish them.

One of the most popular recent examples of these supportive technologies is the Agile framework, which is also the origin of our main topic for this article: DevOps.

Many articles on the Internet will call DevOps (among other newer topics in the IT world) one of the most famous buzzwords to ever come around. To be fair, if something is working why bother switching to fancy words and concepts, right? Well, certainly, it was much more than a simple buzzword because now the whole software engineering and IT industry desperately seek out the implementation of DevOps in any organization’s culture and processes. Why is that? What is the appeal or difference in comparison to other methodologies that already exist and are functional? Could it be that this was the missing knot to tie our dysfunctional family of three once and for all? The answer to that question is what led our organization, GBH, to start paying attention to this “new way” of doing things in the initial stages of its apogee.

We want to show you a little bit of our journey and why we, at GBH, love DevOps.

[DevOps in the world]

In the software development community, you cannot escape DevOps. It has now become one of the most important assets of the SDLC (Software Development Life Cycle) of any organization with significant software development activities. So, what can we say about it?

The benefits of including DevOps in all processes and procedures are no longer underestimated. Many CTOs and IT Managers have seen first-hand how it can enhance the harmony of continuously deploying changes to a system without any worries, while also ensuring availability, integrity, scalability, and reliability for their systems. A culture, a revolution that has changed Software Engineering forever.

One of the key aspects of DevOps is that it does not come with a tutorial on how to achieve success in software development. Its implementation and importance depend highly on the organization’s culture and means of production. This thought is supported by the key findings of the Puppet State of DevOps Report of 2018. In this report, it is stated that the complete implementation of DevOps on any organization can be divided into 5 stages:

• Stage 1: Normalize the technology stack.
• Stage 2: Standardize and reduce variability.
• Stage 3: Expand DevOps practices.
• Stage 4: Automate infrastructure delivery.
• Stage 5: Provide self-service capabilities.

If your organization performs software development in some capacity and you want to implement the DevOps methodology, it is necessary to understand the basic principles and the importance of the aforementioned stages.

The Necessity

What was the drive that led us to worry about some buzzy word that only a handful of people trusted? It was not because things were not running nor delivering the value we wanted for our customers. Rather, it was because we understood the importance of improving what was already working for us, so we could offer a better service with a more streamlined and standardized workflow. We did not have enough standardization across our multiple environments, all issues were attacked reactively, integration and delivery processes were constantly blocked due to heavy manual work and inefficient communication across different teams. In summary, there were many things that we knew could improve but did not know where to start – that’s where DevOps came in as one of the workable solutions for our pains.

The Role

Even though in the DevOps community it is being said that DevOps is not and should not be a “position”, “role” or a “team”, it became a widespread practice to dedicate a role specifically to tackle some of the key pillars of the DevOps methodology, and thus the role DevOps Engineer(ing) came to be. We followed this unofficial convention and our first ever defined role became “DevOps Engineer”. Although initially, we focused on standardizing operations processes, we succeeded in creating a framework capable of transforming the software development life cycle into a more flexible, improved, and overall optimized pipeline.

I landed on GBH in February 2018 and since then, I have been participating in one of the most culture-oriented organizations I have ever been part of since my beginnings in IT near 2015. GBH was looking for a DevOps Engineering Lead at that time but, due to the scarcity and lack of candidates for the role, it was decided to hire a mid-level DevOps-like engineer and provide all the training necessary to perform the role and achieve what was expected of it. At that time, I was a Systems Engineer with a DevOpsy* flavor since I had to understand how applications worked to a better extent than your habitual Ops Engineers.

GBH then became one of the few organizations in the Dominican Republic in 2018 with a DevOps role in its ranks.

Our first steps

Our very first steps into the DevOps journey were focused on improving development onboarding. We had cases where setting everything up for the software engineer to get some work done could take up to 1 week – that was insanely unhealthy considering our main resources for business production were closely related to the developer’s productivity. We brainstormed some ideas and finally concluded that the development environment was the stress point for how much time was spent in the onboarding. For this, we chose to create a system that would allow the developer to execute one single command on his local machine and that would provision everything needed to get started – we called this system “dockerized” initially, but now it has evolved into DEMS (Development Environment Management System).

With DEMS (which is at its core a combination of containerization and shell scripting), we were able to reduce 1 week worth of development time into less than half an hour. That was 35 hours reduced to a couple of minutes – it was a big win because we experienced first-hand how DevOps could improve not only the already tedious workflow of setting a development environment, but also every other process that participates in the development life cycle. We had a guess DEMS was only the beginning and, spoiler alert, it was.

Much has changed since the conception of DEMS; we now have multiple integrations that automate the communication between the systems that support our communications and service delivery. Including the implementation of CI/CD pipelines, implementation and configuration of tools to enhance the continuity mindset and self-service capabilities of our teams, standardization, and reduction of variability across environments and workflows.

Where we are now

We have come from afar, but that does not mean we are now satisfied (I do not think we will ever be!) The world of Information Technology is constantly changing and improving, there is as much to be done about current practices as things that come up every day, which, as we see it, is a continuous wave of challenges forcing everyone to evolve and become better at what we do.

We are proud of where we are, but we have our eyes already set on whatever is next. Infrastructure as Code, streamlining even further our delivery strategies, automation of business and technical processes, adaptability to changes, independency of what we are doing now and falling in love with what we are going to do next. We are overly excited about our achievements with DevOps and as we grow, we will keep this methodology as close to us as possible, because without it, software development would never have been the same as it is now, at least not for us.

Join our team!

Are you passionate about DevOps? Come join us! We are looking for top talent to join our family and push even further our DevOps reach!