Why software-based control of applications and infrastructure is becoming a necessity

A software-based control necessity

To manage the complexity created by huge volumes of managed assets, the increased frequency and speed of change, dynamic configurations, and the sophisticated descriptive cloud agnostic offerings of the future, it should be clear that human-based processes are not enough. All this needs to be automated and driven by software applications.

As humans, what we must do in this situation is to use the power of computers to manage and control that complexity. Once computers come to the rescue of computers, it’s then a matter of controlling software intelligence to trigger development activity, make changes, measure deviations, react to problems or configure policy violations.

In fact, as explained earlier, a commoditization bar is rising from the underlying infrastructure to the
upper level of the application stack, with cloud evolving from IaaS services to PaaS, CaaS and
serverless functions as-a-service. With large organizations relatively slow to adopt these new technologies, the level of ease and efficiency of the latest cloud service offerings is accelerating the pace — just as the realization that pure “lift-and-shift” approaches were not producing optimal results.

Similarly, we know that SaaS services remain one of the most successful ways to consume services
in the cloud. In fact, we are seeing a SaaSification of independent software vendor (ISV) offerings, offering APIs instead of user interfaces and enabling enterprises to integrate ISV products into their own IT ecosystems.

There is no reason that the commoditization of infrastructure services will stop where it is today. It’s likely that the everything as-a-service offering will become the norm with cloud service providers, reflecting the demands of the IT market. Application developers and users should be able to
deploy applications and services where they make sense, without being concerned with the “how” or being constrained by a particular console or user interface.

If we attempt to extrapolate the future of this evolution, we can envision cloudless computing where public clouds and edge provide a true continuum of experience for the compute, data and network. It would act as a gigantic virtual computer, running an intelligent operation system (a kind of cross-cloud control pane) able to dispatch, load and execute attribute-based computing assets that developers describe with required constraints.

The intelligent cross-cloud operating system would be able to make decisions about application component locations and behaviors. Such attributes could be:

- Horizontal / vertical scalability constraints (cost/performance)
- Power consumption capping
- Proximity with a particular data source
- Geo-fencing constraints due to regulations or privacy concerns

NOTE: To support that cross-cloud vision, I would hope major cloud providers enter discussions to collaborate with east / west interfaces and agree on standards allowing them to dispatch and balance workloads with each other, or to have common event notification formats. This is essentially what is happening with Kubernetes cluster federation APIs. As time goes by, competitive technologies eventually begin to commoditize and aggregate back into standards.
Case in point: Today, who remembers the various incompatible implementations of the TCP/IP stack between Microsoft, Novell and OSI in the 1980s?

Software-control sophistication

Even though we now understand the need to use software for the task, it is interesting to think about
the nature of the control software. Achieving a level of control over this volume of small, dynamic objects is far beyond the scope and power of the old fashioned shell script-based
approach, which very quickly becomes too complex and unable to scale. There is a need for more
modern and robust approaches.

More modern and sophisticated software are needed to manage IT assets like servers, storage, network, containers and functions. With this power comes responsibility. Like any controlling software, it must be designed with high quality standards and should be capable of resisting the complexity and growth it will face over time.

Software has underlying data models, which are only good at managing things which are described as objects in some form of data entities and relationships — like an ontology definition. For software to
come to the rescue and manage assets and applications at scale, it requires first knowing what to
manage. Therefore, developers need a way to describe their cloud-native applications in terms of the underlying elements that compose it. These lower-level elements are getting further and further
away from the usual concept of databases, servers and middleware — and are now becoming more abstract concepts.

For instance, Kubernetes goes quite far into offering a description model and a set of abstract service objects which practically hide the cloud and infrastructure layer. As part of the application description, a Kubernetes application developer must “claim” the use of (meaning describe the content of) their deployment to their cluster in terms of abstract objects like microservices, pod replicas, persistent storage and ingress traffic flow. Add to this a list of predefined object types, and we see a growing list
of operators or custom resource descriptor (CRD)-based extensions which extend that programming model to other types of conceptual objects. Some are not yet invented, but all are powered by this software-defined everything layer.

For the engineer in charge of deploying an application, it becomes far more important to master the YAML language and the abstract model of a cloud-native application than to understand what a
VM, a disk or a network card is. These application underpinning objects have little to do with the usual infrastructure elements we once knew. However, they are all codified in a text file, so we are just one step away from dynamically generated YAML application manifest files from a higher level of
intelligence!

So, software now manages software objects in an automated way — not just the provisioning but also Day 2 lifecycle management actions. Automated provisioning is creating a consistent and predictive landscape that enables us to safely apply Day 2 automated management actions because it is consistent. With the help of AI-assisted automation, it is even possible to improve the level of
tolerance for automated management to react to environmental differences.

Blog 1: Is the infrastructure management world turning into a software engineering business? - Atos

Blog 2: The change behind numbers - Atos