devopsy.kinsta.cloud

Category: Enterprise DevOps

The Right Tool for the Job: Container Edition

I have written about “the right tool for the job” repeatedly. Because (again) we are absolutists in IT. My father was an antiques restorer that dabbled in flipping houses and was rather forceful about the “right tool for the job.” When I left the service and joined IT, it was something of a shock to me that the “right tool for the job” was considered situational.

At the time, there were a large number of Microsoft zealots that loved Visual Basic, and a larger number of non-zealots that preferred C or Java. That was how we got to my first “right tool” article. VB was very strong with regard to UI and record crunching, while to-the-metal was C’s strength and Java fell in between the two—not being perfect at either. So my article stated that. Front-ending databases? Use VB. Writing drivers and low-level processes? Use C/C++. Need a bit of both and easy web page generation? Go with Java.

It is many years later and time for an article that seems just as obvious to me, but in a different IT space. We have all heard of the three architectures: Data center, cloud and mixed/multi-cloud. We have also heard of how, in this rapidly changing world of DevOps, Agile and containers, different organizations are using different deployment methodologies. That’s all good so far. Just as the variety of programming languages available today is a bonus in many ways, so are multiple deployment and operations options.

Where it gets sticky is when people include the “We’re an X shop” in conversations. Or try to do everything under the sun with one of these methodologies. For many of us, container infrastructure is perfect. Use an orchestrator like Kubernetes, build systems and security practices, then not have to care much if the Kubernetes instance it runs on is on-premises, hosted or cloud. Of course you have to care some. Networks have to connect, etc. But most of the work is done.

Then there are the people that have use cases that don’t fit this mold and have not acknowledged that fact yet. This blog is for you. We’ve all heard of companies that have containers whose life expectancy is measured in seconds. Beyond that, I was told about a company that is using containers as message queues. Honestly. Creating a container with a startup command and putting it on a queue. When it is pulled off the queue, it executes that command and then goes away. We’ll call this crowd the “Over Users”.

Finally, we have the people that cannot or will not be moving their systems anywhere. There are a variety of reasons for this, but these are companies that know their applications will continue to run in the data center for the foreseeable future. We’ll call this group the “No Needs”.

For Over Users, that is literally what serverless is for. Create a queue with a (much smaller) call to an API in a serverless environment and be done. Fewer configuration issues, less maintenance, less everything but code. Add a trigger, remove entire OS/network/configuration generation and maintenance. The most likely resistance to this advice is “But we have an investment…” Yes. And for most orgs it is an investment in unnecessary technical debt. Divest. Keep the good parts—a container architecture meant to shuffle through many containers that exist for a short time is well-architected.

For No Needs, before you port everything to containers—which I am generally in total support of—you should consider if you need to; think about if it offers any benefits and what the ROI of such a move is. Honestly. For DevOps-heavy shops or orgs that require highly portable solutions, the ROI of containers is quick and obvious. For orgs whose applications are not changing a ton and are highly unlikely to move anywhere, the ROI is a whole lot murkier. “But it gives us options!” is the most likely negative response to “We don’t need that right now.” But that’s the problem—you have those options now. What it gives you is a shifting of cost from some possible future where it might be needed to today’s already constrained budget. If there is a verifiable need—normally in portability, but any verifiable need—then make the move. Until then, spend that time and money making those apps rock.

You’re doing it. The lights are on and the applications are useful. Use the architecture that makes sense for what you are trying to achieve. Right tool for the job, as my Dad often said (he said it a bit more forcefully when I thought a chisel was a screwdriver, but that’s a different story). Keep rocking it, and stay focused on need.

September 14, 2022
DevOps World 2022: DevOps Tail Wags the Dog of Digital Business

As a methodology for building and deploying applications faster, DevOps has been around for more than a decade. But it’s only now that the methodologies and concepts pioneered years ago are starting to wag the dog of digital business transformation.

