Everyone is talking about AI agents. Most of the conversation is about coding assistants and chatbots. But the real structural shift is happening one layer below, in the infrastructure itself. Platform engineering, the discipline that was supposed to tame cloud complexity, is being fundamentally rewired by agentic AI. And the implications for how enterprises run their cloud infrastructure are bigger than most CIOs realize.

Let me explain what is actually happening on the ground.

The Day 1 story vs. the Day 2 reality

Platform engineering had its Day 1 moment around 2022-2023. The pitch was clean. Build an internal developer platform. Abstract away the Kubernetes complexity. Give developers a golden path. Backstage becomes your portal. Humanitec or Kratix handles orchestration behind the scenes. Terraform or Pulumi manages provisioning. Everyone is happy.

That was the theory. The Day 2 reality was messier.

Most platform teams ended up as bottlenecks instead of enablers. They built portals that developers half-used. They wrote Terraform modules that drifted within weeks. They created self-service workflows that still required a Slack message to actually work. The tooling was better than what came before, but the operational overhead did not disappear. It just moved.

Backstage, to its credit, captured roughly 89% market share among organizations that adopted an internal developer platform, according to recent industry analysis from platform engineering tooling surveys. But having a portal is not the same as having an intelligent platform. And that distinction matters now more than ever.

Enter the agents

The shift that happened in 2025 and accelerated into 2026 is not just “AI added to platform tools.” It is a change in the operating model itself. Platform engineering is moving from deterministic automation (if this, then that) to adaptive, context-aware systems that can reason about infrastructure state and act on it.

Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by 2026. That is up from less than 5% in 2025. According to LangChain’s State of Agent Engineering survey, 57% of respondents now have agents running in production environments. These are not chatbots answering questions about your Kubernetes cluster. These are systems that detect a misconfigured security group, evaluate the blast radius, and fix it before your on-call engineer wakes up.

The difference between traditional automation and agentic operations is worth spelling out. A traditional runbook says: “If CPU exceeds 80% for 5 minutes, scale up by 2 instances.” An agent says: “CPU is at 78% and rising, but this is a batch processing job that finishes in 12 minutes based on historical patterns. Do not scale. But do alert the team if the pattern deviates.” One follows rules. The other reasons about context.

This is not a subtle distinction. It changes what platform engineering is for.

What agents are actually doing in infrastructure today

Let me walk through the specific domains where agents are already changing how platform teams operate.

SRE and incident response

This is where agentic AI has the most mature production deployments. Agents now sit in the observability pipeline, correlating signals across metrics, logs, and traces. When an incident fires, the agent does not just page someone. It pulls the relevant runbook, checks recent deployments, correlates with similar past incidents, and drafts a root cause hypothesis before a human even opens their laptop.

The important nuance here is that the best implementations are not fully autonomous. They are what practitioners call “human-in-the-loop.” The agent does 80% of the diagnostic work. The SRE validates and approves the remediation. This is the pattern that is actually working in production, not the fully autonomous SRE that vendor pitches promise.

Security and compliance

This is where the stakes get interesting. The Cloud Security Alliance’s 2026 report highlights a sobering fact: non-human identities (service principals, secrets, autonomous agents) now outnumber human users by a ratio of 100 to 1. Every agent you deploy is a new identity with permissions that need governing.

But agents are also the answer to the compliance challenge they create. In regulated industries, multi-step agentic compliance systems can now monitor regulatory changes, identify impacted policies, update internal workflows, and create a complete audit chain. The old model was quarterly compliance reviews with spreadsheets. The new model is continuous compliance as code, enforced by agents that never take a day off.

Here is the catch, though. Only 24% of organizations have full visibility into which AI agents are communicating with each other. More than half of all deployed agents run without security oversight or logging. The industry is deploying agents faster than it is governing them. That gap is going to produce some ugly headlines before it gets fixed.

FinOps and cost optimization

This might be the domain where agents deliver the most immediate ROI. The numbers tell a clear story. According to Flexera’s 2025 State of the Cloud Report, 84% of companies struggle to manage cloud spend. 72% of global enterprises exceeded their cloud budget last fiscal year.

Agentic FinOps tools from vendors like CloudZero, Vantage, and Amnic are moving beyond dashboards and recommendations into autonomous action. They identify idle resources, rightsize instances, negotiate reserved capacity, and enforce cost policies without waiting for a human to review a weekly report. Vendor case studies from CloudZero, Vantage, and others consistently cite 25-30% cost reductions in organizations with mature agentic FinOps implementations. Take those numbers with the usual vendor-study caveats, but the directional signal is real.

But there is a new cost problem that nobody anticipated. Agentic Resource Exhaustion. A single AI agent caught in a reasoning loop can rack up thousands of dollars in compute costs in one afternoon. Analytics Week projected a collective $400 million in unbudgeted cloud spend across the Fortune 500 from runaway agents in 2025. That is an estimate, not an audit. But even if the real number is half that, it points to a governance gap that is growing faster than the tools to close it. The tools that save you money can also burn it if they are not properly governed.

Infrastructure provisioning and drift management

This is where the traditional platform engineering workflow gets the biggest upgrade. Instead of writing Terraform modules and hoping teams use them correctly, agents now watch for configuration drift in real time. They detect when a production environment has deviated from its declared state. They can either auto-remediate or create a pull request with the fix for human review.

The platforms that are winning here are the ones that treat agents as first-class citizens in the delivery pipeline. Not bolted on as an afterthought. Integrated into the same permission model, the same audit trail, the same policy engine that governs everything else.

Why this is different from the last automation wave

I want to address the skepticism head-on because it is reasonable. We have been through automation waves before. Configuration management (Chef, Puppet, Ansible). Infrastructure as code (Terraform, CloudFormation). GitOps (Argo, Flux). Each wave promised to eliminate operational toil. Each delivered real value but did not eliminate the need for skilled humans making judgment calls.

Agentic AI is different in one specific way. Previous automation tools encoded human decisions as rules. Agents can make novel decisions within defined boundaries. A Terraform module cannot decide that a particular deployment should be rolled back because the error rate pattern looks similar to an incident from three months ago. An agent can.

That does not mean agents replace platform engineers. It means platform engineers shift from writing automation to defining the boundaries, policies, and guardrails within which agents operate. The job becomes more about governance and less about execution. More about defining what “good” looks like and less about manually making things good.

What enterprise CIOs should actually do

Enough diagnosis. Here is what I would tell a CIO who wants to make their cloud infrastructure leverage agentic operations across SRE, security, compliance, and FinOps.

First, treat your internal developer platform as the agent runtime

Your IDP is no longer just a portal for developers to request resources. It is the runtime environment where agents operate. Every agent needs identity, permissions, audit logging, and policy boundaries. If your platform does not provide these as first-class capabilities, you are going to end up with shadow agents that nobody governs. The same way shadow IT happened with cloud, shadow AI agents will happen with infrastructure.

Build agent governance into your platform from day one. Not as a bolt-on after something goes wrong.

Second, start with FinOps agents because the ROI is immediate and measurable

You do not need to boil the ocean. FinOps is the highest-signal, lowest-risk starting point for agentic operations. The outcomes are measurable in dollars. The blast radius of a mistake is a slightly wrong-sized instance, not a security breach. And with 72% of enterprises overspending on cloud, the savings fund everything else you want to do.

Deploy agentic cost optimization on your non-production environments first. Measure. Then expand to production with human-in-the-loop approval for any action above a cost threshold you define.

Third, make security the guardrail, not the bottleneck

The 100-to-1 ratio of non-human to human identities is going to get worse before it gets better. Every agent you deploy expands your attack surface. But the answer is not to block agent adoption. The answer is to apply Zero Trust principles to agent identities the same way you applied them to human identities.

Every agent gets least-privilege access. Every agent action is logged. Every agent-to-agent communication is authenticated. If you cannot see what your agents are doing, you do not have an agent strategy. You have a liability.

Fourth, use agents for continuous compliance instead of periodic audits

If you are in a regulated industry (healthcare, financial services, government), compliance is your most expensive operational burden. It is also the most tedious. Agents are perfectly suited for the continuous monitoring, policy checking, and audit trail generation that compliance requires.

