devopsy.kinsta.cloud

Tag: cloud infrastructure

The Problems With Golden Templates That No One Wants to Talk About

Without question, golden templates (or golden images) simplify the process of deploying resources in on-premises and cloud infrastructures. These templates can save time. They ensure consistency by setting up a computing environment that matches the specifications. The templates also encourage component reuse, rather than requiring individual users to manually compose infrastructure as code (IaC) from scratch for each application. For common types of projects, the infrastructure is frequently the same, so why force busy developers to rewrite it for everything they want to deploy?

Golden templates were a great first step in making IaC more accessible for end users, including people who might otherwise find it difficult to compose IaC. Preset standards can plug-and-play with the users’ applications and projects.

That’s far better than the alternatives. Nobody has to ask those users to learn new tools, such as Terraform, AWS CloudFormation, or Ansible, each of which has its own syntax and nuances. Nor are those end users expected to understand the infrastructure, such as servers, storage, networks and operating systems. It’s akin to a PowerPoint template that is pre-equipped with a brand’s colors, fonts, icons, and predefined layouts.

Golden templates make it easier to get started with IaC and deliver something that looks right, with all the right pieces.

Or, at least, that was the goal. Despite the strengths of golden templates, there are still issues to resolve.

The Problems Golden Templates Address Well

Making IaC repeatable makes sense. It builds in infrastructure security, consistency, and performance by removing the likelihood of manual errors, ensuring best practices are followed, and enforcing the use of approved modules, providers, and resources.

Golden templates work fairly well for simple things you need to do all the time, such as deployments where the infrastructure is the same every time and the underlying codebase rarely changes. There’s no need to reinvent the wheel for every application deployment, so it makes sense to use a template that describes which modules to use and in which order. As with that PowerPoint template, the approach is relatively simple and it doesn’t require a platform engineer’s time and attention.

Saving time and improving efficiency are clear wins in themselves, and golden templates theoretically offer both of those, alongside security. For common use cases, templates can make it easy for end users to deploy their work without sending tons of requests to the platform team or exposing their organization to unnecessary risk.

Ultimately, though, like any template, golden templates are fragile.

Where Golden Templates Fail, and Why

Golden templates work great on Day One, but two things happen fairly quickly that throw a wrench into the works: updates to components and updates to the templates themselves.

Templates often include versioned components, such as modules and dependencies on different (often open source) projects.

What happens when you want to use the latest version of a module in your template? You have two options: update the whole template; or try to design your templates to always use the latest version, which has its own risks and pitfalls. Most companies want to test the latest versions before rolling them to production. And you don’t want to update your template one week only to do it again the next week when another component gets a new version.

That brings us to the process of rolling out new versions of the template, whether that happens frequently or once a year. Updating golden templates means they need to be in a version control system or some other distribution channel that your development teams actively use. If you’re lucky, you’ve built those templates into your build/deployment pipelines.

But what happens when not every team is cleared for updates? You want to make sure that your developers use the version that captures all the latest rules, best practices, and institutional knowledge from your platform engineering team. You also need to ensure that you’re not disrupting their existing infrastructure. And, if you’re not building templates into pipelines, you had better keep your fingers crossed that your end users are choosing the updated version of the template appropriately (rather than grabbing an outdated template).

That makes the process more complicated, when the entire point was to simplify. You now need to keep track of who uses which version of the template. You also need to track versions of the various components you need to support, maintain, or plan to manually upgrade eventually. And, as with any other template, if you mess up the golden template everyone uses, the problems trickle down. Everything using that template includes those same problems baked in, creating a sprawling remediation nightmare.

The Service Catalog Alternative… Maybe

Of course, a single template can’t fit all deployment needs, so many companies create service catalogs of templates. These catalogs allow developers to make template selections through multiple-choice questions or by filling in the blanks. This solves the challenges of relying on a single template for many use cases.

However, the service catalog model often requires end users to select infrastructure correctly for their use case, which in turn requires that you wrote the questions or directions expertly to guide them without requiring them to have additional infrastructure knowledge. As anyone who has tried to write instructions or guides for anyone quickly learns: That’s hard to do well! Everyone thinks about things differently, and a straightforward direction for me might be really confusing for someone else. Templates and service catalogs don’t escape this issue.

All of this assumes that every template is equal and that every developer who uses a template has the same baseline knowledge. When you share a template with developers who know about infrastructure, they can fill out their part quite easily. For developers who don’t understand infrastructure, however, it’s much harder to fill in the blanks. They may need to turn to platform engineering for help (or make inaccurate guesses, which is arguably worse), and that undercuts the benefits of the template.

Golden templates never solved the problem of changing application needs, either. Templates are, by design, one size fits all. What happens when an application developer uses a template that just barely fits the needs of their application to get it into production, and then updates that application to have even higher infrastructure requirements? Is that developer going to assess whether the updated application has new requirements? Or are they just going to keep using the same template? The developer may not pull down a new golden template version, consider whether they need an extra database, how expanded capacity may change requirements, or how the scale the application is running at has changed – and the developer is less likely to do so when they are not connected to the day-to-day maintenance of the application’s infrastructure. The result is an application that isn’t set up to handle the load and therefore fails.

The reverse is just as likely. It’s too easy to deploy applications that are over-provisioned, and therefore taking up valuable space and resources. That also creates a wider surface for potential attacks.

Often, developers need to revisit an application’s infrastructure requirements, and templates don’t require or encourage that thought process.

