Description:FIELD OF THE INVENTION
[0001] The present invention pertains to a cloud automation platform and an associated method for orchestrating automation tasks across distributed computing environments, more particularly, the present invention relates to a hardware-enabled cloud automation platform and a method for distributed task execution and external delegation.
BACKGROUND FOR THE INVENTION:
[0002] Cloud automation platforms face challenges in orchestrating tasks across distributed and heterogeneous computing environments. These environments consist of virtual machines, containers, and bare-metal hosts with varying configurations. Coordinating automation tasks across such nodes requires centralized control to ensure consistency, reliability, and security. Absence of centralized orchestration leads to fragmented workflows, configuration drift, execution failures, and increased operational overhead.
[0003] Scalability and adaptability of automation systems in cloud-native environments present additional challenges. Dynamic workloads and infrastructure scaling demand context-aware task execution tailored to each host’s requirements. This includes resource isolation, concurrent execution handling, and environment-specific dependency management. Traditional systems lack this flexibility, resulting in bottlenecks, inefficient resource utilization, and limited support for multi-tenant or role-based execution.
[0004] Integration of external automation tools introduces challenges in controlled delegation. Direct management of external systems by automation engines causes execution conflicts, redundancy, and tight coupling. Such integration complicates orchestration of hybrid workflows where external systems are more suitable for specific tasks.
[0005] Resource inefficiency arises when automation engines remain active during external task execution. Continuous resource consumption without task involvement leads to scalability and performance issues, particularly in high-load or multi-tenant environments.
[0006] US20240220331A1 addresses automation of connectivity between on-premises and cloud routing domains, focusing on network-level configurations. US20240220331A1 does not provide support for executing granular automation tasks on individual target hosts. It lacks task-level orchestration capabilities such as provisioning, patching, or deployment.
[0007] US11294793B1 provides a method of debugging a software robot configured to apply robotic process automation. The said method lacks orchestration or execution of automation tasks across distributed cloud hosts, as described in US11294793B. Furthermore, command-based task triggering is also absent.
[0008] US20250110810 provides a method for creating a software automation process. However, the method lacks framework for executing predefined tasks on infrastructure targets. Centralized command dispatch and host-level execution control are also not supported.
[0009] US20210133650A1 discloses an information technology system featuring a control tower for enterprise-wide automation coordination. The system lacks low-level execution capabilities and does not include message-driven mechanisms for triggering automation tasks on individual cloud hosts.
[0010] Therefore, there is a need for a system or platform which overcomes the problems of the prior art.
OBJECTS OF THE INVENTION:
[0011] An object of the present invention is to provide a unified control system that coordinates automation tasks across virtual machines, containers, and bare-metal hosts to prevent configuration drift and execution failures.
[0012] One more object of the present invention is to provide an automation platform that adapts automation workflows to host-specific requirements, enabling resource isolation, concurrent execution, and dependency management.
[0013] One more object of the present invention is to provide an automation platform that enables controlled interaction with external automation tools, minimizing execution conflicts and decoupling orchestration logic from third-party systems.
[0014] One more object of the present invention is to provide an automation platform that temporarily suspends an automation engine activity to optimize resource usage in multi-tenant environments.
[0015] An object of the present invention is to provide a structured method for task execution across distributed computing environments, enabling consistent and centralized orchestration of infrastructure operations.
[0016] Another object of the present invention is to provide a method for selectively delegating automation tasks to external systems while maintaining internal execution control and optimizing resource usage during hybrid automation workflows.
SUMMARY OF THE INVENTION:
[0017] The present invention pertains to a cloud automation platform and an associated method for orchestrating automation tasks across distributed computing environments. The platform addresses challenges in managing tasks across virtual machines, containers, and edge devices by enabling centralized control, structured execution, and dynamic task coordination. The method facilitates reception of automation identifiers, interpretation of commands, and execution of tasks through integrated messaging, administration, and execution components. One object of the invention is to provide a unified control system that ensures consistent, secure, and scalable automation across heterogeneous infrastructure.
[0018] The platform includes a message layer for receiving automation identifiers, an admin module for command interpretation, and an automation engine for executing tasks within an isolated execution environment. The execution environment supports containers, virtual machines, and serverless runtimes capabilities. The automation engine includes a task scheduler and dependency resolver to manage execution order and concurrency. Target hosts are dynamically identified using inventory or discovery systems and may include cloud instances, on-premises servers, or edge devices. The method defines structured steps for configuration, command dispatch, and task execution.
[0019] Integration with external automation systems is enabled via an API plugin and a unidirectional connection. When an external automation identifier is received, the platform delegates execution to the external system while suppressing internal engine activity. This architecture minimizes resource consumption, avoids execution conflicts, and supports hybrid workflows. Another object of the invention is to provide a method for selectively delegating automation tasks to external systems while maintaining centralized visibility and optimizing internal resource usage.
[0020] The invention is applicable across industries such as telecom, finance, and healthcare, where infrastructure automation is essential for provisioning, patching, and monitoring. Alternative embodiments may include variations in messaging protocols (e.g., AMQP, MQTT), orchestration tools (e.g., Kubernetes, Ansible), and cloud platforms (e.g., AWS, Azure, GCP). Deployment scenarios include SaaS-based platforms, on-premises installations, and hybrid cloud environments, demonstrating flexibility, scalability, and industrial applicability across diverse operational domains.
BRIEF DESCRIPTION OF DRAWINGS:
[0021] Figure 1 shows a block diagram of a cloud automation platform in accordance with the present invention;
[0022] Figure 2 shows a schematic representation of alternative embodiments of a message layer of the cloud automation platform in accordance with the present invention;
[0023] Figure 3 shows a schematic representation of alternative embodiments of automation identifiers of the cloud automation platform in accordance with the present invention;
[0024] Figure 4 shows a schematic representation of alternative embodiments of an automation engine of the cloud automation platform in accordance with the present invention;
[0025] Figure 5 shows a schematic representation of alternative embodiments of an execution environment, the cloud automation platform in accordance with the present invention;
[0026] Figure 6 shows a schematic representation of alternative embodiments of a target host of the cloud automation platform in accordance with the present invention;
[0027] Figure 7 shows a schematic representation of a detailed view of the automation of the cloud automation platform in accordance with the present invention;
[0028] Figure 8 shows a block diagram of one more embodiment of a cloud automation platform in accordance with the present invention;
[0029] Figure 9 shows a flow chart of a method for performing automation tasks in a network enabled computing device in accordance with the present invention; and
[0030] Figure 10 shows a flow chart of alternative embodiment of the method for performing automation tasks in the network enabled computing device in accordance with the present invention.
DETAILED DESCRIPTION OF DRAWINGS:
[0031] In a preferable embodiment of the present invention (Figure 1), a cloud automation platform (CAP) (200) is provided. The cloud automation platform (200) has a message layer (220), an admin module (240), an automation engine (260), an execution environment (EE) (280) and one or more target hosts (290a, 290b). The message layer (220) is configured in a network-enabled computing device (C1). The network-enabled computing device (C1) is a system equipped with hardware and software components that facilitate communication over digital networks. The computing device (C1) includes a processor (P) for executing instructions, and a memory (m) for storing data and applications, and a network interface (not shown) such as Ethernet, Wi-Fi, or cellular modules that enable connectivity with other systems. The computing device (C1) supports deployment of modules like message layers and admin interfaces, allowing orchestration and control of automation workflows across distributed environments.
[0032] In various embodiments (Figure 2), the message layer (220) is implemented as a set of software components deployed within the memory (m) of a network-enabled computing device (C1). The message layer (220) interacts with the processor (P) and network interface (I) to enable asynchronous, decoupled, and real-time communication across distributed automation modules. The message layer (220) is configured to receive automation identifiers (202) and transmit the automation identifiers (202) to downstream components for orchestration and execution of automation tasks.
[0033] The message layer (220) may include one or more messaging architectures (225). The messaging architecture (225) is a message queue (220a) that supports asynchronous and ordered transmission with lifecycle control and durable storage. The messaging architecture (225) can be a publish-subscribe system (220b) enables decoupled broadcasting and topic-based routing. The messaging architecture (225) can be an event stream (220c) supports real-time event capture and processing. The messaging architecture (225) can be a message bus (220d) enables scalable, protocol-driven communication across modules. The messaging architecture (225) can be an in-memory messaging system (220e) supports low-latency data exchange using volatile storage and lightweight brokers. Technologies implementing these components include RabbitMQ, Apache Kafka, Redis, Amazon Kinesis, Azure Service Bus, and others.
[0034] The message layer (220) further comprises a logic component (220f) for rule-based filtering, routing, and transformation of automation-related messages. The message layer (220) includes a message persistence (221) and retry mechanisms (220g) are implemented through durable buffers, retry schedulers, and failure-handling modules. These features ensure reliable message delivery, execution continuity, and scalable communication across distributed automation environments.
[0035] In an embodiment (Figure 3), the automation identifier (202) may be received from various sources within or connected to the platform (200b). These sources include a user interface (275a) with structured input components. A machine learning module (275b) may generate the automation identifiers (202) based on predictive analysis. Service outputs (275c) from computing activities (275d) such as monitoring or CI/CD pipelines may provide the automation identifiers (202). Service inputs (275e) from computing environments (275f) such as orchestration systems or deployment tools may also provide the automation identifiers (202). A scheduler (275h) may generate the automation identifiers (202) based on time-based or event-driven triggers. External systems (275i) may transmit the automation identifiers (202) via APIs or service connectors (not shown).
[0036] The automation identifier (202) includes one or more task identifiers (202a), a workflow identifier (202b), a script reference (202c), a policy tag (202d), or a configuration profile (202e), each representing a distinct automation context. These elements enable precise execution, multi-step orchestration, script invocation, policy enforcement, and environment-specific configuration. The automation identifier (202) also carries metadata such as task priority, timestamp, and contextual information related to the initiating a user, supporting prioritization, scheduling, and access control.
[0037] These structured elements and metadata collectively enable the platform (200) to interpret, route, and execute automation tasks with precision, scalability, and compliance across heterogeneous computing environments. The message layer (220) receives and processes these identifiers using secure communication protocols, ensuring reliable orchestration across distributed modules.
[0038] The admin module (240) (Figure 1) is instantiated as a software-based control and coordination unit within the memory (m) of the computing device (C1), which may include local memory or cloud-based services such as SaaS platforms. The admin module (240) is communicatively coupled to the message layer (220) and is configured to receive the automation identifier (202). The admin module (240) includes a command dispatcher for interpreting automation identifiers (202), a task registry for mapping identifiers to predefined automation commands, and a communication interface for interacting with the message layer (220) and the automation engine (260).
[0039] The admin module (240) further includes a rules engine (240a) configured to determine execution logic based on the automation identifier (202). The rules engine (240a) maintains a mapping registry that associates the automation identifiers (202) with corresponding commands. Additional components of the admin module (240) include a logging and auditing subsystem for traceability, and mechanisms for role-based access control and policy enforcement to ensure secure and authorized execution of automation workflows across distributed environments.
[0040] The automation engine (260) (Figure 4) is configured within a dedicated computing node (N) that is connected to the processor (P), memory (m), and network interface (I) of the cloud automation platform (200). The computing node (N) is provisioned with execution resources such as CPU cores, memory blocks, and containerized runtimes to support scalable and concurrent task execution. The automation engine (260) includes components such as a task interpreter, execution scheduler, and resource allocator, which collectively enable the processing of predefined commands received from the admin module (240) and dispatch automation tasks to target hosts (290a, 290b).
[0041] The automation engine (260) is communicatively coupled to the admin module (240) via the network interface (I), allowing secure and low-latency transmission of automation commands. Upon receiving a command corresponding to an automation identifier (202), the automation engine (260) initiates task execution within the execution environment (EE) (280). This environment (280) supports runtime isolation, dependency resolution, and host-specific configuration handling. The automation engine (260) also includes logging, error recovery, and performance monitoring subsystems to ensure reliable and auditable execution across distributed and heterogeneous infrastructure.
[0042] In an embodiment, the automation engine (260) is configured to execute multiple automation tasks within a parallel computing environment (260a) and a distributed computing environment (260b). The parallel computing environment (260a) includes multi-core processors, distributed memory architecture, and containerized runtimes that enable concurrent execution of automation tasks (t1, t2) across multiple threads or nodes. This configuration supports high-throughput orchestration, reduces execution latency, and enhances scalability. The automation engine (260) leverages this parallelism to handle diverse workloads such as provisioning, patching, and deployment across heterogeneous target hosts (290a, 290b), ensuring task isolation, resource allocation, and fault tolerance through integration with the execution environment (280) (Figure 5).
[0043] The distributed computing environment (260b) includes multiple interconnected computing nodes equipped with execution resources and network interfaces. These nodes collaboratively process automation tasks (t1, t2) across geographically or logically separated infrastructure, enabling fault tolerance, load balancing, and horizontal scalability. The automation engine (260) utilizes distributed task schedulers, inter-node communication protocols, and state synchronization mechanisms to coordinate execution. Examples include provisioning virtual machines across cloud regions or deploying updates to container clusters managed by orchestration platforms such as Kubernetes.
[0044] The automation engine (260) includes a task scheduler (260c) and a dependency resolution module (260d) to manage task execution within defined workflows. The task scheduler (260c) initiates tasks based on predefined criteria such as time schedules, task priorities, or system-defined triggers. The dependency resolution module (260d) analyses task relationships to determine execution order, ensuring that dependent tasks are executed in the correct sequence. This coordination ensures logical consistency, prevents conflicts, and supports complex automation workflows.
[0045] In another embodiment, the automation engine (260e) supports secure and reliable communication with target hosts (290a, 290b) using secure remote communication protocols (p1, p2) such as SSH or TLS By incorporating both communication methods, the automation engine (260e) ensures flexible, secure, and scalable interaction with distributed infrastructure, supporting a wide range of automation scenarios.
[0046] The execution environment (EE) (280) is operatively coupled to the automation engine (260) to facilitate the execution of automation tasks. The execution environment (280) may include virtual machines, containers, or isolated runtime instances capable of hosting and running automation scripts, workflows, or executable modules. This environment provides system-level resources such as CPU, memory, storage, and network access required for task execution.
[0047] The automation engine (260) is configured to deploy the automation tasks (t1, t2) into the execution environment (280), where they (t1, t2) are instantiated and executed. Deployment may involve transferring task definitions, scripts, or binaries from a central repository or configuration store to the execution environment. The automation engine (260) monitors task execution, collects runtime metrics, and handles error recovery or retries based on predefined policies.
[0048] The automation tasks (t1, t2) are executed within the execution environment (280) are targeted at one or more remote systems or target hosts (290a, 290b). Communication with these hosts (290a, 290b) is established using secure remote protocols or as defined in other embodiments. The execution environment (280) may also support sandboxing, logging, and audit capabilities to ensure secure and traceable task execution.
[0049] This configuration enables scalable, secure, and policy-driven automation across distributed infrastructure, supporting use cases such as system provisioning, configuration management, software deployment, and operational monitoring.
[0050] In an embodiment (Figure 5), the execution environment (280a) includes a plurality of isolated computing instances configured to execute automation tasks in a secure, scalable, and resource-controlled manner. Each instance is selected from the container (282), the virtual machine (284), or the serverless runtime (286). The container (282) provides process-level isolation using operating system-level virtualization for lightweight deployment and efficient resource sharing. The virtual machine (284) offers hardware-level isolation suitable for legacy compatibility and full-stack control. The serverless runtime (286) supports ephemeral, event-driven execution without persistent infrastructure, enabling dynamic scaling and cost-efficient operation for stateless tasks.
[0051] The execution environment (280a) enforces fine-grained isolation at the level of individual tasks, users, or workflows. This is achieved through namespace segregation, dedicated resource allocation (e.g., CPU, memory, I/O bandwidth), access control enforcement, and runtime sandboxing. These mechanisms ensure that concurrent tasks do not interfere with each other, preserving data integrity and execution determinism. The architecture supports multi-tenant scenarios, fault containment, and secure orchestration of distributed workloads across heterogeneous infrastructure.
[0052] In another embodiment (Figure 7), the execution environment (280b) includes pre-installed automation tools and libraries required for task execution. These may include scripting engines, configuration management utilities, orchestration frameworks, diagnostic modules, and domain-specific libraries. Pre-installation eliminates the need for external dependencies or manual setup, reducing latency and improving reliability. The execution environment (280b) includes snapshotting, version control, transactional execution, automated retries, and escalation workflows. These features ensure resilient and fault-tolerant automation across distributed systems.
[0053] The target hosts (290a/290b) (Figure 6) include a set of computing resources selected from a cloud-based instance (292), an on-premises server (294), or an edge computing device (296). Each type of computing resource is configured to support remote execution of automation tasks and may vary in terms of network accessibility, resource availability, and operational context. The cloud-based instance (292) typically refers to a virtualized compute node provisioned within a public or private cloud infrastructure, offering elastic scalability and API-driven management. The on-premises server (294) represents a physical or virtual machine located within an enterprise data centre, providing direct control over hardware and software configurations. The edge computing device (296) includes resource-constrained or specialized hardware deployed at the network edge, optimized for low-latency processing and localized task execution.
[0054] The target hosts (290a) are dynamically identified using either an inventory management system (296a) or a discovery service (296b). The inventory management system (296a) maintains a real-time registry of hosts with metadata such as type, location, and operational status. The discovery service (296b) performs active or passive scanning, service enumeration, or API-based querying to detect and register new or updated hosts within the automation framework. To enable selective task execution, the target hosts (290a) support tagging or grouping mechanisms (296c), allowing classification based on attributes such as function, environment, region, or workload type.
[0055] The architecture supports deployment across hybrid computing environments (297) and multi-cloud infrastructures (298), combining cloud-based, on-premises, and edge resources. This flexibility ensures scalable, fault-tolerant, and policy-driven task distribution across diverse operational domains. The automation engine (260), upon receiving a predefined command from the admin module (240), selects an appropriate execution environment (280) and identifies target hosts (290a, 290b) using the inventory management system (296a) or discovery service (296b). The hosts (290a, 290b) may include cloud-based instances (292), on-premises servers (294), or edge computing devices (296), and are filtered using tagging mechanisms (296c).
[0056] The automation engine (260) dispatches tasks to the selected hosts using secure remote communication protocols (p1, p2) ensuring secure, isolated, and monitored execution. The execution environment (280), including containers (282), virtual machines (284), or serverless runtimes (286), is selected based on task-specific requirements and is pre-configured with automation tools and libraries .
[0057] This architecture enables consistent, context-aware automation for tasks such as provisioning virtual machines, deploying microservices, applying security patches, and collecting diagnostic logs across hybrid and multi-cloud infrastructures.
[0058] In one more embodiment of the invention (Figure 8), the CAP (200) includes an API plugin (300) operatively coupling the automation engine (260) with an external system (400) with a unidirectional connection (301). The automation identifier (202a) is for performing an external automation in the host (290a). The automation engine (260) facilitates the execution of external automation only and remains non-functional when the external system (400) is performing the tasks (t1, t2). The API plugin (300) establishes the unidirectional connection (301) between the automation engine (260) and an external system (400). When an automation identifier (202a) corresponds to an external automation task intended for execution on a target host (290a), the admin module (240) routes the predefined command through the API plugin (300) directly to the external system (400). The unidirectional connection (301) ensures that control flow and execution responsibility are transferred exclusively to the external system (400), without invoking the internal orchestration or execution modules of the automation engine (260). This architectural design supports external automation workflows while maintaining strict separation of execution responsibilities.
[0059] To enforce non-functionality during external automation, the automation engine (260) incorporates a suppression mechanism that disables internal execution components when an external automation identifier (202a) is detected. This includes deactivation of the task scheduler (260c), the dependency resolution module (260d), and the execution environment provisioning logic. The automation engine (260) also locks internal resources such as the containers (282), the virtual machines (284), and the serverless runtimes (286) to prevent unintended allocation. Additionally, the task registry (283) marks externally managed tasks to prevent monitoring. These components collectively ensure that the automation engine (260) remains passive and non-operational while the external system (400) performs automation tasks (t1, t2) on the target host (290a), thereby preserving system integrity and avoiding execution conflicts. Non functionality here refers to being non-functional related to internal operations of the automation engine (260). When external automation tasks are being performed, the automation engine (260) facilitates tasks related to the external system (400) on/at the target hosts (290a). The automation engine (260) is preconfigured with a set of instructions for enabling facilitation of external tasks when the external system (400) is connected to the target hosts (290a) through the automation engine (260).
[0060] In one more embodiment of the invention (Figure 9), a method (700) for performing the automation tasks (t1, t2) in the network enabled computing device (C1) is provided.
[0061] The method (700) starts at step 710.
[0062] At step 720, the message layer (220), the admin module (240),the automation engine (260) is configured in the memory (m) of the computing device (C1).
[0063] At step 730, the automation identifier (202) is received by the message layer (220).
[0064] At step 740, the automation identifier (202) is transmitted from the message layer (220) to the admin module (240).
[0065] At step 750, a predefined command corresponding to the automation identifier (202) is transmitted to the automation engine (260).
[0066] At step 760, the execution environment (EE) (280) is coupled to the automation engine (260). The automation engine (260) executes the automation tasks (t1, t2) on the target hosts (290a, 290b) based on the received command.
[0067] The method 700 ends at the step 765.
[0068] In one embodiment of the method (701) (Figure 10), the method (701) includes step 770, which involves coupling the automation engine (260) to an external system (400) via the API plugin (300) over the unidirectional connection (301). This connection (301) enables command transmission from the automation platform to the external system (400) while preventing bidirectional control or feedback. At step 780, upon receiving an automation identifier, the method (701) determines whether the identifier (202a) corresponds to the external automation. If so, the method (701) facilitates execution of automation tasks (t1, t2) by the external system (400), while maintaining the automation engine (260) in a non-executing state. During this state, the automation engine (260) suppresses internal task scheduling, execution environment provisioning, and monitoring functions, ensuring that task execution is exclusively managed by the external system.
[0069] The method 701 ends at the step 790.
[0070] The cloud automation platform (200), implemented using the method (700), is applied in enterprise IT environments to automate infrastructure operations such as software deployment, configuration updates, and log collection. The method (700) enables structured execution by receiving an automation identifier (202) through interfaces like dashboards, APIs, or schedulers, interpreting it via the admin module (240), and dispatching a predefined command to the automation engine (260). The automation engine, coupled with the execution environment (280), executes the task on appropriate target hosts (290a, 290b), ensuring consistent and efficient automation across cloud, on-premises, and edge systems.
[0071] In hybrid environments where external automation tools are used, the method (701) supports seamless delegation. When an automation identifier corresponds to the external task, the platform (CAP 200a) routes the command to the external system (400) via an API plugin (300) over the unidirectional connection (301). During this process, the automation engine (260) remains inactive, allowing the external system to execute the task independently. This setup provides centralized control and visibility while leveraging specialized external capabilities, making it ideal for distributed automation across multiple platforms.
[0072] The cloud automation platform (200), in conjunction with the method (700), provides centralized orchestration across heterogeneous infrastructure, addressing challenges such as fragmented workflows, configuration drift, and inconsistent task execution. The automation engine (260) and execution environment (280) enable reliable task execution across virtual machines, containers, and bare-metal hosts. The message layer (220) and admin module (240) ensure secure and policy-driven command dispatch.
[0073] Scalability and adaptability are achieved through the use of isolated execution environments (280a) and intelligent task management using the task scheduler (260c) and dependency resolution module (260d). These components support concurrent execution, resource isolation, and host-specific automation, improving operational efficiency and enabling multi-tenant support.
[0074] The method (701) introduces controlled delegation to external systems (400), solving the problem of execution conflicts and tight coupling in hybrid workflows. By keeping the automation engine (260) inactive during external task execution, the method (701) reduces unnecessary resource consumption and enhances performance in high-load environments. Additional advantages include dynamic host identification, task prioritization, and integration with messaging systems, enabling precise, scalable, and secure automation across hybrid and multi-cloud infrastructures. , Claims:We Claim:
1. A cloud automation platform (200) comprising:
a message layer (220) configured in a network-enabled computing device (C1) having a processor (P) and a memory (m), the message layer (220) is configured to receive an automation identifier (202);
an admin module (240) configured in the memory (m) and communicatively coupled to the message layer (220) and the admin module (240) is configured to receive the automation identifier (202) from the message layer;
an automation engine (260) configured in a computing node (N), the computing node (N) is connected with the processor (P), the memory (m), and a network interface (I); the network interface (I) is communicatively coupled to the admin module (240);
an execution environment (EE) (280) coupled to the automation engine (260) and the automation engine (260) is configured to execute one or more automation tasks (t1, t2) on one or more target hosts (290a, 290b);
wherein, upon receiving the automation identifier (202), the admin module (240) transmits a predefined command corresponding to the automation identifier (202) to the automation engine (260), and the automation engine (260) executes the automation tasks (t1, t2) on the target hosts (290a, 290b) based on the received command.

