devopsy.kinsta.cloud

Tag: cloud deployment

Microsoft Azure Skills Plugin Gives AI Coding Agents a Playbook for Cloud Deployment

AI coding agents are good at writing code. They’re not good at knowing which Azure service fits your workload, which SKU makes sense, what needs to be validated before deployment, or which permissions and quotas matter. That gap between writing code and getting it to production is exactly what Microsoft’s new Azure Skills Plugin is designed to close.

Announced March 9 by Chris Harris on the All Things Azure blog, the plugin bundles 19+ curated Azure skills, the Azure MCP Server with over 200 tools across 40+ services, and the Foundry MCP Server for AI model workflows — all in a single install. It works across GitHub Copilot in VS Code, Copilot CLI, Claude Code, and other tools that support the agent plugin and skills patterns.

The timing isn’t accidental. This is one of the first major plugins built on the VS Code agent plugin architecture that shipped in VS Code 1.110 just days earlier. And it demonstrates what that architecture looks like when a cloud platform vendor fills it with real operational knowledge.

Three Layers in One Install

The plugin packages three distinct capabilities that work together.

Skills are the decision layer. The 19+ Azure skills package expert knowledge as reusable workflows, decision trees, and guardrails. They don’t just list tools — they tell the agent when to use them, in what order, and what to avoid. Key skills include azure-prepare (analyzes your project and generates infrastructure code, Dockerfiles, and deployment config), azure-validate (runs pre-flight checks before deployment), azure-deploy (orchestrates the actual deployment pipeline), azure-cost-optimization (finds waste and produces savings recommendations), and azure-diagnostics (troubleshoots failures with logs, metrics, and KQL queries). Additional skills cover compute, observability, compliance, storage, migration, RBAC, and messaging.

The Azure MCP Server is the execution layer. It provides over 200 structured tools across 40+ Azure services — listing resources, checking prices, querying logs, running diagnostics, provisioning infrastructure, and driving deployment workflows. The agent doesn’t just advise. It acts.

The Foundry MCP Server is the AI specialist. It connects the agent to Microsoft Foundry for model deployment, agent management, and model catalog workflows. For teams building AI-powered applications on Azure, this layer handles model and agent scenarios that generic cloud guidance can’t.

The design principle: skills guide, MCP executes, the plugin packages both so the guidance and execution layers stay aligned.

What Changes for Developers

The before-and-after comparison in the announcement is telling. Ask an agent without the plugin to deploy a Python Flask API to Azure, and you get a generic tutorial — maybe some az commands, maybe a docs link. Ask the same agent with the plugin, and it activates azure-prepare, azure-validate, and azure-deploy in sequence, producing a Dockerfile, infrastructure files, deployment config, validation output, and real MCP tool calls against Azure.

Same prompt. The difference is that the agent has a playbook and the tools to follow it, rather than generating advice.

Skills load on demand — the agent reads their name and description to decide which are relevant, then loads only what’s needed. You can install the full skill set without cluttering every prompt. They’re plain text, version-controlled, and auditable. One team can package hard-won Azure knowledge once and reuse it across projects and engineers.

According to Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group, “Microsoft is packaging institutional cloud knowledge as versioned, executable skills that agents consume automatically, collapsing the gap between writing code and deploying it to production. Skills encode the decision logic, MCP tools execute against real resources, and the plugin architecture keeps guidance and execution aligned. That’s agent orchestration with guardrails, beyond just automation with documentation.”

Ashley continues, “The tribal knowledge that once lived in a senior engineer’s head becomes an installable, reviewable artifact. Teams that figure out how to package their own expertise in this model will accelerate deployment cycles. Those waiting for agents to infer that knowledge from generic training will keep getting generic answers.”

Why This Matters for DevOps

The Azure Skills Plugin is a concrete example of a pattern that’s becoming central to how DevOps teams work with AI agents. We’ve covered agent plugins as infrastructure, IronCurtain’s policy-as-code model, Google ADK’s integration ecosystem, and Copilot’s Jira bridge. The Azure Skills Plugin sits at the intersection of all of them: Packaged expertise, delivered through a plugin architecture, with both guidance and execution capabilities built in.

For platform engineering teams, the plugin represents a model worth watching. Instead of writing documentation that developers may or may not read, you package the knowledge as skills that agents consume automatically. The agent doesn’t need to read your Confluence page about which Azure services to use. It activates the skill that encodes that decision tree.