Since the onset of the COVID-19 pandemic, digital business transformation has been all the rage. Organizations of all sizes now have a much deeper appreciation for digital processes that enable them to respond more adroitly to changing business conditions regardless of whether the global economy is expanding or contracting.

DevOps Wags the Dog

Not too long ago, ironically, business executives routinely complained that IT simply wasn’t fast enough to keep pace with the needs of the organization. At the CloudBees DevOps World 2022 conference in Orlando next month, it will be made crystal clear that businesses are now adopting concepts originally defined by DevOps pioneers to not only keep pace with the current rate of application development innovation but in many ways actually manage the business itself.

As Mitch Ashley, principal analyst for Techstrong Research, an arm of Techstrong Group, publisher of both devopsy.kinsta.cloud and Digital CxO, recently noted during a podcast, “It’s all about the software.”

Of course, the shift in the relationship between IT and the business it supports has been a long time coming. The debate over how to close the divide between IT and the rest of business has been going on for decades. Even with the rise of DevOps, it’s been more than 11 years since the Jenkins continuous integration/continuous delivery (CI/CD) platform was officially launched. Today, advances in IT are now happening at a rate that many businesses are struggling to absorb.

In fact, what started out as small teams of application development and deployment specialists looking for ways to automate the building and deploying of applications has now evolved into a multi-billion dollar sector of the software industry. And it is driving a level of business transformation that hasn’t been seen since PCs running word processing and spreadsheet applications arrived in the 1980s.

Software is (Still) Eating the World

Just how big an impact DevOps is going to have going forward is still to be seen. It’s still early days as far as pervasive adoption of DevOps best practices is concerned but, as Marc Andreessen once noted, software continues to eat the world. Today, the bulk of that software is being constructed with DevOps best practices in mind and using everything from containers to serverless computing frameworks that make it simpler than ever to add new capabilities to applications both inside and outside of the cloud. The pace at which technological innovations are being made is only going to accelerate.

As such, it’s arguably never been more important for DevOps professionals to gather in person to share knowledge and insights. During the COVID-19 pandemic, DevOps platforms evolved tremendously. The teams that use those platforms exercise more influence than ever within their organizations. The best way to appreciate the value of DevOps has always been to learn firsthand how practitioners are employing those principles to achieve a wide range of strategic business goals.

No matter how large or small the organization, the need to embrace and then continuously improve DevOps processes and workflows is, as always, a pressing concern. Achieving that goal in isolation may be possible, but there’s no doubt in anyone’s mind there’s nothing quite like spending a few days with a few thousand like-minded souls to make attaining those goals a whole lot easier.

Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

September 13, 2022
Database Observability: How to Circumvent your Weakest Link

Today, IT pros field an increasing number of assets they need to monitor to secure systems and understand what’s happening in their database and applications. This is further complicated as organizations adopt hybrid IT strategies and IT pros are tasked with managing tech stacks that span across on-premises and public clouds.

To cut through complexity and create end-to-end visibility into their IT systems, organizations must enact an observability approach.

Monitoring Vs. Observability

When it comes to observability, many think it means the same as monitoring. Whereas monitoring is a verb; observability is a measure of how well the internal states and conditions of a system can be inferred from its external outputs.

When monitoring systems are set up, dashboards are built around certain assumptions that an IT pro may expect will happen. When monitoring databases, teams are building multi-level component IP systems. The algorithms must process that data, and the user interface must interact with it.

However, to make that system highly observable, performance information and other kinds of metrics across all kinds of different endpoints must be incorporated. Especially since IT pros must deal with microservices, mesh, IoT or containers orchestrated through Kubernetes.

How to Monitor Effectively

In the past, IT pros would typically monitor a SQL Server or even other database platforms like PostgreSQL or MySQL. In this new era of observability, on the other hand, IT pros need to do something different with the front-end code with regard to the different kinds of algorithms processed against that data set. Typically, developer teams would write the code, but there wasn’t anything written in that code to send out debug signals.