2. The cloud automation platform (200a) as claimed in claim 1, wherein the platform (200) includes an API plugin (300) operatively coupling the Automation engine (260) with an external system (400) with a unidirectional connection (301), wherein when the automation identifier (202a) is for performing an external automation in the host (290a), the automation engine (260) facilitates the execution of the external automation only and remains non-functional when the external system (400) is performing the tasks (t1, t2).

3. The cloud automation platform (200b) as claimed in claim 1, wherein the automation identifier (202) is received from a user interface (275a) of the platform (200b), a machine learning module (275b), a service output (275c) of a computing activity (275d), a service input (275e) from a computing environment (275f), an API (275g), a scheduler (275h), or an external system (275i), and includes one of a task identifier (202a), a workflow identifier (202b), a script reference (202c), a policy tag (202d), or a configuration profile (202e), and the automation identifier (202) includes metadata including at least one of a task priority, a timestamp, or contextual information associated with a user initiating the automation.

4. The cloud automation platform (200c) as claimed in claim 1, wherein the message layer (220) comprises one or more of a message queue (220a), a publish-subscribe system (220b), an event stream (220c), a message bus (220d), or an in-memory messaging system (220e), and a logic (220f) for filtering, routing, or transforming messages, and implements message persistence and retry mechanisms (220g); and wherein the admin module (240) comprises a rules engine (240a) configured to interpret the automation identifier (202), maintains a mapping between the automation identifiers (202) and predefined automation commands, logs or audits received identifiers and dispatched commands, and supports role-based access control or policy enforcement.