How to Ensure Secure, Efficient IaC

We do not want to give up the positives of golden templates: automation of repetitive tasks, creating knowledgeable guidelines for users with less infrastructure knowledge, and more ability to build in known best practices and secure patterns.

But if templates are too fragile to use to reliably deliver secure and efficient IaC, how can organizations solve these problems while still gaining the benefits? Shift your thinking from a template where developers fill in the blanks, to asking how you and your organization can generate IaC from standards.

Standards are guidelines your organization defines for how to build and structure infrastructure. Standards establish the requirements to ensure your applications and projects are deployed such that they meet the needs of your business, the industry, and your customers.

Standards change significantly less often than templates, which implicitly combine standards with module and other component versions. Instead of placing the burden on developers to remember and align to these standards, apply your policies and standards automatically when IaC is generated, eliminating the need to scan and fix it after creation. This approach enables developers to deploy applications faster and platform engineers to provision infrastructure more easily because there’s no need to worry about whether the IaC is secure and efficient.

Photo credit: Neeqolah Creative Works on Unsplash

May 1, 2024
Navigating the Multi-Cloud Ecosystem

Multi-cloud infrastructure, an approach where organizations utilize services from multiple cloud providers, is rapidly gaining traction in the tech world.

In this article, we will unpack the concept of multi-cloud infrastructure, examining how it enables businesses to diversify their cloud ecosystems for enhanced performance, greater flexibility and improved risk management.

Understanding the Multi-Cloud Ecosystem

Multi-cloud environments represent a strategic approach in cloud computing where businesses utilize services from multiple cloud providers to meet diverse operational needs.

This concept differs from hybrid cloud, which typically blends both private and public cloud infrastructures, aiming to offer a balance between the two under a single unified environment.

In contrast, a multi-cloud strategy involves using distinct cloud services – for instance, one provider for storage, another for computing power and another for analytics – without necessarily integrating them into one cohesive system. This approach allows organizations to leverage the unique strengths and offerings of various cloud providers, thereby optimizing their IT infrastructure for efficiency, cost-effectiveness and enhanced performance.

The Advantages of a Multi-Cloud Approach

Adopting a multi-cloud approach brings several key benefits, the biggest among them being enhanced resilience, flexibility and the avoidance of vendor lock-in.

By distributing resources and workloads across multiple cloud environments, businesses can mitigate risks associated with relying on a single cloud provider, such as service outages or data loss. This diversity ensures continuous operation and robust disaster recovery capabilities.

Additionally, a multi-cloud strategy empowers organizations with the flexibility to select the best services that each cloud provider offers, tailoring their IT infrastructure to specific needs and operational demands. This tailored approach enables businesses to optimize both performance and cost. Different providers may offer competitive pricing for specific services, allowing companies to choose the most cost-effective solutions for their requirements.

Moreover, by avoiding vendor lock-in, organizations retain the freedom to switch providers as needs evolve or as newer, more advantageous services become available. This strategic utilization of multiple clouds ultimately leads to a more efficient, agile and economically sound IT infrastructure.

Key Challenges in Multi-Cloud

Multi-cloud management comes with its own set of challenges, particularly in terms of complexity, data security and compliance. DevOps teams often grapple with the complexity of managing disparate cloud services, each with unique features and interfaces, making seamless integration and consistent operation a demanding task.

Data security is another critical concern, as safeguarding sensitive information across multiple platforms requires robust and adaptable security measures. Additionally, ensuring compliance with varying regulations across different cloud environments adds another layer of complexity.

These challenges necessitate that DevOps teams are technically proficient and adept at strategic planning and coordination to manage a multi-cloud ecosystem effectively.

Best Practices in Multi-Cloud Deployment and Management

When managing and deploying within a multi-cloud ecosystem, DevOps teams can greatly benefit from the following five best practices:

1. Strategic Cloud Service Selection: Carefully assess and choose cloud services based on specific workload requirements, performance metrics and cost-effectiveness to ensure optimal deployment.
2. Centralized Monitoring and Management: Utilize centralized tools for monitoring and managing different cloud environments to maintain consistency and control and to streamline operations.
3. Consistent Security Posture: Apply uniform security policies and practices across all cloud platforms to protect data integrity and comply with regulatory standards.
4. Automation: Automate repetitive and routine tasks across different clouds for efficient resource utilization, reduced errors, and faster deployment cycles.
5. Cost Management and Optimization: Continuously monitor and manage cloud spending across platforms to avoid cost overruns, ensure efficient use of resources and follow cloud cost optimization best practices.

Building a Multi-Cloud Strategy: A DevOps Perspective

From a DevOps perspective, building a comprehensive multi-cloud strategy involves aligning cloud infrastructure with business objectives and core DevOps principles.

The first step is clearly defining business goals and identifying how different cloud environments can support these objectives. This should be followed by selecting cloud services that best match the specific needs of each workload, considering factors like performance, cost and compliance requirements. Integrating continuous integration and continuous deployment (CI/CD) processes is crucial in a multi-cloud setup.

This integration ensures software can be developed, tested and deployed rapidly and reliably across different cloud platforms. The strategy should also include implementing robust automation and monitoring tools to maintain consistency and efficiency across the cloud.

By focusing on these elements, a DevOps team can develop a multi-cloud strategy that not only aligns with the organization’s goals but also adheres to the agile and efficient ethos of DevOps methodologies, ensuring seamless operation and scalability in the multi-cloud environment.

