Tuesday, July 15, 2025

Build Your First AI Team: A Step-by-Step Guide to crewAI

Ever faced a task so complex it felt like you needed a whole team to tackle it? What if you could build that team with AI? Welcome to the world of crewAI, a powerful framework for orchestrating autonomous AI agents who can work together to solve complex problems.

In this guide, we'll go from zero to hero, building a sophisticated AI team right inside a Google Colab notebook. Our crew will consist of a Python Developer and a QA Tester. Their mission: to write, test, and debug a Python script that solves the classic Traveling Salesman Problem (TSP) using a professional optimization library.

Let's dive in!




## Getting Started: Setup and API Keys

First, we need to set up our workspace and install the necessary libraries. crewAI is the core framework, crewai_toolsprovides useful add-ons, and ortools is the powerful optimization library our crew will use.

Run this command in a Colab cell:

Python
!pip install crewai crewai_tools ortools

Next, you'll need an OpenAI API key. The most secure way to handle this in Colab is by using the built-in Secrets Manager.

  1. Click the key icon (๐Ÿ”‘) on the left sidebar of your notebook.

  2. Click "Add a new secret".

  3. For the Name, use OPENAI_API_KEY.

  4. In the Value field, paste your actual OpenAI API key.

  5. Make sure the "Notebook access" toggle is on.

Now, use this code to load your key into the environment:

Python
import os
from google.colab import userdata

os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')

## The Building Blocks: Tools, Agents, and Tasks

A crew is made of three core components:

  • Tools ⚙️: Skills you give your agents, like running code or searching the web.

  • Agents ๐Ÿค–: The AI workers, each with a specific role and goal.

  • Tasks ๐Ÿ“: The assignments you give to your agents.

Creating a Custom Tool

Our tester agent needs the ability to execute code. We can grant this skill by creating a custom tool. BaseTool lets us define a new capability from scratch.

Python
from crewai.tools import BaseTool
import io
from contextlib import redirect_stdout, redirect_stderr

class CodeExecutionTool(BaseTool):
    name: str = "Code Execution Tool"
    description: str = "Executes Python code and returns the output or error. Input should be a string of Python code."

    def _run(self, code: str) -> str:
        output_buffer = io.StringIO()
        error_buffer = io.StringIO()
        try:
            with redirect_stdout(output_buffer), redirect_stderr(error_buffer):
                exec(code, {})
            
            output = output_buffer.getvalue().strip()
            error = error_buffer.getvalue().strip()

            if error:
                return f"Execution failed with error: {error}"
            elif output:
                return f"Execution successful with output: {output}"
            else:
                return "Execution successful with no output."
        except Exception as e:
            return f"An exception occurred during execution: {str(e)}"

code_executor = CodeExecutionTool()

Designing Your AI Agents

Now, let's define our two agents. Notice how their role, goal, and backstory give them a clear persona. We'll equip our tester with the code_executor tool we just built.

Python
from crewai import Agent

# Developer Agent ๐Ÿง‘‍๐Ÿ’ป
developer = Agent(
    role='Senior Python Developer',
    goal='Write clean, efficient, and error-free Python code using the Google OR-Tools library to solve the Traveling Salesman Problem.',
    backstory=(
        "You are an experienced Python developer with a knack for solving complex algorithmic problems. "
        "You receive task descriptions and turn them into functional Python scripts, "
        "diligently debugging and refactoring based on QA feedback."
    ),
    verbose=True,
    allow_delegation=False
)

# Tester Agent ๐Ÿงช
tester = Agent(
    role='Software Quality Assurance Engineer',
    goal='Test the Python code provided by the developer to ensure it is error-free and provides the optimal solution.',
    backstory=(
        "You are a meticulous QA engineer. Your job is to take Python scripts, "
        "run them using your execution tool, and rigorously test them. If you find any issue, "
        "you report it back to the developer with the error message and suggestions for how to fix it."
    ),
    tools=[code_executor], # Assign the tool here
    verbose=True,
    allow_delegation=True # Allow the tester to send tasks back to the developer
)

Defining the Mission: Tasks

Finally, we create the tasks. We'll define the problem and the expected outcome. The context parameter in testing_taskis crucial—it tells the tester to use the code produced by the developer in the coding_task.

Python
from crewai import Task

# Task description for the developer
algorithm_description = (
    "Create a Python function that solves the Traveling Salesman Problem (TSP) using the "
    "Google OR-Tools library. "
    "\n\nThe function should be named `solve_tsp_ortools` and take one argument:"
    "\n1. `distance_matrix`: A 2D list representing the distances between cities."
    "\n\nThe implementation must use `ortools.constraint_solver.pywrapcp` to create a routing model, "
    "find the optimal solution, and return a tuple containing:"
    "\n1. `path`: A list of city indices for the optimal tour, starting and ending at city 0."
    "\n2. `distance`: The total distance of the optimal tour."
    "\n\nInclude a test case that calls the function with a sample distance matrix and prints the resulting path and distance."
)