Today that has changed. To make sure our systems are fully observable (because we can’t anticipate all possible problems!), we must log different steps to keep track of the many moving pieces. Organizations must collect as much of everything as possible. The more data, the more information organizations have about what’s happening in their application, from the database through the virtualization or containerization layer to the virtualization host or the orchestration to the bare metal. If organizations can get visibility into those elements, we can enable our systems to be fully observable and more easily diagnose any problem or anomaly that happens.

An Observability Approach

When using the observability approach, high-level dashboards are handy. They can help IT pros roll up everything that’s happening and get to a root cause analysis if there is a problem. However, sometimes there’s not a specific problem; there’s just a general performance issue. With observability platforms, teams can quickly discover, map and understand dependencies in ways that make it easier to achieve and maintain service level objectives (SLOs).

As IT teams increasingly distinguish between merely monitoring IT environments and achieving observability, they can proactively surface anomalies using machine learning algorithms and other forms of data science. And the depth and insight that can be applied to managing IT is increasing dramatically. Observability is quickly becoming table stakes for any modern IT organization.

September 12, 2022
Governing Microservices in an Enterprise Architecture

Software development strategies continue to evolve to meet changing business needs. There has been a lot of discussion of digital transformation recently, and custom software development is driving much of that transformation. Agile software development and DevOps have become the norm as companies strive to develop better, faster, more flexible applications. Microservices offer the next step in the evolution of enterprise application development.

DevOps separates developers (Dev) and operations (Ops) into teams collaborating on new enterprise solutions. Similarly, microservices expand on the idea of specialization, creating specialized app building blocks to build new applications. Microservices enable an even shorter development time and greater agility. They also present a new set of challenges for enterprise architects who must oversee these microservices and govern the development process.

A Series of Building Blocks

If you are unfamiliar with the term, microservices are a series of building blocks assembled to make new applications. Just as agile software development is a philosophy as well as an approach to development, microservices are an architectural and organizational approach to enterprise software development.

The value of microservices is in the building block approach. With old-school monolithic services, you must design and maintain a single application and its various components to act as a unit. Change or remove one element, and the entire application needs to be rewritten and tested, which is costly and time-consuming.

With microservices, the individual services function as self-contained functional units that can be mixed and matched as needed to create different custom applications. Using microservices is faster, more versatile, and more reliable, simplifying the delivery of large, complex applications.

Microservices also are built around business capabilities so that business application components can be created in tandem with DevOps agile enterprise development. And with different teams working to create smaller components, there is less chance of having a single point of failure.

No-code/low-code development solutions are placing the power of microservices in the hands of business users. Domain experts in product development, finance, logistics, and other departments can use a drag-and-drop interface to develop microservices that can then be incorporated into other applications. In short, microservices gives subject matter experts the tools to create custom apps that can be added to the enterprise architecture.

The Pros and Cons of Microservices

Microservices offer businesses and enterprise architects several benefits. Deployment of new applications is faster, and you have more flexibility to adapt to changing enterprise and business needs. They also scale quickly and make it simple to add new features to existing applications. And microservice elements are reusable.

Of course, there are challenges as well, including governance. As the architecture evolves, there are more components to be managed. In addition to different departments building microservices, the DevOps team is still responsible for overseeing application development and solving everyday problems. Having a mature engineering culture helps automate app development and track microservices, providing the necessary guidance to ensure app development supports larger business objectives.

Microservices also create architectural overhead. Applications must be documented to ensure ongoing business value. Trying to document everything, however, creates delays, so the documentation is never current with the stage of development. The challenge is providing enough documentation to be useful without delaying ongoing software changes.

This requires a new enterprise application mindset. DevOps needs to closely watch autonomous teams to control development and ensure they support larger corporate goals. The use of no-code/low-code tools also could result in shadow IT not being sanctioned by the network architects or DevOps.

Governing Development

One of the market forces driving microservices adoption is the need for “outside-in” application development. All microservices should be developed at the request of a customer, whether that customer is inside or outside the organization. Customer requirements continually change, and microservices can accommodate those changes faster and more efficiently.

