frameworks

Istio Route Rules: Telling Service Requests Where to Go

Istio Route Rules: Telling Service Requests Where to Go

OpenShift and Kubernetes do a great job of working to make sure calls to your microservice are routed to the correct pods. After all, that’s one of the raison d’être for Kubernetes: routing and load balancing. What if, however, you want to customize the routing? What if you want to run two versions at the same time? How do Istio Route Rules handle this?

[This is part two of my ten-week Introduction to Istio Service Mesh series.  My previous article was Part 1: Introduction to Istio; It Makes a Mesh of Things. Want to see this in a video? Check out the video edition here.]

Continue reading “Istio Route Rules: Telling Service Requests Where to Go”

Share
Angular, React, and Javascript framework fatigue

Angular, React, and Javascript framework fatigue

Introduction

I’m an avid follower of Hacker News and many various programming related subreddits. There is a constant flow of posts where the author expresses fatigue, weariness, and many times backlash at JavaScript and the plethora of front-end frameworks. Much of this conversation surrounds React and Angular and then other frameworks such as Mithirl, Meteor, Ember, Vue and others (and there are many others). The conversation many times will go X is the best framework, or X is not the best framework Y is, and the reasons, or much consternation that X or Y is short lived and will be superseded soon by Z. Then many times it is just complaining about X, Y, Z, and frameworks and JavaScript in general.

I’d like to offer a few thoughts counter to this outcry of fatigue in the industry.

Overview

What if you viewed the churn and the constant creation of frameworks and libraries as a positive growth factor. What if you viewed the JavaScript ecosystem as parallel to the machine learning ecosystem.

Continue reading “Angular, React, and Javascript framework fatigue”

Share