# The coding task
coding_task = Task(
    description=f"Write a Python script that implements the following: {algorithm_description}",
    expected_output="A single block of clean, executable Python code that defines the `solve_tsp_ortools` function and includes a test case.",
    agent=developer
)

# The testing task
testing_task = Task(
    description=(
        "You are responsible for testing the Python code for the Traveling Salesman Problem. "
        "Use your 'Code Execution Tool' to run the script."
        "\nThe test case in the script should find an optimal solution with a total distance of 80."
        "\nVerify that the script's output contains 'Total Distance: 80'. "
        "\nIf the code runs and the distance is correct, your final answer is the code itself with a confirmation. "
        "If there is any error or the distance is not 80, delegate back to the developer with a report."
    ),
    expected_output="The final, correct Python code with the confirmation 'Code is tested and works perfectly with an optimal distance of 80.'",
    agent=tester,
    context=[coding_task]
)

## Launching the Crew ๐Ÿš€

With our tools, agents, and tasks ready, it's time to assemble the crew and kick off the mission! We'll use a sequentialprocess, where tasks are executed one after another. crewAI's delegation logic will handle the back-and-forth between the agents if the tester finds a bug.

Python
from crewai import Crew, Process

# Assemble the crew
code_crew = Crew(
    agents=[developer, tester],
    tasks=[coding_task, testing_task],
    process=Process.sequential,
    verbose=2 # Use verbose=2 for detailed, step-by-step logging
)

# Kick off the work!
result = code_crew.kickoff()

# Print the final result
print("\n\n########################")
print("## Crew Work Complete!")
print("########################\n")
print("Final Result:")
print(result)

When you run this, you'll see the agents "thinking" and passing work between each other. The developer will write the initial code, and the tester will run it. If it fails, the tester will send it back with an error report until the code is perfect!


## Conclusion

You did it! You've successfully built and launched a multi-agent AI team to solve a complex programming task. From installing libraries and defining custom tools to designing specialized agents and launching a crew, you've seen how crewAI can automate sophisticated workflows.

The possibilities are endless. You could build crews for market research, content creation, financial analysis, and so much more. Now it's your turn to get creative—what will your crew build next?

You can find the Jupiter notebook with all the working code for this example case following the Github link.

Monday, June 9, 2025

Generative AI and Operations Research: A New Frontier of Optimization

Operations Research (OR) has long been the bedrock of optimal decision-making in a world of limited resources. From logistics and supply chains to finance and manufacturing, OR professionals have leveraged mathematical models and algorithms to find the best possible solutions to complex problems. Now, a new technological force is poised to revolutionize the field: Generative AI.

The intersection of Generative AI and Operations Research is more than just an incremental improvement; it's a paradigm shift. While traditional OR has excelled at optimizing well-defined problems, Generative AI introduces the ability to handle ambiguity, generate novel solutions, and interact with complex systems in a more intuitive, human-like way.


The Democratization of OR

One of the most significant impacts of Generative AI on Operations Research is the democratization of its powerful tools. Large Language Models (LLMs) can act as a "smart interface" for complex optimization models. This means that users without deep technical expertise can interact with and leverage OR models using natural language. Imagine a factory floor manager being able to ask, "What's the most efficient production schedule if we experience a 10% delay in raw material delivery?" and receiving an optimized plan in seconds. This capability will empower a broader range of professionals to make data-driven decisions, breaking down the barriers that have often confined OR to specialized departments.

Enhancing the Modeling Process

Generative AI is also set to transform the very process of building and refining OR models. It can act as a powerful coding assistant, automating the generation of mathematical models and suggesting improvements to existing ones. Furthermore, Generative AI can be used to create synthetic data that mirrors real-world operational scenarios. This is invaluable for training and testing optimization models, especially when historical data is scarce or incomplete. By generating a wider range of potential scenarios, we can build more robust and resilient systems that are better prepared for unforeseen disruptions.

A New Wave of Applications

The combination of Generative AI and Operations Research is unlocking a host of new applications. In supply chain management, it's being used to optimize routes in real-time, taking into account a multitude of variables like traffic, weather, and delivery windows. In manufacturing, it's helping to design more efficient production lines and even generating novel product designs that are optimized for weight and material usage. We're also seeing its application in areas like resource allocation, scheduling, and risk assessment, where it can provide insights that were previously unattainable.


The Road Ahead

Of course, the integration of Generative AI into Operations Research is not without its challenges. Issues of data quality, model interpretability, and ethical considerations will need to be carefully addressed. However, the potential benefits are immense. By combining the rigorous analytical power of Operations Research with the creative and intuitive capabilities of Generative AI, we are entering a new frontier of optimization. The future of OR is not about replacing human experts, but about augmenting their abilities, allowing them to solve more complex problems and create a more efficient and sustainable world.

Monday, June 2, 2025

