The term “cloud” originated from diagrams of large-scale data networks and, for a long time, the cloud was just a “means to transfer information from one place to another using someone else’s computer.” In time, privately controlled services emerged that allowed users to store data with “cloud service providers,” new businesses that permitted access to their “private” data from anywhere.
In truth, the user’s data lived on computer systems owned and hosted by a cloud service provider. Those physical places became known as data centers, consisting of racks and racks of computers, storage devices and networking devices that communicate and/or support many compute functions. Such services must be capable of expanding—as necessary—to meet the user demands for short-term, long-term and immediately accessible data housed in locations typically unknown to those end users.
Private Clouds
Large companies often have their own “scaled” data centers located at their physical buildings, which allow for personalized management and cost a great deal to fabricate, support and manage.
Today, there are two general meanings of this “data center” terminology:
- It’s where the term “on-prem”—meaning “on the premises” comes from—inferring that self-managed compute services (usually servers and computer elements), storage and input/output network management are physically placed in the company’s owned-and-operated facility (such as a hardened warehouse full of electronics, cooling, backup power and security).
- You can host your data in your own datacenter “on prem,” or you can host it with another service “as in the cloud.” Private companies are now building entire data centers to either outsource/lease space (only) or house entire systems solutions for users to place their own gear into or rent the service provider’s systems on a “square-foot” basis or a “rack-by-rack” space basis—with or without maintenance or support by a third-party organization.
Cloud Structure
A cloud can be considered a business when it is owned and operated by a “recognized” entity such as Amazon (Amazon Web Services), Microsoft (Azure), Google, etc. But they may not be the only “cloud resources”—companies that offer software services under their own “private” cloud (e.g., Wasabi or Comcast). Such cloud organizations or structures may also provide intercloud offerings, allowing them to scale across larger data sets, bridge various specialized “data centers” or even sublet entire facilities to a particular single entity as needed.
For on-prem solutions or even large-scale public data centers, monitoring platforms are “managed over-the-top subsystems” that may drive an entire solution set platform (data center) or link groups of data centers. For an on-prem environment, such a platform could require a large up-front commitment by the organization.
If your organization is employing a cloud-based DevOps solution with rapid iteration and continued live or real-time practices that involve continuous results reporting and direct-to-developer feedback, though, it may be difficult to predict or understand the depth of commitment necessary on the front end, let alone what might occur as the systems scale upward in response to growing needs for client services or compute and storage expandability.
Self-deployed monitoring systems may also generate a lot of unused capacity and wasted resources. That is unpredictable as the software-solutions processes move through the various “bring-to-market” stages. Even when the DevOps solution is built for internal or local operations only, the self-built/self-managed monitoring platform can overwhelm the IT or engineering services with unpredictable consequences.
Today, there are many potential open-source monitoring solutions available to organizations; some strictly on-prem and others entirely cloud-based. Any improperly integrated solution could generate a lot of unused capacity and wasted resources—as reported by service providers, vendors and end users.
That’s not to mean an experienced organization familiar with today’s most relevant trends (and with sufficient cloud management solutions experts in-house) should not or cannot develop a comprehensive, scalable monitoring solution that fits its needs. However, the risks and costs can escalate as the environment expands or as the scale mushrooms. It is a complex balancing act that can make or break the organization’s performance or profitability.
Before venturing into this domain, be sure to understand the overall solutions development processes—especially the real-time management core initiatives and the harmonization of the operation’s IT functions.
First, Defining DevOps
DevOps is a collaborative approach that merges software development and IT operations—and is nearly always a live or real-time environment. DevOps typically combines people, processes and automated tools to build, test and release software much faster and with greater reliability.
Throughout the DevOps process, software is constantly monitored while in development or in use. During the testing and “spinning up” process, user issues generate large amounts of data and feedback that go directly back to developers to be quickly improved. Once deployed, the procedures usually continue and may require more capabilities than an “on-prem” solution might be able to handle.
In the cloud, DevOps may function by using “on-demand” cloud infrastructure (Fig. 1) to automate software delivery, manage infrastructure through code and auto-scale resources dynamically to meet delivery needs, adjusting the flows by reacting to anomalies, including failures, crashes or data overruns. In the cloud, instead of manually configuring physical servers, teams write code to provision environments, test automatically and deploy updates while continuously monitoring application health.
Infrastructure as Code (IaC) is the process by which operations teams define network servers, databases and environments using configuration files (such as Terraform or AWS CloudFormation) rather than manual clicks in a portal.
Continuous Integration and Continuous Delivery (CI/CD) is an accompanying cloud-native service (such as AWS CodePipeline or GitHub Actions) that permits the automatic testing of code as soon as developers commit it. Once verified, the cloud platform automatically pushes the software update into production.
Data Centers
One of the “DIY” challenges is when an organization is driven to write all of the integrations itself and then forced to manage those integrations long-term. Novel “open-source solutions” require a great deal of upkeep, attention and maintenance.
Users report they almost need to have a Ph.D. to set up effective and sufficient monitoring capabilities that can address the ever-growing needs of a DevOps environment.
Some (but certainly not all) system solutions vendors may either make it difficult to figure things out intentionally or require long-term solutions support contracts, resorting to extensive Googling or digging into all kinds of online forums for answers. Much of that information will likely be inapplicable to the organization’s actual needs without considerable DevOps adoption (while under live operations).
Monitoring for Success
Effective end-to-end monitoring is crucial for enterprise DevOps teams to ensure high-quality, scalable and secure software delivery across complex environments.
Key requirements for enterprise DevOps monitoring platforms (Fig. 2) must be properly selected to ensure scalable, reliable and efficient software development and operations. The cloud on its own is not generally designed to develop those platforms without a considerable amount of code or structured elements that are specifically fashioned to the needs of the user’s organization.
Effective end-to-end monitoring is crucial for enterprise DevOps teams to ensure high-quality, scalable, and secure software delivery across complex environments.
In our next installment, we will dig deeper into issues on dynamic scaling, integration and vendor support, the importance of documentation, how to establish real-time notification and developer access without infrastructure exposure and end-to-end data capture across the DevOps lifecycle.