The shift is from “prove you were compliant during the audit window” to “prove you are compliant right now, continuously, with an immutable audit trail generated by agents.” This is not theoretical. Microsoft, IBM, and several startups are already shipping this capability. The regulated industries that adopt it first will have a structural cost advantage over those that keep running quarterly manual audits.

Fifth, invest in platform engineering talent that understands governance

The platform engineer of 2024 wrote Terraform modules and built CI/CD pipelines. The platform engineer of 2026 defines agent policies, designs guardrail architectures, and builds the control planes that agents operate within. This is a different skill set. It requires understanding of AI systems, policy as code, and distributed systems governance.

If your platform team still thinks their job is managing Kubernetes clusters, they are going to be surprised by how quickly agents make that work obsolete. Retrain now. Hire for governance thinking. The execution layer is being automated. The governance layer is where humans add value.

Sixth, do not wait for the “perfect” agent platform

The tooling is moving fast. Backstage is adding AI capabilities. Humanitec is integrating agentic workflows. Cloud providers are shipping agent runtimes natively (Azure’s Agentic Cloud Operations is a recent example). There is no single vendor that has the complete answer today.

Pick a domain. Start small. Run agents in production with human oversight. Learn what works in your environment. The organizations that will be ahead in 18 months are not the ones waiting for the market to consolidate. They are the ones building institutional knowledge about how agents behave in their specific infrastructure right now.

The bottom line

Platform engineering was always about making infrastructure self-service. Agents make it self-aware. That is a fundamental leap. But it only works if you govern the agents with the same rigor you govern the infrastructure they operate on.

The CIOs who get this right will run leaner, more secure, more compliant cloud operations at lower cost. The ones who either ignore agents or deploy them without governance will create a new category of operational risk that makes the old cloud sprawl problem look quaint.

The infrastructure already has a brain. The question is whether you are going to give it the right boundaries to operate within.

PS: This is not something I am writing based on theoretical understanding. I built a multi agent system handling all the functions mentioned here for my startups to manage their cloud infrastructure

Want Help?

Myth #1: Platform Engineering is Just Another Name for DevOps

This is a typical mix-up. While platform engineering and DevOps have similar goals, they’re not identical. DevOps is all about getting development and operations teams to work better together, while platform engineering goes a step further. It’s about creating a self-service platform that streamlines developer workflows and reduces workload.

Here’s how platform engineering builds on DevOps:

• A centralized development environment that’s standardized for everyone

• Self-service tools and automation to speed up processes

• Simplifying infrastructure complexities so developers can focus on coding

• Prioritizing developer productivity and experience

Myth #2: Platform Engineering Slows Everything Down

It’s the opposite! Platform engineering aims to speed development by offering ready-to-use environments, automated workflows, and self-service tools. This means developers spend less time setting things up and more time coding.

How platform engineering boosts speed:

• Faster environment setup

• Quick onboarding for new team members

• Smoother deployments

• Consistent environments across the board

Myth #3: You Need to Start from Scratch for Platform Engineering

Nope, you don’t have to throw everything out and start fresh. Platform engineering can be implemented gradually, building on what you already have.

How to ease into platform engineering:

• Start small with a minimum viable platform (MVP) for a limited group

• Expand as you get feedback from users

• Integrate your existing tools and processes

• Focus on high-impact areas first, then roll out to the rest

Myth #4: Platform Engineering is Just for Big Companies

While big companies can benefit, platform engineering isn’t only for them. Businesses of all sizes can use platform engineering to make their development processes more efficient.

Benefits for smaller businesses:

• Standardized development environments

• Better resource usage

• Stronger security and compliance

• Faster time-to-market for new features

Myth #5: Infrastructure Teams Become Obsolete with Platform Engineering

This is a big misunderstanding. Infrastructure teams are still vital in platform engineering. They design, implement, and maintain the underlying systems on which the platform depends.

Roles infrastructure teams still play:

• Building scalable and resilient infrastructure

• Ensuring security is baked in

• Optimizing performance and cost

• Solving complex infrastructure issues

Myth #6: All Cloud Services Are Part of Platform Engineering

It’s tempting to think that using cloud services automatically means you’re doing platform engineering, but that’s not quite right. The key is how these services are integrated into your platform and how they impact your overall developer experience.

Things to keep in mind with cloud services:

• Make sure each service fits into your platform strategy

• Ensure compliance and security requirements are met

• Simplify how developers use these services through abstraction layers

• Keep optimizing service usage for efficiency

Myth #7: Platform Engineering is a One-Time Setup

Platform engineering isn’t something you set up and forget about. It’s an ongoing process that needs regular maintenance, optimization, and tweaks to stay up-to-date with tech changes.

Ongoing platform improvements:

• Regular feedback from developers

• Monitoring performance and usage

• Staying updated on new tools and practices

• Adapting to changing needs and tech advancements

Myth #8: Platform Engineering Trades Security for Speed

People often worry that focusing on developer productivity might compromise security, but that’s not true. Platform engineering can improve security by enforcing consistent practices across all applications and environments.

How platform engineering boosts security:

• Centralized security policies

• Automated security scans and tests

• Standardized access controls and authentication

• Better visibility and auditing

Myth #9: Platform Engineering is All About Tools

Tools are part of it, but platform engineering is more than picking the right software. It’s about building an ecosystem that supports developers throughout the entire software lifecycle.

Other critical aspects of platform engineering:

• Setting up best practices

• Creating helpful documentation and knowledge bases

• Supporting and guiding development teams

• Promoting a culture of continuous improvement

Myth #10: Platform Engineering Is About Kubernetes

There seem to be some efforts by marketing teams in the Kubernetes community and some media/influencer community critics to paint Platform Engineering with the Kubernetes brush. This is plain FUD, and that is not the case. While Platform Engineering can be used using Kubernetes platforms, it is much more than just Kubernetes. It is about building a platform that provides developers with a self-service approach to deploying their applications and operators, a more automated approach to streamlining operations and ensuring security and governance. Whether the platform is built on Kubernetes or VMs, cloud-native services, or even Mainframe doesn't matter.

Platform Engineering is about:

• Standardizing environments

• Automating repetitive tasks

• Improving team collaboration

• Boosting system reliability and scalability

and NOT Kubernetes

Conclusion

Platform engineering holds great potential for cloud and IT pros to streamline operations, boost developer productivity, and improve system reliability. By debunking these myths, it’s easier to see the actual value of platform engineering and how to implement it effectively. It’s not a one-and-done solution, but careful planning and commitment can significantly impact your organization.

What Exactly Are Platform Engineering and CloudOps?

Before discussing the differences, let’s ensure we all understand what these terms mean.

Platform Engineering is all about building a self-service ecosystem for developers. Imagine a smooth, efficient development highway that lets your dev teams access the tools, infrastructure, and workflows they need—on their terms. It’s designed to streamline the development process, automate repetitive tasks, and ensure your developers aren’t bogged down with the nitty-gritty of infrastructure.

On the flip side, CloudOps (for those not aware, it is the short form for Cloud Operations 😛) is focused on the ongoing care and feeding of your cloud environment. Think of it as the "behind-the-scenes" team ensuring everything in the cloud runs smoothly. CloudOps is responsible for keeping the lights on—optimizing performance, managing costs, providing security, and ensuring your cloud services are always available when needed.

Breaking Down the Differences: Where Each Shines

1. Core Focus

Let’s start with the heart of the matter: the main focus of each discipline.

Platform Engineering is developer-centric. The goal is to simplify developers' lives by automating workflows, removing roadblocks, and providing them with a slick, efficient platform to deploy their code faster.

CloudOps, on the other hand, is all about keeping the cloud environment optimized and stable. It’s like a ship's engine room, ensuring everything runs smoothly without developers worrying about the infrastructure.

2. Who’s It For?

Platform Engineering is laser-focused on developers and internal engineering teams. It’s all about providing tools and frameworks to ship code faster and more reliably.