That’s a shift in how institutional knowledge gets distributed. Documentation explains. Skills execute. The tribal knowledge that used to live in a senior engineer’s head — which SKU to pick, which pre-flight checks to run, which cost traps to avoid — becomes a versioned, reviewable, installable package.

The plugin also ships guardrails alongside capabilities. Skills include validation steps, permission checks, and cost awareness. The agent operates against real Azure resources, so curated skills, trusted plugin sources, tool approvals, and least-privilege access all matter. This isn’t simulated cloud work. It’s real provisioning, real deployment, real cost implications.

Install the Azure Skills Plugin at aka.ms/azure-plugin. One install, three layers, and a much different answer to “deploy my app to Azure.”

March 11, 2026
Why You Need a Multi-Cloud and Multi-Region Deployment Strategy

As I began writing this article, I encountered some technical challenges in my attempt to provision three cloud providers in three separate regions to simulate multi-cloud and multi-region deployments.

I couldn’t get one of the regions to behave as I expected when provisioning the environment. As it turned out, the region (and by association, cloud) was down due to a cut undersea cable, and it would take several weeks until the outage was mitigated.

Fortunately, there are plenty of clouds in the sky to choose from, but this experience emphasized the importance of multi-cloud redundancy, especially in a production environment.

This article examines the benefits of adopting a multi-region and multi-cloud deployment strategy for better resiliency, regulatory compliance and optimal user experience.

Resilient Reasons to Choose Multi-Cloud and Multi-Region Architectures

The first reason to choose a multi-cloud or multi-region environment is for data resilience. When our data is in a single region or on a single cluster, there is a good chance that you will experience data failure. You need a mitigation strategy if you want to keep the data lights on 24/7. These strategies fall into two buckets: Multi-region and multi-cloud.

We first need to define the differences between multi-cloud and multi-region. The architectures are simply the implementation details of how we plan for one versus the other. However, depending on your database provider, those details can represent a significant time investment, which we’ll look at later.

Multi-Region

With multi-region, we typically deploy our applications to globally distributed regions. However, regional deploys are subjected to physical faults. Inclement weather, political unrest, acts of foreign or domestic terrorism and other physical variables have all led to regional outages in the past.

Regardless of the cloud, the regions are exposed to similar physical faults. Instead of losing your data, we can switch to another region to handle the workload. Even though much as our industry hates latency, it is always preferred over loss.

Deploying to multiple regions allows for failover handling. If the Sydney region goes down, Singapore may still be online. It would be a globally bad day if the same physical faults simultaneously impacted Frankfurt, Sydney and Seattle, for example.

Multi-Cloud

Physical faults are only one of the problems that public and private clouds encounter. User error, poorly configured networks and even banal errors can have substantial consequences that impact entire clouds, either from the provider or the user.

In these circumstances, regional failover won’t help you. An expired certificate, accidental deletion or disabling the wrong port will take you offline, regardless of whether you’re in Seattle or Sydney. If that happens, someone somewhere is most definitely awake and is likely very unhappy.

Choosing a multi-cloud configuration protects you from these types of faults so that if Google, for example, has interruptions, AWS is still online—or IBM, Deutsche Telekom, OVH or Hetzner.

The Correct Answer: Deploy Both!

Multi-region is a go-to method to mitigate against mostly physical faults. Multi-node clusters in each of those regions handle general data corruption or failures on a more granular level.

Multi-cloud is a go-to method to mitigate configuration or software-level faults, which are not that uncommon.

The correct answer is to blend the two, working within operational cost constraints and general survivable requirements from regulatory and business objective use cases. For example, I do want access to my heart-rate data from two years ago, but the order of browsing across Amazon shopping is less important.

Regulatory Reasons for Multi-Region Architecture

Apart from data resiliency, most companies serving a global market are subject to a number of geopolitical influences, as well. Most users will be familiar with the GDPR regulations ensuring European data stays on European soil. Further regulations require the ability for government oversight to request data at will from service providers, which requires its own set of reasonable isolation from those not in those jurisdictions.

Using a multi-region database provider allows companies to ship single binaries of software without creating isolated applications for different countries—a practice that was the norm not too many years ago.

Performant Reasons for Multi-Region Architecture

Co-locating data and access provides the optimal pathway for getting a user’s data to the end destination. It goes without saying, but the less copper your data has to traverse, the faster the experience will be for your users. Retention and regulation aside, in many cases, you need to mitigate latency caused by region separation.

It’s not just the individual user’s data. Imagine a sales enablement platform where an account executive needs to manage all of APAC or EMEA. If these accounts are optimally stored for reads on geo boundaries, you can remove seconds of delay between page navigations for your account manager. We all know how much account executives like to click!

