Showing posts with label Cloud Computing. Show all posts
Showing posts with label Cloud Computing. Show all posts

Monday, August 10, 2026

The Next Architecture War: Centralized AI vs. Embedded AI

 

Every laptop sold this year ships with a neural processing unit rated for 40–50 TOPS. Most of them do almost nothing.

Meanwhile, the four largest hyperscalers guided to roughly $725 billion of capital spending for 2026. More than 60% goes to power, cooling, and buildings rather than chips.

Two enormous bets, pointing in opposite directions.

One says intelligence belongs in a few dozen buildings with substation-grade power. The other says it belongs in your pocket, your car, your doorbell. Both camps have spent the last two years describing the other as a transitional phase.

They're both wrong. The argument they're actually having is not the one they think they're having.


The Historical Pattern Nobody Is Naming

Computing history moves in pendulum swings.

1960s: Mainframes centralized compute because computers were expensive.

1980s: Personal computers decentralized compute because chips became cheap.

2000s: Cloud centralized infrastructure because operating servers became difficult.

2010s: Mobile distributed applications closer to users.

2020s: Large Language Models centralized intelligence.

2030s? Embedded AI begins distributing intelligence again.

The pattern is not random. Each swing happens when the underlying economics shift. The question is not "which side wins." Both sides are right about their constraints. The question is: who decides where intelligence lives for each specific decision?