Wrapping Up

In conclusion, effectively navigating the multi-cloud ecosystem is crucial for DevOps success, as it offers unparalleled flexibility, scalability and resilience in managing diverse cloud resources. DevOps professionals are encouraged to embrace multi-cloud strategies as they enhance operational agility and open avenues for innovation and improved service delivery.

January 16, 2024
Massdriver Adds Cloud Cost Controls to Internal Developer Platform

Massdriver has made available tools for tracking cloud costs and generating a cloud infrastructure bill of materials (Cloud IBOM) to internal developer platforms (IDPs) as part of an ongoing effort to streamline platform engineering workflows.

The Cloud IBOM makes it possible, with a few clicks, to map hybrid cloud resources such as databases, machine learning pipelines and serverless computing frameworks.

Massdriver CEO Cory O’Daniel said collectively, these tools reduce expenses by preventing misconfigurations that result in unexpected costs. Rather than solely providing a summary of costs incurred, the tools provided by Massdriver surface how much cloud services are going to cost at the time the developer is invoking them, he noted.

In the absence of that context, developers will nearly always overprovision cloud resources to ensure maximum availability regardless of cost, says O’Daniel. The overall goal is to help organizations reduce the total cost of IT by providing developers with insights into costs in real-time, he added.

Earlier this year, the company launched an IDP that comes with platform engineering tools that, for example, make it possible for DevOps teams to build a catalog of infrastructure components that developers can access within the context of guardrails they define. The platform also includes observability and visualization tools that make it simpler to track metrics and monitor the usage of cloud resources.

Massdriver is making a case for an IDP that provides built-in tools and workflows that enable organizations to embrace platform engineering as a methodology for managing DevOps workflows at scale. The goal is to reduce the level of expertise required to build and deploy applications in cloud computing environments, said O’Daniel. One of the primary reasons there are not more applications running in the cloud today is that these environments are still too complex to successfully manage, he added. An IDP abstracts away that complexity within a set of workflows that have been vetted by a DevOps team, he added.

There are, of course, multiple approaches to building an IDP, but rival approaches require too much effort to set up and maintain, said O’Daniel. A proprietary platform provides a more turnkey approach that doesn’t require DevOps teams to either build their own or customize an open source platform, he added.

It’s not clear at what pace organizations are embracing platform engineering, but there is a clear need to strike a balance between delivering IT services managed by a centralized team and the desire a developer might have to embrace new tooling whenever they see fit. Today, too much responsibility for provisioning IT environments has been pushed left toward developers who now have less time than ever to write code.

There is, naturally, no guarantee that reducing the cognitive load for developers will increase productivity. Building applications requires streaks of inspiration, but, in theory, an IDP should provide more time for inspiration to strike. DevOps teams, as part of that effort, should be continuously working toward eliminating any bottlenecks that have emerged in their DevOps workflows.

December 18, 2023
Technical Debt is Inevitable. Here’s How to Manage It

Eventually, your organization will accumulate technical debt. It doesn’t matter what programming language, software stack, computing style, host, or slick hybrid mix you use. It doesn’t matter if you’re using a waterfall or agile methodology. Ultimately, most technology becomes technical debt one day.

“Technical debt is inevitable,” said Insight’s North American chief technology officer, Juan Orlandini. “Technical debt is like credit card debt. If you’re not smart about how you use it, your balance keeps increasing.”

Today’s technological trends will one day fall out of favor, especially as talent moves on and older maintainers retire. And while this all might sound grim, acceptance is the first step toward change. Realizing this pattern of technical debt and accepting its inevitability may be the key to building future-proofed, evolvable software ecosystems.

I recently chatted with Orlandini to understand some of the significant contributors to technical debt and how software maintainers can plan for and address it. Below, we’ll outline some of the major causes of technical debt and suggest methods to tackle it and prevent it from accumulating.

Major Contributors to Technical Debt

Enterprises face growing technical debt. A study from Outsystems found that 40% of IT budgets are devoted to addressing technical debt in large enterprises. To mitigate technical debt, we must first understand the main contributors to it. The causes of technical debt are wide and varied but can be distilled into a few common areas, said Orlandini.

Unsupported software stacks. One major cause of technical debt is outdated or unmaintained software. Too often, a consumer will purchase a proprietary system that eventually becomes sunsetted, said Orlandini. Or, the vendor may evaporate during an acquisition or merger. When this occurs, the package goes unmaintained and leaves a mess on your hands.

Trends in programming languages. Another obvious area is the continual evolution of programming languages. Even today’s most popular languages aren’t that future-proofed—Python replaces Perl, Go replaces Python, Rust replaces Go and so on. The same is true for frameworks. Ruby on Rails used to be in, but now Vue.js is a more hip framework.

Aging cloud infrastructure Just because you’re in the cloud doesn’t mean you don’t have technical debt, reminds Orlandini. When early cloud adoption began, many core services we take for granted today, like authentication and authorization, weren’t offered by the cloud service providers. Some of the first-ever cloud migrations were stitched together with homegrown tooling, which may not be aging well. Or, organizations may have “lifted and shifted” legacy services into the cloud. Operators overseeing these older cloud-based environments will likely feel the pressure to refactor into more modern, cloud-native styles.