Choosing a DB Provider With Multi-Region and Multi-Cloud

At this point, you should be convinced of the benefits of multi-region and multi-cloud deployments. But at what cost? Creating replication, failover, logging and synchronization mechanisms is a big, expensive ask. Even with deployment tooling, coordinating all the pieces for multi-region deploys is still a significant operational lift, let alone multi-cloud, where variables in APIs come into play.

Choosing a single provider that deploys across regions and clouds means you get to benefit from their collective experience while reducing a significant burden.

Having a database provider offer one-click multi-region deploys is the way to go, but you still need to handle the data access layer. The role-based access, federation and other settings that enable your developers still need to be distributed along with the underlying data sources.

You need a provider that makes it simple to deploy the same configuration for horizontally scaled instances, leaving you to pick your geo router of choice to distribute the request to the nearest point of presence.

Closing

Multi-cloud and multi-region deployments provide significant redundancy, scalability and flexibility. Not only does this enable faster access times and improved reliability, but also provides the flexibility required to adapt to disruptions or unpredictable increases in traffic.

Deploying multi-cloud and multi-region is no small feat–but the peace of mind and security it provides make it worth the effort.

June 1, 2023
Reducing Cloud Infrastructure Complexity
The impact of the cloud and its role in mainstream IT is undeniable. According to IDC, global cloud IT infrastructure spending is projected to reach US$92 billion (SG$126 billion) in 2023. Notably, cloud spending is exceeding the spending on non-cloud IT infrastructure, underscoring the influence of the cloud in modern IT deployments.

Fast Forward to Cloud

Why are enterprises and startups alike turning to the cloud? At the forefront is its sheer scalability and how it enables rapid time-to-market. Instead of waiting weeks or months for hardware systems to arrive, cloud infrastructure can be launched and put to work within minutes. Moreover, cloud-based resources such as managed cloud databases reduce the complexity of deploying new services, thereby enabling smaller teams of developers to do more.

New cloud-centric methodologies have also emerged with the maturity of the cloud. For instance, infrastructure as code (IaC) makes it possible to automate the management and provisioning of an entire technology stack with configuration, replacing error-prone manual deployments. Among others, IaC also supports CI/CD deployments and disaster recovery plans with the ability to easily deploy test environments or even the entire infrastructure stack.

Cloud proficiency varies across organizations, however. For most, the journey to the cloud began with low-hanging, lift-and-shift migrations or relatively straightforward cloud implementations, such as a website or an online shop. Other enterprises might have started with cloud-native applications within their organization as part of an effort toward rapid experimentation.

Like most IT projects, cloud deployments are probably implemented with the technologies of the day and by developers and architects who prefer quick results over efficiency. Although this laissez-faire approach yields quick results, it can be inefficient and culminate in systems that are hard to maintain. The situation is worsened over time as additional services or new features are built on top of the initial design.

Cloud-amplified complexity

It’s no surprise that deploying well-designed cloud systems is getting more difficult. As organizations look to leverage the cloud in more advanced ways, some are forced to re-architect existing systems, preventing them from realizing the benefits of reduced time-to-market.

Other factors that increase the complexity of the cloud include the following:
- Rapid evolution of the cloud: The breakneck growth of the public cloud has birthed new cloud technologies and strategies that did not exist before. For instance, serverless architecture and containers entered the mainstream only in recent years.
- Deep expertise matters more than ever: While there are more qualified cloud engineers today, there remains a dearth of experts given the sheer demand for them. A team of “been there, done that” experts can enable an organization to move ahead much faster.
- Larger attack surface: As more systems and workloads are moved to the cloud, IT teams are under increasing pressure to keep up with the dramatically increased attack surface. From catching configuration drift to patching software libraries that are used within the technology stack, having team members with the right mix of experience is invaluable.
Modern public cloud platforms offer nuanced, broad capabilities that continue to evolve at a rapid pace. Leveraging the right features can bring forth immense rewards not just in terms of cost, but also offer greater reliability and maintainability. Conversely, ignoring good design can lead to cloud sprawl and ballooning cloud costs, tangling the organizations in a web of spiraling complexity that hinders new cloud implementations.

A Better Cloud Infrastructure Design

Ultimately, the cloud journey does not end with the successful implementation or migration of individual systems to the cloud. The breakneck pace of development in the cloud means that best practices and optimal strategies are constantly evolving, making it highly challenging for in-house IT to pin down. Moreover, as new cloud capabilities become available, the onus is on enterprises to leverage the right features for the best cloud solution possible, which necessitates constant optimization.