Harnessing the AI-Cloud Symbiosis for Advanced Manufacturing Operations

The convergence of Artificial Intelligence (AI) and cloud infrastructure is a pivotal development, fundamentally reshaping engineering and manufacturing paradigms, especially within the intricate domain of semiconductor fabrication. This synergy is not merely about co-locating resources but about creating a deeply integrated ecosystem that accelerates innovation and operational excellence.


Effective AI deployment typically follows a structured lifecycle encompassing three critical phases: data preparation, model development (training and validation), and model deployment (inference). The adoption of containerization technologies, prominently Docker, across these stages is instrumental.

  • During data preparation, Docker containers ensure that the complex web of dependencies for data cleaning, transformation, and feature engineering tools is encapsulated, providing reproducible environments critical for consistent data pipelines.
  • For model development, containers allow AI/ML teams to package specific versions of frameworks (e.g., TensorFlow, PyTorch), libraries, and CUDA drivers, ensuring that training environments are identical across different machines, whether on a local workstation or a powerful cloud GPU instance. This mitigates the common "works on my machine" problem.
  • In the model deployment phase, containerized AI models can be seamlessly deployed as microservices, offering scalability and simplified management through orchestration platforms like Kubernetes. This facilitates rolling updates, A/B testing, and robust monitoring of inference endpoints.

The strategic decision to migrate specific AI workloads or entire AI lifecycle phases to the cloud is often driven by compelling technical advantages. Scalability is paramount; cloud platforms offer virtually limitless compute resources (CPUs, GPUs, TPUs) and storage on demand. This elasticity is crucial for compute-intensive tasks like training deep learning models on massive datasets, where capital expenditure for equivalent on-premise hardware would be prohibitive or inefficiently utilized. Flexibility in choosing diverse instance types, storage solutions, and specialized AI services (e.g., managed Kubeflow, SageMaker, Azure Machine Learning) allows tailoring the infrastructure precisely to the workload's needs. Furthermore, high resource utilization is achieved by paying only for consumed resources, optimizing operational expenditure.

For AI developers and MLOps engineers, cloud platforms provide a rich ecosystem of tools and managed services that significantly streamline the development-to-deployment pipeline. This includes integrated development environments (IDEs), automated machine learning (AutoML) capabilities, data versioning tools, model registries, and CI/CD/CT (Continuous Integration/Continuous Delivery/Continuous Training) frameworks. By abstracting significant portions of the underlying infrastructure provisioning and management (e.g., server maintenance, network configuration, patching), developers can concentrate on the core algorithmic and modeling challenges, accelerating the iteration cycle and time-to-market for AI-driven solutions.


Latency considerations, particularly for real-time process control or defect detection in high-speed semiconductor manufacturing lines, are a legitimate concern with purely cloud-centric AI deployments. This is where edge computingand hybrid architectures become critical. By deploying trained models within containers to edge devices located closer to the data source (e.g., on the factory floor, near metrology equipment), inference can be performed locally with minimal latency. The cloud still plays a vital role in this hybrid model by centrally managing model training, updates, and overall orchestration of distributed edge deployments. This approach combines the low-latency benefits of local processing with the scalability and manageability of cloud resources, offering a robust solution for time-sensitive AI applications. Data pre-processing or aggregation can also occur at the edge to reduce data transmission volumes to the cloud.

In summary, the sophisticated integration of AI algorithms with versatile cloud architectures, augmented by containerization and strategic edge deployments, provides a powerful toolkit for tackling complex challenges in modern manufacturing. This combination allows for unprecedented levels of automation, predictive capability, and operational agility, driving significant advancements in yield, quality, and efficiency.


Note: This blog article deep dives into the concepts mentioned in an earlier interview I made for Applied SmartFactory. If you are interested, you can read the interview following the link below:

https://appliedsmartfactory.com/semiconductor-blog/ai-ml/ai-and-cloud-integration-part-2/

Sunday, June 1, 2025

The Indispensable Symbiosis: Deepening the AI and Cloud Integration

The convergence of Artificial Intelligence (AI) and cloud computing is no longer a futuristic vision but a present-day imperative driving innovation across industries. As AI models grow in complexity and data appetite, the sophisticated, scalable, and resilient infrastructure offered by cloud platforms has become the bedrock for successful AI deployment and operation. This article, the first in a series, will delve into the fundamental aspects of this critical integration.

Deconstructing the Cloud: More Than Just Remote Servers

The term "cloud" often simplifies a complex ecosystem of technologies. Fundamentally, it provides on-demand access to a shared pool of configurable computing resources—ranging from processing power (CPUs, GPUs, TPUs) and extensive storage solutions (object, block, file storage) to highly adaptable network infrastructures and a plethora of managed services.