The proliferation of microservices and APIs. Furthermore, cloud services retire features all the time. Thus, it can be challenging to keep up with these minute changes to retain backward compatibility for things like API versioning shifts. In the DevOps world, web APIs are the glue that connects our tools. But in an increasingly complex landscape, it can become easy to produce shadow IT and lose track of dependencies.

Legacy physical infrastructure: It’s not just the software that becomes debt; the systems and hardware it runs on might also become obsolete. For example, the network itself might be full of old edge switches and wireless access points, says Orlandini. Or, an enterprise may hold onto aging on-premises servers. (This is often due to the depreciation benefits of using a capital expense accounting model as opposed to an operational expense model.)

Other factors that could contribute to technical debt are things like rushed decision-making, skills and resource gaps and failure to implement DevSecOps.

Ways to Tackle Technical Debt

Technical debt is a threat to innovation, so how can we mitigate it? Well, if you don’t already do so, it’s a good idea to build technical debt into your budgeting, planning and ongoing operations, said Orlandini. “You have to manage it, expect it and be responsible with your technical stacks in the same way you are responsible with your financial stacks,” he said. Here are a few other ways to manage the debt you have and avoid accumulating more.

Consider using AI to refactor legacy code. Generative AI could be leveraged to reactor legacy code into more modern programming languages. This could help automatically convert PEARL code, for instance, into JavaScript. Today’s large language models (LLMs) could help solve many of today’s problems. However, since they are built on a pre-existing body of work, they will use less trendy languages and might cause some technical debt in the process, cautioned Orlandini.

Don’t over-rely on new DevOps processes as a cure-all. DevOps can accelerate the time to release features, but it does not, by its nature, eliminate technology changes, said Orlandini. Just because DevOps helps deploy an aging framework doesn’t mean it will maintain or evolve the debt. As frameworks go out of style, IT teams must continually assess their software stack.

Remain lean whenever possible. Preventing the accumulation of unnecessary technology should be top of mind. In the DevOps world, there is a proliferation of individual services, and it’s easy to loop in a tool because it’s “the next best thing.” While sleek tools can help quickly integrate new functionality, looping in too much unnecessary tech could introduce sprawl concerns, said Orlandini. In general, he recommends keeping things as optimized as possible and carefully vetting the introduction of new technology. This includes carefully vetting new partners to ensure their business model works and that they themselves are future-proofed.

Continually maintain updates of dependencies. Today’s software infrastructure is largely composed, at its foundation, of open source software. And if these packages aren’t mature and well-supported, you may be sitting on an unstable house of cards. It’s a good idea to continually audit your OSS use and respond to updates in a timely manner.

Managing the Inevitable: Tech Debt

Tech debt is like credit card debt—easy to get into and tough to get out of. And just like its financial equivalent, you shouldn’t go too far into technical debt. Thankfully, we’ve covered some best practices to keep in mind that should help spot key problem areas and reduce bloat before things get out of hand.

As a final note, consider asking: How much stuff are you using and why? It’s become a trope, but the principle of KISS (keep it simple, stupid) bears repeating in software architecture dialogues. Because if you reduce the surface area, it will make ongoing maintenance easier and reduce the potential of cyberattacks.

The subject of technical debt is a multi-faceted issue with many factors to consider. For related insights, you can also watch the conversation between Techstrong Group Chief Content Officer Mike Vizard and Juan Orlandini on Techstrong.tv here:

June 8, 2023
Top Three DevOps Tools for Cloud Infrastructure

A survey from Canonical of 326 IT executives found the most widely employed DevOps tool for managing cloud infrastructure is the Bash shell and command language (53%), followed by the Ansible automation platform (47%) and Terraform (40%). Another 27% reported they used tools they developed themselves.

The survey also found 58% managed their cloud infrastructure entirely on their own rather than relying in part or entirely on some type of managed service.

Not surprisingly, the survey also found that 83% have seen spending on cloud infrastructure expenses increase over the last two years, but 23% have no visibility into how much they are actually spending. Well over half (57%) do feel they are paying “a lot” for cloud infrastructure.

Tytus Kurek, a product manager at Canonical, said during uncertain economic times, there’s now more focus on the total cost of IT. Cloud costs have become a much larger percentage of the IT budget, so more scrutiny is being brought to bear, he added. As such, there’s more interest in FinOps as a framework for programmatically managing cloud costs more effectively, noted Kurek.

However, only 58% said they believed their public cloud costs were predictable. Well over half (53%), however, noted they qualified for discounts on cloud services offered by providers. In comparison, 73% said their private cloud costs were predictable.

The most widely deployed software on cloud infrastructure are web applications (57%), followed by file storage (52%) and databases (51%). The most widely employed cloud service providers were Amazon Web Services (AWS) at 60%, Microsoft Azure (49%) and Google Cloud Platform (GCP) (33%). In terms of private cloud platforms, the most dominant is VMware (40%), followed by OpenStack (28%) and Azure Stack (15%). Only 25% of respondents managed less than 1TB of data.

In general, cloud computing environments are evolving as more cloud-native applications are built and deployed. The bulk of applications running in the cloud today are monolithic. As such, they typically consume a set of IT infrastructure resources dedicated to running that application. Cloud-native applications take advantage of Kubernetes to scale consumption of IT infrastructure more efficiently; over time, the cost of running a cloud-native application should be less than a monolithic application. It’s still early days as far as deployment of cloud-native applications is concerned, so the bulk of applications running in the cloud will continue to be monolithic for many years to come, noted Kurek.

