In the previous blog, my colleague David Bericat discussed why Internet of Things (IoT) architecture should be built with open source. One of the core components of end-to-end IoT architecture listed in that article was an intelligent IoT gateway that can process data near its source in near real time and filter/prioritize the actionable data. In this article, we’ll explore the reasons behind the need for an intelligent IoT gateway.
Designing, implementing, securely operating, managing and maintaining IoT projects is complex. In fact, there are entire organizations whose sole mission is solving a specific problem within an IoT architecture. The problems that can be found within such architectures can range from connectivity to figuring out where apps live.
Computing styles ebb and flow. The centralized mainframe in the glass room largely ebbed in favor of the PC revolution that itself gave way, at least in part, to the web and the cloud. Today, we have a complex mix of massive datacenters, Internet-of-Things (IoT) devices, and sophisticated computers we can hold in the palm of our hand.
The TripleO project is transitioning from bare-metal to containers-based OpenStack deployments. This transition started almost a year ago and it was split in two phases. The first phase targets Docker as the container runtime, whereas the second phase moves these container images to Kubernetes. In this post, we will focus on the second phase of the transition–specifically, how to deploy these services.
In January of 2015, the Open vSwitch (OVS) team announced they planned to start a new project within OVS called OVN (Open Virtual Network). The timing could not have been better for me as I was looking around for a new project. I dove in with a goal of figuring out whether OVN could be a promising next generation of Open vSwitch integration for OpenStack and have been contributing to it ever since.
Network Functions Virtualization (NFV) is revolutionizing the telecommunications industry. That word, “revolution”, is often misused, but it is appropriate for the transformation of core network services from physical to virtual infrastructure.
Back in January 2016, Ansible delivered the first integration of network support into the Ansible 2.0 code base. The initial introduction of network support was originally conceived to help operators focus on being able to execute configuration changes on network devices with a set of imperative-based configuration modules.
As a result of long-term cooperation with the Faculty of Electrical Engineering of Czech Technical University, especially in the area of teaching, Red Hat has opened an open source laboratory directly on the University grounds on October 26th, 2016.
The reason behind the Brno office’s growth in the last decade is predominantly the capability of local universities to produce talented people, with world-class skills. The success of the university program in Brno suggests that this system can be replicated in other cities with similar characteristics (such as Prague). Cooperation with universities in Prague is a natural next step to finding new talent in an area that Red Hat is now equipped to cover with engineer activity.