Running a Single Page App and can’t wait for Lambda@Edge? Here’s an alternative*

* Yes, I do understand that Lambda@Edge will provide a completely different level of scale and performance, and is an industrialised managed offering. None the less, what’s described below could serve many use cases just fine. 😉

With that, on to it.

There’s no point arguing that Single Page Apps (SPAs) are in vogue. One of the approaches to SPAs is to move business logic into the client, and leverage a range of API-based services to provide needed server-side functionality. Here’s a very good argument presented on this topic: Joe Emison – 10X Product Development.

A side effect of following this pattern is your SPA code ends up on a server that only knows how to serve your static client content (html / js / css / images). This may present a problem when you try to integrate your SPA with another stand-alone application, for example, blog hosted by WordPress.

Let’s have a look in a bit more detail, followed by what can be done about it.

NSX-v with Brocade 6740 Hardware VTEP – additional considerations

With Hardware VTEP being implemented in, well, hardware, how things work depends on capabilities of the underlying chipset. This means that when we design solutions using these products, we need to keep these capabilities in mind and configure things accordingly.

In this short post I’ll cover a situation we’ve encountered at one of our customers where things “should” have worked but didn’t, and what was the reason for that.

Deploying Brocade Virtual Traffic Manager cluster in AWS through a CloudFormation template

Last time we’ve talked about the concept of Infrastructure as Code (IaC), and introduced two most prominent tools in the space, AWS CloudFormation and Hashicorp Terraform.

In this post, we’ll have a look at an AWS CloudFormation template that you can use to deploy a cluster of 2 x Brocade Virtual Traffic Managers with WAF into a new AWS VPC; what makes up that template; and how it all works.

We will take things quite slowly here. Some basic understanding of automation and/or scripting/programming will help, but not strictly necessary.

If on other hand you’re already well-versed in AWS CloudFormation but still interested in automating deployment of Brocade Virtual Traffic Managers in AWS, feel free to jump straight to the GitHub repo, and optionally read the vADC EC2 Instances section below.

Please note that this is work in progress and the code you’ll find there has no official support at this time, but rest assured, it is coming! 🙂

Validating HW VTEP deployment for integration with NSX-v

This post is next in series on using HW VTEPs with NSX-v. You can find earlier posts here: 1, 2, and 3.

Today we’ll look at a couple of choices you’ll need to make when deploying Brocade’s HW VTEP, and then check if our configuration is correct before linking it with NSX-v next time.

Planning deployment of a Hardware VTEP with NSX for vSphere

In a couple of previous blog posts, we’ve looked at the use cases for HW VTEPs. Now, let’s start digging a bit deeper.

In this instalment, we’ll have a look at what things you need to think about when planning your Hardware VTEP deployment. While I’ll be using Brocade VCS as the HW VTEP for this post, some of this info should be applicable to other Vendors’ solutions.