In the meantime, there is a clear need for more automation. Many cloud infrastructure resources are currently provisioned by developers. There is an opportunity for DevOps teams to automate that process so that it is more efficient and more secure. Developers tend to make mistakes when provisioning cloud resources that, for example, result in data being exfiltrated by cybercriminals via a port inadvertently left open.

One way or another, the management of cloud computing is becoming more structured in an era where IT organizations are rediscovering the importance of capacity planning. The challenge is that many organizations have never known anything other than the cloud, and they may not even know how to achieve that goal. On the plus side, however, it may not be too long before the whole process is automated by an artificial intelligence (AI) model that optimizes the allocation of resources without any human intervention required.

January 18, 2023
Infrastructure Abstraction Will Be Key to Managing Multi-Cloud

There’s no doubt we’re now living in a hybrid multi-cloud age. Companies are using major cloud providers like AWS, Azure and GCP with niche cloud computing providers emerging within the market. Simultaneously, many organizations still retain workloads in on-premises data centers or embrace colocation. Regardless of deployment pattern, DevOps teams desire the same elasticity as the cloud, but it’s becoming increasingly difficult to consistently manage the nuances of each service provider.

To support today’s distributed polyglot architectures, a common layer could ease issues when deploying applications and provisioning various servers. By decoupling the infrastructure control plane from specific cloud providers, a unified management console could bring visibility into cost and performance, empowering CloudOps with knowledge before they commit. But engineering such an outcome would rely on plugins for each environment and a robust set of APIs to enable programmatic control.

I recently met with Jake Warner, Cycle.io, to explore how increased infrastructure abstraction can solve the above problems. According to Warner, a standard layer for computing management is needed to enable consistent control over multi-cloud and bespoke on-premise environments. Below, we’ll define this concept and consider the benefits infrastructure abstraction could bring to modern enterprise software development.

The Problems Facing Infrastructure Management

We like to think that the cloud is pervasive and that everyone’s on board with a similar computing style. However, this is far from the truth. Multi-cloud is rising, and 95% of businesses are making multi-cloud a strategic priority in 2022, a Valtix study found. Yet only about half of respondents felt they had the appropriate tools and skills required to execute a multi-cloud strategy.

“There’s a lot of value in multi-cloud, including reducing risk, ensuring better uptime and the flexibility to select the best hardware for the use case,” said Warner. “But multi-cloud is extremely complex.” Using multiple clouds means supporting increasingly variable operational processes for each environment. Whether it’s AWS, GCP, Azure, Equinix or Vultr, operators also require a deep level of visibility into telemetry data. This becomes complicated to track as software is increasingly modular and distributed across multiple computing regions.

Furthermore, on-premises data centers are far from dead—surprisingly, a Spiceworks study found that 98% of enterprises still used on-premises servers. Traditional servers are often preferred due to corporate restrictions or to meet security compliance mandates. It could also be a cultural case of “if it works, don’t fix it.” The dilemma is that you can’t easily obtain common cloud features like auto-scaling and load balancing while on your own infrastructure.

Another issue Warner described is that traditional platform-as-a-service (PaaS) companies present inherent limitations if you aim to build substantive applications and services. “Many of these PaaS offerings make it really easy to get started but, more often than not, developers are quickly forced to make compromises with their approach. These compromises can create long-term technical issues, especially when it’s time to scale,” he said. “Need a server with a specific hardware configuration in a targeted region? Good luck. For most PaaS companies, their exit ramp is just as defined as their on-ramp.”

Movements Toward Infrastructure Abstraction

We’re already seeing movement within the market to manage the operational burdens of multi-cloud. One example is the Infrastructure Abstraction Layer (IAL), open sourced by Cycle.io, which Warner explained can act as a standardized system for deployments. With the specification, an infrastructure provider can generate an API endpoint to enable the provisioning of infrastructure without requiring a deep integration between both services. With this endpoint live, an application development platform or orchestrator gains the ability to send standardized JSON payloads to provision servers, allocate IPs, configure regions and a number of other requests. The response, another JSON payload, confirms that the desired request has been completed and includes a unique ID.

With more programmatic control over infrastructure, an engineer could interface with a standardized list of all the servers, across a number of providers, to deploy to and act upon this information in one unified console. This layer is an opportune location to help compare costs and server configurations for different regions too. It’s also an advantageous spot to filter by proximity to showcase the closest available servers to optimize delivery.

Benefits of Unifying Multi-Cloud Deployment

Decoupling the infrastructure management layer from service providers can bring potential benefits to DevOps, said Warner. For one, it enables operators to extend infrastructure automation into their private data centers, helping them achieve the same programmability they would have in the cloud. A degree of standardization can remove many of the cons of multi-cloud, too—”Developers can move from one provider to another provider without any major changes along the way,” he said.

Of course, IT doesn’t want an added burden. This is why an API-based solution is required to enable programmability, said Warner. By taking a RESTful API approach to managing a hybrid infrastructure, operators could create custom flows based on fine-grained environmental characteristics that change over time, like latency, expense or location. “One of the neat things is it allows infrastructure providers to constantly make tweaks and improvements without having to resubmit their integration with an underlying platform,” said Warner.

The Flexibility of LowOps

Today’s software deployment is increasingly wide and varied—a recent HashiCorp report found that 76% of organizations are already multi-cloud. Multi-cloud brings many advantages, yet it also multiplies the number of operational tasks required. At the same time, organizations want to leverage investments into on-premises data centers for as long as they are economically viable. Automating DevOps for such a varied infrastructure can be difficult without a unified layer decoupled from each niche computing area.

