A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.

Loveholidays

Scaling Devops without Hiring

Modern enterprises are constantly challenged by the competition unimpeded by the heft of legacy systems, bureaucracy, and unchallenged status quo. New entrants are cloud first, on-demand billed and built on top of open source products. Such enterprises can be assumed to be DevOps enabled. Their processes, tools and most importantly, culture are built around shared goals and extensive collaboration.

Existing organisations seeking to embrace DevOps practices often aim to fill this gap by hiring DevOps engineers and building out entire DevOps teams. There is a lot of debate on whether a DevOps engineer is even a thing, but let’s not get ourselves distracted by it. While many organisations may benefit from hiring a DevOps visionary to set course for the rest of the engineering organisation, it is also well worth looking into existing talent and see who is longing to scratch the DevOps itch. We can map paths for searching and cultivating the internal DevOps talent to the technological choices of organisations. There are three main ways that infrastructure can be run in the post-on-premises era.

The most idealistic approach would be serverless. Instead of running services using virtual machines or container orchestration, you delegate this task to the public cloud provider and rely on elastic, managed services. By breaking down the business logic into isolated tasks that can run as functions, we can create a clear separation of concerns, improve maintainability and increase agility. Modern vendors can deliver on-demand capabilities such as databases, storage, analytics, compute, machine learning and AI via APIs, therefore, eliminating capacity planning.

Another common scenario is lift-and-shift, where the infrastructure and applications receive a minimum amount of changes necessary to be able to run them in the public cloud. Applications are still legacy and not cloud native, local storage is used instead of object storage, applications are run 24/7 and scalability is always done via human intervention. It is a stepping-stone into the cloud, which allows organisations to embark on Infrastructure as Code practices and move towards container orchestration by freeing its resources previously focused on day-to-day operations or, at some cases, keeping the lights on. With the right cultural focus on DevOps practices, enterprises can begin the transition of traditional Operations teams into DevOps practitioners.

Existing Organisations Seeking To Embrace Devops Practices Often Aim To Fill This Gap By Hiring Devops Engineers And Building Out Entire Devops Teams

With infrastructure built using commodity cloud products, development teams have a common terminology that they and operations teams can both speak now. It results in increased communication between infrastructure and cloud curious developers and operations. Such developers start to deliver pieces of work around their areas of responsibility. On the opposite side of the spectrum, operations are no longer tied to hard-to-overcome limitations of the physical infrastructure and therefore begin to operate using higher levels of abstractions, adopting development practices for operational purposes. We are observing the convergence of development and operations into DevOps around common building blocks and methods.

The third way is a public cloud with container orchestration. In 2019, there is minimal argument left about the platform of choice for container orchestration with Kubernetes taking the spotlight. Some organisations have taken more significant risks and modernised and containerised their applications or started that way in the cloud. This is where Development and Infrastructure (Site Reliability Engineers, DevOps, but hopefully no longer simple operations) teams have even more commonalities. While low-level infrastructure work is still the responsibility of specialised teams, we are observing further convergence around standard building blocks of Kubernetes. There are no longer instance types, availability zones, load-balancer
types to know about — Kubernetes in public cloud abstracts all of this using terminology common across all clouds. Kubernetes extension model allows public cloud providers to develop integrations enabling Infrastructure as Code using native Kubernetes manifests. Now developers are using the same repository, platform and methods to provide common infrastructure components as they use to develop, deploy and configure applications. With such level of integration, development teams can self-serve most of their infrastructure needs within a familiar workflow, while simultaneously deepening their knowledge and understanding of the systems. In the environments of shared tooling and processes, developers are much more likely to have a greater awareness of infrastructure related changes and have greater compassion towards infrastructure team’s challenges. In the meantime, existing DevOps practitioners are freed to focus on platform-wide deliverables, whether it is unified metrics or logging tools, secret management or least privilege enforcement.

As seen in all three scenarios, it is possible to break a wall between development and operations by embracing a common set of practices and tooling. Well-documented platforms like public clouds or Kubernetes will always be preferred to bespoke legacy systems as such platforms provide a globally ubiquitous language. In a serverless world, the responsibility is shared among every member of the development team, allowing DevOps specialists to focus on the underlying architecture and future expansion. In lift-and-shift cloud adopters, the first wave of Infrastructure as Code and common building blocks can allow moving away from repetitive operations towards more scalable automation. Lastly, enterprises running Kubernetes can benefit from convergence around the same container orchestration tool and sharing.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.

Weekly Brief