CloudOps speaks more to IT operations teams and higher-level business stakeholders who need to ensure the entire cloud environment functions without a hitch while controlling costs and meeting compliance standards.

3. Scope of Responsibilities

Platform Engineering involves designing and building internal developer platforms (IDPs) and creating self-service tools so developers can handle their own provisioning needs. It’s about enabling automation and consistency.

CloudOps is more about managing the day-to-day operations of your cloud infrastructure—monitoring, troubleshooting, scaling and optimizing the cloud so that it runs at its best 24/7.

4. Tech Stack: What Tools Do They Use?

While there’s some overlap, platform engineers and CloudOps teams often lean on different tools.

Platform Engineers use infrastructure-as-code (IaC) tools like Terraform, container orchestration tools like Kubernetes, and CI/CD pipelines.

CloudOps Teams focus more on cloud management platforms (think VMware or Morpheus), observability tools like Prometheus, and cloud-native security solutions.

Real-Life Scenarios: How Do They Tackle Problems Differently?

Sometimes, it’s easier to grasp the differences through examples. So, let’s examine two common IT challenges.

Example 1: Deploying an Application

Platform Engineering Approach: Your platform engineering team builds a one-click deployment portal. Developers can use it to launch applications without considering the underlying infrastructure. Pick the app type, choose the environment, and it’s up and running!

CloudOps Approach: On the CloudOps side, the team ensures that the cloud resources behind that application—compute, storage, and networking—are optimized, secure, and scalable. They also monitor performance closely and troubleshoot any issues.

Example 2: Managing Databases

Platform Engineering Approach: Platform engineers create a "database-as-a-service" option that lets developers spin up and manage databases without worrying about backups, scaling, or security patches. It’s all automated and straightforward.

CloudOps Approach: The CloudOps team ensures that databases in the cloud are configured correctly, performing optimally, and secured. They also handle disaster recovery and capacity planning.

When Should You Lean Into Platform Engineering?

So, when does platform engineering deliver the most value? Here are some prime scenarios:

You have a growing development team, and each developer spends more time managing infrastructure than writing code.

• Your organization juggles multiple development teams working on different projects, and you need consistency across the board.

• You’re aiming to reduce your time-to-market for new features and products.

In large organizations—think e-commerce giants or companies with tons of microservices—a well-built internal platform can help streamline development, reduce the learning curve, and speed everything from testing to deployment.

Where CloudOps Comes Into Play

On the other hand, CloudOps becomes essential when:

• You’ve got a sprawling cloud environment that needs constant attention.

• 24/7 monitoring, security, and compliance are mission-critical.

• You’re laser-focused on managing cloud costs and maximizing the efficiency of your infrastructure.

For companies in heavily regulated industries—like finance or healthcare—their CloudOps teams are the unsung heroes who ensure everything stays compliant, secure, and performant.

The Perfect Partnership: How Platform Engineering and CloudOps Work Together

Here’s the thing: these two aren’t enemies, far from it. Platform engineering and CloudOps often work hand in hand. A robust internal platform reduces the operational workload on CloudOps teams by automating many of the routine tasks developers used to rely on Ops teams for.

At the same time, insights from CloudOps—whether around performance bottlenecks or infrastructure costs—can help platform engineers improve and fine-tune their offerings. This symbiotic relationship can lead to a more efficient, cost-effective, and secure cloud environment.

Conclusion: Leveraging the Best of Both Worlds

Platform engineering and CloudOps might have different focuses, but they build a better, faster, and more reliable IT environment. By understanding their roles, you can make smarter decisions for your organization—whether you’re aiming to boost developer productivity or maintain a lean, secure cloud infrastructure.

In a rapidly evolving cloud landscape, knowing when to tap into the power of platform engineering and when to leverage the strengths of CloudOps can make all the difference in your organization’s success.

What’s the Deal with OKRs and KPIs?

OKRs: Setting Ambitious Goals

OKRs (Objectives and Key Results) are about setting clear, ambitious goals and then outlining measurable steps to achieve them. The objective is your big-picture goal, while the key results are specific, trackable outcomes that let you know you’re on the right path. OKRs are designed to push teams to aim higher and stay aligned with the company’s strategic priorities. They help focus on what matters, driving meaningful improvements across the board.

KPIs: Tracking Performance

KPIs (Key Performance Indicators) are your scorecard. They’re metrics that track how well your team or organization is performing over time. Unlike OKRs, which tend to be bold and aspirational, KPIs are usually straightforward and give you a clear picture of what's working and where there’s room for improvement. Think of KPIs as your team's compass, helping you stay on track toward your goals.

How OKRs and KPIs Supercharge Platform Engineering

Platform engineering teams are responsible for building and maintaining the tech infrastructure that supports software development and deployment. That means reliability, scalability, and security are always at the top of my mind. Using OKRs and KPIs gives these teams the structure to work more efficiently, improve code quality, and deliver projects on time.

Key OKRs Every Platform Engineering Team Should Set (Examples)

1. Boost Development Speed

• Objective: Speed up the development process.

  • Key Result 1: Increase sprint velocity from 42 to 60 points.

  • Key Result 2: Reduce bugs per feature from 1.7 to 1.

  • Key Result 3: Cut code review time by 30%.

2. Automate More Processes

• Objective: Improve deployment automation.

  • Key Result 1: Set up Continuous Integration (CI) and Continuous Deployment (CD) automation.

  • Key Result 2: Ensure all errors are logged in Sentry.

  • Key Result 3: Bring Travis's build times down to under 5 minutes.

3. Elevate Code Quality

• Objective: Maintain high coding standards.

  • Key Result 1: Ensure 100% of projects follow standardized style and linting rules.

  • Key Result 2: Achieve 100% pull request reviews and approvals.

  • Key Result 3: Implement a unified code style for all teams.

4. Tighten Security Compliance

• Objective: Achieve SOC 2 compliance.

  • Key Result 1: Fully document security issue resolution processes.

  • Key Result 2: Deliver security training for the entire team.

  • Key Result 3: Regularly perform security audits and penetration tests.

Key KPIs to Keep Your Eye On

1. Deployment Frequency

• What it measures: How often code is deployed to production.

• Why it matters: It shows how quickly the team delivers value to users.

2. Change Failure Rate

• What it measures: The percentage of code changes that cause issues in production.

• Why it matters: It helps gauge the reliability and stability of your deployments.

3. Time to Recover

• What it measures: How long it takes to recover from a system failure.

• Why it matters: It reflects how quickly the team can respond to incidents and maintain uptime.

4. Cycle Time

• What it measures: The time from starting work on a feature to when it’s deployed.

• Why it matters: It highlights how efficient the development process is and helps pinpoint bottlenecks.

5. Code Quality Metrics

• What it measures: Things like code coverage, linting errors, and static analysis results.

• Why it matters: It ensures the long-term maintainability and quality of the codebase.

Making OKRs and KPIs Work for Your Team

Align with Business Goals

OKRs and KPIs need to be aligned with the company's broader goals to have a real impact. This ensures that platform engineering efforts directly contribute to overall business success. Collaborating with stakeholders to set realistic but ambitious objectives is also key.

Review and Adapt Regularly

OKRs and KPIs aren’t “set it and forget it” tools. You must review them regularly to check progress and adjust as needed. This approach keeps your team agile and responsive to any shifts in business priorities. Regular check-ins also help everyone stay focused on the most critical tasks.

Foster a Culture of Continuous Improvement

OKRs and KPIs aren’t just about meeting targets—they’re about fostering a mindset of ongoing improvement. Encouraging the team to experiment with new ideas and push for innovation can lead to huge gains in productivity and efficiency over time.

Wrapping Up

OKRs and KPIs are game-changers for platform engineering teams. They provide a solid framework for setting goals and tracking progress, ensuring alignment with company objectives. Teams can consistently improve their processes and performance by focusing on areas like development speed, automation, code quality, and security. With regular reviews and a commitment to continuous improvement, these tools can help teams stay agile, productive, and ahead of the curve.