According to Warner, companies require a LowOps platform and the flexibility to abstract this automation on their own infrastructure when appropriate, which can vary widely. For example, operators may be working with a fleet of tens of thousands of IoT devices. Furthermore, as we’ve covered previously, a LowOps method can be beneficial to small-to-medium-sized companies that may lack the resources to support complex infrastructure like Kubernetes.

Could something like IAL ever become an open standard? Well, at the time of writing, the IAL specification has only been implemented by Cycle.io and a few of its infrastructure partners, but there’s no reason it couldn’t be extrapolated into a common specification down the line, said Warner. He even foresees a community marketplace or shared registry for infrastructure abstractions, enabling platforms to support hundreds of cloud providers.

In conclusion, the need for LowOps, combined with the rise of multi-cloud and the staying power of on-premises data centers, is fueling a requirement for a decoupled management center. Infrastructure abstraction could enable the convenience of a PaaS while empowering operators with custom infrastructure choices.

November 17, 2022
TidalScale Enables Hot-Swapping of Failed Servers

TidalScale has updated its namesake software for automating server management to include the ability to detect and prevent impending failures and enable IT teams to hot-swap another server.

Version 4.1 of TidalScale also adds server wear leveling and preventative health checks that identify servers that should be replaced based on their remaining estimated life span.

TidalScale CEO Gary Smerdon said that capability is especially critical given the high rate of DRAM memory failure that results in a high rate of downtime caused by server failures. The latest update to the company’s software-defined server management software reduces the failure rate in on-premises or cloud computing environments by a factor of 100 to ensure 99.999% uptime, he said.

The company also announced that its software is now available on the Amazon Web Services (AWS) Marketplace.

TidalScale employs machine learning algorithms to aggregate and virtualize CPU cores, memory and I/O across servers to present operating systems with a single software-defined server. That makes it possible to hot-swap individual servers to ensure availability.

The single biggest cause of downtime in IT environments is memory failures; they are now 100 times more likely than they were a decade ago, noted Smerdon. In most cases, the root cause of the issues is the demands of modern applications running on legacy infrastructure that was not intended to support the latency requirements of those applications, he added.

That issue can be especially acute in cloud computing environments where infrastructure is often shared by multiple applications, said Smerdon.

It’s not clear at what rate cloud service providers are replacing legacy server infrastructure, but the ability to determine when to replace infrastructure gives IT teams an added measure of control over servers regardless of where they are deployed. The biggest issue, of course, is not so much replacing a server as it is determining which one actually failed. It often takes longer to identify a failed server than it does to bring a new one online.

TidalScale is made available by both cloud service providers and manufacturers of servers used in on-premises IT environments, but it needs to be configured and deployed by an IT team. The overall goal is to not only increase system availability but also reduce the total cost of IT by managing infrastructure more efficiently across the life span of a server, said Smerdon. Some IT teams routinely replace servers at specified intervals, regardless of actual usage, to avoid downtime. TidalScale enables IT teams to determine which servers to replace based on the actual wear within the context of a self-healing server farm, he noted.

Given all the things that might potentially go wrong in an application environment, not having to worry about server failures should enable DevOps teams to spend more time optimizing application performance.

In theory, of course, modern applications based on microservices should be able to reroute calls to application programming interfaces (APIs) anytime a server becomes unavailable. However, over time it’s not uncommon for single points of failure to emerge as applications are updated. In the meantime, the majority of applications running today are based on legacy monolithic architectures that are much more susceptible to server failures that, unfortunately, are still far too common.

August 30, 2022
Oracle’s Free Managed Service Integrates With Microsoft Azure

Oracle today extended its alliance with Microsoft to include a managed service that makes it simpler for IT organizations to embrace hybrid cloud computing. Oracle Database Service for Microsoft Azure integrates Windows applications with Oracle databases running on Oracle Cloud Infrastructure.

Leo Leung, vice president of products and strategy for Oracle, said the managed service is an extension of an existing capability that was rolled out in 2019. However, many IT organizations found it too difficult to provision hybrid cloud computing environments themselves. The managed service makes it easier to access Oracle databases across a high-speed network spanning 11 global regions, Leung said.

There is no charge for the Oracle Database Service for Microsoft Azure, the Oracle Interconnect for Microsoft Azure, data egress or ingress when moving data between OCI and Azure, said Leung. Organizations will pay only for the other Azure or Oracle services they consume.

DevOps teams have often spent significant amounts of time trying to integrate diverse cloud computing environments. Now, with just a few clicks, Oracle is making it possible to connect Azure subscriptions to OCI. The service automatically configures OCI and Azure environments, federates Azure Active Directory identities and enables monitoring with Azure Application Insights.

Oracle and Microsoft, of course, are locked in a fierce database contest as Microsoft looks to drive adoption of SQL Server as an alternative to the Oracle relational database. However, there are many organizations that today run Oracle databases on Windows servers in on-premises IT environments. Oracle is looking to make it easier to migrate those environments to the cloud with minimal disruption, noted Leung.

Theoretically, organizations are embracing multi-cloud computing to ensure they don’t find themselves locked into a single provider. The challenge is that each cloud computing environment has its own set of management tools that need to be mastered. As organizations add additional clouds, the actual total cost of IT rises as more specialists are brought on board to manage those environments. Oracle’s approach addresses that issue by enabling IT teams to manage Oracle databases via a single pane of glass that resides on the Azure cloud, said Leung.