Microservice development works best in a domain-driven architecture, which models the applications based on the organization’s real-world challenges. A domain-driven architecture assesses the enterprise infrastructure in light of business requirements and how to fulfill them. Most organizations already have a domain-driven design strategy in place that maps the architecture to business capabilities.

Bounded Context is a strategy that is part of domain-driven design. Autonomous teams responsible for microservices are formed around areas of responsibility such as inventory management, product discovery, order management, and online transactions, i.e., bounded context. The domain expertise resides within the team, so the enterprise architect’s responsibility is to guide development to align with strategic goals, balancing immediate needs and future business objectives.

When governing microservices as part of the enterprise, applying the C4 model for software architecture—context, containers, components and code—makes sense. The context defines the relationship between the customer or end user and the application. The container represents the microservice itself and how it is packaged to serve as an application building block.

The secret to governing microservices in any enterprise architecture is to map business capabilities to the digital infrastructure, then promote the vision behind the enterprise architecture as well as the guidelines to achieve that vision. Focus on organization-wide objectives for both business transformation and IT strategy. Educate the stakeholders on when to involve the enterprise architect. Also, try to anticipate topics beyond the perspective of the DevOps team and focus on the big picture—what is the long-term business strategy and how do microservices contribute to that strategy?

September 7, 2022
Focus on What You Can Do
Here we are in the second half of 2022 and the writing is on the wall. No matter how much budget you have had in the last few years, be it large or small, it is going to shrink. This is cyclical, and should not be a surprise. The amount of budget shrinkage may be larger, but budgets have fluctuated since before any of us were born. I would argue that they fluctuate in IT more than any other part of the business, simply because much of IT is still viewed as overhead and, honestly, we’re expensive. Our salaries, our equipment, our software and our SaaS cost a lot, making them juicy targets when corporate belts have to tighten.

So let’s talk about what to do for the next year (or five) while things finish sinking and then start to recover. New projects will be few and far between but improving what an organization already has deployed costs little. And the “Do it now” mentality of Agile and DevOps has helped in a ton of ways, but honestly leaves a trail of “could be better” implementations behind. Implementations that you can use iterations to improve. My “Look at me! I’m a pundit too!” recommendations would be:
1. Review
2. Consolidate
3. Evaluate
4. Iterate
Review what you have across the entirety of the org. I’ve made this recommendation before—possibly even as recently as six months or so ago—but it bears repeating. We had a phase where teams and even individual developers made choices for a product or product line. This created a lot of overlap. List tools used at each step of the DevOps chain; for each project/DevOps toolchain.

Consolidate. In the short term, costs need to go down and be sustainable once they do. Better to eliminate software or SaaS redundancy than that other kind of redundancy. This step also means simplifying the corporate DevOps infrastructure. So compare products doing the same job and choose one. This isn’t as easy as pundits make it sound; each product brings something unique to the table. But you have to make the hard choices and reduce maintenance costs and hours.

Evaluate. This is not hard to believe for anyone who has worked at multiple organizations, but in case anyone missed it, no environment is perfect. They all have strengths and weaknesses. The best staff in the world, given unlimited time and budget, will do at least one dumb thing. Then after a year, a lot of the smart things they did look dumb too—because the market and/or the technology have moved on. Look at each step of your environment—from which libraries/modules are included to the deployment steps and run-time monitoring. Figure out what could be better and then organize by cost and schedule them out.

Iterate. Start back at the review stage and do it again, because if you think you got it all the first time, you’re wrong. Or you are a heck of a lot smarter and more thorough than the rest of us, one of the two.

This will keep the team improving the corporate IT environment while outside factors keep budgeting down. This cycle is different from others because it is unclear how IT staffing will be impacted. While it is looking more and more like IT will have the same impacts as usual, at the start of this downturn that wasn’t at all clear. Either way, improving the environment without million dollar projects is useful in hard economic times. My company is currently reconsidering our choice of frameworks and how we’re still using a test tool as DevOps management tool, for example.