Ever since cloud computing took roots in the industry, Infrastructure as Code (IaC) has gained tremendous traction mainly aided by the programmatic interfaces for managing the cloud resources and recipe-based config management tools like Chef, Ansible, and others. This shift to treating infrastructure as code helped organizations embrace DevOps and streamline the consumption of infrastructure resources to meet the application needs. The modern-day avatar of using Git as the single source of truth for all of the infrastructure further increased the adoption of infrastructure as code inside the enterprises.

Benefits of Infrastructure as Code

Some of the benefits of Infrastructure as Code include:

• IaC increases agility as the infrastructure necessary for the applications can be provisioned by executing a script. In fact, offerings like Chef Habitat when used with Chef Infra and Chef Automate could help organizations streamline not only provisioning of the infrastructure needed to deploy their applications but also in ensuring seamless application delivery

• IaC ensures that there is consistency in infrastructure provisioning and, when used under the GitOps model, it also helps maintain a single source of truth for the underlying infrastructure. This also reduces risks as the changes in Human Resources will not have any major impact

• IaC helps an organization become more efficient in how infrastructure is procured and consumed (in terms of capacity planning and seamless scaling up and down based on application needs). This helps organizations cut down on resource wastage and save costs

As organizations modernize, they want to empower their developers to programmatically provision the necessary infrastructure for their applications and also right-size the underlying infrastructure. This is where the Pulumi platform comes in handy. They empower developers to provision and manage the underlying resources for their applications using the same programming language developers are familiar with. Whether it is Javascript, Typescript, Python, Go, or .NET, the Pulumi platform allows developers to use their favorite programming language on a familiar IDE to effectively manage the infrastructure.

Hashicorp’s Terraform has gained traction as a multi-cloud Infrastructure as Code platform. Along with other Hashicorp products like Vault, Consul, Nomad, Terraform has emerged as the foundation for automating infrastructure provisioning across multiple cloud providers. Terraform also has a vibrant community extending the platform further.

Beyond IaC, the time is ripe for Governance as Code

As IaC (or its modern avatar GitOps) becomes a norm in enterprises, the attention is being shifted from the programmatic provisioning of infrastructure to ensuring compliance to the organization’s policies in a programmatic way. This has lead to a new trend by name Governance as Code (GaC). With Governance as Code, organizations are making sure that the governance policies are properly enforced while also empowering the developers to innovate. With Governance as Code, central IT is moving from gatekeepers to enable rapid innovation by giving developers easy access to the underlying infrastructure while, also, programmatically keeping track of all the guardrails put in place to ensure governance. Governance as Code is the next evolution of Modern Enterprise IT. They become part of the core innovation team in today’s enterprise while also ensuring compliance with both governance policies as well as regulatory requirements.

Env0 is a startup that offers a seamless governance platform that makes it easy for IT departments to ensure cost management and policy compliance using the Governance as Code paradigm. The key advantage offered by the Env0 platform lies in bringing together cost management and policy enforcement into one platform, thereby, ensuring more holistic governance of the underlying infrastructure.

Pulumi Crossguard also allows programmatic control of policy compliance along with security and cost control. Pulumi allows developers to codify these compliance rules using the programing language they are comfortable with. Chef has taken its comprehensive infrastructure automation platform to enable Governance as Code with its Chef Compliance platform. Chef Compliance works across hybrid and multi-cloud environments, making it easy for central IT departments to ensure automated audit and remediation and, thereby, continuous governance.

Terraform has built the Sentinel policy as a code framework to work with its other products to ensure automatic compliance to governance. Sentinel is the foundation for multi-cloud Governance as Code for Hashicorp customers, giving them a more fine-grained policy control and multiple level enforcement.

While they don’t directly compete in the Infrastructure as Code and Governance as Code, it should be mentioned that CoreStack, a Seattle-based startup, provides a template-based infrastructure orchestration and governance platform.

Governance as Code is picking up steam and more enterprises are jumping into automated policy enforcement using code. While Terraform, Chef, and Red Hat Ansible lead the pack among the Infrastructure as Code players, Pulumi and Env0 are also competing hard with their own differentiation. Governance as code is the next frontier they are trying to target as multi-cloud adoption increase and enterprises demand a more seamless way to automatically ensure governance compliance without adding any friction for developers. Governance as Code is the next step in the enterprise IT modernization strategy.

We expect all the Governance as Code platforms to embrace machine learning to ensure continuous governance. CoreStack has taken the necessary steps to bring in machine learning to gain the necessary insights for remediation. From my conversations with Chef, Pulumi, and Env0, I expect them to use machine learning for ensuring policy compliance. While I haven’t spoken to Hashicorp recently, my conversations with the product team during 2019 Hashiconf gave me the impression that they will also bring machine learning into their platform.

Governance as Code is The Next Step For Enterprise IT Transformation was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

A very happy new year to readers of this blog and supporters of Rishidot Research. As we enter a new decade with maturity in cloud services offered by various cloud providers and newer services focussed on IoT and AI becoming a hot topic, it is time to talk about what we expect to see this year in the technology space. This first blog post of the year is dedicated to discussing the trends we expect to see in the industry.

Move over Day 1 hype, Day 2 reality matters

After all the hype about new cloud services, Kubernetes, Serverless, etc, people are slowly moving over from the hype surrounding Day 1 technologies to the harsh realities of Day 2. After buying up multiple cloud services from a single cloud provider, they are wondering where is the integration between their services to make their life on Day 2 better. More developers are waking up to the reality that a flashy new service on Day 1 could easily turn into an operations nightmare on Day 2. The realization by developers that the flashy new Serverless service requires managing the underlying storage and other DevOps tasks makes them wonder what about Day 2.

2020 will be the year when the industry conversations will shift towards Day 2 issues. Cloud providers are seeing this. Whether the tone of AWS re:invent in 2019 or the announcements like Azure Arc, the Day 2 realities are taken seriously by the cloud providers. Other larger companies like IBM-Red Hat and VMware will increase their focus on Day 2 issues. Expect to see more startups hitting the newswire talking about Day 2 issues than a shiny new toy technology. It is time people wake up from the illusion that cloud services imply NoOps and focus on Day 2. Cloud services change the operations model by bringing in abstractions and giving hooks at a higher level than traditional IT. As organizations embrace cloud services, they should understand the various hooks that are provided by these services (either through APIs or SDKs) and use intelligent automation (automation fed by predictive analytics or AIOps in the marketing lingo) to optimize the delivery pipeline.

Developers wake up to Day 2 too

Even developers are waking up to Day 2 issues. Whether it is about realizing the limitations of database technologies built for traditional web applications or managing the complexity associated with Microservices architecture, developers are also moving beyond the Day 1 marketing hype to Day 2 reality. They are realizing that traditional databases used for web applications are too limited for their Microservices applications and the streaming technologies of the last decade add unnecessary complexity. They are looking for SQL databases built ground up with cloud-native technologies or streaming APIs that provide them the flexibility to bring together various data sources without additional resource or operations overhead.

Edge Computing and IoT extends the IT perimeter making it more fluid

In Dec of 2009, I wrote a position paper talking about a move from a client-service-like model of cloud to a more P2P model. We are nowhere closer to have a fluid computing model with a P2P architecture but the innovations in Edge Computing and IoT in the last few years are moving us closer to such a reality. Edge computing and IoT with centralized cloud services in the mixture is slowly nudging us in the path towards a more fluid computing architecture. 2020 is going to further advance this trend. Even though 2020 may not bring some of the innovations listed below to reality, it will launch us towards a decade where we will end up with a more fluid computing architecture. We are going to see:

• More autonomous management solutions that will make it easy to tackle fluid computing architectures

• A marriage between predictive analytics and automation becoming deeper in solving some of the operational problems large organizations face

• Increased intelligent automation bringing in scale using smaller operations teams than what we have today in IT organizations

• A realization that security and privacy first approach to IoT is the necessary foundation of fluid computing architectures

Developers are going to build more disposable applications and such a shift towards smaller distributed applications is critical to take advantage of the fluid compute infrastructure underneath. At the end of this decade, pushing data to the cloud for processing will be considered a legacy approach. Disposable applications will be the mantra for Developers from 2020 onwards and it will grow loud as the decade progresses.