Oracle has been trying to gain market share in the cloud by reducing the total cost of cloud services. A free managed service for integrating Azure cloud with OCI also reduces the incentive any existing Oracle customer might have to replace Oracle databases as they migrate to the cloud.

It’s not clear how far the Oracle service will advance hybrid and multi-cloud computing, but it does set a new benchmark for what IT organizations should expect. The days when cloud service providers largely ignored each other are coming to an end. In this day and age, IT teams should not have to devote resources to integrating low-level APIs simply because cloud service providers don’t want to acknowledge the fact that application workloads are routinely deployed on multiple clouds.

July 20, 2022
DevOps and Hybrid Cloud: Life in the Fast Lane?

Scream if you want to go faster! When it comes to a dual hybrid-cloud-and-DevOps rollout, most organizations would admit they’re eager to get going a little bit faster. But what started so enthusiastically can turn to frustration (and a different kind of screaming starts) when they’ve accelerated into this major transformation without considering all the necessary elements.

The benefits are clear. Hybrid cloud backed up by DevOps is an efficient vehicle for change. A robust DevOps platform can be a make-or-break factor in developing a hybrid cloud strategy that goes the distance. Together, they are a force for transformation, and if organizations aren’t already implementing both DevOps and hybrid cloud, they should be asking themselves why not.

It is true that the move to hybrid cloud is a different journey for cloud-enabled organizations than it is for cloud-native ones. The trip is harder for cloud-enabled, particularly for larger enterprises. Increased release frequency requires tighter alignment and collaboration than is traditionally seen between lines of business, development and IT operations, and this, in turn, drives the need for enhanced collaboration, automation and information transparency.

But although the transition might be harder, it must be seen as inevitable. Organizations could wait another year, maybe a little more, but the transformation of technology and business is going to happen—so why not get started? In the first of two articles, I’m going to take a look at what needs to change so that organizations can start living life in the hybrid cloud and DevOps fast lane.

A Cultural Phenomenon

As has been covered in these pages in some detail already, the move to hybrid cloud backed by DevOps is doomed to fail if organizations think all they need to worry about is tooling and hiring. It’s not. Underlying both of these transformations is a sweeping cultural change. DevOps is about agility, trust and autonomy, and so is hybrid cloud.

Most of all, though, DevOps and hybrid cloud are a commitment to enhancing an organization’s developer experience (DevX), and that’s not something that can be achieved with simply a ticketing tool or by adopting a GitOps approach. DevX means autonomous, unbound movement. It means empowerment, user experience and self-service. These are changes that can only happen with a successful change in business culture, not a tool. And this is an important starting point that many organizations are still struggling to understand.

The People Problem

People are another well-worn topic, but one that continues to present a major challenge. The cultural transition required to successfully implement DevOps can, theoretically, start with just one person. But for a successful outcome, it actually requires long-term change as deeply-ingrained beliefs are disbanded and tribal loyalties are broken down.

For instance, many believe that implementing DevOps requires hiring new people. That belief embraces two fallacies: One, that organizations will be able to hire the teams they need and two, that DevOps is just a job title. As we know, a good DevOps team is not hired, it is developed through the melding of development and operations. The old silos, where devs developed and ops operated, is a relic from less-enlightened times.

Today, it requires learning how to build automation, often open source, while managing on-premises, private and public cloud infrastructure. DevOps is a philosophy that seeks to help others, and with that comes the need for collaboration, encouragement, persuasion and other soft skills.

Security and Privacy Are not Straightforward

Moving to a hybrid cloud means that more care needs to be taken with regard to security and privacy. One of the main problems is that it’s no longer enough for security teams to reign from on high. With control moving from the server room to the cloud and from highly-siloed ops engineers to the whole team, security policies also need to change. Competent developers will make the right decisions, but they need the right bottom-up tooling that takes their decisions from theory to reality and safeguards those who aren’t as aware.

These must be a catalyst to make organizations sit up and take a long look at what security in the age of cloud, containers and microservices really means. If the simultaneous move to DevOps and hybrid cloud is that catalyst, then so be it. Just as DevOps is revolutionizing the way teams approach their work, DevSecOps is going to revolutionize the way they look at security.

Security shows its face at various stages of infrastructure: When a cloud organization is created and structured; when a vault is integrated to ensure that key passwords are secured and even when a pipeline is launched that triggers dedicated security software. This isn’t an exhaustive list, but it illustrates how organizations need to start taking a methodical, step-by-step look at security in their hybrid cloud.

What About GitOps?

Gartner recently found that the average company uses 28 infrastructure tools. That’s simply too many to be handled and understood by one person. Even specialist DevOps engineers can’t be experts in all the cloud providers, OpenStack and VMware. Other studies showed that a developer generally only uses 5% of their Git repositories or an average of five repositories.

The mistake lots of companies make is thinking that suddenly shifting to using APIs with a GitOps approach is adequate to handle the change to hybrid cloud. It’s not, and can actually be detrimental to DevX. Why? There’s too big a gap—it’s like just doing a long weekly run the day before a marathon. You might start, but you’ll be severely compromising your ability to meet your goal. Even DevOps engineers struggle to maintain a single source of truth and well-maintained reusable repositories.