We primarily distinguish between:

  • Public Clouds: Characterized by multi-tenant infrastructure owned and operated by third-party providers (e.g., AWS, Azure, GCP). They offer significant advantages in terms of economies of scale, a broad array of standardized services (from IaaS, PaaS, to SaaS), pay-as-you-go pricing, and rapid elasticity. This model allows organizations to offload infrastructure management and focus on innovation.
  • Private Clouds: Feature infrastructure dedicated to a single organization. While requiring more upfront investment and operational overhead, private clouds provide maximal control over hardware, data sovereignty, security configurations, and resource allocation, which can be indispensable for specific regulatory or performance requirements.
  • Hybrid Clouds: Increasingly common, these environments combine public and private clouds, aiming to leverage the benefits of both. Workloads and data can be strategically placed based on factors like cost, performance, security, and compliance, often orchestrated through unified management planes.


Containerization: The Linchpin for Agile AI Deployment

In the realm of AI/ML development and deployment, containerization technologies have emerged as a transformative force.

  • Docker: At the development stage, Docker allows for the creation of lightweight, standalone, executable software packages—containers—that include everything needed to run an application: code, runtime, system tools, system libraries, and settings. This ensures consistency from a developer's laptop to testing and production environments, mitigating the "it works on my machine" syndrome.
  • Kubernetes (K8s): As we move to production, especially with microservices architectures common in complex AI systems, orchestrating numerous containers becomes a challenge. Kubernetes, an open-source container orchestration platform, automates the deployment, scaling, and management of containerized applications. It handles service discovery, load balancing, self-healing (restarting failed containers), and rolling updates, providing a resilient foundation for AI workloads.
  • Helm Charts: To further simplify application deployment on Kubernetes, Helm charts act as package managers. They allow developers and operators to define, install, and upgrade even the most complex Kubernetes applications using pre-configured templates, enhancing reusability and operational efficiency.

The Economic Equation: GPUs, AI Workloads, and Infrastructure Choices

The financial implications of infrastructure choices are paramount, particularly for AI applications that are often GPU-intensive. Training deep learning models or running large-scale simulations can require substantial GPU capacity over extended periods. While cloud providers offer a wide array of GPU instances, the associated costs can accumulate rapidly. For sustained, high-demand GPU workloads, an on-premise deployment, despite its initial capital expenditure and ongoing maintenance responsibilities, can sometimes offer a more predictable and potentially lower total cost of ownership (TCO). However, this must be weighed against the cloud's elasticity for burst workloads, access to the latest hardware without procurement delays, and the avoidance of over-provisioning. The "data gravity" – where data resides and the cost/latency of moving it – also significantly influences these architectural decisions.


AI's Trajectory: Scaling Innovation and Hardware Dependencies

The remarkable strides in AI, especially with foundational models and Large Language Models (LLMs), are largely attributable to our ability to scale up training on massive datasets using increasingly powerful hardware. GPUs have been central to this, providing the parallel processing capabilities essential for deep learning. While cloud platforms are major providers of GPU capacity, the underlying hardware advancements themselves are not exclusive to the cloud. The critical insight is the accessibility and scalability that cloud platforms bring to these powerful resources. Furthermore, the evolution continues with specialized AI accelerators (like TPUs, NPUs, and other ASICs) becoming more prevalent, often first accessible through major cloud providers.

The Indispensable Cloud Backbone for AI Operations

For any organization serious about leveraging AI, particularly when dealing with petabyte-scale datasets and deploying sophisticated models, a robust cloud infrastructure is not merely beneficial but essential. The entire MLOps lifecycle—from data ingestion and preprocessing, exploratory data analysis, model training and validation, to deployment, monitoring, and retraining—can be significantly streamlined and automated using cloud-native services. These include managed databases, data lakes and warehouses, serverless compute for inference endpoints, and integrated MLOps platforms.

Looking ahead, as AI technologies continue to evolve at an accelerated pace, cloud platforms must also adapt proactively. This includes addressing challenges such as optimizing data transfer costs for enormous datasets, reducing latency for real-time AI applications, providing more efficient and cost-effective access to specialized AI hardware, and developing more sophisticated software stacks to manage the increasing complexity of AI workflows. The symbiotic evolution of AI and cloud computing will undoubtedly continue to redefine technological frontiers.


Note: This blog article deep dives into the concepts mentioned in an earlier interview I made for Applied SmartFactory. If you are interested, you can read the interview following the link below:

https://appliedsmartfactory.com/semiconductor-blog/ai-ml/ai-and-cloud-integration-part-1/ 


Monday, January 28, 2013

Who Controls the Cloud Market – Providers or Consumers?

We first went from reserving cloud capacity to securing capacity on-demand, and then we even started to bid for unused capacity in the spot market – all in an effort to decrease cost in the cloud.  Can we take this one step further?  Instead of us bidding for capacity, wouldn’t it be interesting if we can get providers to bid for our demand?


Retail Supply Chain Market Analogy