And, Google Cloud will be there by the end of the decade. Watch out for the new episode of Modern Enterprise Podcast where I discuss this topic with a Xoogler.

If you thought cloud computing made the last decade interesting, wait for AI, Edge, and IoT making this decade more interesting as the adoption of newer technologies throws up some unique challenges requiring innovative solutions. A very happy 2020 to all of you.

2020 Storylines In Cloud, IoT and beyond was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever since cloud computing came into prominence in the late 2000s, there is more focus on the cost savings in the industry and customer conversations. Cloud costs are a much more complex discussion than a simple statement on cost savings. We have heard tons of stories from organizations that save money on the cloud but we have also heard stories about burgeoning costs and move back to On-Premises data centers. In this post, we want to tackle cloud costs and help users consider the nuances that are in play.

Stating the obvious

There are few things about cloud costs that are obvious and one cannot argue against them.

• Cloud changes the financial model from Capex to OPEX. You don’t have to invest heavily in capital expenses building out the infrastructure anymore. Also, don’t confuse this with paying upfront for Reserved Instances, a confusion that still exists for users moving to the cloud from hosting services. Reserved instances differ from the long-term up-front payments to hosting companies. Reserved Instances not only offer considerable cost savings but there is also a market to offload unused Reserved instance capacity

• The very fact that you pay for what you use will ensure that you don’t pay for what you don’t use. But there is a nuance here which we will highlight later. Just the fact that it is pay per use will make cloud costs lower than legacy hosting costs

• At lower scales, cloud costs are cheaper than both On-Premises and hosting service providers. There could be some edge cases where the costs are higher but this is mostly true

But many of you are overpaying in the cloud

Most organizations are overpaying the cloud providers than what they should actually be paying. This is due to various factors such as

• Not having an elastic infrastructure that takes advantage of various compute or storage types that are available from the cloud providers

• Not having control over resource wastage

• Wrong sizing

Let us now discuss these two factors a little deeper

• Cloud providers rely on the On-Demand pricing for their margins and most organizations pay On-Demand prices as they manage the fluctuating needs for their workloads. Even though many are using Reserved and Spot Instances at the infrastructure level, cloud providers still benefit from the On-Demand pricing of most of their cloud services. Even if you are convinced that Reserved Instances and Spot Instances are giving you enough cost savings, it is only with compute service. The other cloud services like Containers, Serverless, DevOps services, etc. are still priced comparable to On-Demand pricing. Clearly, customers are overpaying for their cloud services

• Resources wastage is another unnecessary customer spend on the cloud. Resource wastage happens on many fronts. If we just consider the compute service, we will see unused virtual machines kept on all the time. Some resources will not be needed to run on the weekends but they are not shut down because the operational cost of handling this shutdown and restart process is more than what organizations pay for the resource. Many organizations procure more Reserved instance capacity than they will ever need during the life of these Reserved instances. There are many other ways resources are unused or underutilized. Customers pay the cloud provider even though they don’t use these resources

• Usually, users over-provision the resource sizes either as a precaution or due to lack of knowledge about their workload needs. Many times, we see resources running at less than half the capacity. Such underutilized resources are contributing to cloud waste

Be smart about cloud costs

Predictive Analytics and automation will play a critical role in optimizing cloud costs. By tapping into predictive analytics and automation, users can tap into Spot Instances, Reserved Instances, and On-Demand Instances to save a considerable amount of money while also meeting the SLA needs of enterprises. The same thing can be done about cloud storage too. Predictive analytics and automation can store data in the low-cost storage disks while not in use and match higher-priced disks based on performance needs. Even container workloads can be run on elastic infrastructure that taps into spot instances. For example, SpotInst Elastigroup is a platform to use all types of instances and save 90% on cloud costs. You can do it for containers using SpotInst Ocean (equivalent to AWS Fargate). Similarly, Qubole offers savings for big data and machine learning workloads using spot instances

To rein in cloud waste, either in the form of runaway instances or unused or under-used instances, it is critical to have a good management and monitoring platform to cut down on the resource waste. Whether it is resource shutdown or right-sizing, predictive analytics and automation can help organizations save on cloud costs. Cloud Governance platforms like CoreStack or VMware’s CloudHealth are good examples of platforms that can help cut down on cloud waste. Univa NavOps offers similar cost optimization tools for HPC workloads.

Conclusion

Whether or not you accept it, most organizations are overspending on the cloud. It is time to wake up and realize that you can have considerable savings in the cloud but you need to have the right strategy and use the right set of tools to save costs without incurring additional overhead. Keep in mind that you are not obligated to improve the cloud providers’ margins but you need to save costs for your organization by not overpaying for the cloud services.

Yes, You Are Overpaying For Cloud Services was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

Even though some pundits push back against multi-cloud, it is happening. This is not just some speculation by a clueless analyst or hallucination of a multi-cloud marketing person but the real data on the ground points towards multi-cloud. While it is easy to dismiss the use of multi-cloud as long as it is not their problem, it is not easy to manage multi-cloud. In the past month, I have been speaking to many enterprise decision-makers on their organization’s multi-cloud strategy. The following are some key points I repeatedly heard from them. Of the total number of decision-makers I spoke with ( disclaimer: It is not a scientific survey and the sample size is in lower double digits. The sample could have a bias because we sought people to discuss multi-cloud usage), most of the organizations are using multi-cloud. Of the remaining who were not using, they said they expect their organization to adopt multi-cloud in the future.

Learnings from multi-cloud usage

Most organizations end up using multi-cloud. Only a handful told us they strategically embraced multi-cloud. Most organizations started off with one cloud provider but they ended up being multi-cloud because:

• They offered one cloud provider to their developers, and they figured out that there are developers/teams that use a different cloud provider for their needs (shadow IT). They have embraced multi-cloud as a strategy to make sure that they can allow their developers to use any cloud service they want from any cloud provider. They feel that embracing multi-cloud as a strategy can allow them to set up policies and governance.

• They acquired a company and figured out that the cost of re-architecting the application to migrate to another cloud provider is not worth compared to the costs they will incur managing multiple cloud providers. One CIO said, “if I have to migrate a new acquisition to AWS (their cloud provider), I will have to fire the existing talent and hire new talent.”

• There were a few who said that they have embraced multi-cloud strategy by design. They said that having a strategy helped them to force architectural decisions they feel will give them the flexibility to innovate fast

Almost everyone I spoke with said that they didn’t go multi-cloud to save costs but to have the flexibility to innovate rapidly and keep developer satisfaction. In fact, I even got a chance to speak with some developers in an organization that has embraced multi-cloud. These developers spanned multiple teams/divisions and they feel that they are happy that they could use any cloud service they find suitable for their applications instead of making compromises to use the service offered by a single cloud provider (eg: a specific database service).

Most of the decision-makers I spoke to point out the following challenges:

• Providing a cloud provider like user experience for developers

• Managing the security as the perimeter now spans multiple providers. At least half of them are thinking of using a third-party IAM solution

• Everyone agrees that governance is difficult with multi-cloud but they are confident that they can manage it as governance tools have evolved in the past few years

From my conversations, it is evident that most organizations will have multi-cloud. Even if they go with a strategy of using a single cloud provider, the shadow IT will use other providers for their experimentation. Sooner than later, most organizations will confront the “cloud shadow IT” and will move towards multi-cloud. It is definitely not by design but by the needs of their developers and business users.

Multi-Cloud Happens But Not Necessarily By Design was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is a constant drumbeat about multi-cloud among the pundits, especially the ones who are fans of AWS. Most of them are dismissive of multi-cloud and talk about using one cloud provider (and it is mostly AWS for them). While it might serve as good chatter on social media, it is not going to help the end-users who care about solving problems that matter to their organizations. In this post, we plan to highlight why an argument against multi-cloud is too simplistic and how it is based on FUD.

FUD Against Multi-Cloud

Let us first highlight some arguments made against multi-cloud and explain why it is either FUD or doesn’t make any sense from the enterprise customers' point of view.