The solution is to plan for the long term. It’s not realistic to believe that one or two DevOps engineers can be the saviors of a hybrid cloud approach. There are far too many tools, best practices and options—between Ansible, Terraform, Kubernetes and Concourse CI/CD to name just a few—to be managed by a handful of devs, no matter how talented they are.

That’s why the true way to hybrid cloud mastery lies in the ability to get the whole tech team pulling in the same direction, collaborating, upskilling and leveraging their strengths to support the parts that make the whole. This might sound like a pipe dream, but there are companies out there talking the talk and walking the walk.

Start Your Engines

It is futile to tell an organization exactly how to get started since many are already taking the first steps and every organization’s situation is unique. There is more to cover; in the next installment, I’ll be taking a look at areas like FinOps, automation and cloud waste. Hopefully, you’ll see the fast lane is clear up ahead.

May 23, 2022
The Past, Present and Future of OpenStack

OpenStack, described as the world’s most widely deployed open source cloud software, will mark its 12-year anniversary milestone later in 2022. In September 2012, the OpenStack Foundation launched as an independent organization to manage and promote the technology—a watershed moment for a project announced just two years earlier.

Today, with contributions from more than 34,000 people at 550 companies, OpenStack is one of the three most active open source projects, alongside the Linux kernel and the Chromium web browser, according to the group now known as the Open Infrastructure Foundation (OIF). More than 25 million OpenStack cores are running in production worldwide.

It’s easy to forget that only a few years ago many predicted OpenStack’s demise. Initially, OpenStack was positioned as a general-purpose private cloud platform that offered an open source alternative to Amazon Web Services (AWS), but it never stood much of a chance in that matchup.

Then, after OpenStack regained momentum and pivoted to become a platform for telco network function virtualization infrastructure (NFVI), it was rumored that it would be overtaken by the new ‘next big thing’—Kubernetes, the open source orchestration and coordination system for containerized applications.

The Kubernetes-as-OpenStack-killer talk was silly, in retrospect, because the technologies are complementary, not competitive. In fact, more than 70% of OpenStack users reported running Kubernetes on top of OpenStack for container coordination, according to the OIF.

And OpenStack adoption should continue to flourish in 2022. Gartner forecasted that global spending on cloud services will exceed $480 billion this year, up from $313 billion in 2020, as more organizations invest in hybrid cloud: A mix of pay-as-you-go public clouds and private clouds that can offer lower, more predictable operating costs and greater customization. As the hybrid cloud market expands and open source continues to become more firmly entrenched in development and IT organizations, OpenStack is more relevant than ever.

If you’re not familiar with OpenStack, here are 10 things you should know about its past, present and its future.

1. OpenStack began in early 2010 as a collaboration between Rackspace and engineers at NASA’s Ames Research Center in Mountain View, California. Rackspace wanted to rewrite the infrastructure code running its cloud servers and the NASA team wanted to standardize the space agency’s websites. Their original mission was “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.”

2. The first OpenStack design summit was held in Austin, Texas in July 2010, and the project was officially launched at the O’Reilly Open Source Convention (OSCON) later that month.

3. A whopping 80% of OpenStack clouds are used in production, while 13% are under development and 8% are in the proof-of-concept stage, according to the OIF. With that level of adoption, no wonder OpenStack is considered the most widely deployed open source cloud software.

4. An OIF survey showed that nearly half of the organizations using OpenStack have deployed at least 1,000 cores. The breakdown: 29% of organizations have 1,000-9,999 cores, 13% have 10,000-99,999 cores, 6% have 100,000-999,999 cores and 1% have one million or more cores.

5. An enormous corporate ecosystem supports OpenStack, including IBM, Red Hat, HP Enterprise, Intel, Huawei, NEC, Cisco, VMware, AT&T and Canonical, whose Ubuntu Linux distribution is the most popular operating system for OpenStack deployment (used by about 40% of OpenStack clouds globally).

6. OpenStack has a great resource guide available on openstack.org with all kinds of helpful information for developers, including for those new to the platform.

7. One of the main qualities people love about OpenStack is that it’s a modular architecture with interconnected components including, for example, services that expose API endpoints and handle basic cloud functions, a dashboard, SQL databases that store records created by OpenStack services and message queues for facilitating inter-process communication.

8. OpenStack jargon includes several special terms. A tenant, for example, is a user or group of users with isolated cloud resources. (OpenStack is multitenant.) An image is a template containing an OS for instance provisioning. A flavor is a template defining cloud resources for instance provisioning. An instance is a virtual machine (VM) provisioned from the image and flavor. And so on.

9. The platform has expanded through the years to include a panoply of core services, such as the Keystone identity service that manages domains, projects, roles, groups and user accounts, the Glance service that manages the catalog of cloud images, Nova for instance provisioning, scheduling and termination, the Neutron network service and the Cinder block storage service.

10. Beyond these core services, several newer services are seeing increased adoption. For example, according to the OIF, use of Ironic, a project that provisions bare metal, nearly tripled between 2016 and 2021. Others with growing traction include Octavia, which provides load balancing capabilities, Manila for file system sharing between instances and OpenStack Charms which provide rich life cycle management capabilities for services.

As these 10 points show, far from being on its deathbed, OpenStack has survived, sometimes against the odds, and thrived as a unique force in open source and cloud computing. Given its journey over the last 10 years, it will be interesting to see what lies ahead in the next decade.

February 18, 2022