Keep the lights on, keep rocking the servers and apps running the org and focus improvements around factors you can’t change. But keep making it better, no matter what’s going on around you.
September 7, 2022
How to Go Multi-Cloud: A Simple Three-Step Approach
Odds are your business already uses cloud technology for automation, cybersecurity, IT infrastructure updates and other purposes. But you don’t have to stick to a single cloud server or provider. In fact, you can take advantage of multi-cloud strategies for your organization and reap the benefits for years to come.

That said, multi-cloud adoption and optimization can be tricky, especially if you don’t have a plan in mind from the get-go. Today, let’s break down a simplistic yet effective three-step approach to go multi-cloud without running into major problems.

Step One: Map Your Cloud Zoning Policy

Your first major step should be to map out your cloud zoning policy and plan. In a nutshell, the cloud zoning choices you make can impact your commitments, costs, and even the eventual functionality of the multi-cloud setup.

By mapping out your clouds, you also map out which processes and applications will run on each individual cloud server or provider. In essence, you decide what gets locked into one cloud, what data has to be ported between clouds and what applications must run on multiple clouds simultaneously.

Need an example? A cloud zoning policy might cover whether you keep your web surfing or data analytics on separate cloud providers or on the same cloud servers.

You should map your cloud zoning policy regardless of whether you do the setup or hire a service. In the latter case, offering a read-to-go zoning map will make the service’s job easier and minimize the possibility of mistakes and/or hiccups.

How to Determine Optimal Cloud Zoning

Naturally, figuring out how to optimize cloud zoning can be difficult. The best way to do this is to determine your special focus areas. Alternatively, consider how you want your multi-cloud strategy to best benefit your organization.

Say that you want to guarantee 100% uptime for your customers or visitors, even if your service goes down or if you experience a data breach. In this case, you can set up your cloud zoning strategy to balance the data load across multiple clouds at the same time.

Or say that you want to make sure your users have global availability 24/7/365. In that case, you can set your cloud zoning policies to ensure that users can access your data or websites from anywhere around the globe at any point.

Essentially, figure out what matters most to your organization–and what you want the most from multi-cloud optimization–and zone your cloud applications and policies accordingly.

Step Two: Architect the Multi-Cloud Environment

The next major step is to architect your multi-cloud environment. This involves looking at the high-level design of the environment and creating a rock-solid foundation for multi-cloud servers.

At this stage, you should have at least some idea of how your business will grow and how the multi-cloud environment will assist with its scalability and resource needs. You need to know:
- Where your data science and machine learning applications need to be
- Where your product application serves from
- Where your data warehousing takes place
- Where cloud security is run from
- How each of those functions grows alongside the others
In the architecture phase of a multi-cloud setup, you need to figure out which projects and apps are so-called “cloud agnostic.” Cloud agnostic projects and applications don’t have to be portable; because of this, they can lean on managed services or proprietary IT infrastructure from your organization.

How to Set Up an Ideal Multi-Cloud Environment

To reap the most benefits out of a multi-cloud environment, you should adopt a containerized and flexible approach. Not only is this cost advantageous, it also allows you to set up your multi-cloud environment with as much versatility as possible.

If you architect or plan your multi-cloud environment so it is containerized and flexible, you can work with practically any infrastructure-as-a-service (IaaS) provider. Therefore, you can transition to different cloud hosts or service providers whenever necessary according to your budget or other factors.

To do this, be sure to perform heavy forecasting. You need to know how much data storage your computing will require, the database utilization your organization will need, the number of computer nodes you’ll likely require and so on.

As a side bonus, containerization in your multi-cloud setup means that if one server or process goes down, the others are less likely to fail from a cascade effect as well.

Step Three: Prep for Contracts and Forecast Costs

The last step in going multi-cloud for your organization is handling the financial aspect of the process. You need to prepare for contracts and commitments alongside forecasting costs.