5. The cloud automation platform (200d) as claimed in claim 1, wherein the automation engine (260) is configured to execute multiple automation tasks in a parallel (260a) or in a distributed computing environment (260b) and the automation engine (260) comprises a task scheduler (260c) or a dependency resolution module (260d) configured to determine the execution order of automation tasks based on predefined task relationships.

6. The cloud automation platform (200e) as claimed in claim 1, wherein the automation engine (260e) is configured to communicate with the target hosts (290a, 290b) using secure remote communication protocols (p1, p2).

7. The cloud automation platform (200f) as claimed in claim 1, wherein the execution environment (EE) (280a) comprises one or more isolated computing instances selected from containers (282), virtual machines (284), or serverless runtimes (286), and is configured to provide isolation at a granularity of individual tasks, users, or workflows.

8. The cloud automation platform (200g) as claimed in claim 1, wherein the execution environment (280b) includes pre-installed automation tools or libraries required for executing automation tasks.

9. The cloud automation platform (200h) as claimed in claim 1, wherein the one or more target hosts (290a) comprise computing resources selected from cloud-based instances (292), on-premises servers (294), or edge computing devices (296), and are identified dynamically using an inventory management system (296a) or a discovery service (296b), support tagging or grouping mechanisms (296c) for task targeting, a hybrid computing environment (297) or a multi-cloud infrastructure (298).

10. A method (700) for performing one or more automation tasks (t1, t2) in a network enabled computing device (C1) having a processor (P) connected to a memory (m1), the method (700) comprising steps of:
configuring a message layer (220), an admin module (240), an automation engine (260) in the computing device (C1);
receiving an automation identifier (202) by the message layer (220);
transmitting the automation identifier (202) from the message layer (220) to the admin module (240);
transmitting a predefined command corresponding to the automation identifier (202) to the automation engine (260); and
coupling an execution environment (EE) (280) to the automation engine (260) and the automation engine (260) executes the automation tasks (t1, t2) on the target hosts (290a, 290b) based on the received command.

11. The method (701) as claimed in claim 10, wherein the method comprising a step of coupling the automation engine (260) to an external system (400) via an API plugin (300) over a unidirectional connection (301), and upon determining that the automation identifier (202) corresponds to an external automation, facilitating execution of the automation tasks (t1, t2) by the external system (400) while maintaining the automation engine (260) in a non-executing state during the task execution.