• Multi-cloud is not cheaper than single cloud: There was never a cost argument for multi-cloud except under certain scenarios. If you are approaching multi-cloud with just cost savings in mind, you may be in for a surprise. While the constant price competition between cloud providers may present you an opportunity to move workloads from one cloud provider to another, it can end up being more expensive. Similarly, using a multi-cloud strategy for use cases like HA will be very expensive. Everyone knows that running different components of an application on different clouds makes no financial or user experience sense. However, if you have the right automation in place or use a platform like the one offered by SpotInst that takes advantage of spot instances, you could definitely save money with the multi-cloud strategy. By default, multi-cloud is not just about cost savings.

• Multi-cloud is not more agile: This is another misconception or FUD. The use of multi-cloud comes from the need for flexibility (more about this later) than about agility. Multi-cloud is as agile as using a single cloud provider. With the right DevOps pipeline in place, it doesn’t matter whether you are using one cloud provider or more. The bottleneck could be in having the right talent or training for all the cloud providers but it is no different from training the employees on a single cloud. With the right automation in place and by avoiding the use cases that are not suitable for multi-cloud (eg: HA across different cloud providers), organizations can have the same agility they get with a single cloud provider.

• Multi-Cloud is not about depth: One of the arguments made against multi-cloud is that while using multiple cloud providers, developers are forced into using a common set of features. Partly, this is due to the past approach towards multi-cloud where a common library was used which took into account the least common set of features and gave an easy interface for developers to use. That approach failed because these libraries offered breadth but not depth. Today’s multi-cloud approach is different and, it is about taking advantage of unique services offered by different cloud providers than HA/Portability in mind. Developers are encouraged to use the right set of services needed for their applications and, in many organizations, this automatically leads to multi-cloud usage.

So, what is multi-cloud then?

Multi-cloud is about giving developers the flexibility to use any cloud service from any cloud provider for their applications. If my app demands Google’s AutoML, I should be able to use Google Cloud Platform provided I can take the data to the platform. If I have a new app with limited traffic, I may not want to run a database instance continuously either on a container or from a database service. A better way is to take advantage of a Serverless database. I may want to run that app on AWS even if my organization has other apps running on Azure. The key is to give the developers flexibility to use the right service than force them to make compromises on their apps to use the service offered by a specific cloud provider. Multi-cloud provides organizations a lever to empower their developers than constrain them with services from a single cloud provider. Multi-cloud is about flexibility without compromising on agility. Under certain circumstances and with the right tools, it can also save costs.

Ha, the multi-cloud is the magic pill?

At the same time, people should be aware of the real challenges (as opposed to the FUD in the media) with using multi-cloud. I am listing the critical ones but there are other challenges too.

• Multi-cloud can create the same problem with shadow IT if the service provisioning is not managed through a central authority but without compromising on user experience. This implies allowing developers to provision directly from the cloud provider on-demand or by providing an API that offers the same cloud provider like user experience

• Each cloud provider has different IAM options and, without managing them properly, organizations will end up with a huge governance problem

• If security in the public cloud is a problem for any organization, managing security across multiple cloud providers is a bigger problem. Without the right guardrails in place, this will become unmanageable fast

So, what do I do?

At Rishidot Research, we always tell CIOs that it is about giving flexibility to the developers without having to manage complexities. Whether you are a startup or a large organization making a foray into the cloud, start with a single cloud provider giving them the flexibility to use any service they want. If your developers feel that the services are too constraining for their application needs or you acquire a company that is using another cloud provider, allow them to use multiple cloud providers but have the right set of tools to manage the challenges that come with multi-cloud.

Busting The Multi-Cloud Drumbeat was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the biggest complaints against Functions as a Service (FaaS) like AWS Lambda, Google Cloud Functions, Azure Functions, IBM Functions, etc. is the problem of cold start. Cold start is about the delay between the execution of a function after someone invokes it. To be more specific, it is about the function at the time of invocation. In the background, FaaS uses containers to encapsulate and execute the functions. When a user invokes a function, FaaS keeps the container running for a certain time period after the execution of the function (warm) and if another request comes in before the shutdown, the request is served instantaneously. Cold start is about the time it takes to bring up a new container instance when there are no warm containers available for the request.

Most FaaS providers have 1–3 second cold starts and this impacts certain types of applications where this latency will have a dramatic impact. The cold start varies by the cloud provider and programming languages. Though it is almost a year old, this benchmark study shows cold start latency impact in various FaaS offerings.

In the 2018 Serverless Community survey, developers quote cold start latency as the third biggest concern. Rishidot Research has been talking to various enterprise customers about their Serverless adoption plans and we hear a lot about cold starts. At Rishidot Research, we feel that the concerns regarding cold start are overblown and we will talk about our rationale in this blog post.

The cold start problem is overblown for various reasons. First, and foremost, users should understand that while FaaS is maturing fast, it is not suitable for many workloads. They can meet the needs of event-driven functions but, for most other workloads, containers are a better fit. It is also important for users to understand that the low cost of the service is because FaaS providers need not run infrastructure in anticipation of use and they can shut down unused resources in a more fine-grained way. They then translate the cost savings because of these resource efficiencies into cost savings for customers. Users make this choice while picking FaaS as their application platform. IBM is using stem cell containers to cut down on the cold starts and platforms likeOpenFaaS give users control over how they want to use the resources. In fact, users could avoid the cold start problem by embracing serverless container platforms like SpotInst Ocean which gives considerable savings by taking advantage of Spot Instances. Most cloud providers will find out a way to solve this problem eventually but the concerns regarding cold starts are overblown.

We strongly recommend that users consider the continuum of services from containers to serverless containers to services like Google Cloud Run to FaaS. Taking a binary approach of Kubernetes vs FaaS is shortsighted and it will not help your organization use the resources optimally.

On The Serverless Cold Start Problem was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever since Serverless gained traction among developers with the early success of AWS Lambda, there is quite some confusion on how these platforms fit application needs. In the last two years, there was a proliferation of the next generation of Serverless platforms, going beyond the event-driven use cases to support complex enterprise applications. In the early days, AWS Lambda and other Serverless offerings imposed severe constraints on developers, limiting the application architectures supported by these platforms. However, the newer Serverless platforms are versatile, giving developers more choice with limited constraints on the application architectures. In this blog post, we will discuss the evolution of Serverless platforms and highlight the enterprise-grade features offered by newer platforms.

The Serverless market has been steadily growing, driven by agility needs and a shift in how enterprise applications are architected. Microservices and Serverless Functions help developers churn out features at the speed of business, rather than the traditional approach of refreshing applications on longer timeframes. In fact, the market research firm Markets and Markets predicts the FaaS market size to grow to more than 7 Billion in 2021, driven mainly by the shift from DevOps to Serverless Computing. Based on our conversations with enterprise developers and decision-makers, we expect the growth in the Serverless market to be fueled by the large-scale adoption of Serverless computing in the enterprise. Enterprises see value in Serverless, but their application needs require a more flexible platform that does not constrain developers unlike the Serverless offerings from major cloud providers.

Serverless — Going beyond DevOps in the Enterprise

The needs of enterprise developers are different from that of individual developers coding for their itch or even startup developers. Enterprise applications go beyond just event-driven functions to complex stateful applications. Any Serverless platform should not only support stateful applications but also give developers the necessary flexibility to handle the complex needs of typical enterprise applications.

Stateful and Big Data Applications

Even though the early iterations of Serverless platforms focused on supporting stateless applications, newer platforms support application state. These platforms not only support databases, object storage, and in-memory data grids out of the box but also ensure that the data storage systems scale seamlessly with usage as well as simultaneous invocations of the functions with scale. These next-gen Serverless platforms provide more flexibility and impose minimal constraints because they are built on top of open-source platforms like Apache OpenWhisk and Kubernetes. By taking advantage of the container engine supported by these platforms, newer Serverless platforms provide more enterprise-grade features. These platforms go beyond supporting simple functions to microservices, big data workloads, and other complex stateful applications.

Better Developer experience