The Two Paradigms (And What They're Actually Selling)

Centralized AI keeps models in cloud clusters operated by hyperscalers. Data travels outward; results return. One model endpoint. Updated whenever the lab ships. The largest context windows, the strongest reasoning, the newest tool-use behavior, available the day it exists.

Examples: ChatGPT, Claude, Gemini, DeepSeek APIs, enterprise copilots.

Embedded AI (edge AI) places models on endpoint devices: phones, laptops, industrial sensors, vehicles, robots. Inference happens locally. No network round-trip. Nothing leaves the device.

Examples: Apple Intelligence processing on-device, autonomous vehicle perception systems, smart factory sensors, medical wearables.

Both stories are true. Both are also incomplete.


Where Centralization Wins (And Fails)

The Centralization Pitch:

  • Unmatched Compute: Massive models (400B+ parameters) are feasible only in the cloud
  • Continuous Learning: Models update in real-time across millions of users
  • Economies of Scale: Shared infrastructure makes complex reasoning cheaper per token
  • Consistency: Every user gets the same answer from the same model

The Hidden Costs:

Cheaper tokens created workloads that never would have existed at old prices. Inference crossed two-thirds of enterprise AI spend by 2026, up from a third in 2023. Enterprise AI bills are still rising because volume growth outpaces cost reduction.

Agentic pipelines are the culprit. A reasoning model burns 50–100 times the tokens its visible output suggests. Chain six of those together with tool calls and retries; the bill stops resembling anything you estimated from a demo.

Meanwhile: latency. The speed of light is a hard physical limit. Sending data to a server thousands of kilometers away and back introduces latency unacceptable for real-time applications. A self-driving car cannot wait 300 milliseconds for a cloud server to recognize a pedestrian.

And privacy. Centralized AI requires data to leave the user's device. In an era of strict global privacy regulations (EU AI Act, GDPR, data sovereignty laws), transmitting sensitive health records, financial data, or factory telemetry to the cloud is becoming a massive regulatory and reputational liability.


Where Embedding Wins (And Fails)

The Embedding Pitch:

  • Zero Latency: Inference happens sub-20ms on-device, not 300ms+ over the network
  • Privacy by Default: Data never leaves the device; no data breach surface
  • Offline Resilience: Works in airplane mode, remote locations, network-constrained environments
  • Cost at Scale: Marginal cost per inference rounds to zero (no API fees)

The Hidden Costs:

Running the model on the device doesn't make the capital expenditure disappear. It moves it onto the customer. On-device AI quietly became a hardware refresh cycle.

Entry-level AI PCs with usable NPUs start around $1,100–$1,300. The practical floor for running local language models is 16GB of RAM; 32GB if you plan to do it regularly. Someone paid for that silicon, and it wasn't the software vendor.

That's a real business advantage, not a criticism. A vendor whose cost of goods sold drops to zero per user has margins a token-metered competitor cannot match. It's just worth naming the mechanism: embedded AI is a cost-shifting strategy at least as much as a privacy strategy.

More fundamentally: agents.

Small models (3B–7B parameters) have improved. A 3B model on an NPU is good enough for classification, extraction, transcription, summarization. For a forty-step agent loop with tool calls, shared state across sessions, and an audit trail, it isn't close. The teacher-student gap is documented: distilled models still trail on hard multi-step reasoning.

Add model churn. The best model available today will not be the best model in four months. A cloud provider ships that improvement Tuesday. Getting new weights onto a device fleet means an app update, or nothing at all if a meaningful share of the install base never updates. You're shipping a snapshot of state-of-the-art and hoping it ages well.


The Real Battlegrounds

This is playing out across industries right now.

Consumer AI: Tech giants race to embed NPUs into chips (Apple Neural Engine 38 TOPS, Qualcomm Snapdragon X Elite 45 TOPS, Intel Lunar Lake 40 TOPS). Will your phone run a local 7B model for everyday tasks while escalating complex reasoning to the cloud? Or is the cloud the default?

Autonomous Vehicles: Split-second delays are fatal. Core perception and immediate reaction must be embedded. But model training, fleet learning, and HD map updates remain centralized. This is already shipped; the war here is decided.

Healthcare: Continuous monitoring generates sensitive data. Embedded AI detects anomalies locally (atrial fibrillation, glucose spikes) instantly, without uploading biometrics. But complex diagnostics and population-level analytics require cloud aggregation.

Industrial IoT: Factories generate terabytes of sensor data. Sending raw vibration signatures and audio to the cloud is prohibitively expensive. Embedded AI allows sensors to detect acoustic signatures of failing bearings and send only a text alert.

Regulatory Jurisdictions: EU AI Act enforcement begins August 2026. Gartner expects 65% of governments to introduce technological sovereignty requirements by 2028. Health records and government material often cannot cross a border regardless of contract. Local inference shifts from optimization to legal requirement.


The War Nobody Is Talking About: Control of the Router

Look at how the systems that actually ship are built.

Apple's design is the clearest tell. A system orchestrator decides, request by request, whether something handles via on-device foundation models, or escalates to Private Cloud Compute.

Microsoft's Copilot+ does a version of the same thing.

Enterprise deployments converge on the same shape: a routing layer with explicit thresholds, sending 80% of routine traffic to cost-optimized models and reserving expensive tiers for high-stakes work. This cuts inference spend 60–80% with minimal quality loss. Add semantic caching; API call volume drops another 30–50%.

The question became: "Where does the model live?" Or more precisely: "Who controls the dispatcher?"

Every serious system is already hybrid.

The question is: Who owns the dispatcher?

Whoever owns the router decides:

  • Which model sees the request
  • What context travels with it
  • What gets logged and where
  • What happens when the local path fails
  • What the default is when nobody configured anything

Defaults decide markets. The model weights are becoming commodity parts sourced from whoever is cheapest this quarter. The routing and memory layer is where the lock-in actually lives.

That's the architecture war. Not cloud vs. device. Control of the thing that chooses between them.


Three Failure Modes Nobody Is Testing For

Silent Escalation

Plenty of products describe themselves as on-device and quietly reach for the network the moment a task gets hard. This isn't necessarily dishonest, but it makes the privacy claim unverifiable. If your compliance position rests on "this runs locally" and the orchestrator escalates under load, you have an incident nobody can see. There's no good audit trail yet, and few teams have written down their escalation conditions.

Version Skew

The cloud model changes weekly. The device model changes when the user accepts an OS update. Same prompt, same product, two different answers depending on which path served it and which build the user is on. Ask a QA lead how they test that matrix.

TOPS Theater

The number on the spec sheet describes peak throughput under ideal conditions and predicts real performance badly. A generation job that finishes in 10 seconds with vendor-optimized libraries can take 60 on generic APIs. Fragmentation across Qualcomm's QNN, Apple's CoreML, and MediaTek's NeuroPilot is resolving. Buying decisions made on TOPS alone are buying a badge.


Five Questions That Settle Most Cases

Skip the scoring matrix. These five questions determine architecture.

Does the task have a hard latency ceiling under 100ms? Local. Physics doesn't negotiate.

Does the data carry a jurisdiction tag? Local or sovereign. Classify the workload against risk categories first. Most compliance failures happen because nobody mapped workloads against risk before picking infrastructure.

Does it run continuously (per frame, per keystroke)? Local. Per-token pricing will destroy you at that volume regardless of how cheap tokens get.

Does it need long-horizon reasoning, extended tool chains, or shared state across sessions? Central. A 3B model is not going to bail you out. Demos that die in production are expensive.

Does every user need an identical answer? Central. You cannot guarantee consistency across a fragmented device fleet.


The Hybrid Future (That's Already Here)

The future is not cloud vs. device. It's hybrid cloud-edge continuum.

The winning architecture uses:

  • Intelligent Routing: OS-level orchestrator analyzes each request. Routine tasks (write a text, summarize an email) route to local NPU. Complex reasoning (legal brief from 3 PDFs) routes to cloud. User experiences unified interface, unaware of handoff.

  • Federated Learning: Instead of shipping raw data to the cloud, the cloud ships the current model to devices. Devices train locally on private data. Send only mathematical weight updates back. Cloud aggregates to improve global model. Privacy preserved. Capability continuous.

  • Tiered Swarm Intelligence: In robotics and IoT, embedded devices handle micro-decisions locally. Periodically sync with local edge servers (home hub, factory gateway). Those edge servers sync with centralized cloud for macro strategy and global updates.


What to Watch in 2026–2027

  • SLM Capabilities: Can 3–7B models close the gap with 70B+ cloud models for enterprise tasks?
  • Federated Learning at Scale: Will enterprises adopt privacy-preserving collaborative training?
  • Edge Hardware: Chiplet-based SoCs, RISC-V accelerators, neuromorphic chips will redefine on-device capability.
  • Routing Standards: Will verifiable routing emerge? Can users confirm where their request actually ran?
  • Regulatory Evolution: How will AI Acts and data sovereignty laws adapt to distributed architectures?

The Prediction

Within two years, the companies worth watching will not describe themselves as cloud-AI or edge-AI companies.

The label will have stopped meaning anything.

They'll compete on the quality of the escalation decision.

The ones with the best routers will appear to have better models than they actually do. That's a strange and slightly uncomfortable thing for labs spending nine figures on training runs, but it's the game being played.

Centralized AI will remain the "brain": the repository of global knowledge, engine for training, fallback for impossible tasks.

Embedded AI will be the "nervous system": reacting in real-time, protecting privacy, bringing intelligence to the physical world without network friction.

The architecture war is not about choosing sides.

It's about orchestrating both.

The side that masters the orchestration wins.


Wednesday, January 28, 2026

Is the era of the 'Best-of-Breed' giant over? Why the hyperscale oligarchy is coming for Salesforce, SAP, and the rest of the independent enterprises?

 

The answer is messier than either or. We’re heading toward a stratified market where both thrive, but in fundamentally different ways

Short answer: hyperscalers will dominate infrastructure and primitives, but they will not own the entire enterprise stack. There is still room for independent players, but only if they operate in very specific lanes and avoid pretending the old model still works.

Here’s an unsentimental breakdown:

1. What hyperscalers actually win (and why)

Hyperscalers (AWS, Azure, GCP) have structural advantages that compound:

A. Capital + utilization flywheel

  • Massive capex amortized across millions of customers
  • Better utilization → lower marginal cost → more investment
  • No independent vendor can match this curve

Result:
Compute, storage, networking, and AI infra become utilities.

B. Control of primitives

Hyperscalers own:

  • Cloud Infrastructure
    • Compute
    • Storage
    • Observability & Monitoring
  • Identity, Access, and Security Primitives
  • Data Warehousing & Core Analytics
  • Developer Platform & Runtime
  • AI runtimes

These are horizontal, non-negotiable layers.

Once primitives are owned, everything above is pressured.

D. Developer Platforms

Developers follow gravity and hyperscalers are a new shiny thing on the horizon

  • IDE and allied tools
  • Container orchestration
  • API Gateway
  • Low-code development will entice non-programmers into programming
    • Workflow orchestration
    • Ad-hoc Platform integration

E. Distribution power

  • One-click procurement
  • Integrated security and compliance
  • Enterprise trust at the CIO level

Result:
Anything that looks like “undifferentiated plumbing” gets absorbed.

2. Where hyperscalers fail (systemically)

Hyperscalers struggle with deep, opinionated domain-specific software – producing polished products.

Not accidentally but structurally.

Why:

  • They optimize for breadth, not depth
  • Products must serve incompatible customer needs
  • Internal incentives reward infra leverage, not domain mastery
  • Regulatory risk pushes them toward neutrality

This creates a ceiling on:

  • ERP nuance
  • Industry-specific workflows
  • Mission-critical business logic
  • High-stakes compliance interpretation

Hyperscalers ship platforms. Enterprises run businesses.

Example: AWS has likely launched over 10 database services, but enterprises still pay Snowflake billions because Snowflake understood data warehouse users’ workflows in ways that AWS didn’t bother to. The hyperscalers ship features; independent vendors ship solutions.

3. The survivable lanes for independent giants (Oracle, SAP, Salesforce, etc.)

Independent enterprise giants survive only where all three conditions hold:

1. Domain lock-in is real, not contractual

  • Understanding of local tax laws and continuous updation
  • Own the workflows that run actual businesses - payroll, financial close, procurement, HR processes, Sales cycle, etc.
  • Industry regulations (healthcare, utilities, banking, insurance, defense, etc.)

If the cost of being wrong is existential, not inconvenient, hyperscalers back off.

2. The product encodes institutional knowledge

Software that embodies:

  • Decades of edge cases
  • Legal interpretations
  • Audit logic
  • Process memory
  • Internal politics embodied as organizational structure

This is representation learning, not CRUD.

Enterprise software is deeply embedded in work culture and politics.

3. Switching costs are cognitive, not technical and/or financial

APIs are easy to rewrite.
Mental models are not.

If users think in your system, you’re defensible.

4. Enterprise Software vendors: obsolete or underestimated?

Enterprise Software vendors are not dead but narrowing.

Where Enterprise Software vendors still win

  • Regulated enterprise workloads
  • High-scale transactional systems
  • Enterprises that value predictability over innovation

Enterprise Software vendors’ strength is not agility; their invariant-ability.

Where Enterprise Software Vendors lose

  • Developer mindshare
  • AI-native workflows
  • Anything that smells like commodity infra

5. The new equilibrium (2025–2035)

The enterprise stack is splitting into three layers:

Layer 1: Utilities (hyperscalers)

  • Compute
  • Storage
  • Networking
  • AI runtimes
  • Security primitives

Winner-take-most.

Layer 2: Platforms (contested)

  • Data platforms
  • Integration
  • Analytics
  • Workflow engines

Hyperscalers pressure here but don’t fully own it.

Layer 3: Systems of Record & Judgment (independent giants)

  • ERP
  • Financials
  • HR
  • Industry-specific cores

This layer cannot move fast without breaking reality.

That’s Enterprise Software vendors’ natural habitat.

6. The real threat is not hyperscalers - it’s collapse via false grokking

Independent giants don’t die because hyperscalers kill them.

They die because they:

  • Mistake contracts for moats
  • Optimize sales over learning
  • Ship abstractions divorced from real workflows
  • Stop encoding new reality

Hyperscalers apply pressure.
False grokking pulls the trigger.

7. The absorption heuristic (use this yourself)

Ask four questions:

  1. Is correctness universal or contextual?
    Universal → hyperscaler
    Contextual → independent
  2. Does value increase with scale or judgment?
    Scale → hyperscaler
    Judgment → independent
  3. Is the buyer optimizing cost or risk?
    Cost → hyperscaler
    Risk → independent
  4. Can failure be rolled back safely?
    Yes → hyperscaler
    No → independent

If you answer “hyperscaler” to 3+ of these, absorption is inevitable.

8. Final verdict

The future of enterprise software is not owned by hyperscalers, but it is bound by them.
The independent giants that survive will be those with genuine moats the hyperscalers can’t easily replicate: deep vertical expertise (Veeva in pharma), workflow lock-in (ServiceNow for ITSM), or network effects (Salesforce’s AppExchange ecosystem). They’ll increasingly run on hyperscaler infrastructure while providing the opinionated layer on top.

What’s genuinely threatened is the middle - companies selling undifferentiated infrastructure or horizontal tools without strong moats. Why buy a standalone monitoring tool when each hyperscaler offers something 80% as good that’s deeply integrated?

The future probably looks like: hyperscalers own the infrastructure and broad horizontal services, independent giants own the high-value vertical workflows with real lock-in, and a healthy ecosystem of specialized vendors serves niches too small for hyperscalers to care about.

Tuesday, August 20, 2013

Cloud Computing: for my sophomore



Me: Do you know, what is cloud computing?

Yash: Are we doing some computing with clouds! :-)

Me: Nope.  Do you want to know about what is Cloud Computing?

Yash: Yes.

Me: Lets us make an analogy for Cloud computing.  OK, I have one.
I have few questions for you.  In which type of house, your friends John, Ram, Rita and Tom lives?

Yash: Means?

Me: Let me rephrase. Does your friends John, ram, Rita and Tom lives in independent single family houses or in apartment complex?

Yash: Each of these my friends live in independent single family houses.

Me: Ok. Does it also mean that each of your family is responsible for their water bill, electric bill, gas bill, maintenance of house, and front yard.

Yash: Yes. It is their house. It is their responsibility to maintain their houses.

Me: Understand. But is also means that they (or their parents) have to assign some minimum number of hours per week for upkeep of house.

Yash: Yes, they do.

Me: But in return of this sweat, they gate freedom to remodel their houses internally as well as externally. One import aspect we were missing – Huge money to purchase a house. Your friends had spent lot of money to purchase a house.

Yash: Yes. Provided they get permit from city.

Me: Sure. 

Me: Now assume all of your friends are living in a multi-story apartment complex on lease. In this case your friends (actually their parents) can offload some of the responsibilities of maintenance to apartment complex management like maintenance of green areas, shared lights, common walk ways, parking areas, building façade, etc. They need to worry only about consumables like electric bill, water bill, etc.

Yash: Yes.

Me: Also, in limited sense your friends can customize their houses – decoration etc. but cannot change basic structure of apartment.

Yash: Yes.

Me: Now, let us draw analogy. Independent houses are equivalent to computing environment where each enterprise (company) purchases computers, maintain them and get freedom to run any type of software program to run on those computers. This is traditional computing

Yash: Then, what is cloud computing?

Me: In case of multi-story apartment complex building, each tent is not owning any apartment but leasing it. Similarly in cloud computing environment, each tenant (company/enterprise) lease computers (computing power) and pays money on regular cycle. Tenant also pays money on consumables – like bandwidth used, number of users on computers, etc. So tenant does not pay any money to purchase of computers upfront but pays regularly for the resources consumed.  This is cloud computing.

Yash: So cloud computing essentially about leasing of computing power and paying money regularly instead of upfront.

Me: Yes, but not forget about offloading of day to day work to cloud provider (maintaining front yard, etc.) but limited flexibility to work within limits set by cloud computing provider.

Yash: This cool.

Me: Cloud computing provider ensures that one tenant does not encroach into another tenant’s house.

Yash: Yeah, it is must. No one likes that someone peak into their house.

Me: Depending upon level of flexibility to modify apartments, there are various types of cloud provider.

Yash: so what are various types of clod computing providers?

Me: Let us assume multi story apartment complex apartment’s management rents not the apartments but an area in building with defined boundaries. In this case tenants can design their own apartments.  These types of cloud computing providers are equivalent to Infrastructure as a Service (IaaS).

If multi-story apartment complex provider provides fully built apartments but allows sufficient flexibility to shift few walls here and there. These types of cloud providers are called Platform as a Service (PaaS).

In last case, fully built apartment is provided with only choice is left to lease of decoration. These types of cloud computing providers are called Software as a Service (SaaS).

Yash: I feel cloud computing can be summarized in one statement.

Me: which one?

Yash: As Spiderman said - With great power comes great responsibility.

Wednesday, August 3, 2011

Information Lifecycle for Data Security in Cloud

Security Guidance for Critical Areas of Focus in Cloud Computing V2.1, Chapter on Information Lifecycle Management assumes very simplistic view on Data Security Lifecycle.


This view hides subtle lifecycle stages. Typically, Information follows following lifecycle:


In my view CSA should revise ILM and so the recommendations.

Tuesday, August 2, 2011

Tuesday, July 12, 2011

Security threats posed by public cloud computing

Criminal Use of Cloud Computing: The ease of the registration process for services opens up services to abuse by spammers, malicious code authors, and other criminal elements.
Solution: Strengthen verification process of the registration.

Insecure Application Programming Interfaces: Cloud computing services management and interaction interfaces have very coarse authorization which opens up security hole.
Solution: More granular authorization and multifactor authentication process.

Malevolent Insiders: The threat posed by a malevolent insider is not unique to cloud computing. However, the threat is inflated by the convergence of IT services and customers under a single cloud environment, economic scale and a lack of visibility into the hiring standards and practices of cloud employees.
Solution: Enforce strict supply chain management security and comprehensive background check of cloud employees. Also setting up legal framework to tackle such malicious scenarios.

Shared Technology Vulnerabilities: Cloud computing delivers services by sharing infrastructure. This opens up the entire system to security breaches.
Solution: Defense-in-depth strategy that includes computer, storage, and network security enforcement and monitoring


Data Loss/Leakage: The enhanced risk of destruction or loss of data, whether accidental or intentional, due to increased number of actors and interactions.
Solution: Encrypt data in transit and implement strong data backup and retention strategies. Granular authorization strategy.


Service Disruption: Due to large number of customers on cloud, service disruption or reduced QoS may enhance impact to manifold.
Solution: In-depth replication of infrastructure across location.

Account, Service, and Traffic Hijacking: Account, service, and traffic hijacking, such as phishing, fraud, and exploitation of software vulnerabilities, pose risks to any computer system. With cloud these risks increases due to large number of interactions and actors.
Solution: use strong authentication techniques and unauthorized activity monitoring. Granular Authorization.

Unknown Risk Profile: Due to outsourcing nature of public clouds risk of losing track of the security ramifications of cloud deployments are very true. Security by obscurity may be low effort, but it can result in unknown exposures.
Solution: Maintain detailed information about who is sharing the cloud infrastructure, as well as network intrusion logs, redirection attempts, and other security logs. Deeper engagement with cloud computing provider.

Reference:
  1. https://cloudsecurityalliance.org/topthreats/csathreats.v1.0.pdf
  2. http://www.ists.dartmouth.edu/docs/HannaCloudComputingv2.pdf
  3. http://www.privatecloud.com/2011/03/16/5-overlooked-threats-to-cloud-computing
  4. http://en.wikipedia.org/wiki/Cloud_computing_security
  5. http://www.networkworld.com/news/2008/070208-cloud.html

Monday, April 18, 2011

Migration of Applications to Cloud


To migrate an application to cloud there are 4 possible options:

1. Rehost: Redeploy the application on HaaS (Hardware as a Service) such as Rackspace or IaaS (Infrstructure as a Service) such as EC2 virtual machines.

2. Refactor: Tweak existing application (usually web application) to run on IaaS platform (such as Amazon EC2.

3. Rebuild: Rewrite your application (usually web application) and then port it to cloud (utilize SaaS – Software as a Service such as Force.com, PaaS – Platform as a Service such as Windows Azure). You may also utilize Haas and/or IaaS.

4. Replace: It is clear slate approach. Maximum flexibility is available. One can choose to use SaaS (such as salesforce.com), Paas (Microsoft Azure, Google AppEngine, Force.com), and/or IaaS (such as Amazon EC2).

So which one are you doing?


Saturday, March 5, 2011

Book Review: Cloud Security: A Comprehensive Guide to Secure Cloud Computing


Book Review: Cloud Security: A Comprehensive Guide to Secure Cloud Computing by Ronald L. Krutz & Russell Dean Vines: Publisher- Wiley: ISBN- 13: 978-0470589878

As the name suggests this book covers security aspects related to Cloud. But book fails to add any substantial to the subject. Book is just collection of IT security concepts appended by cloud.

I do not recommend this book.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: Competing book are Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance By Tim Mather http://www.amazon.com/Cloud-Security-Privacy-Enterprise-Perspective/dp/0596802765 and Cloud Application Architectures: Building Applications and Infrastructure in the Cloud by George Reese http://www.amazon.com/Cloud-Application-Architectures-Applications-Infrastructure/dp/0596156367

One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Cloud-Security-Comprehensive-Secure-Computing/dp/0470589876/
2. Publisher -- Wiley http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470589876.html

Tuesday, February 1, 2011

Book Review: Cloud Security and Privacy

Book Review: Cloud Security and Privacy by Tim Mather, Subra Kumaraswamy, and Shahed Latif: Publisher- O'Reilly: ISBN- 13: 978-0596802769

Cloud Security and Privacy by is one of the first book which focuses on security, privacy and Audit need of Cloud Providers as well as consuming enterprises. As rightly stated by authors in Preface book is targeted to business personnel who are concerned with processes and methodologies rather than dirty technical details.

Book covers security aspects – Data and Network in detailed manner in initial chapters and then shifts to Privacy and Audit.

For such a vast subject certainly couples of hundred pages are not sufficient but book is a good and successful attempt in right direction.

In the end of book authors has provided sample/template of SAS 70 and SysTrust Reports. The book also covers Open Security Architecture for Cloud Computing in very short and concise manner.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: A competing book is Cloud Security - A Comprehensive Guide to Secure Cloud Computing by Ronald L. Krutz and Russell Dean Vines http://www.amazon.com/Cloud-Security-Comprehensive-Secure-Computing/dp/0470589876/


One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Cloud-Security-Privacy-Enterprise-Perspective/dp/0596802765
2. Publisher – O’Reilly http://oreilly.com/catalog/9780596802776/
3. Book webcast http://www.oreillynet.com/pub/e/1514
4. Book Review http://blogs.securiteam.com/index.php/archives/1400
5. One more review http://www.lockergnome.com/it/2009/09/23/cloud-security-and-privacy/
6. Review: http://www.velocityreviews.com/forums/t727353-review-cloud-security-and-privacy-tim-mather-subra-kumaraswamy-shahed-latif.html
7. Review: http://www.infoworld.com/d/security-central/gartner-seven-cloud-computing-security-risks-853
8. Review: https://www.informit.com/articles/article.aspx?p=1582936