Getting this right requires the involvement of experts who are well-versed with the latest cloud practices and automation strategies that can be gleaned only from experience, a deep understanding of the latest cloud methodologies, and the evolving capabilities of each public cloud platform. As these cloud experts focus on core designs, in-house IT can keep doing what they do best: keeping users happy and improving productivity and user experience.

For instance, Indonesia’s streaming service provider Genflix wanted to migrate its video-on-demand (VOD) workflow to Amazon Web Services (AWS). With a library of 10,000 hours of VOD content, efficiency and seamless processing were vital. CloudCover helped Genflix architect an end-to-end media workflow with a serverless computing design in a span of just three months.

Whether you are rolling out a new cloud-native system from scratch or looking to improve an existing cloud deployment, a review of your cloud deployment might be in order. This isn’t as daunting as it seems and can be initiated through a simple discovery and analysis phase.

This article is part of a series of articles from sponsors of KubeCon + CloudNativeCon 2020 North America
October 20, 2020
Considering Hybrid Cloud? Focus on the Why

So much of business—and life in general—comes down to semantics. We articulate goals and measure success using a variety of terms. Some serve to clarify; others confuse. Consider the term “hybrid cloud”—a Google search yields 5.96 million results. So, yes, hybrid cloud is a hot topic, but what exactly do we mean by it?

The (current) accepted definition of a hybrid cloud is any compute/storage environment using a combination of third-party and private (on-premises) cloud resources. Yet, this definition is somewhat misleading. It is very likely that your company has already been using third-party platforms and services—a hybrid cloud model—for many years.

Hybrid cloud is less about the “what” than the “why.” The question isn’t, “Should I move to a hybrid cloud?” (You already have.) The better question is, “Am I using that model to my best advantage?”

On-Premises vs. Public Cloud Capacity—Strategic vs. Non-Strategic Applications

The number of diverse applications, systems and business requirements IT must support is growing exponentially. In response, more tools are being made available to help. Public cloud, private cloud, edge computing and PaaS/SaaS models all give CIOs and IT managers options for handling new, more complex demands. Each has its advantages and disadvantages. The challenge for IT is developing the best mix of available tools to ensure business goals are being met in the most efficient way possible.

Source: Veritas Inc., global IT consulting

The first step in developing a hybrid cloud strategy is understanding which functions, applications and requirements are strategic to the business. More specifically, which operations are core to the organization’s purpose or must remain in-house (i.e., private cloud) due to security, regulatory or other governance issues? These are the high-priority operations for which it makes sense to prepare highly efficient, on-premises resources and staff to support your cloud initiatives.

In deciding whether an application or function is strategic, it is essential to separate the IT output from the hardware/software producing it. For example, you may have significant dollars invested in a legacy mainframe with the software and analytics to run mission-critical applications. But the real question is: How strategically important is the output? If it is strategic, then, by all means, keep it in-house. If not, it may make more sense to migrate applications to public cloud equivalents and use the vacated space for something more strategic.

On the other hand, non-strategic functions represent an opportunity to increase operational efficiency and cost-savings. For example, using a SaaS or PaaS provider to host your CRM platform in a public data center provides more space, staff and resources to support the higher-priority business.

Maximum Productivity and Value, Minimum Space

While the functional purpose of a hybrid cloud strategy is to determine which applications remain on-site and which can go, the overall goal is improving the value and delivery of strategic and non-strategic functions. Often, the full weight of your decisions is not realized until later, when you must address the need for additional data center space.

The cost, time and manpower needed to plan, design, build and maintain a new facility represent some of the most substantial investments a company can make. By strategically optimizing your on-premises cloud capacity—and offloading non-strategic functions to the cloud—you increase available white space. This buys you more time to figure out when you need more space and whether your current optimized facility remains competitive with other options. Additionally, your on-premises equipment (because of its strategic importance) becomes far more valuable and productive.

In some cases, organizations will discover that, once they take their non-strategic operations to the cloud, the cost of running key applications on-site does not warrant maintaining their existing data center. At this point, it may make more sense to sell the data center and lease back the space needed or partner with a multi-tenant data center.

Potential Pitfalls

Of course, moving applications and business functions off-premises also has its downside. Select well. Re-locating core capabilities to the cloud compromises control and can erode your competitive edge. And, while public cloud may appear to be an especially good option for smaller organizations, it can quickly become cost-prohibitive as you scale. Should you decide to transition from a public cloud, re-locating your data to a new environment is often complex and costly, restricting future options. This is not to say that public cloud options are intrinsically high-risk; they’re not. It does, however, emphasize the need to view every decision within the context of your long-term strategy while weighing the cost and agility entailed by public cloud options.