Forecasting is critical in this phase because you’ll prepare for contracts and select different cloud services. Because of this, you need to understand how flexible your budget is relative to your infrastructure requirements.

Specifically, you’ll need to match the costs to every multi-cloud forecast and build your overall resource and money consumption budget. Basically, you need to know:
- How much you’ll likely spend on multi-cloud processing and services
- Whether you need certain features, such as website monitoring tools like Visualping
- Whether your budget can take that forecasted strain
If the answer to the third question is “no,” you may need to go with a more affordable service or adjust your multi-cloud environment architecture and zoning policies. By forecasting costs ahead of time, you won’t run into a disaster scenario where you already have your multi-caught environment up and running but can’t pay for it, forcing you to scramble as a result.

Minimize Commitment Risk

Luckily, there are ways to minimize commitment risk and avoid budgetary disasters. For example, you can use commitment buy-back guarantees, or you can use flexible commitment options like that from AWS. These include computing savings plans, which consume cloud resources in any region and which result in very low savings rates.

Of course, you can and should also practice very careful budgeting and accounting. Once you ensure that your commitment costs and savings are attributed to the right services, server resources, applications, etc., you’ll have a better idea of how much money and other resources you really need and avoid over-committing to a provider that is too expensive.

Then you can further avoid commitment risk when planning your migrations of applications between different vendors carefully. Budgetary costs can skyrocket if migrating applications and data between vendors take longer or result in unexpected complications. Therefore, you should make sure that your migrations go quickly and easily or that a cloud service provider offers assistance during this phase (possibly as part of a deal to get you to sign with them in the first place).

Wrapping Up

As you can see, you can transition your organization to multi-cloud in a matter of months. But even if you follow the above steps perfectly, remember that you won’t optimize your commitments, performance and costs up to 100%. Still, you can prep your organization for long-term success and multi-cloud benefits with the right preparation and planning.

With the right cloud services provider, you’ll gain additional assistance and support throughout this process and be able to take advantage of the extra resources from a multi-cloud setup quickly and easily.
September 6, 2022
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Monster.com

Google
Mountain View, CA
Software engineer
$167,149

ZipRecruiter

Deloitte
Boca Raton, FL
DevSecOps Engineering Lead
$145,000 to $241,000

Dice.com

gWorks
Omaha, NE
DevOps Manager
$150,000 to $180,000

SimplyHired

Cubic Corp
Ashburn, VA
DevOps Engineer
$87,000 – $120,000

Indeed.com

Blue Cross and Blue Shield of North Carolina
Remote
DevOps Engineer
$94,600 to $120,000

September 6, 2022
Build Once, Deploy Anywhere

This late in the game, it seems stunning to me that I have to write this, but there are plenty of you who aren’t there yet—so let’s try a different approach.

A huge part of DevOps is reducing redundancy. We have cut the fat until it hurt, then refocused and cut some more. There is a blog here about burnout, but we’ll save that for another day. The point is, we don’t do the same thing over and over unless there is a quantifiable benefit—like rebuilding and testing new iterations or spinning up base images to start a new project.

We insist that our applications run in as standardized an environment as possible, with images from a repository and standardized software installed.

And then we promptly put it into a unique environment where deployment is completely different. Yes, I’m talking about which cloud or which data center; if it’s deployed via a data center, then hardware, virtual machine or container? The work to standardize the important bits and leave the less impactful bits to teams to decide has been astounding on the Dev side of DevOps (for those new here, what I call DevOps), but have been far less effective in DevOps. Even companies that claim to be pure cloud generally have two or more cloud vendors, each of which is doing things differently.

So, with all of that said, I can say what I should not have to say after all of these years:

Make containers standard. I don’t care which flavor and management tool you use, but add in that portability layer. It will protect you from a future where your preferred hosting environment (be it cloud, local or hosted) becomes hostile or overly expensive—or simply ceases to exist. And it will standardize the rest of your DevOps processes. Yes, your preferred cloud vendor offers Kubernetes, and no, that’s not sufficient. Kubernetes offerings today are like Microsoft in the 1990s. Embrace and extend to build the lock-in barrier higher. You do get some great functionality from the cloud vendors I pay attention to, but processes become non-standard. Better to limit platform-specific work to “spin up a server” and have everything else be reusable whereever you are deploying. The benefits here are far-reaching; there will be configuration and security issues that are different when you move from cloud to cloud or cloud to data center or data center to cloud, but the core of DevOps will remain standardized. There are tools to help with baseline cloud security and risk management, so those in addition to using Kubernetes as a portability platform will make current work less onerous, and massively increase portability from deployment location to deployment location.

You’re short of staff. It does not take a rocket scientist to predict that this situation will not change. Adopt the things that will reduce your workload—like DevOps standardization on Kubernetes (or OpenShift or whatever) as a deployment platform—and keep rocking it. You can’t wave your hand and get more staff or hours in the day, but you can implement containers as the sole deployment option to save time. And use those hours to solve other company problems—because that’s what we do, solve problems for the business. And keep smiling, because you’re rocking it. If you weren’t, they’d find someone who could.

August 31, 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
DevOps World 2022: Why DevOps Needs a Remix

I was checking out the DevOps World website today to gather information, as Techstrong.TV will be live streaming from the show in Orlando, Florida September 28 and 29, 2022. The theme for this year’s DevOps World is “DevOps Remix.” The more I thought about it, the more it became clear that DevOps Remix is a perfect theme for DevOps World—and for DevOps as a practice.

What does a DevOps remix mean? Well, I won’t pretend to speak for CloudBees, the event’s host, but here’s what they have on the DevOps World website:

“The tempo will be faster, more energized, and more harmonious in keeping with the accelerated pace of the DevOps transformation. Progressive delivery, value stream management, and everything from AIOps to XOps are now part of the mix creating new paths, new beats, and faster code releases.”

That’s what a DevOps remix means to them; here’s what DevOps remix means to me.

I believe a DevOps remix speaks to the continuing maturation of DevOps as a methodology and a practice and to the DevOps market and community. DevOps is no longer nebulous; there’s no longer a question of “Is it real or not? What exactly is DevOps?” kind of thing. No, DevOps is very much a player in the software development life cycle (SDLC). So much so that as digital transformation continues to involve software in places it hasn’t been before, DevOps is helping it get there. DevOps is going places it has never been before.

Techstrong Group’s own DevOps Experience event, now in its fifth year and coming this November, has a similar theme: DevOps Everywhere. DevOps, as part of the CI/CD pipeline, still exists, but DevOps today is so much more. To be successful today, organizations large and small (but especially enterprises) need to take DevOps fundamentals and implement them whenever and wherever they are building, deploying and managing software.

Another reason the idea of a remix is so appropriate is that, as the world emerges from COVID-19 lockdowns, there is something comforting about revisiting in-person events, conferences and training—the ‘normal’ industry activities and events that happened before the pandemic. For those of us in the DevOps space, DevOps World is one of those things. I have been going to DevOps World since before it was even called DevOps World—when it was Jenkins World. There’s a remix for you!

DevOps does need a remix, and it’s happening right now. While I do think it’s great to be able to resume many of the same activities, go to the conferences and get training, I don’t expect this year’s DevOps World to be like previous editions in San Francisco or online. That’s part of what makes it such a terrific event—a mix of the old, the new, the tried and true, the cutting edge and the familiar. So, if you consider yourself a member of the DevOps community and can make it to Orlando at the end of September, you should consider being part of the DevOps Remix.

This year, DevOps World will be held in Orlando, Florida, at the World Marriott Center. The CloudBees folks have published a discount code, DW22, to use when registering that should save you some money on a full ticket for the show, including some training, some great sessions and interactive activities. We can’t wait to see you there for the DevOps Remix!

August 30, 2022