In fact, this is a common phenomena in the retail supply chain industry.  For example, Walmart has a large amount of freight that needs to be shipped between different cities over the course of the year.  So, every year an auction is conducted in which Walmart lists all their shipments, and carriers such as JB Hunt, Schneider, Yellow etc. bid for the opportunity to carry these shipments using their fleet of trucks.  The reason carriers are bidding for retailer demand is because in general, capacity exceeds demand in the retail industry.

Cloud Computing Market

Keeping this in mind, let us now take a look at the Cloud Computing Market.  Does capacity exceed demand or is it the other way around?  A quick way to find out is by observing spot prices in the cloud market.  In today’s market, Amazon’s Spot Instances are 86% cheaper than their on-demand instances, and Enomaly’s SpotCloud also shows lower spot prices across the board.  This leads us to believe that capacity exceeds demand in the cloud market as well.  A related indicator is the predominance of data center consolidation initiatives in both the commercial and government marketplaces.
Since capacity exceeds demand, consumers have an upper hand and are in control of the cloud market at the moment.  Moreover, they should be able to replicate what is being done in the retail supply chain industry.  In other words, cloud consumers should be able to auction off their demand to the best fit lowest price cloud provider.

So, …

Consumers should seize the opportunity and control the market while the odds are in their favor i.e. Demand < Capacity.  At the same time, Service Integrators and Value Added Resellers can help Enterprise IT consumers in this process by conducting Primary-Market auctions using Cloud Service Brokerage technology.


Friday, July 27, 2012

Cloud Technology Spectrum

Doesn't it make you cringe when people use the term cloud brokerage when they really mean cloud marketplace?  Or, when they say they provide virtualization management whereas they really provide cloud management services?  A number of such cloud terms are used interchangeably every day, but the challenge is that cloud terminology has yet to reach steady state.

In this article, we hope to clarify a few cloud technology terms using Level of Integration as the criteria.

Note that each layer builds upon the layer below it, thus leading to a spectrum of cloud technologies - aka - The Cloud Technology Spectrum.  The table below shows some of the key providers in each layer of the spectrum.

There are a number of other providers as well, and some providers in fact go over multiple layers of the spectrum.  But the point here is to note that in order for any technology to claim to be in a specific layer, it should effectively integrate at least one item from each of the layers below.

When deciding to migrate to the cloud, it is important for consumers to know where in the spectrum they would end up if they purchased some piece of cloud technology, and how much additional effort would be required on their part.  The Cloud Technology Spectrum helps in this step of the process.

Go to Cloud Deployment Tree for a view of the different cloud deployment options...

Monday, April 30, 2012

Secure Environment for Federal Government Cloud Pilot

How is the Federal government hoping to achieve the $12 Billion in projected annual savings?  This projection was quoted by the MeriTalk Cloud Computing Exchange and published today by Forbes.com, and it doesn't seem too optimistic given that the Federal government is already saving approximately $5.5 Billion per year.

These savings have been achieved by individual agencies adopting cloud solutions, but such organic growth will only go so far.  In order to expand this in a generic and scalable manner, the Federal government would need a secure environment to test the cloud and run pilot programs.

A Fire-fort?

Key features of such an environment:


1. Multi-provider provisioning and compliance
Agencies should be able to provision resources across cloud providers without having to worry about vendor lock-in.  This would require the use of a brokerage platform that enables auto provisioning across providers.  Monitoring would also be necessary to ensure the providers maintain SLA compliance, failing which they would be quarantined.

2. Fed certified cloud providers
The list of cloud providers should include those that are FedRAMP certified, or at least FISMA compliant.  Agencies should be able to compare providers side by side and pick the best-fit provider.  This requires standardization of cloud offerings and pricing models.

3. Integration with existing data centers private / hybrid clouds
Agencies should be able to interoperate between the cloud and their existing data centers and private clouds.  This provides a backup plan in case the cloud solution does not succeed.  For this feature, the test environment would need to be agnostic across VMware, Xen, Hyper-V, vCloud Director, etc.

4. Connectivity to existing security frameworks
The test environment should be integrated with the security frameworks currently used by the Federal government.  In this way, valuable resources need not be wasted in re-designing a security framework that is already very efficient.  Instead, resources can be assigned to enhance the existing framework with intrusion detection and intrusion prevention features.

5. Complete cost transparency
First of all, agencies should not be required to sign multi-year contracts with cloud providers.  Secondly, the cost of cloud services should be visible at the highest level so that budgets may be allocated based on resource requirement.  This allows complete auditability as well.

6. Recalibration based on historical data
Cloud usage data should be constantly correlated with cost to ensure that cost is minimized without impacting mission goals.  This requires the test environment to be powered by advanced analytics engines for continuous recalibration through command and control.

All the above features would need to be tested by the Federal government through a pilot program before executing any major cloud migration initiatives.  If successful, the test environment can then be established as the official government cloud portal which is bound to be successful because it has been built on NIST standards and governed through strict monitoring and compliance.

Friday, January 27, 2012

Can Clouds Plug the Ozone Hole? (pun intended…)