Business First

The bottom line is that developing a hybrid cloud strategy is first a business decision. When done well, it is based on the vision and trajectory of the company and implemented using the best combination of all available options—XaaS partners, private cloud, public cloud, hosted providers, captive resources and edge computing.

Before you start trying to figure out details such as architecture and security, you’ve got to nail the strategy. For more common non-strategic applications, cloud-based deployments offer a degree of flexibility and cost-efficiency the data center can’t match. On the flip side, when it comes to supporting mission-critical applications, nothing beats the on-site control and dedicated resources of your data center.

There are certainly pros and cons when deciding what stays and what goes. Your challenge is figuring out which is which—and why. Choose well.

August 10, 2020
Identifying Cloud Migraines Before Cloud Migration: 6 Tips

Migrating to the cloud isn’t as simple as signing up for a SaaS application or deploying applications on a cloud infrastructure or platform; there are other factors at play. And the move to cloud shows no signs of slowing, with Gartner predicting the worldwide public cloud services market to grow 17.3 percent in 2019. Getting cloud deployments right is more critical than ever.

As organizations shift more to the cloud, it means they will increasingly rely on networks and infrastructure they don’t own and directly manage. Yet, this infrastructure is just as critical to consume and deliver the applications and services as when it was in the data center. Being able to explore these networks to identify choke points and routing issues in advance helps to inform better network investment and configuration decisions. It is essential for a successful cloud deployment as well as ensuring an optimized environment on an ongoing basis.

There are six key network considerations IT managers should take into account before shifting to the cloud.

Baseline Performance Before Deployment

Getting a baseline measure of network performance when moving to the cloud, first and foremost, requires adopting a different set of data points than organizations have typically used in the past. The move to IaaS, SaaS—or any cloud service for that matter—means organizations are beholden to those providers as well as third-party service provider networks through which the application or service traffic traverses.

Prior to cloud adoption, the network was essentially under an organization’s control. And it’s not that networks are necessarily less complex, it’s just that network teams had access to all the network data like packets, flows and device level information to monitor performance and security. And when issues arose, teams had the ability to troubleshoot and triage problems. Traditional monitoring approaches worked in a world where the network was managed and contained and boundaries were known. However, these data sources are no longer available for monitoring the performance of the cloud network, where devices can’t be directly instrumented or polled. Visibility into cloud and third-party networks can only come from data sources such as synthetic and end user monitoring. These techniques can provide quality of experience metrics that network teams can rely upon to test configurations and baseline performance before moving to the cloud.

See and Understand Bottlenecks in your Infrastructure

It’s very possible that, based on existing configurations and routing policies, certain offices and sites are not optimized to consume applications or services over the internet. For example, a branch office in India may have issues accessing Salesforce because of transcontinental latency and a bandwidth constrained MPLS circuit. Similarly, a branch in Austin may have better and more reliable access to applications being served from El Paso rather than San Antonio.

But how do you know what the ideal configurations are before deploying? Time to have a look at your new data sources. The first in your arsenal is actually derived from a technique you may already be familiar with for monitoring application experience in terms of page load and user transaction timings. Synthetic monitoring can be used to gain insight into infrastructure and network performance as well as your application. What’s great about synthetic monitoring is that it works in cloud environments and across the internet in addition to your data center for in-depth information about how each portion of the network is performing.

Map Out Real Traffic Paths

Having visibility into specific areas of a distributed network that are problematic, as well as pertinent details that can help determine a root cause, results in more tangible and actionable information for the network you own and those of your providers. To achieve a more complete picture of how traffic is traversing the cloud network, it is essential to combine synthetic tests with ping and traceroute functionality. Now network teams can not only test the reachability of an endpoint or host through the cloud, but also use that data to determine the route or path of packet through a distributed network while measuring transit delays.

Another useful data point is Border Gateway Protocol (BGP) routing table information. BGP knits the internet together by exchanging routing information between networks. And these routes determine how traffic flows to or from your apps and services. Layering this information into your diagnostic approach helps understand how routing configurations and changes impact reachability, latency, loss, jitter or other performance metrics.

Collaborate with SaaS and Cloud Providers

