Operations | Monitoring | ITSM | DevOps | Cloud

SOLID is one of the most popular sets of design principles in object-oriented software development. All of them are broadly used and worth knowing. But in this first post of my series about the SOLID principles, I will focus on the first one: the Single Responsibility Principle.

Choosing the right OpenStack distribution is essential to the success of an OpenStack project at every organisation. When selecting one, organisations should always follow certain criteria. Is it possible to operate the considered OpenStack distributions economically? How easy is it to deploy them? Can the organisation upgrade its production OpenStack cloud without affecting the workloads? Everyone planning to deploy OpenStack should ask themselves these questions.

FIPS 140-2 is a set of publicly announced cryptographic standards developed by the National Institute of Standards and Technology. It is an essential part of FEDRamp requirements for many governmental agencies in the US and Canada, as well as their business partners from all around the world. Furthermore, as a well established and verified security standard, an increasing number of large companies and financial institutions are asking for FIPS compliance.

When monitoring highly distributed applications, which might rely on hundreds of services and infrastructure components across multiple cloud-based and on-premise environments, identifying problems and pinpointing the origin of an issue can be challenging. Even if you already have robust monitoring and alerts, your infrastructure and applications will likely change over time, which may make it difficult to reliably detect irregular behavior.

In part 1 we will talk about the industrial applications and benefits that 5G and fast compute at the edge in the form of ‘smart cell towers’ will bring to AI products. In part 2 we will go deeper into how you can benefit from this new opportunity. Part 3 will focus on the key technical barriers that 5G and Edge compute remove for AI applications.

People working in digital enterprises will have no doubt noticed that customers have an insatiable appetite for new features and updates, with next to zero tolerance if digital services are performing poorly – or not at all. To thrive and survive in the digital era, it’s become an imperative for organizations to innovate at an unprecedented pace.

Rancher 2.4 is here – with new under-the-hood changes that pave the way to supporting up to 1 million clusters. That’s probably the most exciting capability in the new version. But you might ask: why would anyone want to run thousands of Kubernetes clusters – let alone tens of thousands, hundreds of thousands or more? At Rancher Labs, we believe the future of Kubernetes is multi-cluster and fully heterogeneous.

In the last month, we’ve seen one of the most dramatic movements in economic activity ever recorded. Many business owners are clutched in the grips of mandatory closures and uncertainty of the future, for their business and for their employees. The tech world has been hit less hard — at least for now. Remote work is second nature to many of us and offering our products in the digital space means we are open for business.

The Vanilla framework has a history of being released very infrequently. Sometimes it has been months between releases, which made the upgrade process often hard and time-consuming. One of the reasons for that was a manual and a quite time-consuming release process. Over several weeks earlier this year, we’ve been working on various improvements that helped us release more frequently and reliably.