Environmental protection has been a major concern over the past few years... and if it hasn't been an issue for us, it probably should be.  In any case, as an IT analyst it is important to know where we fit in and scrutinize our contribution to the environment from an analytical perspective, leaving all subjectivity aside.


For those of us who are not EPA experts, let us say we can help conserve the environment by:
1. Protecting the environment from pollution and habitat degradationCloud computing does not do much when it comes to habitat degradation or water pollution, but it does play a part in controlling air pollution.  This is because physical servers are consolidated into more efficient blades and chassis in the cloud.  Consolidation of resources results in less power and cooling requirements, which in turn reduces air pollution.  Moreover, cloud data centers can be placed in colder parts of the world to further save on power for cooling.
2. Sustaining the environment by avoiding depletion of natural resources
In the same way that cloud data centers can be placed in cold parts of the world, they can also be placed in remote areas with high wind (to harness wind power) or areas with more direct sunlight (for solar power).  As a result, alternative sources of energy can be used to power cloud data centers.  This placement of cloud data centers away from consumers is feasible because data and compute processing is not lost over wireless networks (unlike power loss during transfer of electricity from wind farms in the West coast to consumers in the rest of the country).


However, there are a number of underlying assumptions that need to be satisfied for cloud to successfully deliver Green-IT...
Assumption 1: Utilization of cloud resources is high and efficient.
Underutilization greatly reduces the consolidation ratio from physical to cloud resources and power savings are minimal.  Efficiency in the cloud can be boosted by turning VMs on/off based on demand (i.e. autoscaling) and load balancing between VMs.
Gravitant's CloudMatrix technology specializes in "optimizing" the cloud for consumers through a SaaS console across multiple providers.
Assumption 2: Data being collected is summarized and compressed before storage.
Otherwise, the constant collection and storage of data will lead to data obesity which brings into question "how much duplication there is and more importantly how much integrity does the data have?" (CloudVisions).
EXAR's hifn technology provides data deduplication and data compression services.
Assumption 3: Virtualization and storage caching technology is continuously improving.
Otherwise, the ever increasing processing and data needs will catch up and diminish the relative benefit of the cloud.
Cisco and EMC are constantly improving their virtualization and thin provisioning technology respectively.


Therefore, it is safe to say that Cloud computing can deliver Green-IT provided that the right tools are used and innovation continues unabated.

Tuesday, December 20, 2011

What Do We Mean by Cloud?

From Gravitant's blog.

http://blog.gravitant.com/2011/12/19/what-do-we-mean-by-cloud/


“In all the ambiguity of what adds value to the Cloud or what facilitates the Cloud, Gravitant sits at the intersection of both, which makes it a pure Cloud company with all the experience, expertise, and solutions built around the Cloud.”



I’ve been writing mostly about what we’ve been developing for and around the Cloud in Gravitant, recently. Now is the time to elaborate a little bit about what’s being said and done about the Cloud outside of Gravitant. I am not intending to analyze specific articles, rather present an overall picture of the impression I get about what is out there and where Gravitant stands in this picture.
As Cloud is getting hype and determining the next generation of IT and what the Internet constitutes of, it is getting a whole lot of attention from the actors of the sector and beyond. While the Cloud has defined itself during its construction with a bottom-to-top approach, recently the new actors of the Cloud are trying to define/re-define the Cloud with a top-to-bottom view.
The concept of IT resource sharing can be dated back as far as the use of mainframe, the Internet, VMware, or EC2 depending on your perception. However, the name “Cloud” -which is cleverly set by the way- comes definitely after commoditization of IT resources, which is very recent. Before Cloud became the “Cloud”, standards of traditional IT had given direction to all innovative efforts towards Cloud. These efforts have been very technical and mostly motivated by infrastructure oriented improvements. Later on, the commoditization of IT resources has required the business model to be well defined. Although there is a lot of technical, infrastructural advancements noted, probably most of the focus is in the definition of business of the Cloud.
I have read many blog articles, white papers and research papers about the Cloud in addition to web content of cloud companies. If there is one thing common among all these articles, that is what exactly could be labeled as Cloud is not very clear. I get same kind of confusion among my colleagues as an Analytics professional, too. Most of the time, boundaries of the field of Analytics is not very clear. It makes sense in both cases, because their definitions of businesses are still in progress. However, I believe certain examples could draw a more indicative line of what could be called as a pure Cloud effort.
Most of the work branded as Cloud efforts are actually conversion of existing desktop software to SaaS. Especially, if you search keywords “Cloud” and “Analytics”, you will see many analytics tools as SaaS. Although I believe every type of Cloud effort is a brick in the wall while constructing a whole Cloud environment, I think we should start distinguishing what Cloud effort is made “for” cloud and what Cloud effort is made by “facilitating” Cloud. So if I have to give an example, if you convert a management software to a SaaS application, then you are “facilitating” Cloud. If this management software is used to manage your Cloud resources, then this is an effort made “for” Cloud. Although there is a considerable gray area in the intersection of the both, I hope the example makes itself clear to the reader. 
Where does Gravitant stand at this intersection? First of all, Gravitant is an established Cloud brokerage company which is enlisted by Gartner’s recent report on Cloud brokerage companies. NIST defines a cloud broker as “…an entity that manages the use, performance and delivery of cloud services and negotiates relationships between cloud providers and cloud consumers.” In the light of this definition, Gravitant’s CloudMatrix and CloudWiz tools manage all traditional IT resources and Cloud resources end to end from sourcing to provisioning and monitoring. They include very powerful and intelligent capacity planning, advanced monitoring and advanced analytics tools which enable enterprises to strategically and tactically plan capacity of their IT resources on the Cloud and in-house in addition to efficiently analyzing huge data collected from the resources and proposing the most effective Cloud Analytics solutions. All these efforts are made for Cloud to make Cloud a more manageable and less costly environment for IT needs of enterprises. 
On the other side, Gravitant’s major Cloud brokerage and management tools CloudMatrix andCloudWiz are ultimate user friendly, fast and smart SaaS applications. They naturally run on the Cloud very efficiently, reliably and securely. Gravitant runs all its other applications and internal IT resources on the Cloud. So Gravitant facilitates the Cloud and has the first-hand Cloud experience as a Cloud user.