So, when it comes time to work with your your SaaS, ISP and cloud providers, it helps to share this information, related visualizations and diagnostic information in an easily consumable way. That way, when a trouble ticket is generated, it is dealt with much more quickly by the vendor or provider. Knowing exactly where a problem exists and the related cause analysis empowers teams to take immediate action and enable the responsible party take immediate action as well.

Get Things Right Before Deployment

With detailed visualizations and hop-by-hop metrics, it becomes possible to try out a routing change, plan for a new data center or test a roll out of a new application or SaaS service. Synthetic testing layered with contextual data and a detailed visual network topology allows teams to test performance and gain insight into initial infrastructure configurations, plan changes and understand their impact on cloud applications to get things right before deployment.

Continually Monitor the Performance of Your Network and Its Impact on Applications

The same techniques and data sources teams are used to baseline performance and achieve optimal cloud configurations can also be used on an ongoing basis to ensure continued performance. Active monitoring with additional layered information allows organizations to constantly keep an eye on performance degradation to optimize end user experiences across their network. And the additional inclusion of visual analysis reduces mean time to troubleshoot and repair issues. As the internet and cloud computing reshape the enterprise network, incorporating these new data sources, correlation of pertinent data points with a unified visualization is critical to the successful deployment and management of cloud applications and services.

This virtuous cycle of better performance becomes even more important in the future as organizations increasingly rely on the internet for their critical operations. Growing levels of software-based automation will only increase the number of different network paths traversed and the resulting end user experience. Accurate insights into the entire cloud network enable organizations to troubleshoot and solve their cloud performance problems, alleviating potential cloud migraines and ensuring the business runs smoothly … and painlessly.

— Alex Henthorn-Iwane

January 23, 2019
DevOps: The (Absolutely Critical) Cloud Enabler
A couple weeks ago, I gave a talk titled, “DevOps: The Cloud Enabler” at a conference. As I was putting together some requisite materials previewing my session, I made a few mistakes. (Yes, I’ll readily admit it.) I used the words “should” and “can” and “consider.” Instead, the words “must” or “not optional” or “operationally imperative” make better sense.

Companies are moving to the cloud (or at least endeavoring to); that’s a fact of IT life. If you’re not doing it, your competitors are lapping you. That may not be what you want to hear, but hey, reality bites. The cloud is simply the most scalable, flexible, efficient way to run a business these days. Cloud was just a buzzword for the longest time, but companies in all industries are actually putting it to work now. If your CIO isn’t at least in the midst of forming an application migration plan to the cloud, it might be time to light a fire under him or her; otherwise, start reading the writing on the wall and look for a new gig.

Easier said than done, though, right? I’ve heard many a CIO say, “We’re going to have all our apps in the cloud by 2018!” No, you’re not. You don’t know how. You don’t have the tools and road map to get there. Let me enlighten you with some of those stronger, more urgent words I mentioned earlier. In your move to the cloud, DevOps MUST be the conduit. Period. Stop. End of argument. Game, set, match. Not optional; it’s imperative.

Here’s why: One of the most fundamental problems that’s part and parcel of a move to reliance on the cloud is that IT orgs want every scrum team to have its own environment, complemented by an individual database instance. Eventually, that leads to creating a distinct database instance for every single developer. You probably can see where this is headed.

I’ve used this comparison time and time again, but cloud and database instances become like the wire hangers in your closet you accumulate every time you pick up clothes from the dry cleaner. They multiply over time and, all of a sudden, you seemingly have a million on your hands, with no idea where they came from and no good way to get rid of them. To compound things, once the proliferation begins, it’s hard to stop. Shut down a database instance (as with an application instance), and you lose the underlying data. No can do.

That reality spells disaster for the database administrators (DBAs) being flooded with thousands of development SQL scripts and database changes across multiple app release cycles across multiple environments. For DBAs to attempt to keep pace with this rise in change requests, organizations all but have to go through DevOps’ economies of scale. DBAs need reprieve, and DevOps can be just that. David Linthicum put the solution thusly: “Stop separating the development and operations skills; they are tightly coupled and need to be peers. You’ll find this is the hardest part of the process of moving to devops and the cloud.”

Spot on. To be more prescriptive:
- Developers need to understand what DBAs are dealing with as part of the cloud migration and know how their work rolls downhill.
- Automation needs to reign supreme, removing manual work.
- Developers need to have the ability to be involved directly in cloud ops and enact 95 percent of changes themselves.
- DBAs need to be freed to oversee the 5 percent of changes that truly need their attention and management skills.
- The flow from cloud application updates to cloud DB changes needs to be seamless.
In bringing development and DBAs into sync, DevOps then becomes the vital remedy, the critical cloud enabler.