Early Serverless platforms imposed significant constraints on developers, and while some of these constraints are being lifted, others remain. For example, take the upper limit on the execution time of a function. AWS Lambda has a limit of 15 minutes per function invocation, and if the job takes more than 15 minutes, you need to either invoke containers from AWS Fargate or Virtual Machines from AWS EC2. There are other ways to run long-running jobs like calling Lambda functions asynchronous by taking advantage of context objects. Enterprise developers don’t want such constraints or workarounds and they want a more seamless experience. The newer breed of enterprise-grade Serverless offerings support log running jobs out of the box and they can scale seamlessly without additional overhead. Some platforms provide support for containers, vastly increasing support for libraries and other dependencies needed by the enterprise applications. Even though serverless is supposed to provide a better developer abstraction, the early Serverless platforms required developers to have operations knowledge to put together the backend; data storage, and handle scale. Today’s enterprise-grade Serverless platforms provide a more out-of-the-box experience for building enterprise applications without the additional DevOps knowledge.

Enterprise-Grade Security

While all Serverless platforms provide the security needed to secure the applications, enterprise security needs require easy integration with their existing security tools. Beyond integrating with Identity and Access Management tools, the Serverless platforms should integrate with other security and auditing tools like container vulnerability scanning tools, network security tools, and auditing tools. Enterprises cannot easily use general-purpose Serverless offerings from the large cloud providers to integrate with their existing security toolchain to ensure security and governance. Such integration requires customization of the Serverless platforms which is not supported by the ones offered by major cloud providers.

Application architecture flexibility

Unlike the early Serverless platforms, the newer enterprise-grade platforms support many different applications from event-driven applications to microservices to web applications and big data workloads; This is possible because these platforms are built on top of industry-tested container platforms, giving developers the flexibility to deploy complex architectures without compromising on the ease of use. These newer platforms also provide a canvas that can be used by developers to define the workflows so that they can develop on local machines and test on the cloud seamlessly. This also removes some of the operational and DevOps complexities associated with 1st generation Serverless platforms. With tight integration to data stores and other backend services needed for enterprise applications, modern Serverless platforms support a wide range of application architectures.

On-Premises and Multi-Cloud support

Today’s modern enterprises require applications to provide the best user experience, not just an acceptable user experience. In order to deliver the best user experience, developers should be empowered to use the right set of dependency services rather than compromising by using services supported by a single cloud provider. Moreover, many enterprises have existing applications running on their own data centers. Many enterprises, they need the flexibility to run their Serverless applications on-premises as well as in the cloud. While the early Serverless platforms were cloud-based and constrained only to the specific cloud providers, modern Serverless platforms deliver both the flexibility of a cloud-based service across multiple cloud providers and deployability on-premises with little operational overhead. The modern FaaS platforms enable both hybrid cloud and multi-cloud architectures.

Conclusion

Serverless changes how applications are developed and deployed to meet the challenges of global business. Modern enterprises will not (and cannot) compromise on agility and seamless user experience. Adding constraints to developers may not be optimal in the enterprise context. As FaaS became attractive among developers, the need for enterprise-centric features became more apparent. Modern Serverless platforms like Nimbella are built for enterprise needs and offer a better and more integrated developer experience. In future posts, we will delve deeper into how these modern platforms are helping enterprise developers deliver at the speed of business.

Originally posted at Nimbella blog

Not All Serverless Platforms Are Created Equal was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

THE Enterprise IT market is tough for startups. We recently saw Redis Labs moving to a more restrictive license to fend off competition from the cloud providers. This difficulty results from both open source and public cloud services. Look at Docker and its troubles monetizing their platform, despite its huge success with developers. Just a few years back, there was a huge ecosystem behind Docker and I don’t know what happened to some startups in that ecosystem. The same is happening in the Kubernetes ecosystem today. Despite marketing spin by many startups in the Kubernetes ecosystem, they are struggling for monetization.

Why enterprise software companies struggle?

Open source and public cloud services are completely reshaping the enterprise IT ecosystem. Whether you are a large traditional vendor or a startup, these two forces are disrupting these vendors or severely impacting their monetization. Look at Oracle and see the market pressure on their business due to both open source and public clouds. On one side, open-source software is severely impacting their margins and, on the other side, public cloud services are undercutting their database business. The same story applies to startups and they are getting hammered by both open source and cloud services.

When we talk about open source, the impact on startup is not just from a vendor in a particular market segment releasing the software under an open-source license but, also, from technology companies in areas not related to enterprise IT. For example, open-source software released by companies like Netflix, Capital One, Expedia, etc. disrupted many startups in the DevOps space. These companies released the tools developed for their internal use into open-source software and fostered a community around it. There is no way startups could monetize under these circumstances.

Now think of the Kubernetes ecosystem. According to certain estimates and from our own analysis of public data, AWS is making more money than any other vendor in the ecosystem. Apart from AWS, both Google and Microsoft are positioned to take advantage of the Kubernetes ecosystem. Among the legacy vendors and those focussed on on-premises deployments, Red Hat has established itself as a leader in the on-premises Kubernetes deployments and Pivotal has the potential to gain traction with PKS. Then there are few other vendors like Docker and Mesosphere that can take advantage of the ecosystem to compete against Red Hat and Pivotal. But, it will be tough for many other startups in the Kubernetes ecosystem to fend off both the impact of open source and the market share of AWS (and other cloud providers).

Open source and public cloud services are completely disrupting the infrastructure and platform market along with some layers above the platform. Large vendors struggle to effectively monetize with open source because of the onslaught of AWS and startups are facing a double whammy with both open source and public cloud providers severely restricting what is available in the market share pie.

How to compete in a world dominated by OSS and public cloud providers?

There are two strategies startups can use to compete in today’s enterprise IT market.

• Innovate on the business model that runs along with the cloud providers’ business model. SpotInst is a good example of this strategy. SpotInst takes advantage of spot instances provided by various cloud providers and offering an abstracted service on top. Spot instances will not go away as long as the need for maintaining excess capacity exists for the hyperscale providers (almost forever). As long as a startup feeds off its excess capacity without directly impacting the cloud providers’ revenue model, the cloud providers will not care about the business opportunity. SpotInst is well prepared to take advantage of the excess capacity from multiple cloud vendors. Serverless compute also fits well with this consumption model, providing SpotInst with another opportunity to monetize spot instances. Startups need to innovate on the business models that silently works along with hyperscale providers without attracting them into space

• If business model innovation described above is not an option, startups should focus on building a model that takes advantage of the following two factors

• Multi-cloud is key. None of the hyperscale providers care about multi-cloud. Even though Google and Microsoft talk about multi-cloud today, it is a marketing message focussed on stopping all the workloads from going to AWS. Offering a higher-order service that can help enterprises use multi-cloud seamlessly is still a good opportunity

• Open source is another important factor to consider. Open source is not a viable path for many startups, especially VC-funded startups. First, monetizing on open source is tough because the underlying economics is one of abundance and few startups have the appetite or wherewithal to effectively compete in this market dynamic. But, without open-source, another open-source project could easily disrupt the startup. However, for startups to compete effectively with open source, they need to be multi-cloud and, probably, use a license that protects them from the market muscle of public cloud providers. An even more effective strategy is to standardize one of the AWS services but make it available as a multi-cloud offering. Minio, an object storage platform with S3 compatible API, is a good example of this approach. Such an approach will keep AWS at a distance and the startup can take advantage of industry standardization with AWS API

Competing in today’s enterprise IT market is tough. Startups need a multi-cloud offering and an anchor in the open-source community to compete effectively in the market.

The Dilemma Of Enterprise IT Vendors was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently Redis Labs announced Commons Clause License that caused quite a bit of uproar among the open source communities. One reason for the uproar was a marketing spin implying it is an open-source license. Even though the license applies only for their proprietary add-ons than the core Redis itself, the pushback is real. But, in their quest to push back against Commons Clause, there is little discussion on the reason behind this move by Redis Labs. Even though I do not agree with Redis Labs’ move, I have been vocal about the underlying cause. I call this Robin Hoodization of OSS and I will use a question-and-answer format to address the issues surrounding this.

What is your take on Commons Clause License?