Gravitant both adds value to the Cloud and uses it for its own benefit. All these Cloud centric activites make Gravitant a pure Cloud company. Gravitant’s Cloud network grows very fast day by day including Amazon, Terremark, Savvis, Rackspace, IBM, etc. There is a lot to learn about Gravitant’s cloud experience. If you have any ideas, thoughts or questions to add to this discussion of what is “for” cloud and what is “facilitating” cloud, please respond to this post or contact us so that we can share the intellectual part of the Cloud experience together.

Monday, December 12, 2011

Cloud Deployment Tree

The spectrum of cloud deployment models are many, and everyone has a unique combination. Follow this cloud deployment tree to identify the combination that best suits your requirements.



We have intentionally avoided industry terminology in the tree due to lack of standardization. However, the legend can be used to map each combination to commonly used industry terms (as of today). The legend also shows industry leaders for each combination.

This is the very first step in Cloud Assessment.  The next step is to determine if your application would even be feasible in the cloud.  Click here to see if your application would be a good fit in the cloud...

Wednesday, December 7, 2011

Gravitant published in latest Gartner Report

What makes a Cloud Services Broker (CSB)?
Gartner identifies three primary roles that qualify a company to be a CSB:

  • Aggregation (across VARs, IT distributors etc)

  • Integration (with SIs etc)

  • Customization (for SIs, PS etc)



"As both an enabler and a cloud brokerage, Gravitant pulls together a number of the capabilities that IT organizations, VARs and SIs, and public cloud providers can use to extend the value of their offerings." - Daryl Plummer (Gartner Analyst)

Full report here...

Thursday, November 17, 2011

Cloud Capacity Allocation: Reserved vs. On-Demand Capacity or How I Managed to Get over with Black Friday Rush

From Gravitant's blog.

http://blog.gravitant.com/2011/11/17/cloud-capacity-allocation-reserved-vs-on-demand-capacity-or-how-i-managed-to-get-over-with-black-friday-rush/


The shopping season just arrived and who knows how much pressure is on the shoulders of IT administrators of e-commerce companies. Competition is tough so if one has to wait more than a couple of seconds to view a deal, he or she can easily move on to some other website to get them all. So the clock is ticking and all the e-commerce websites are supposed to have the resources to fulfill the oncoming demand. Thanks to the cloud, these problems are behind. And thanks to Advanced Analytics team of Gravitant, the related cost-cutting solutions are provided to enterprises as a part in our cloud domain. 

Commoditization of computing via cloud allows IT demand to be fulfilled in time. Ideally, it is possible to acquire the required resources whenever the demand occurs. Obviously, this would be the perfect policy to replenish IT resources regardless of budget constraints. However, putting technical difficulties and lead times aside, supplying demand on time is not very practical and smart when cost and alternative pricing models of the suppliers are considered. Most cloud providers offer lower rates for bulk cloud procurements. 

Practical concerns and budget considerations force enterprises to make a three dimensional IT capacity procurement decision in the cloud. Following are the right questions to ask while making these decisions:

1.    How much capacity to reserve at the beginning?
2.    When to order additional capacity?
3.    How much additional capacity should be ordered each time?