TL;DR: If you have DevOps alignment, processes, responsibilities and tooling properly implemented in advance, then when you decide to move to the cloud, you can simply flip the switch from on-premise to the cloud. One click and you won’t miss a beat. Seriously, it’s that easy. Sound appealing? I know.

If you truly want to get to the cloud, you must have a sound DevOps strategy that encompasses application development, web and the database. Without that in place, swim at your own risk. This is the year that we’ll see much more of the true impact of DevOps. And that’s coming just in the nick of time, because without DevOps, CIOs and their IT orgs would be in for some nasty surprises in their all-important moves to the cloud.
July 25, 2016
It’s Time to Slay the Universal Installer Unicorn

While many people want a universal “easy button installer,” they also want it to work on their unique snowflake of infrastructures, tools, networks and operating systems. I call them snowflakes because their small differences expand combinatorially. That divergence turns the idea of a prescriptive reference architecture into a destructive myth that limits community and ecosystem growth.

Because there is so much needful variation and change, it is better to give up on open source projects trying to own an installer and instead focus on making their required components more resilient and portable.

Universal Installer Fallacy

So what does an easy button install look like? Let me tell you about one that I built.

Crowbar Mascot

It was 2011, the dawn of the OpenStack Era, and our team at Dell was already battle-weary from trying to make repeatable installs around Azure, Eucalyptus, Joyent and Hadoop. The simple reality was there was no success pattern we could follow deploying any one of those platforms—and certainly none cross-platform. Even though all used basically the same compute and network infrastructure, each had custom deployment code and configuration approaches. We jumped on becoming an OpenStack founding partner as a way to try to break the failure pattern.

What was failing? Each platform had deeply embedded environmental assumptions that were not repeatable or portable.

For example, one of those platforms required thirty (30!) full racks of gear and tethering back to the master deployer because its management and topology was hardwired into its infrastructure. Others were not much better: Installation often was “ssh apt-get install platform,” then “scp pre-built configuration files.” Even worse, those steps were always proceeded with 30 pages of prescriptive manual system prep steps that were updated daily.

Incorrectly, we believed that the solution was to create a better installer for OpenStack.

The Crowbar project, which is still used by SUSE, created a fully integrated install sequence from PXE boot and discovery to testing the final OpenStack installation. We could build a cloud on a complete rack of gear from boxes in minutes. The open source project even used open tools such as Chef and hardware-agnostic options to increase its community appeal. As the first installer (it predated even DevStack), the project was widely used in early OpenStack evaluations.

Despite that success, as a v1 technology, Crowbar’s major shortcoming was that it tightly coupled components and services together. That made the installation and management process very rigid and non-conforming to disparate operational models and environments.

Our install scars showed us the real battle lines that prevented portability. Even minor infrastructure variations resulted in broken or site-specific configurations. A major part of the challenge is that variation is not neatly contained; instead, it is spread throughout the environment. We needed to create automation that could both cope with heterogeneity across the community and be change-tolerant after installation to enable upgrades.

We came to accept that there is no single installer. Instead, scalable installers must assume that they will operate with other parts of the system in a coordinated way, because the diversity of options makes it impossible for them to control everything. In fact, we’ve seen that smaller, composable install steps are much easier to automate consistently. Even more importantly, smaller steps make it possible to manage systemwide upgrades in a controllable way.

Asking for an “easy button” installer is the wrong question. Instead, let’s ask, “Can we create sharable components that can be automated in multiple ways?”

There’s no universal installation script to create cloud rainbows; however, there are strategies we can use to make individual projects installable over a wide range of options. These approaches include composability, consistent configuration and use of standard tools and patterns for operation. These items help projects focus on their own concerns and allow operators to apply best practice techniques.

Basically, the first step is for project developers to limit their scope and delegate operational concerns to operators.

Even in a platform-as-a-service (PaaS) project that attempts to hide operational complexity from developers, such as Kubernetes, there remains someone who must operate that platform using foundational infrastructure and tooling. We make that job more complex when we get distracted trying to apply the new concepts to the old infrastructure. The addressing of an impedance mismatch pulls effort away from the central abstraction.

Since we do need consistent installs from the community, projects do have a responsibility to help those efforts.

How can they help? By ensuring that their component services are well-bounded with clear input configurations, operational requirements, upgrade patterns and output expectations.

But really, that’s a future post. Please let me know what you think and where we should go from here.

June 8, 2016
Best Practices for Cloud Deployment