It is a self-serving license, and it is not open source. I recommend you to read Steve O’ Grady’s excellent take on the topic. I agree with him mostly except for his take on the value of the code (which I will explain later in this post). It is a self-serving move by Redis Labs to fend off AWS.

What do you mean by Robin Hoodization of OSS?

I am borrowing the term Robin Hood from the English folklore where he strips money from the rich and gives it to the poor. I am using the term loosely and I am not making an exact mapping with the story which itself has several forms. I am using the term to imply that value is taken away (albeit legally) from one group and delivered to another group that gains from the derived value. By Robin Hoodization of OSS, I mean that hyperscale cloud providers (specifically AWS and more about it later) take the value from OSS but their contribution back to OSS is not commensurate with the value they derive from OSS. This is not just restricted to hyperscale cloud providers. Every technology company, including pure-play open-source companies, takes more value from OSS than their contribution back to the project. So, it is actually about value derivation per unit of contribution.

Of the three major hyperscale cloud providers, I am more critical of AWS because they have derived maximum value from OSS but contributed little compared to the value they derived. Google with Kubernetes, Tensorflow, and other OSS contributions and Microsoft with .NET, Kubernetes, and others have given back much more than AWS. Prove me wrong on this with real data but I have dug through AWS contribution in Github and they have either contributed OSS tools that will onboard people to their cloud service or Linux kernel patches useful for them. The only exception is the Gluon AI framework they announced with Microsoft.

However, if you look at how much value AWS is deriving from open source, it is several orders of magnitude more than their contribution (code or monetary support as with CNCF membership). Imagine a scenario (circa 2006–07) when AWS was getting started. Do you think they could have convinced Microsoft across the lake to offer flexible licenses for OS and Virtualization so they can offer cloud services? The OSS license is the reason we saw innovation happening in how we consumed compute resources. OSS gave the world cloud computing. Even recently, they are the biggest financial benefactor from Kubernetes (at least based on the public information we can derive) but their contribution back to the project is minimal. They not only lag other hyperscale cloud providers but many of the startups in the Kubernetes community too.

But, hey, developers are benefitting from AWS services and that’s what matters

The usual refrain from AWS advocates is that developers are benefitting from AWS’s use of OSS. Absolutely, that is the truth. AWS’s success lies in operationalizing software into an easily consumable service. They do a good job of it and that is why they are a (financially) successful cloud provider. It still doesn’t take away the fact they benefit from OSS without contributing back. They make money from operationalizing the software and it is theirs. They need to contribute code back to the OSS project and it is their responsibility.

Software code does not matter

I disagree that code has no value in today’s world. Yes, services are the way we will consume software but code is the underlying foundation of any service. The innovation happens in the underlying code along with the efficiency in operationalizing it. You cannot discount the value of the underlying code and attribute innovation to higher efficiencies. If your innovation focus is only on the business model and supply chain innovation, you may discount the value of code but most of the real innovation happens (and will happen) through code, and hence both the code and the OSS license matters for innovation (Think of the difference between Amazon’s idea of innovation and Google’s).

That is why Commons Clause

No, I disagree. They do not need Commons Clause to stop Robin Hoodization of OSS. One can stop such abuse with a right license from existing open-source licenses. Commons Clause is about getting a slice of profits from other vendors who use the software governed by the license. It is not at all in the spirit of open source. It is about sharing the wealth and not stopping abuse. If AWS or any other vendor adds value to open-source software, they have every right to benefit entirely from the value creation. The demand should be about contribution for the value (complying with the spirit of OSS) AWS or any other vendor realize from OSS than sharing the wealth from their business.

If I put it bluntly in political terms, Commons Clause is about socialism while some hyperscale providers’ approach borders around predatory capitalism. Yes, this comparison is not an accurate mapping but I am using it to explain the gulf between the problem (lack of contribution by some hyperscale providers) and the proposed solution (Commons Clause)

I am confused now. You say no to sharing wealth but also demand AWS to contribute. How else can they contribute?

Good question. When I talk about AWS contributing back incommensurate with the value they derive from OSS, I am only talking about contribution in the spirit of OSS. I don’t want AWS to contribute the money they get by providing a service with open-source software. I, rather, want them to contribute back code (that is the OSS spirit) to the community. Code contribution is the only currency that fits well with the OSS spirit. The monetary contribution is secondary and it may even go against the OSS spirit or OSS philosophy. The only way to fix the problem with hyperscale provides abusing OSS is to put enough community and market pressure (instead of putting top AWS folks on the conference stage because they paid their membership dues, put the AWS engineer who contributes a lot to OSS on the stage). Talk to journalists and customers to make them understand the OSS spirit and how it leads to continuous innovation and how it prevents monopoly from developing in the market. The only fix to the AWS problem is getting AWS to contribute more code to the projects they consume. Code contribution is the only currency that matters. Period.

Robin Hoodization of OSS and Commons Clause License was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

Multi-Cloud is fast becoming the norm in the enterprise. At Rishidot Research, we estimate that most organizations will use more than one cloud provider by 2020. A recent survey by RightScale of 1,000 IT professionals found 85% of enterprises now have a multi-cloud strategy, up from 82% in 2016. Multi-cloud is fast becoming the de facto deployment strategy among the enterprise decision-makers because of many advantages including:

• Cost and this becomes a big factor with a continuous reduction in the costs of various cloud services. With Multi-cloud and spot instances, users can realize larger cost savings

• The flexibility to choose the right services for the applications. In fact, enterprise IT should give this advantage to their developers by embracing multi-cloud or, else, they will end up facing the shadow IT problem. The developers will use a cloud provider whose services suit their application needs by going directly with the cloud provider

• Performance advantages, compliance needs, and edge computing also drive multi-cloud advantages

Multi-cloud governance is key

The multi-cloud advantage comes with an overhead which, when left unchecked, could result in IT failures. In this post, we want to highlight the factors that could contribute to failed multi-cloud projects. Most of these factors come under the umbrella of governance.

• The biggest advantage of multi-cloud is that it has cost flexibility but it is also the biggest risk. Left unmanaged, VM or cloud services sprawl could be a good problem. Resource wastage will add up to make multi-cloud very expensive

• Security is another issue where it is critical for enterprise IT ensure that they apply all security patches across instances in multiple cloud providers, access management is enforced in accordance with the organization’s policies and data privacy and security is ensured. As workloads move across cloud providers, data security becomes as important as infrastructure and application security

Governance is a big factor in successful multi-cloud implementation. The other big challenge with multi-cloud is the operational complexity. With so many services across many cloud providers, operational challenges can be overwhelming.

Recommendations

The challenges with multi-cloud should not deter your organization from embracing it as a part of your IT strategy. Rather, focus on mitigating these challenges. We recommend a tool that provides a single pane of glass to implement governance in conformance with their policies. We also recommend higher levels of automation to mitigate some operational complexities. Tools like Chef, Ansible, Puppet, and other automation-focused tools can help ensure automation across multiple cloud providers.

We strongly believe AIOps is critical in ensuring success in the multi-cloud world. We are already seeing many products that use machine learning and AI in the realm of observability and some in governance. We expect this trend to accelerate in the coming years. As multi-cloud becomes the de facto deployment strategy. AIOps will be a critical component of the multi-cloud world.

Multi-Cloud Governance: Hard Problem But Essential For Success was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we launched a new product called Rishidot Research Decision Makers Guide. Rishidot Research’s Decision Makers’ Guides are research briefs made to help decision-makers gain a quick understanding of a technology or compare two or more technologies. The guides are designed to help modern enterprise decision-makers quickly understand the pros and cons of specific technologies or scenarios to plan their strategy. Unlike Rishidot Research’s long-form reports, these guides are purposed to inform decision-makers about the strengths and weaknesses of specific technologies. This understanding will empower them and their teams to make objective strategic decisions without depending on vendor marketing materials. When decision-makers want a deep dive into specific technologies or need to evaluate various scenarios as part of their planning process, Rishidot Research can aid that process through consulting engagements.

As subscribers to Modern Enterprise Newsletter, you will get notified every time we release this guide or other research reports. Our first guide is about Nomad Vs Kubernetes. You can download the PDF version of the guide at our Github repo.