Over the last year, we have witnessed a shift in engineering working habits. COVID-19 forced many of us into lockdown. Instead of working from the office, coffee shops, and airport lounges, I found myself mostly working out of my (hastily built) home office. For many of us, this meant shifting back to a workstation over a trusty laptop. Not surprisingly, this did nothing to abate the heated discussion over which computers and operating systems are best for developing software.

Each day, more and more companies consider opting for cloud-based solutions, and they almost always end up adopting them to some extent. While the increasing popularity of cloud services may be a significant factor in accelerating the adoption rate of cloud-based solutions, some individuals remain skeptical of migrating their applications to the cloud due to unfamiliar territory.

5G is in the process of transforming communications technology, enabling never-before-seen data transfer speeds and high-performance remote computing capabilities.

Microservices have become a popular way to architect applications, particularly those that compose functionality from a variety of loosely coupled systems and services. While there are a variety of frameworks and tools for implementing a microservice architecture, it isn’t always clear how to expose native code like C or C++ code within a wider microservice system. That’s where HydraExpress comes in.

In this first section, I’ll provide a quick overview of the business case and the tools you can use to create a Kubernetes ingress API gateway. If you’re already familiar, you could skip ahead to the tutorial section. Digital transformation has led to a high velocity of data moving through APIs to applications and devices. Companies with legacy infrastructures are experiencing inconsistencies, failures and increased costs. And most importantly, dissatisfied customers.

As a team we have spent many years troubleshooting performance problems in production systems. Applications have gotten so complex you need a standard methodology to understand performance. Fortunately right now there are a couple of common frameworks we can borrow from: Despite using different acronyms and terms, they fortunately are all different ways of describing the same thing.

The project used in this article is experimental and changes a lot between commits. Use at your own discretion .

Over the last few days, I have been hard at work writing an up to date comparison of Kubernetes tooling (check out the first and second posts if you haven’t already, which cover tools that help you reproduce issues locally). Going through the sprawling Kubernetes ecosystem and curating the knowledge that would be the most interesting to fellow developers and engineering managers has been no small task. That’s why section 3 will cover the heart of cloud-native development: the IDE.

Over the last few blog posts, I have covered critical elements of developer tooling for Kubernetes and how things are looking in 2021. As we continue to dive into that discussion, we must not forget the process of building container images. Of course, most of us create our images by writing Dockerfiles and building them with the Docker engine. And yet, more and more teams are adopting newer alternatives.