When it comes to deploying apps in the cloud, the conventional wisdom is that DevOps is not required if you’re a small or midsized company. The cloud is designed to enable virtually anyone to set up the infrastructure they need, quickly and easily, without a lot of experience in the intricacies of managing data center operations or hardware. But then, by the time the company realizes it needs DevOps, it’s almost too late—the cloud infrastructure has become complex, costs have exceeded expectations and precious time is being wasted.

To ensure you’re able to optimize cloud, or hybrid cloud, deployments—and avoid many of the problems that other companies have experienced—there are a number of best practices you must employ within your company.

Best Practice No. 1: Realize You Need DevOps from the Start

When you manage your own hardware, you know exactly what the deployment costs are and what resources are available, and have a clear understanding of how they are interrelated. The abstraction of the cloud makes the initial setup a snap. But typically there is no formal structure involved: Individual developers can initiate new instances whenever they need them, without considering the bigger picture of the resources already in use, how they’re used or what is being planned by the organization.

Spinning up unnecessary cloud resources not only costs a company more in the long run, it also leads to a cloud sprawl that requires time-consuming, manual processes to maintain. Think about the challenges your company would face if it had thousands of machines created by different processes but you didn’t know who created them, what they were being used for or even if they were still needed.

By employing DevOps from the start, you will be able to balance the needs of developers with the availability of resources in the cloud to ensure expenses do not run out of control and you understand exactly how the cloud infrastructure is being used now and into the future.

Best Practice No. 2: Have a Process and Purpose

As you create your cloud infrastructure, you need to have a clearly defined purpose, as well as a process in place for deployment and ongoing management. You will need to keep track of what resources are being used and their designated purposes. Some cloud vendors, such as AWS, offer tagging capabilities that help you keep track of what services each machine was created for and whether they are being used for production, backup, load balancing or testing.

Regardless of whether you use tagging capabilities or maintain a separate database of cloud resources, knowing what you have purchased and how it’s being used will provide needed visibility, ease of management and greater control of costs.

Best Practice No. 3: Leverage Automation

Automation is important—both in the cloud and on premises—to streamline routine practices, make sure they’re applied consistently and eliminate potential errors that are common with manual processes.

When deploying on multiple clouds or in a hybrid environment, it is important to understand that tags used for one cloud provider won’t work on another. The process is typically broken into three steps: inventory creation, system preparation and automatic deployment. Many cloud systems allow you to create a dynamic inventory directly from the servers, eliminating the need to create or maintain it manually. However, deployment over multiple clouds require an abstraction of this inventory; it is common to create a static inventory in a unified format from the various dynamic inventories.

Best Practice No. 4: Design the Network with Security in Mind

Poorly designed networks are almost impossible to secure. Problems often arise when companies allow their networks to grow organically rather than being planned out in advance. A number of companies have employed the best practice of segregating the services network and the management network. The services network includes all the components required to provide services to your customers and users, while the management network is comprised of what you need internally to manage the network. Separating these networks provides greater assurance that unauthorized users cannot gain access to your systems via the Internet.

Another part of security is key management. Depending on the cloud provider, keys can be widely available or have a root password that is open to the world. In fact, many hackers routinely scan Github for keys developers accidentally check in. With having to manage so many keys, you may struggle to ensure that they’re not exposed. DevOps plays an important role in keeping the keys locked away, then providing them to a select group of individuals who can use them only in production.

Best Practice No. 5: Be Strategic About Monitoring

When you’re deploying hardware on-premises, it’s a common practice to define in advance what to monitor. But monitoring in the cloud is quite different, with basic defaults that produce vast quantities of data—much of which may not be relevant to your organization.

Taking a cue from how you handle monitoring on-prem, you’ll want to design cloud monitoring to fit your company’s unique needs and filter out the information that isn’t pertinent to your network or operations.

Best Practices Go a Long Way

Keeping in mind these best practices and employing a DevOps model from the start will enable your company to get the most benefits from its cloud deployment regardless of its size, and avoid the costly and time-consuming challenges that arise without proper advanced planning and a strong focus on network design and processes.

About the Author/Roger Fulton

Roger Fulton is Iron.io’s director of Infrastructure and Operations. His background includes broad experience in software architecture and operational planning. He manages international teams to deliver highly available products for end users and highly performing in-house infrastructure. Prior to joining Iron.io, Roger served as head of application and infrastructure engineering at Kaybus. He has also held technical leadership roles at JRV Consulting Group, Cybrata, Invisible IT and Clarus Systems. Roger holds a Masters from the Queens University of Belfast, having graduated with highest honors.

May 20, 2016