The digital landscape has witnessed a significant shift in the dynamic between IT operations teams and application developers over the past decade by switching to cloud engineering. Initially, these two entities operated distinctly – the operations team tended to the upkeep of servers and other elements required for application functioning, while developers concentrated on enhancing application features, troubleshooting bugs, and preparing artifacts for deployment.
Such division inevitably led to compartmentalization, resulting in communication obstacles and last-minute scrambles for meeting deliverable requirements. These challenges not only generated roadblocks in software delivery but also created a disconnect in handling application and infrastructure issues, thus giving rise to the “throw it over the wall” mentality.
The DevOps movement emerged as a counteractive measure to these difficulties, aiming to bridge the divide between developers and operations teams. DevOps promotes a culture of collective responsibility through enhanced communication and integration.
It fosters automation in infrastructure and application code using Continuous Integration (CI) and Continuous Delivery (CD), encourages the adoption of microservices architectures, and augments visibility via monitoring, logging, and tracing. This synergy allows for quicker and more reliable release cycles. However, aligning with DevOps ideology and meeting cultural expectations can pose substantial challenges for many organizations.
The constant tug-of-war between speed and stability often leads to reversion to old behaviors, stemming from a fear of downtime and unstable environments. Herein lies the question – how can organizations provide developers a seamless experience, embedding best practices and setting guidelines, while enabling self-service capabilities? Enter, cloud engineering.
Platform engineering is rapidly establishing itself as a vital discipline within organizations. It drives the evolution of infrastructure and operations and empowers developers to create resilient, scalable applications.
The objective is to refine the developer experience by offering self-service mechanisms for resource provisioning that incorporate good practices. This methodology builds upon DevOps by enabling developers to maintain full control over their resources via self-service, eliminating the need to “throw it over the wall”.
Platform engineering teams accomplish this through various methods, from adopting a GitOps-centric strategy to constructing Internal Developer Platforms with a user interface and/or API. This approach is gaining traction in many organizations, facilitating streamlined operations, enhancing visibility, minimizing costs, and simplifying the process of onboarding new applications.
In this article, we will delve into prevalent operational models within organizations, the role of platform engineering in these models, familiar patterns utilized to construct and develop these self-service platforms, and the prospects of this burgeoning field.
Operational models in cloud engineering
To begin with, it’s crucial to comprehend how technology teams currently function and their various methods of supporting development teams – from initializing infrastructure to defining pipelines and deploying application code. The following diagram illustrates four widely used operational models, each with their unique benefits and challenges, and importantly, their relationship with platform teams.
Copyrights @Amazon_AWS
Centralized Provisioning
In a centralized provisioning model, a core team shoulders the task of designing, deploying, and managing infrastructure. Organizations assign control enforcement to specific roles with limited scope, such as release management, process management, and isolated teams (networking, compute, pipelines, etc.).
Typically, a request model demands a ticket to be sent to a central or isolated team, where it enters a backlog, and developers must wait until resources can be provisioned for them. Ideally, these central teams can swiftly provision resources and pipelines to enable developers. However, reality often proves otherwise, causing bottlenecks in the delivery process, slowing down deployment cycles, and prolonging feedback loops.
While this model ensures centralized control over resource provisioning, it tends to struggle when supporting a multitude of development teams with diverse requirements and use cases. Over time, such a model can breed frustration and friction between teams, prompting organizations to consider alternatives. This transition brings us to the next model – the Platform-enabled Golden Path.
Navigating organizational change: Modern trends in cloud engineering
In the transformative landscape of IT operations and application development, organizations are now embracing a number of operative models to better streamline their development process. These varying models are shaped by the paradigm of striking a balance between developer customization and the establishment of consistent standards, and they highlight the profound role of platform engineers in this evolving arena.
Firstly, the Platform-Enabled Golden Path model is an innovative approach which permits developers to incorporate their unique customization, yet still abide by a uniform set of standards. In this operative model, platform engineers meticulously design preferred norms, guardrails, and exemplary practices based on popular architectures for application by development teams.
This could encompass:
- Utilizing a managed Infrastructure as Code (IaC) orchestration service
- Constructing a bespoke Internal Developer Platform
- Deploying a GitOps model and associated tool
- Establishing templates in a central repository for reuse, complete with documentation
- Creating custom libraries or modules
Under this model, the platform engineering team shoulders the responsibility of generating and updating the templates. This method strikes a delicate balance between maintaining consistency and permitting flexibility. However, one might encounter challenges in ensuring organization-wide visibility, particularly when development teams avail freedom to tailor their infrastructure. This becomes more pronounced when platform teams aim to propagate a change across resources deployed by diverse development teams.
The Embedded DevOps model is another paradigm wherein DevOps engineers align directly with development teams to plan, provision, and upkeep their infrastructure. This model can manifest in two predominant patterns:
Floating model
A central DevOps team operates a floating model where a DevOps engineer directly collaborates with a development team early in the development cycle to facilitate the construction of requisite pipelines and infrastructure resources.
Permanent embedded model
Alternatively, a development team could incorporate a permanent DevOps engineer in the team to support early iterations as well as maintenance as the application evolves.
A central platform or architecture team may establish acceptable configurations and resources, while DevOps engineers determine their optimum usage to fulfill the needs of their development team. While this model offers greater agility and flexibility, it also requires the allocation of resources to hire DevOps engineers per development team, which can escalate costs as development teams expand.
Lastly, the Decentralized DevOps model allows development teams to take full ownership of their infrastructure and pipelines. In this model, a central team might focus on building out guardrails and boundaries to ensure limiting the impact of any incident within established limits. This model offers the greatest agility and flexibility but also comes with the highest risk of inconsistency, errors, and security vulnerabilities.
Each of these operative models has its strengths and weaknesses, and the purpose of this blog is to shed light on the emerging patterns. The ultimate choice of the right approach is dictated by an organization’s specific needs, goals, and its cultural inclination for change.
Evolution of Internal Developer Platforms and GitOps
Regarding emerging trends, Internal Developer Platforms and GitOps practices are gaining immense popularity due to their capacity to streamline the software development process and boost collaboration.
Internal Developer Platforms offer a centralized platform for developers to access resources and tools required to construct, test, deploy, and monitor applications and associated infrastructure resources. In contrast, GitOps is a methodology that leverages Git for orchestrating and managing the deployment of infrastructure and applications.
In conclusion, we’ve journeyed through various operational models and emerging trends aimed at enhancing these models.
Platform Engineering signifies the continuous evolution of DevOps, aiming to enhance the developer experience for rapid and secure deployments. Developers possess varying skill sets and preferences. As such, the platform engineering practice must continually adapt to these patterns, to enable rather than obstruct progress.
To identify where your organization fits within these operational models, we recommend undertaking a self-assessment and fostering internal discussions. Consider the advantages and challenges of each model and how they align with your organization’s specific needs, goals, and cultural willingness to shift.
By performing this self-assessment and fostering open dialogue, your organization can identify the most suitable operational model and develop a strategic plan to optimize collaboration, efficiency, and agility within your technology teams.