Among these three questions, the last two are the easiest to answer as long as we know the answer to the first question. The combined answer to the last two questions is to order the excess demand whenever it occurs. So the first question remains, “what should the reserved capacity be?”
If we assume the preferred cloud provider prices its cloud uniformly, which means it does not implement any bulk pricing and there are no fixed costs per order and no lead times, then it only makes sense to order equivalent to demand quantity whenever there is a demand realization, hence zero reserved capacity. However, the real world does not work exactly this way so we have to keep some reserved capacity to minimize cost and deal with uncertain technical and business problems.
There are a couple of alternative approaches to solving this problem with operations research and advanced analytics techniques. We can either solve the problem with a deterministic optimization approach or implement Markov Decision Process regarding stochasticity. In the next blog article on this topic, I will discuss these alternative approaches in detail and give an idea of what solutions Gravitant offers to enterprises on the issue of reserved vs. on-demand capacity in the cloud.

Wednesday, November 2, 2011

Part 2 - Your application would be a GREAT FIT in the Cloud if...

1. Your application is fairly isolated from other applications

Typical examples of isolated applications are CRM, messaging, and other custom built applications.  On the other hand, traditional ERP applications are tightly woven with others and hence might require re-architecting the application to fit the cloud.

Alternative: In most cases your application is probably somewhere between isolated and completely integrated with other applications.  In this case, here are some options based on the nature of the dependency:
  1. Communication channel dependency - Create a distributable communication channel that is secure
  2. Architecture dependency - Make a copy of the shared layer for the cloud
  3. Single sign-on security - Upgrade single sign-on to support remote sign-on
If none of these options are feasible, then either both applications would need to be migrated to the cloud or both should remain as is.


2. Your application architecture is cloud friendly

Any application on an x86 platform would work well in the cloud regardless of the operating system.  If the application is on some platform other than x86 and you still want to go cloud, then you would need to re-architect the application to the x86 platform before you begin migration.

Also, if the online-architecture is web based or client server, then your application is more cloud friendly.  Moreover, if the online-architecture is heterogeneous from the batch-architecture, then your application is even more cloud friendly.

Alternative: If your application is on any other platform (such as Sun Sparc, Power PC, or Mainframe), then it might be a better candidate for managed hosting.  Another reason to opt for managed hosting is if your servers require software licenses that can only be tied to physical cores.

3. Your application security requirements are satisfied by FISMA compliance

Some cloud providers are FISMA (Federal Information Security Management Act) certified which ensures they are satisfying all the Federal security standards as measured by NIST.  In addition to FISMA compliance, security can be further enhanced by engaging managed services for security on the cloud (like netForensics).

Alternative: If it is necessary for all the data and/or hardware to be located on-site, then a private cloud or a public/private hybrid may be an option.

<- Back to Part 1 - Your application may NOT YET be ready for the Public Commodity Cloud if...

Tuesday, October 11, 2011

Creating a Virtual Machine on/off schedule

“Wouldn’t it be nice to have a schedule to automatically turn VMs on or off at certain times of the day?” I’ve heard this from many of our clients, and this is definitely an interesting optimization problem.  Since most providers price by VM hours, one always needs to make sure not to end up with VM sprawl.  The fact that licensing on these VMs are also priced by the hour doesn’t help either.  So, yeah VM scheduling would be great but where do we start?

Actually, it isn't very complicated because most of us use load balancers anyway.  The load balancers are monitoring VM utilization (through connection count) and can thus keep track of times when all the VMs are underutilized.  Dr. Zarifoglu, in his load balancing article, identified thresholds for turning VMs on or off based on the workload.  So, turning one or more VMs off is simply an additional step after load balancing!

This leads to two possible approaches for VM Scheduling:
Dynamic scheduling – where VMs are automatically turned on or off based on demand and threshold policies, or
Static scheduling – where one would simply monitor VM utilization over time and come up with a user defined schedule that doesn’t change.

Obviously, the best approach would be to have a hybrid solution where the static schedule is automatically modified at fixed time intervals (say weekly) and is executed only after being approved by an administrator.  See Gravitant’s CloudMatrix – Policy Manager for more details on managing VMs in the cloud.


Caveat

The caveat is that most cloud providers don’t allow simply turning VMs on or off (except for OpSource and Terremark).  Most providers will charge for stopped VMs as well, unless the VM is ‘deleted’.  So, an alternate process for turning a VM off (with the expectation of turning it on again at some point in time in the future) is to first create an image of the VM and save it in the backup storage space, and then ‘delete’ the VM.  In order to turn this VM back on, a new VM needs to be created and then the image from backup storage needs to be installed on the new VM before it can become functional.

Alternatives

As a result, the process of turning VMs on or off may be not be time and cost efficient.  However, here are a few alternate ways to do this:
(1) Go with a cloud provider like OpSource that allows VMs to be turned on or off at the click of a button and doesn’t charge for VMs that are turned off. (Note that there is a small fee for storage space occupied by the VM).
(2) Go with a cloud provider like Terremark that doesn’t even price by VM.  However, they would still charge for the OS licensing and storage if the VM was turned on at any point in time during the month.
(3) Go with any cloud provider but subscribe to an automated backup and restore service. Gravitant expects to provide this capability in its CloudMatrix console in early 2012.

For more information, go to www.gravitant.com.